Date: Sun, 9 Feb 1997 14:14:25 -0800 (PST) From: "Bryan K. Ogawa" <bkogawa@primenet.com> To: robert@nanguo.chalmers.com.au Cc: freebsd-questions@freebsd.org (bsd) Subject: Re: Annex and pppd hung connections solved I think. Message-ID: <199702092214.OAA03058@foo.primenet.com> References: <199702090825.SAA01445@nanguo.chalmers.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In localhost.freebsd.questions you write: >Ok, >I think I may have solved the Annex/rfc/no-connect problem. >For those interested. I reduced the ppp 'mtu' and 'mru' options from >1500 to 296. Now connections seem to be working fine. Let me know >if not please. >I note the Annex settings were also 1500. This was probably the same >problem there. I'll see next week. >Thanks for all the feedback and help. It all may not be solved yet, >but it looks promising. This is hypothetical, and may be just me experiencing "have a hammer, all things are nails" syndrome. I'd like to hear what others think. OK. This sounds like you are getting hit by path MTU discovery (or something like it). TCP path MTU dscovery is described in the wonderful _TCP_IP_Illustrated_, Volume 1, by W. Richard Stevens, in 24.2, Path MTU Discovery, page 340, which is paraphrased (and summarized) below: MTU is the number which indicates the largest size packet an interface will transmit. In path MTU discovery, packets are transmitted while marked "Don't Fragment" (DF). Normally, if a big (say 1500 byte IP packet) is sent to a router which has a small MTU (say, 576 bytes), the packet is split into fragments (of 576 bytes or so) and then these several packets are sent through the small pipe. With the DF bit set, when a router realizes that it is supposed to send a 1500 byte packet through a 576 byte MTU, it returns an ICMP error which says, essentially, "this packet is too big and you won't let me split it up". When the originator gets this message, it must split up the packets and then resend them in smaller size. By continuing to vary packet size, the originator can then find out what the optimal size packet is. If the Annex doesn't respond properly to the DF bit, it may not return the ICMP error, which, to the sender, looks like a dead link (no packets go through, no errors return). You may still be able to do certain things which use small-size packets (like interactive telnets, perhaps?). Normally, if everything is working right, and you have smaller MTU somewhere in the path, you'll see an initial delay as the first big burst of data goes through the link (which sends a big enough packet through the link to trigger the DF). I experienced this with a Solaris machine trying to do POP mail. What would happen would be that the entire first message (if it were over about 1K in size) would transmit EXTREMELY SLOWLY, followed by the rest of the messages quickly. The reason (I surmise) was because my side of the link was misreporting the MSS of the link. Because my mru was at 576, and my mtu was 1500, the originating packets said, "it's OK to send packets up to 1500 bytes in size through this link". The Solaris box then sent them w/ 1500 byte size (starting with the message--the user and password queries were too small), which reached the 576 byte pipe to my machine, and then bounced back with the error message, forcing retransmit. Since popd dumped the entire message out, the entire message was transmitted (with the size at 1500 bytes and DF set), and had to be bounced then retransmitted. At least, that's my theory. Returning to the issue, you can try to turn off path MTU discovery, which is described in RFC 1191, if I'm reading Stevens correctly, and see if that helps. I'm afraid that I don't have a good picture of how your machine and the annex relate to each other, so I'm not getting a good picture of which machine is the gateway... eg is it: -------------- ------------- + + + + + freebsd2.2 +----------+ annex +------- the world + + + + +------------- ------------- If so, then your solution of fiddling with MTU / MRU seems like the necessary one (unless you can turn off mtu path discovery, or get the annex upgraded)? I hope that was at least vaguely comprehensible...? -- bryan k ogawa <bkogawa@primenet.com> http://www.primenet.com/~bkogawa/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702092214.OAA03058>