Date: Thu, 18 Jan 1996 13:09:33 -0700 From: Nate Williams <nate@sri.MT.net> To: pete@pelican.com (Pete Carah) Cc: current@freebsd.org Subject: Re: pppd route/proxy problem Message-ID: <199601182009.NAA12968@rocky.sri.MT.net> In-Reply-To: <m0tczOi-0000SaC@pelican.com> References: <m0tczOi-0000SaC@pelican.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I think this is an old problem that has never been resolved, but I may > have some narrow circumstances now, and some idea what to do about > part of the problem. I've posted all of the details in the past, I even know the high-level 'how' needed to fix the problem, and know the file where it happens in the kernel but after staring at the code for days I'm still no better off. I *really* would like a networking code expert to help me out, but no-one is interested. [ Description deleted ] > 1. Proxy arp entry should nuke (or just overwrite?) any incomplete > entry whether or not the incomplete entry has timed out. Actually, it's not a proxy arp problem specifically. Basically, the routing table has three different types of 'arp' entries, and the priority of the entries is as follows (again, I may be confusing the names, but the results are obvious): 1) ARP entries from the ethernet layer 2) ARP entries from external routing protocols 3) Proxy arp entries from routing protocols So, if you have a un-resolved ARP entry from the low-level layer, it (wrongly) takes precedence over a resolved entry which came from the routing protocols. > 2. Somehow an incomplete can get written into the table with no > expire time (we've had them last days); I presume that this is > a race with the pppd termination. Actually, that entry will time out within about 15 minutes *as long* as no new packets are being sent to the machine generating them to keep them alive. I've checked this one out to be sure. > 3. It would be nice to have a flag (-v?) for arp -a that would > print out *all* the arp info including expire time or lack of it... I'm not sure this information is even gettable in the kernel, and I don't see how it would be that helpful. If you know when it times out how will that help you? > Maybe this can point the way to some of the other routing table > problems with pppd that people have remarked over the years... Most of the other pppd routing problems people are having are due to not understanding the routing protocol. However, there is a work-around for this bug that I've come up with, but it's an ugly hack. (It's also been added to NetBSD's rarpd software) I'm using kernel pppd, but this would work fine with anyone who uses hard-coded IP addresses for login. For the PPP login shell, I have the following script. /etc/ppp/Login-remhost ------------------- #!/bin/sh PATH=:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin export PATH mesg n stty -tostop /etc/ppp/arp-hack -d remhost > /dev/null /etc/ppp/arp-hack -d remhost > /dev/null exec pppd `hostname`:remhost debug proxyarp ----------------------------- The command /etc/ppp/arp-hack is a version of arp that has been hacked to output all messages to stdout. I couldn't get the version of /bin/sh in FreeBSD to output both stdout/stderr to /dev/null, so this is probably un-necessary. I did this to avoid having any error messages from 'arp' confusing the incoming PPP process. I am also running it twice just in case the original proxy-arp entry didn't get deleted, so doing it twice makes sure all of the arp entries are deleted. If no-one helps me debug the protocol, I *may* actually hack this into both user-ppp and kernel-ppp if proxyarp is called. Basically, I'd do a couple arp deletes just before the entry is added into the table. I'm going to write all of this up in the handbook sooner or later, but until then it's just bits and pieces. Again, if *any* of the network folks will work with me on this I can give them crash dumps, ways of easily repeating this, etc.... Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601182009.NAA12968>