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.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
