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. 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. 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.
_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
-- Douglas E. Engert <[email protected]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
