From owner-freebsd-hackers Fri Oct 27 10:38:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07307 for hackers-outgoing; Fri, 27 Oct 1995 10:38:30 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07298 for ; Fri, 27 Oct 1995 10:38:24 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA04408; Fri, 27 Oct 1995 11:40:38 -0600 Date: Fri, 27 Oct 1995 11:40:38 -0600 From: Nate Williams Message-Id: <199510271740.LAA04408@rocky.sri.MT.net> To: hackers@FreeBSD.org CC: "Garrett A. Wollman" Subject: ARP and routing table problems Sender: owner-hackers@FreeBSD.org Precedence: bulk Here's the situation. My ISP happens to be a FreeBSD box sitting at the office. This box is on it's way to becoming our router/terminal server/DNS/firewall box, but it's more than adequate to the task as a nicely loaded 486/66. I've been setting it up this week to accept both SLIP/PPP connections from the different machines we have locally, and of course the best way to do this is with my box at home. So, my box can login as both a SLIP host, and a PPP host. I'm using kernel mode SLIP/PPP for the dialin lines to avoid any extra overhead. I have two problems, but they may be related. First of all, if I make a SLIP connection to the box (which works fine), and then make a PPP connection to the box the routing table is in a manner where it will try to route all the traffic to my box via the now-dead slip connection, even though the interface is marked down. This is no good since I'm validly logged in via the SLIP interface. It's obvious that I'm using the same IP address for both of the interfaces, but this is necessary since my remote box is on the internet full-time and has a set address. This problem isn't so bad since normally I won't be switching protocols on the fly, but it's a pain in the butt and I am hoping that the behavior can be fixed. Next is a more serious problem. As you may have noted, I just finished my mods to make the user-mode PPP do full-time connections irregardless of the outgoing packet situation. So, if the link goes down, the remote end will attempt to re-establish the connection immediately. This behavior seems to work fine for the most part, however it appears that somehow the arp table entry for my box is getting re-imported after it's deleted on my server box. Nomenclature: ------------- remote - Remote machine connecting via PPP server - PPP server machine local - FreeBSD box on the same local network as the PPP server machine sunloc - Sun box on the local network 'remote' calls 'server', which attaches itself to the proper line and does a proxyarp for the new IP address. The arp table entry is propagated to 'local' who then knows to send any data to 'remote' via 'server'. So far so good. However, the link goes down for some reason (like me turning off my modem to make sure the re-dial code works). At this point 'server' deletes the arp table entry for 'remote'. But, 'local' still has the copy of the arp table entry, and it's got data to send to 'remote' (since it was in the middle of a TCP seesion when I killed the session). So, 'local' sends data to 'server' who no longer has any idea how to get to 'remote'. At this point, 'server' makes an entry into it's arp table for 'remote' that looks like this. remote.do.main (10.5.5.5) at (incomplete) Now, 'remote' is in 'demon dialer' mode and by now has gotten the idea that the link went down, so it is now re-dialing 'server' for the connection. Once 'remote' connects to 'server' the PPP process adds another arp entry into the table usint it's ethernet address, so now we have two entries in the table for 'remote'. remote.do.main (10.5.5.5) at (incomplete) remote.do.main (10.5.5.5) at 00:00:00:00:00:00 At this point in time, 'server' won't talk to 'remote' since it appears that it's trying to route the information to the ethernet. The only solution at this point is to do a route flush and delete all entries in the routing table and add them back by hand, which is impossible to do if you happen to be at the remote site. What can I do to avoid this problem? In this case I'm using correct procedure for routing and such. Note, I need to use proxyarp instead of adding routing table entries because one of our boxes a laptop can be on the network or connected remotely via PPP. Since it's ARP table entry can exist on either network hard-coding the routing information is not a workable solution. I don't have these sorts of problems with the Sun boxes and we've been running a similar setup for 8 months, so I suspect this is a FreeBSD specific problem. Nate