Date: Thu, 14 Aug 1997 11:32:30 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: wollman@freebsd.org Cc: current@freebsd.org Subject: Well, I guess it's about time I mentioned this little problem... Message-ID: <1433.871583550@time.cdrom.com>
next in thread | raw e-mail | index | archive | help
David G. and I poked around at the problem a bit during a recent phone conversation of ours, but nothing really came to mind as a solution. Here's the scenario: Box G, a FreeBSD 3.0-current machine, contains an SMC ethernet card configured as ed0 and a standard serial port with a ISDN Terminal Adaptor running at 115.2KBaud and configured as sl0. This slip line goes to another ISDN TA which is plugged into hub.freebsd.org, everything on that side configured pretty much the same way. Box A, a FreeBSD 2.2-stable machine, talks to box G over its own PCI NIC, configured as de0. Box G is configured as this machine's default gateway and it's your basic, standard "n machines on a LAN being served by one gateway machine with an ISDN connection" situation. Now here's where it gets weird. By and large, everything works just fine on this LAN and the FreeBSD/ISDN machine has been serving rather happily in this role for over a year. The only flies in the ointment have been certain URLs which just never seemed to be reachable from Box A, whether the browser was Netscape or Lynx or whatever. At first I just wrote this off to the flakey nature of the net in general, but then I started getting suspicious when I noticed that these "stubborn URLs" actually worked just fine from Box G or from hub.freebsd.org, it just failed to work from Box A. During my conversation with David, he suggested that I drop the MTU on box A's ethernet interface from 1500 to 500 and TADA! Suddenly these URLs (one of which is http://www.sunlabs.com/) could be visited just fine from box A, no problems. So the question is: What is it about the MTU size of the ethernet interface on box A which effects the ability of the gateway box G to pass traffic to box A? Here's the tcpdump trace of the attempt to connect from lynx when the MTU of ed0 on box A is set to 1500: 11:30:53.276132 time.cdrom.com.1216 > rocky.sunlabs.com.http: S 2243214515:2243214515(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 11:30:53.501585 rocky.sunlabs.com.http > time.cdrom.com.1216: S 294104724:294104724(0) ack 2243214516 win 8760 <mss 1460> (DF) 11:30:53.501696 time.cdrom.com.1216 > rocky.sunlabs.com.http: . ack 1 win 16384 (DF) 11:30:53.503656 time.cdrom.com.1216 > rocky.sunlabs.com.http: . 1:513(512) ack 1 win 16384 (DF) 11:30:53.797419 rocky.sunlabs.com.http > time.cdrom.com.1216: . ack 513 win 8760 (DF) 11:30:53.797508 time.cdrom.com.1216 > rocky.sunlabs.com.http: P 513:667(154) ack 1 win 16384 (DF) 11:30:56.480098 time.cdrom.com.1216 > rocky.sunlabs.com.http: P 513:667(154) ack 1 win 16384 (DF) 11:30:56.698495 rocky.sunlabs.com.http > time.cdrom.com.1216: . ack 667 win 8760 (DF) <it wedges here> And now with the MTU of ed0 on box A set to 500: 11:30:15.890262 time.cdrom.com.1215 > rocky.sunlabs.com.http: S 2235648945:2235648945(0) win 16384 <mss 460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 11:30:16.075893 rocky.sunlabs.com.http > time.cdrom.com.1215: S 288164975:288164975(0) ack 2235648946 win 9200 <mss 460> (DF) 11:30:16.075990 time.cdrom.com.1215 > rocky.sunlabs.com.http: . ack 1 win 16560 (DF) 11:30:16.077957 time.cdrom.com.1215 > rocky.sunlabs.com.http: . 1:461(460) ack 1 win 16560 (DF) 11:30:16.331161 rocky.sunlabs.com.http > time.cdrom.com.1215: . ack 461 win 9200 (DF) 11:30:16.331258 time.cdrom.com.1215 > rocky.sunlabs.com.http: P 461:667(206) ack 1 win 16560 (DF) 11:30:16.640626 rocky.sunlabs.com.http > time.cdrom.com.1215: P 1:461(460) ack 667 win 9200 (DF) 11:30:16.780091 time.cdrom.com.1215 > rocky.sunlabs.com.http: . ack 461 win 16560 (DF) 11:30:17.036760 rocky.sunlabs.com.http > time.cdrom.com.1215: . 461:921(460) ack 667 win 9200 (DF) 11:30:17.078112 rocky.sunlabs.com.http > time.cdrom.com.1215: . 921:1381(460) ack 667 win 9200 (DF) <much additional traffic as the URL loads successfully> Any ideas on what I should try here to further debug this oddness? Thanks! Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1433.871583550>