how to unset ip flag "don't fragment" on outgoing packets (kernel 2.4.10)

Discussion in 'Linux Networking' started by exo, Dec 8, 2005.

  1. exo

    exo Guest

    I've a problem with a box that is connected to a LAN. A part of the
    Network has a MTU (MaximumTransferUnit) of 512 so the routers like to
    fragment the packets going over this part of the Network. After a sniff
    I could see all packets from this box have the DF-Bit (don't fragment)
    set. (BTW the packets from my workstation (Fedora core 4 2.6.14) it's
    the same).

    I then played a bit arround with ethereal and could see if i send UDP
    packets or ICMP from this machine the DF-Bit was not set. But on TCP
    connections telnet, http is is set on every packet.

    Then I thought no problem this has to be handled somewhere with sysctl
    or in /proc/sys/net. I've found out that older kernels like 2.2 had a
    key named "ip_always_defrag" there but the 2.4 don't. Also a long
    google session did not help very much.

    All I want is to tell the kernel that it should not mark all tcp-ip
    packes per default with DF. Is there a way to do this? Am I searching
    in the wrong place?

    thanks for help

    exo, Dec 8, 2005
    1. Advertisements

  2. MTU Discovery is the correct way to handle this situation. When packets
    with an TU > 512 (or whatever) and DF set hit that part of the network
    with MTU = 512, the packet should be dropped and an ICMP error sent back.

    ICMP Type-3/Code-4 is "Fragmentation Needed and Don't Fragment was Set"

    The ICMP should include the MTU. Your host should adjust the TU and
    retransmit with correctly-sized packets.

    There's also MSS-clamping, but that's the _wrong_ way to solve the problem.
    Allen Kistler, Dec 8, 2005
    1. Advertisements

  3. I still don't know what problem you think you have. If TCP/IP is
    working why would you want the IP DF bit not to be set?

    If TCP/IP is not working then you may well be looking in the wrong
    place. Check for the file /proc/sys/net/ipv4/ip_no_pmtu_disc.
    If it exists and "cat /proc/sys/net/ipv4/ip_no_pmtu_disc" shows a
    "1" then the Fedora distribution has likely (and foolishly) turned
    PMTU Discovery off in a boot-up file.

    If cat shows a "0" then a broken router blocking ICMP "DF bit set but
    fragmentation needed" messages could cause PMTU Discovery failure.
    In that case compiling the kernel Netfilter MSS clamping option
    (CONFIG_IP_NF_TARGET_TCPMSS) and configuring it with iptables as
    shown in Help should work.
    Clifford Kite, Dec 8, 2005
  4. exo

    exo Guest

    I still don't know what problem you think you have. If TCP/IP is
    No TCP is not working properly over the named part of the network (BTW
    its a WAN link between 2 LANs with only 512Byte MTU). Eg if I open a
    telnet session it works as long as I don't call "ls" or something what
    will result in a tcp packet larger than 512B. Then the connection
    yes its "0" so I have to look with the carrier of the WAN link. They
    told me we are sending packets with DF set and that causes the problem.
    But now (with your information) it looks like their router does not
    handle it right (send back ICMP)

    Thanks a lot for understanding IP a bit more

    exo, Dec 9, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.