Strange MTU Problem - Networking

This is a discussion on Strange MTU Problem - Networking ; On Mon, 26 May 2008, in the Usenet newsgroup comp.os.linux.networking, in article , Geoff Lane wrote: >Moe Trin wrote: >> I'm not aware of a protocol that would use 20 or 28 bytes. >On the following URL it explains about ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: Strange MTU Problem

  1. Re: Strange MTU Problem

    On Mon, 26 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Geoff Lane wrote:

    >Moe Trin wrote:


    >> I'm not aware of a protocol that would use 20 or 28 bytes.


    >On the following URL it explains about using PING to check MTU and gives
    >the explanations following.
    >
    >http://www.kitz.co.uk/adsl/MTU2.htm


    OK - a little on the simple side. I'd rather check using a packet sniffer
    as you may find your systems are using options to the IP or TCP header
    which increase the length by up to 40 bytes (80 if both are at maximum).
    UDP is a fixed 8 bytes, and ICMP depends on the type of message (see
    RFC0792). Fragmentation then shows up very obviously.

    > In the example above it shows that my highest responsive ping is 1402.
    > From this we need to add on 28 to get the maximum MTU figure.
    >(28 being the header size for IP + ICMP)


    1402 + 28 is 1430, which is still a rather unusual value. And you're
    assuming no IP options.

    >Do not go above 1472. (1472 + 28 = 1500 MTU) since 1500 is the maximum MTU.


    But that assumes no options to the IP header. You may want to check that.
    But recall that the MTU includes the IP (and what-ever the packet contains)
    headers

    Old guy

  2. Re: Strange MTU Problem

    On Mon, 26 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Geoff Lane wrote:

    >Moe Trin wrote:


    >>> As the only thing I recalled altering was the MTU changed it back to
    >>> 1472 and now all fine.

    >>
    >> Someplace, there is a firewall that is dropping ICMP Type 3 Code 4
    >> packets ("Fragmentation needed, but don't fragment bit set"). This
    >> could be a mis-guided attempt at security, or a NAT translation that
    >> isn't forwarding the error to the right computer.

    >
    >I've got an older Vigor 2600 NAT router, on the IP tables I have barred
    >everything in and out unless I open the ports.


    Depends on the routers - mine does not forward stuff by default, so
    unless I've added a rule telling the firewall to forward port $FOO
    to host $BAR port $BAZ, the firewall responds with an ICMP Type 3 for
    the protocol and/or port number. Replies to packets that my system
    originated (which are then NAT'ed) are automagically translated and
    forwarded. Outbound filtering I don't use, as I don't have windoze
    boxes auto-installing malware, and the like. It always makes me laugh
    to see the so-called firewalls for windoze always saying that "this
    application tried to connect to host $FOO on the Internet - is this OK?"
    because the user gets used to this, and blindly clicks the icon
    without understanding.

    >To date with trial and error, if anything don't work I check the ports
    >in the router's system log and open that port if I require it. All
    >normal ports are open.


    That's a good plan.

    >The rules apply to TCP/UDP so I assume ICMP is not affected.


    Probably not the case. Does the router know how to forward the ICMP
    errors to the correct host on the NAT'ed side?

    >Is Path MTU Discovery on by default. I have looked at DR TCP and have
    >tried altering the MTU and saving but it always comes up blank when I
    >launch the program again.


    Depends on how your kernel is compiled, but probably so. Simple
    test is to see if the DF flag is set in your outbound packets. A
    sniffer shows this readily.

    Old guy

  3. Re: Strange MTU Problem

    Moe Trin wrote:

    >> To date with trial and error, if anything don't work I check the ports
    >> in the router's system log and open that port if I require it. All
    >> normal ports are open.

    >
    > That's a good plan.
    >
    >> The rules apply to TCP/UDP so I assume ICMP is not affected.

    >
    > Probably not the case. Does the router know how to forward the ICMP
    > errors to the correct host on the NAT'ed side?


    The way I understand it my Vigor 2600 allows everything unless I deny
    it. It can read a rule then branch to another so I set mine for DROP
    IMMEDIATELY unless any further match and later allow popular ports.

    The IP firewall rules allow for specifically tcp, udp, icmp or igmp or
    tcp/udp and mine are set for tcp/udp so I assume icmp go through unhindered.

    Geoff Lane

  4. Re: Strange MTU Problem

    Moe Trin wrote:
    > While 1472+28 certainly does equal 1500, I'm not aware of a protocol
    > that would use 20 or 28 bytes. The default Ethernet packet
    > (RFC0894)


    1472 of payload and 20 bytes of IPv4 and 8 bytes of either UDP or ICMP
    header perhaps involved in how that number came to be, coupled with
    some confusion about MTU and what gets counted?

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  5. Re: Strange MTU Problem

    On Tue, 27 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Geoff Lane wrote:

    >Moe Trin wrote:


    >>> The rules apply to TCP/UDP so I assume ICMP is not affected.

    >>
    >> Probably not the case. Does the router know how to forward the ICMP
    >> errors to the correct host on the NAT'ed side?

    >
    >The way I understand it my Vigor 2600 allows everything unless I deny
    >it. It can read a rule then branch to another so I set mine for DROP
    >IMMEDIATELY unless any further match and later allow popular ports.


    ICMP errors are sent to the system whose source is in the packet that
    caused the error, but ICMP has no port numbers. Think of the situation
    where 192.168.11.21 is one of five hosts hiding behind a NAT router.
    On the local side, a packet has real source address and destination,
    along with real port numbers. The NAT router takes this packet and
    replaces the source IP and source port number, while keeping track of
    both, and the packet that goes out over the Internet has the correct
    destination, but the source address/port number of something on the
    NAT box. The world has no means of easily knowing that the source
    is a box on the 192.168.11.xx net.

    If you next look at RFC0792, you'll find that the ICMP Type 3
    (Destination Unreachable) error has the normal 20 byte IP header, an
    8 byte ICMP header (0x03 0x?? 0xchecksum, 0x0, 0x0, 0x0 0x0) 20+ bytes
    of the IP header that caused the error (20 bytes plus any included IP
    options), and 8 more bytes of the "data" of that IP datagram. Assuming
    a TCP or UDP packet, those 8 bytes includes the source and destination
    port numbers. This means your firewall code has to look at the 28+
    byte data of the ICMP error to find out what address and port number
    the offending packet came from, and from that, figure out who it
    should forward the ICMP error packet after re-writing the contents to
    reflect the address translation function. Not all NAT boxes do this.

    Think also that the ICMP error may well be generated by a host
    other than the destination - perhaps an intermediate router, so you
    can't depend on the source IP of the error datagram matching up with
    the destination IP of anything you've sent.

    One way to check if your firewall is forwarding ICMP errors
    correctly is to use a route tracing application, such as traceroute
    (or better, tcptraceroute, or hping3, which can be configured to do
    the trace using tcp packets rather than ICMP or UDP. If the
    trace shows intermediate hops (recall these applications work by
    sending packets with artificially low TTLs, and depend on the
    intermediate routers to send an ICMP Type 11 "Time Exceeded" error.
    That's not the ICMP Type number you need for PMTU, but you can check
    that ICMP Type 3 is working by trying to connect to a non-existent
    server or port, and hope that who ever set up the destination box is
    not filtering (dropping) such packets.

    Old guy

  6. Re: Strange MTU Problem

    Moe Trin wrote:

    > ICMP errors are sent to the system whose source is in the packet that
    > caused the error, but ICMP has no port numbers.


    Thanks for very informative reply.

    Geoff Lane

  7. Re: Strange MTU Problem

    On 24 May, 10:04, Geoff Lane wrote:
    > I run a small home network with two older Linux machines and an XP laptop.
    >
    > Recently I ran a Windows network analysis tool and after testing various
    > URLs it reported my best MTU to be 1500, as this is the default for ADSL
    > I thought nothing of it and set my router to 1500 (It had been 1472).
    >
    > Everything appeared to be fine, web surfing OK, receiving mail OK but
    > had a problem sending emails with attachments; also there was one web
    > site that I couldn't access on my windows or Linux machines.
    >
    > As the only thing I recalled altering was the MTU changed it back to
    > 1472 and now all fine.
    >
    > I know the default is 1500 also for the Linux machines so is this a
    > common problem with incorrect MTUs that most will work OK but some areas
    > of the network may not.
    >
    > Geoff Lane


    Hi Geoff,

    Yes, this is a common problem - the reason for it is that some web-
    sites will be hosted on servers which do not generate ICMP error
    messages if they receive packets which are too big. These ICMP
    messages are used by the path MTU ( pMTU) discovery process to tell
    your PC to send smaller packets.

    I have had problems using MSN Messenger and accessing any
    microsoft.com web-sites due to this issue.

    Mark.

    www.kpcomputerstore.co.uk

  8. Re: Strange MTU Problem

    mark@kpcomputerstore.co.uk a écrit :
    >
    > Yes, this is a common problem - the reason for it is that some web-
    > sites will be hosted on servers which do not generate ICMP error
    > messages if they receive packets which are too big.


    You must be mistaken. Hosts cannot generate an ICMP error because a
    packet is too big, only routers can. Either the host receives the packet
    and has no reason to reject it because of its size, either it doesn't
    receive it and has no reason to send an ICMP error.

  9. Re: Strange MTU Problem

    On 3 Jun, 12:45, Pascal Hambourg wrote:
    > m...@kpcomputerstore.co.uk a écrit :
    >
    >
    >
    > > Yes, this is a common problem - the reason for it is that some web-
    > > sites will be hosted on servers which do not generate ICMP error
    > > messages if they receive packets which are too big.

    >
    > You must be mistaken. Hosts cannot generate an ICMP error because a
    > packet is too big, only routers can. Either the host receives the packet
    > and has no reason to reject it because of its size, either it doesn't
    > receive it and has no reason to send an ICMP error.


    Quite correct Pascal!
    The host would not reject the packet based on MTU.

    It would be one of the routers in the path to the host.

    Mark.

    www.kpcomputerstore.co.uk

  10. Re: Strange MTU Problem

    mark@kpcomputerstore.co.uk wrote:

    > Quite correct Pascal!
    > The host would not reject the packet based on MTU.
    >
    > It would be one of the routers in the path to the host.


    Thanks for input guys, my original problem is now resolved.

    Geoff Lane

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2