From owner-freebsd-net Sun Jun 11 10:50:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from vortex.greycat.com (vortex.greycat.com [207.173.133.4]) by hub.freebsd.org (Postfix) with SMTP id F1C8C37B7E4 for ; Sun, 11 Jun 2000 10:50:04 -0700 (PDT) (envelope-from dann@greycat.com) Received: (qmail 11580 invoked from network); 11 Jun 2000 17:50:01 -0000 Received: from bigphred.greycat.com (HELO greycat.com) (207.173.133.2) by vortex.greycat.com with SMTP; 11 Jun 2000 17:50:01 -0000 Received: (from dann@localhost) by greycat.com (8.9.3/8.9.3) id KAA08920 for net@freebsd.org; Sun, 11 Jun 2000 10:50:00 -0700 (PDT) (envelope-from dann) Date: Sun, 11 Jun 2000 10:50:00 -0700 From: Dann Lunsford To: net@freebsd.org Subject: Strange MTU related (?) problem Message-ID: <20000611105000.A7581@greycat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. Running 4.0-STABLE as of 28-May-2000. Box is a DFI K6-II 350 mobo with 256M. Ethercard is a 3c509B (ep driver). Box is on my home LAN with a mix of other OS'es (Linux, OS/2, VAX/VMS, NetBSD/VAX, No MS stuff :-) ), behind a Linux box (soon to be replaced with a FreeBSD box) acting as router and firewall. Anyway, a couple of days ago, something wierd started happening: I stopped being able to access certain websites, notably (!) slashdot.org. Doesn't matter what machine I come from, or what browser (lynx, netscape, hotjava, or a hack using netcat as a backend), the same thing happens: Enter URL, see the browser specific "connected to ..." message and then ... nothing. Have waited for 6-7 minutes, just to see what happens. Tcpdump shows the tcp 3-way handshake, my brower sending initial GET, the ACK for the GET, and then the connection just sits there. NO packets at all, till I stop it, and then I see the FIN_ACK, FIN pair for a normal close. This behavior has been observed before, when my ISP had put a Foundry level 3 switch in and was using it to divert web traffic to a squid. I protested, and they re-arranged things so my net connection went to the other side of the switch. Problem solved. I called my ISP and was told by an old friend who works there (that's one reason they're my ISP :-) ) that they were no longer doing that; way too many problems. He also checked and found that my connection was still direct into the main router. So that's not it. I started playing with traceroute, nmap, etc. Nothing obvious; the last few hops to slashdot.org were blotto, but with so many idiots blocking ICMP indiscriminately, that wasn't surprising. Then I realized that path MTU discovery depended on ICMP, so I started playing with the MTU on this box. BINGO! Any MTU larger than 1024 (extremely suspicious number, I think!), slashdot not accessible; 1024 or smaller, everything OK. Turning net.inet.tcp.path_mtu_discovery on or off had no effect, Now this is a solution to the immediate problem, But it irritates me greatly because, among other things, it affects my LAN performance, So, questions: Anybody else see this sort of behavior, and, is there any way to pinpoint what machine is doing this so polite letters can be written to the responsible parties (Packages with high explosives are not an option; much too messy :-) ) ? Thanks! -- Dann Lunsford The only thing necessary for the triumph of evil dann@greycat.com is that men of good will do nothing. -- Cicero To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message