Date: Sat, 23 Jan 1999 09:33:44 +1030 From: Greg Lehey <grog@lemis.com> To: Scott Mitchell <scott@dcs.qmw.ac.uk> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: NFS mount failures -- HELP! Message-ID: <19990123093344.G19921@freebie.lemis.com> In-Reply-To: <19990113135237.C993@dcs.qmw.ac.uk>; from Scott Mitchell on Wed, Jan 13, 1999 at 01:52:37PM %2B0000 References: <19990113135237.C993@dcs.qmw.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 13 January 1999 at 13:52:37 +0000, Scott Mitchell wrote: > OK, all you gurus, this one has everybody around here stumped: > > The story so far -- one small FreeBSD server, running 2.2.7R and configured > much like everything else around here (NIS, everything mounted by amd using > some *very* hairy maps). Working just great until last Friday, when it > suddently started refusing to mount anything from one particular file > server. The timing co-incides with the installation of a new switch with > something of a nanny syndrome; it likes to throw away over-long UDP packets > and those with bad checksums. > > In general our amd maps mount things using UDP with (I think) a 8K block > size. I now can't mount anything from the offending server over UDP, even > wfter reducing the block size to 1K. TCP mounts work fine, but I can't > force those to be used without messing with the (shared) amd maps or > hacking on amd itself. > > The problem appears to be limited to servers that route through the new > switch to get to my client, but I'm not 100% sure on that point. Other > machines (Linux, IRIX) on the same network as the client have no problems. > I haven't changed any configuration on the client for several months, and > it was working perfectly until this started. > > The obvious culprit is the switch, but that doesn't explain why only this > pair of machines is affected (the server runs FreeBSD also, BTW). I've > attached the packet trace result from one such failed mount attempt (chorus > is the client, hotpoint the server) > > Nobody here can figure out exactly what's causing this, so any suggestions > will be most welcome. > > chorus# tcpdump host hotpoint and host chorus > tcpdump: listening on ed0 > 11:18:44.104319 chorus.9dd92009 > hotpoint.dcs.qmw.ac.uk.nfs: 92 getattr [|nfs] > 11:18:44.105054 hotpoint.dcs.qmw.ac.uk.nfs > chorus.9dd92009: reply ok 96 > 11:18:44.105595 chorus > hotpoint.dcs.qmw.ac.uk: icmp: chorus udp port 1035 unreachable This looks very much like the problem I reported in kern/9612. I suspect you would have seen the problem if you had used the -n option to tcpdump. The important detail is that hotpoint has two IP addresses: Name: hotpoint.dcs.qmw.ac.uk Addresses: 138.37.94.24, 138.37.88.162 I'd guess that the request from chorus to hotpoint went to one address, and the reply came from the other address. I haven't fixed the problem yes, but for the time being, you can work around the problem by using the address 138.37.88.162 instead of the name hotpoint. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990123093344.G19921>