fixing out of order first fragment processing?

[Maxim Konovalov]

Hello,

On Thu, 22 Jul 2004, 14:34-0700, othermark wrote:

> Hi,
>
> This is one of those obscure, yet well known issues in FreeBSD,
> some network stacks, like Linux, send the udp/icmp fragment
> first (if multiple frags -- in reverse order), then the orginal
> packet with the header.
>
> In -current, we still cannot process this simple fragged icmp-echo
> request from a Linux host.  For example, 'ping -c 1 -s 1500 <freebsd ip>'.
>
> FreeBSD discards the frag(s) and when it sees the initial packet with
> header waits for the frags.
>
> So two questions:
>
> 1. is there a gnats pr?  I tried various searches with no success.

AFAIK no.

> 2. are there workarounds/patches?

First of all, I can't reproduce this behaviour.  "ping -c 1 -s 4500 freebsd"
from the linux produces a pseudo tcpdump liek below:

linux > freebsd: icmp (frag 64465:68 at 4440)
linux > freebsd: icmp (frag 64465:1480 at 2960+)
linux > freebsd: icmp (frag 64465:1480 at 1480+)
linux > freebsd: icmp: echo request (frag 64465:1480 at 0+)
freebsd > linux: icmp: echo reply (frag 6529:1480 at 0+)
freebsd > linux: icmp (frag 6529:1480 at 1480+)
freebsd > linux: icmp (frag 6529:1480 at 2960+)
freebsd > linux: icmp (frag 6529:68 at 4440)

Linux kernel is 2.4.20-ac2, FreeBSD is 5.2.1-RELEASE.  What are yours?
Could you provide netstat -sp ip | grep frag snippet from the FreeBSD
box?  Clear the stats (netstat -zs) before experiments is a good idea
as well.

-- 
Maxim Konovalov