MTU or Fragmentation Problems on 7.0?

[Len Gross]

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 at verio.net> wrote:
> Len Gross <sandiegobiker at 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 = 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 == Network Admin == fox at 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 been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>
> This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in 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.
>