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

Hi
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

Franky

exo wrote:
> Hi
> 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).
>
> ...
>
> 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?

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.

exo <(E-Mail Removed)> wrote:
> Hi
> 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?

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 Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"

> 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?

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
freezes.

> If cat shows a "0" then a broken router blocking ICMP "DF bit set but
> fragmentation needed" messages could cause PMTU Discovery failure.

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

greez
Franky