Date: Tue, 27 Jan 2009 18:01:25 -0800 From: Len Gross <sandiegobiker@gmail.com> To: freebsd-net@freebsd.org Subject: Re: MTU or Fragmentation Problems on 7.0? Message-ID: <27cb3ada0901271801u6d1db9cfhfb953073355db2d2@mail.gmail.com> In-Reply-To: <20090127064419.GC1284@verio.net> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> <20090127064419.GC1284@verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
David Wow! Thanks for so much help and detail. I guess it is "good news" that this is a result of "common TCP methodology.= " ;-> It will take me a bit of time (i.e Weekend work) to capture / understand the traffic and run some more tests and read up on Path MTU Discovery. BTW: The only firewall I've found in this setup is a Linksys WiFi Router that that connects to a cable modem. Similar setup at a second location with a WiFI router to DSL. One left over item to ponder. Why does Google work? Do they have a packet size smaller than 1450 by "default"? Thanks again, and I'll send an update when I learn more. -- Len On Mon, Jan 26, 2009 at 10:44 PM, David DeSimone <fox@verio.net> wrote: > Len Gross <sandiegobiker@gmail.com> wrote: >> >> If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU >> on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to >> work, BUT browsing on FreeBSD3 "fails" (mostly.) > > You are running into a common TCP methodology in use these days, called > "Path MTU Discovery." In this process, both endpoints choose to set > the "DF" (Don't Fragment) bit on all their TCP packets, and then they > expect all routers along the path to send ICMP "network unreachable" > packets with code "needs fragment", informing them of what maximum > packet size is allowed along the path. Endpoints start out sending > full-size frames and then reduce them in size whenever instructed to do > so by ICMP messages. > > The reception of these ICMP messages is crucial to this process working, > and if the frames are not received, the whole communication breaks down. > >> Using tcpdump there is lots of unusual stuff, some relating to >> fragmentation ICMP? > > These are the messages I referred to. Be aware that, just because > you see them arriving or leaving via tcpdump, does not mean that they > are being received by the host. For instance, a host using PF or IPF > or some other firewall would indeed see the frame arrive, but if its > ruleset rejects the frame, it will not have a useful effect. > >> I have tried putting mtu =3D 1450 using route change on all the routes, >> but that didn't help. > >> Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox >> runs fine there > > That is because, since it has a direct interface with a reduced MTU, it > already knows to negotiate a smaller initial MSS with any endpoints out > on the internet. Hosts behind BSD2 have to learn the Path MTU via the > above Discovery process. > > In another message you mentioned that you have no firewalls in place, > but that hardly seems likely. Everyone runs a firewall at some point, > because it is too dangerous to leave your systems unprotected on the > internet. > > I suppose you may be thinking that this is a problem that exists only on > your local network, but you must realize that Path MTU Discovery works > in both directions, from your systems out to the internet, and from > those internet systems back to yours. > > For instance, if your BSD3 box sends a large packet, the BSD2 "router" > realizes that it needs to be fragmented, but the DF-bit prevents this. > So BSD2 sends a message to BSD3 that it must use a smaller packet size. > If you have no firewalls in place, then this message will surely be > received and acted upon. > > However, when web browsing, the more likely scenario is that the web > server you've contacted will be the one trying to send large packets > back to you. When those packets reach router BSD1, it realizes that the > packet is too big, and sends an ICMP message back to the remote server. > Does that ICMP message make it through your outbound filters further > upstream? Perhaps. Will that message make it thorugh the firewalls > that are surely guarding the remote server? Let's hope so! This is > something that is not really under your control, so it's difficult to > say. Your best method of troubleshooting this might be to test from a > host outside your network to see if the ICMP packets from BSD1 are > making it through. > > -- > David DeSimone =3D=3D Network Admin =3D=3D fox@verio.net > "I don't like spinach, and I'm glad I don't, because if I > liked it I'd eat it, and I just hate it." -- Clarence Darrow > > > This email message is intended for the use of the person to whom it has b= een sent, and may contain information that is confidential or legally prote= cted. If you are not the intended recipient or have received this message i= n error, you are not authorized to copy, distribute, or otherwise use this = message or its attachments. Please notify the sender immediately by return = e-mail and permanently delete this message and any attachments. Verio, Inc.= makes no warranty that this email is error or virus free. Thank you. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > This email message is intended for the use of the person to whom it has b= een sent, and may contain information that is confidential or legally prote= cted. If you are not the intended recipient or have received this message i= n error, you are not authorized to copy, distribute, or otherwise use this = message or its attachments. Please notify the sender immediately by return = e-mail and permanently delete this message and any attachments. Verio, Inc.= makes no warranty that this email is error or virus free. Thank you. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27cb3ada0901271801u6d1db9cfhfb953073355db2d2>