I haven't tried sniffing the trafic to see what exactly is happening yet. If I can get the connection timeouts to reproduce them selves, I'll try it tomorrow.
I've noticed that if I reboot the firewall and delete the afs cache on the client machine the problem goes away, but this is not viable option. Elliot On Wed, 2003-06-04 at 18:08, Derek Atkins wrote: > Hmm, then I dont know what to suggest to you... AFS behind a NAT is > just... weird. It usually works, but it can get into strange states > sometimes. There were a few bugs in the fileserver where it would > try to callback to the wrong address and fail to get a WhoAreYou > response. > > Have you tried running a network sniffer on both sides of the NAT > box to see what's going on with the failed connections? > > -derek > > Elliot Peele <[EMAIL PROTECTED]> writes: > > > These are desktop that are 100% of the time behind the NAT. > > > > Elliot > > > > On Wed, 2003-06-04 at 17:30, Derek Atkins wrote: > > > Are these users on laptops or are they _ALWAYS_, 100% behind the NAT? > > > > > > -derek > > > > > > Elliot Peele <[EMAIL PROTECTED]> writes: > > > > > > > Hi, > > > > > > > > I thought I'd try this again worded a bit different and with a different > > > > subject. I have several users that keep getting connection timeout > > > > errors when trying to access there volumes from behind a firewall. I > > > > believe this may be a problem with the udp timeouts. They are OpenAFS > > > > clients connecting to Transarc AFS server through an iptables NATing > > > > firewall running on Red Hat Linux 7.3 currently with kernel > > > > 2.4.18-24.7.x. > > > > > > > > Thanks > > > > > > > > Elliot
signature.asc
Description: This is a digitally signed message part
