[OpenAFS] OpenAFS, Cisco VPN and MAC OS and mtu

[Jeff Blaine]

> Jeff Blaine wrote:
>> FWIW, this appears to be the same problem I reported in
>> April, but for Windows.
>>
>> https://lists.openafs.org/pipermail/openafs-info/2009-April/031127.html
>>
>> We are still working with our networking+VPN folks to
>> try to determine if it's the same thing or not, as well
>> as how to fix it.
> 
> 
> Have you tried the Windows registry setting rxMaxMtu?
> 
> It needs to be 56 bytes less then the actually MTU.
> Cisco VPN appears to force a MTU of 1300 on the interface,
> so rxMaxMtu should be 1244.

Setting it to 1244 or lower did in fact cause it to start
working.

Well, it works as long as CheckPoint Integrity Flex is
completely off.  With it on, even with all functionality
turned off (Firewall, Program Control, etc), AFS fails.
Figure that one out!  :|

> If you are having a fragmentation problem, ping can help, by setting
> the don't fragment bit and varying the size can help see what the
> limit is.
> 
> On Windows:   ping -f -l nnnn ...
> On Linux:     ping -M do -s nnnn ....
> 
> 
> On the windows client that is failing, try:
> rxdebug 127.0.0.1 -port 7001 -peer -long
> ipconfig /all
> 
> Look for the ifMTU nnnn natMTU nnnn maxMTU nnnn
> lines for each afs server. Also compare the IP numbers
> with the ip number in the ipconfig.

Very helpful debugging notes.  Thanks for sharing!

> As best as I can tell, The code in rx_kcommon.c tries to
> determine the ifMTU based on the addresses of the client and server.
> If they appear to be on the same class a, b, or c network, it
> may work by using the MTU from the matching interface. But none
> if the interfaces match at all, it defaults to using 1500, which can case
> fragmentation. Even in the Windows case I think this might happen.
> 
> To test this I need to get off site. Will try tonight from home.