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. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
