Date: Tue, 24 Mar 2009 13:01:12 -0700 From: "Li, Qing" <qing.li@bluecoat.com> To: "Luiz Otavio O Souza" <lists.br@gmail.com> Cc: Brett Glass <brett@lariat.net>, Qing Li <qingli@freebsd.org>, net@freebsd.org Subject: RE: Problems with inward PPTP tunnel Message-ID: <B583FBF374231F4A89607B4D08578A43039B2E9A@bcs-mail03.internal.cacheflow.com> In-Reply-To: <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> <B583FBF374231F4A89607B4D08578A4303928C88@bcs-mail03.internal.cacheflow.com> <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20 > Yes i've read your patch, but i don't understand what you are meaning... > and yes, changing the definition of rt_Update is not my first intention, > but it is the way i've found to fix this. >=20 > Backing to the patch... The rt_Update need the ifp and ifa information > to correctly update the route, and this is available only in > route_UpdateMTU (wich read the current route table). >=20 > You are suggesting that this information could be found at > sa[RTAX_GATEWAY] (if sa[RTAX_GATEWAY]->sa_family =3D=3D AF_LINK) ? And = i=20 > don't need to pass the sa[RTAX_IFP] and sa[RTAX_IFA] ? >=20 Yes. The concept should be similar to the handling code for route insertion=20 where one does, e.g.: route add -net a.b.c.d/24 -iface em0 Joe Marcus verified my patch in his environment. My suggestion is for you to try it out and see if that patch also fixes whatever problem that you are=20 running into. Thanks, -- Qing
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B583FBF374231F4A89607B4D08578A43039B2E9A>