Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Oct 1995 11:40:38 -0600
From:      Nate Williams <nate@rocky.sri.MT.net>
To:        hackers@FreeBSD.org
Cc:        "Garrett A. Wollman" <wollman@lcs.mit.edu>
Subject:   ARP and routing table problems
Message-ID:  <199510271740.LAA04408@rocky.sri.MT.net>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510271740.LAA04408>