[OpenAFS-devel] rx mtu

Jim Rees rees@umich.edu
Fri, 24 Jan 2003 16:47:18 -0500


I've been looking at mtu again, in particular rxi_InitPeerParams and
rxi_FindIfnet.  I'm pretty sure there is at least one bug here.

rxi_InitPeerParams calls rxi_FindIfnet to find the interface that will be
used to get to a given peer.  rxi_FindIfnet loops through all the
interfaces, looking for the best match, where "best" is determined in this
order:

1. addresses match
2. peer is on same "subnet"
3. peer is on same "net"
4. if no match, just return the first interface in the list

Bug 1: I think "best" no 4 above is wrong.  It should be returning NULL.  A
look at old Transarc code confirms this is what it used to do.

Bug 2: The idea of "net" is some kind of leftover of the pre-CIDR days.  It
shouldn't be used at all.

Bug 3: Only the first address in the interface's address list is considered.
My copy of Transarc 3.3 goes through the entire list for each interface, but
maybe that's something we added.

Bug 4: Since *pifad is always NULL, the code under "if we're given an
address" is dead.

======

Now, let's look at what rxi_InitPeerParams does with this interface.  First,
notice there are two if/else statements after the call to rxi_FindIfnet.
They should be combined to make it more clear what's going on.  Notice that
ifn will never be NULL unless you have no interfaces, due to Bug 1 above.

If we fix Bug 1, ifn will be non-NULL if the peer is attached to a local
net, or at least this seems to be the goal.  We end up with
pp->timeout=2 and pp->ifMTU=(interface mtu - header size).  Otherwise, the
peer is remote, and we use pp->timeout=3 and pp->ifMTU=1444.

If we don't fix Bug 1, we'll use the mtu of the first interface in the list
if the peer is remote.  Maybe the assumption is that this is the default
route?

Note that in most cases, none of these bugs matter.  That's because there is
only one interface, and it has an mtu of 1500.