From owner-freebsd-net@FreeBSD.ORG Sat Feb 13 02:40:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F54C1065672 for ; Sat, 13 Feb 2010 02:40:36 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0223A8FC08 for ; Sat, 13 Feb 2010 02:40:35 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1D2eZpr018172; Fri, 12 Feb 2010 18:40:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 18:38:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing problems on VPN servers running FreeBSD 8.0-RELEASE Thread-Index: AcqsU3oYOecr5BRKQrS/K5ipNFfH0wAAi7eE References: <201002122133.OAA16835@lariat.net> <25ff90d61002121409m6a9d7639qf254a754644a60ca@mail.gmail.com> <201002122240.PAA17544@lariat.net> <201002130004.RAA18387@lariat.net> <201002130041.RAA18639@lariat.net> <201002130222.TAA19338@lariat.net> From: "Li, Qing" To: "Brett Glass" Cc: Luiz Otavio O Souza , net@freebsd.org Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:40:36 -0000 Okay, well, I need to pack. So will get back to it in a week. -- Qing -----Original Message----- From: Brett Glass [mailto:brett@lariat.net] Sent: Fri 2/12/2010 6:22 PM To: Li, Qing Cc: net@freebsd.org; Li, Qing; Luiz Otavio O Souza Subject: RE: Routing problems on VPN servers running FreeBSD 8.0-RELEASE =20 This patch seems to have had a positive effect on ppp(8)/PoPToP,=20 though more testing is needed. However, It appears that mpd uses=20 arp(8) rather than the socket interface to set up proxy ARP. Here's=20 the code (from the file iface.c in mpd 5.3): if (Enabled(&iface->options, IFACE_CONF_PROXY)) { if (u_addrempty(&iface->peer_addr)) { Log(LG_IFACE, ("[%s] IFACE: Can't proxy arp for %s", b->name,=20 u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)))); } else if (GetEther(&iface->peer_addr, &hwa) < 0) { Log(LG_IFACE, ("[%s] IFACE: No interface to proxy arp on for %s", b->name,=20 u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)))); } else { ether =3D (u_char *) LLADDR(&hwa); if (ExecCmdNosh(LG_IFACE2, b->name, "%s -S %s %x:%x:%x:%x:%x:%x pub", PATH_ARP,=20 u_addrtoa(&iface->peer_addr,hisaddr,sizeof(hisaddr)), ether[0], ether[1], ether[2], ether[3], ether[4], ether[5]) =3D=3D 0) iface->proxy_addr =3D iface->peer_addr; } } When this executes, I do not get an error message but nothing=20 actually happens. Must something be done to arp(8) or to mpd to=20 make the code above work? --Brett At 07:03 PM 2/12/2010, Li, Qing wrote: > > > > It'd be good to resolve this as soon as possible, because I have > > two clients who need servers installed this weekend. (They wanted > > them last week, but I was trapped away from the office by a >snowstorm.) > > > >Luiz Otavio and I have been discussing offline about an issue with >the file /usr.sbin/ppp/arp.c in the past week or so. The ARP related >code in arp.c was missing a flag bit called "RTF_LLDATA". > >Luiz Otavio and I just had a debug session on your issue. He was >able to reproduce it, and due to the missing RTF_LLDATA bit, the >proxy-arp entry made it into the routing table, which was not >suppose to happen. Since there is already a PPP host entry >for the remote end, you get the FILE EXIST error. >I believe the reason was due to its confusing the kernel code as >if mpd is installing a routing entry as in >"route add x.x.x.x/y -iface em0". > >So you can wait for Luiz's patch, or you could do it yourself >and try the following 1 line fix: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D=3D=3D >-- usr.sbin/ppp/arp.c (revision 203430) >+++ usr.sbin/ppp/arp.c (working copy) >@@ -119,7 +119,7 @@ > return 0; > } > arpmsg.hdr.rtm_type =3D add ? RTM_ADD : RTM_DELETE; >- arpmsg.hdr.rtm_flags =3D RTF_ANNOUNCE | RTF_HOST | RTF_STATIC; >+ arpmsg.hdr.rtm_flags =3D RTF_ANNOUNCE | RTF_HOST | RTF_STATIC | >RTF_LLDATA; > arpmsg.hdr.rtm_version =3D RTM_VERSION; > arpmsg.hdr.rtm_seq =3D ++bundle->routing_seq; > arpmsg.hdr.rtm_addrs =3D RTA_DST | RTA_GATEWAY; >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D=3D=3D > >I had to reintroduce the RTF_LLDATA flag for compatibility in r187094 >back >in Jan. 2009. This change appears to be missing from the ppp port. > >Please give the above fix a try and see if it resolves your issue. > >-- Qing