Hi,

I'm having a problem with UDP fragmentation reassembly. I'm running the
latest Red Hat 9 errata kernel (2.4.20-20.9) and I have a simple UDP
client and server. The client is sending payloads that range from 1000
to (65535 - 28) bytes.

The problem is that between two Linux boxes, it seems like the only the
last fragment is being seen by the UDP server box. The UDP client box
shows the proper IP fragmentation packets going out the interface. The
following is a tcpdump output from the UDP server box with just the
"udp" filter:

[root@k6-350 udptest]# tcpdump udp
tcpdump: listening on eth0
08:47:47.398756 www.32869 > k6-350.6000: udp 1000 [tos 0x80]
08:47:53.576274 www.32869 > k6-350.6000: udp 2000 (frag 23294:1480@0+)
[tos 0x80]
08:47:54.768272 www.32869 > k6-350.6000: udp 3000 (frag 23295:1480@0+)
[tos 0x80]
08:48:00.876335 www.32869 > k6-350.6000: udp 4000 (frag 23296:1480@0+)
[tos 0x80]
08:48:07.050195 www.32869 > k6-350.6000: udp 5000 (frag 23297:1480@0+)
[tos 0x80]
08:48:18.515435 www.32869 > k6-350.6000: udp 6000 (frag 23298:1480@0+)
[tos 0x80]
08:48:20.233865 www.32869 > k6-350.6000: udp 7000 (frag 23299:1480@0+)
[tos 0x80]
08:48:21.597156 www.32869 > k6-350.6000: udp 8000 (frag 23300:1480@0+)
[tos 0x80]
08:48:27.745616 www.32869 > k6-350.6000: udp 9000 (frag 23301:1480@0+)
[tos 0x80]
08:48:29.525689 www.32869 > k6-350.6000: udp 10000 (frag 23302:1480@0+)
[tos 0x80]
0

The UDP server process only sees packets that are under the Ethernet MTU
of 1500 bytes. I have also tried toggling the IP Path MTU Discovery
flag in /proc/sys/net/ipv4/ip_no_pmtu_disc.

If this is how things are supposed to work now, is there some new socket
API that I need to follow other than just calling recvfrom() in order to
get proper UDP/IP fragmentation reassembly to work again?

Thanks,
Tuan

Tuan Hoang wrote:

> Hi,
>
> I'm having a problem with UDP fragmentation reassembly. I'm running
> the latest Red Hat 9 errata kernel (2.4.20-20.9) and I have a simple
> UDP client and server. The client is sending payloads that range from
> 1000 to (65535 - 28) bytes.
>
> The problem is that between two Linux boxes, it seems like the only
> the last fragment is being seen by the UDP server box. The UDP client
> box shows the proper IP fragmentation packets going out the
> interface. The following is a tcpdump output from the UDP server box
> with just the "udp" filter:
>
> [root@k6-350 udptest]# tcpdump udp
> tcpdump: listening on eth0
> 08:47:47.398756 www.32869 > k6-350.6000: udp 1000 [tos 0x80]
> 08:47:53.576274 www.32869 > k6-350.6000: udp 2000 (frag 23294:1480@0+)
> [tos 0x80]
> 08:47:54.768272 www.32869 > k6-350.6000: udp 3000 (frag 23295:1480@0+)
> [tos 0x80]
> 08:48:00.876335 www.32869 > k6-350.6000: udp 4000 (frag 23296:1480@0+)
> [tos 0x80]
> 08:48:07.050195 www.32869 > k6-350.6000: udp 5000 (frag 23297:1480@0+)
> [tos 0x80]
> 08:48:18.515435 www.32869 > k6-350.6000: udp 6000 (frag 23298:1480@0+)
> [tos 0x80]
> 08:48:20.233865 www.32869 > k6-350.6000: udp 7000 (frag 23299:1480@0+)
> [tos 0x80]
> 08:48:21.597156 www.32869 > k6-350.6000: udp 8000 (frag 23300:1480@0+)
> [tos 0x80]
> 08:48:27.745616 www.32869 > k6-350.6000: udp 9000 (frag 23301:1480@0+)
> [tos 0x80]
> 08:48:29.525689 www.32869 > k6-350.6000: udp 10000 (frag
> 23302:1480@0+) [tos 0x80]
> 0
>
In the output of tcpdump, "(frag 23299:1480@0+)" means a packet with IP
id 23299 was received with the "is fragment" bit set (frag) the "more
fragments" bit set (+) containing 1480 bytes at offset 0 in the
assembled datagram (1480@0) . So, what you are seeing is in fact the
_first_ fragment of each datagram. This is significant since the first
fragment contains the transport layer (UDP) header. Usually, when you
only see the first fragment, the culprit is a firewall rule that allows
the first fragment but not further ones.

[snip]

> Thanks,
> Tuan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
Casey Carter
Casey@Carter.net
ccarter@cs.uiuc.edu
AIM: cartec69

Casey Carter wrote:
> Tuan Hoang wrote:
>
>> Hi,
>>
>> I'm having a problem with UDP fragmentation reassembly. I'm running
>> the latest Red Hat 9 errata kernel (2.4.20-20.9) and I have a simple
>> UDP client and server. The client is sending payloads that range from
>> 1000 to (65535 - 28) bytes.
>>
>> The problem is that between two Linux boxes, it seems like the only
>> the last fragment is being seen by the UDP server box. The UDP client
>> box shows the proper IP fragmentation packets going out the
>> interface. The following is a tcpdump output from the UDP server box
>> with just the "udp" filter:
>>
>> [root@k6-350 udptest]# tcpdump udp
>> tcpdump: listening on eth0
>> 08:47:47.398756 www.32869 > k6-350.6000: udp 1000 [tos 0x80]
>> 08:47:53.576274 www.32869 > k6-350.6000: udp 2000 (frag 23294:1480@0+)
>> [tos 0x80]
>> 08:47:54.768272 www.32869 > k6-350.6000: udp 3000 (frag 23295:1480@0+)
>> [tos 0x80]
>> 08:48:00.876335 www.32869 > k6-350.6000: udp 4000 (frag 23296:1480@0+)
>> [tos 0x80]
>> 08:48:07.050195 www.32869 > k6-350.6000: udp 5000 (frag 23297:1480@0+)
>> [tos 0x80]
>> 08:48:18.515435 www.32869 > k6-350.6000: udp 6000 (frag 23298:1480@0+)
>> [tos 0x80]
>> 08:48:20.233865 www.32869 > k6-350.6000: udp 7000 (frag 23299:1480@0+)
>> [tos 0x80]
>> 08:48:21.597156 www.32869 > k6-350.6000: udp 8000 (frag 23300:1480@0+)
>> [tos 0x80]
>> 08:48:27.745616 www.32869 > k6-350.6000: udp 9000 (frag 23301:1480@0+)
>> [tos 0x80]
>> 08:48:29.525689 www.32869 > k6-350.6000: udp 10000 (frag
>> 23302:1480@0+) [tos 0x80]
>> 0
>>
> In the output of tcpdump, "(frag 23299:1480@0+)" means a packet with IP
> id 23299 was received with the "is fragment" bit set (frag) the "more
> fragments" bit set (+) containing 1480 bytes at offset 0 in the
> assembled datagram (1480@0) . So, what you are seeing is in fact the
> _first_ fragment of each datagram. This is significant since the first
> fragment contains the transport layer (UDP) header. Usually, when you
> only see the first fragment, the culprit is a firewall rule that allows
> the first fragment but not further ones.
>
> [snip]
>

Thanks for the reply. Unfortunately neither box is running a firewall
(i.e. iptables). Something is very wrong here. I don't recall this
happening in kernel 2.2.x under Red Hat 7.x.

BTW, seems like the Linux 2.4.x kernel sends fragments out in reverse
order (at least that's what tcpdump says to me from the UDP sender box).
The fragments seem like they start with the last one and then work
backwards to the one at offset 0.

Tuan