Douglas E. Engert wrote: > Looking closer and doing some testing, rx_kcommon.c appears to use > in a number of places when it can not determine what interface will be use: > > pp->ifMTU = RX_REMOTE_PACKET_SIZE > > In rx_packet.h: > #define RX_REMOTE_PACKET_SIZE (1500 - RX_IPUDP_SIZE) > > This is based on 1500 as an MTU. But in the case of the VPN, the MTU > needs to be smaller, like 1300 so the pp->ifMTU should be 1244. > > I would suspect that the RX_REMOTE_PACKET_SIZE should at least be based > on the smallest MTU of any interface that might be used. The Windows > version > of AFS added the registry rxMaxMtu which get around this same type of > problem. > Maybe all systems should have this capability? > > Using the attached patch on 1.4.10 MacOS 10.4.11 I can at least get the > ifMTU and natMTU set to 1244, (and need to test with the VPN.)
The problem that the Cisco VPN software had is that either the client refused to fragment UDP packets or that the server dropped the fragment on the floor. (I forget which.) This is not a problem that OpenAFS can properly address without adding support for Path MTU discovery to Rx. Setting the RX_REMOTE_PACKET_SIZE to ever small values forces a performance penalty on all users of OpenAFS regardless of whether or not their software implements or is configured to provide less than desirable behaviors. Feel free to submit a patch to add -rxmaxmtu to the Unix client to provide users a workaround. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
