On Sat, 19 Feb 2005 16:20:43 +0100
"ERIK" <ebe-list@get2net.dk> wrote:

> A couple of days ago there was a discussion about NAT not 
> working after the ipfilter update.
> 
> I'm not sure whether it is the ipfilter upgrade or the 
> recent header file shuffling that is the culprit, but I 
> have the problem as well: no connections are ever 
> established out of my nat box (even after removing 
> obj.i386 and doing a full build).
> 
> But today I have observed the following tcpdump output on 
> the external interface on my nat machine:
> 
> 16:08:11.990717 IP truncated-ip - 24480 bytes missing! 
> 192.168.22.105.netbios-ns > (external host)
> 16:08:29.559769 IP truncated-ip - 15300 bytes missing! 
> 192.168.22.2 > (another external host): tcp
> 
> The last entry is seen when trying to do an slogin from an 
> internal machine, and the length of 15300+ looks very 
> suspect.
> 
> - Erik Bertelsen


I'm seeing this problem also.  From tcpdumping the traffic, I believe that
there is a missing htons() or ntohs() somewhere on the packet length (ip_len).

On my firewall (-current on an X86), the packet lengths are correct on one
side, but appear to be byte swapped on the other:


16:10:06.137907 128.101.X.Y > 128.101.A.B: icmp: ip reassembly time exceeded for 128.101.A.B.2049 > 128.101.X.Y.866218979: reply ok 1472 (frag 33112:1480@0+) (ttl 249, len 1500) [tos 0xc0]  (ttl 60, id 45277, len 576)
0x0000   45c0 0240 b0dd 0000 3c01 e7d8 8065 bdb3        E..@....<....e..
0x0010   8065 24c9 0b01 1ed6 0000 0000 4500 05dc        .e$.........E...
0x0020   8158 6000 f911 f770 8065 24c9 8065 bdb3        .X`....p.e$..e..
0x0030   0801 031f 0b94 660e 33a1 73e3 0000 0001        ......f.3.s.....
0x0040   0000 0000 0000 0000 0000 0000 0000 0000        ................
0x0050   0000                                           ..


16:10:12.957862 truncated-ip - 15810 bytes missing! 128.101.X.Y > 128.101.A.B: icmp: ip reassembly time exceeded for 128.101.A.B.2049 > 128.101.X.Y.1981772771: reply ok 1472 (frag 33129:1480@0+) (ttl 249, len 1500) [tos 0xc0]  (ttl 59, id 45284, len 16386, bad cksum e7d1 (->aa0e)!)
0x0000   45c0 4002 b0e4 0000 3b01 e7d1 8065 bdb3        E.@.....;....e..
0x0010   8065 24c9 0b01 287a 0000 0000 4500 05dc        .e$...(z....E...
0x0020   8169 6000 f911 f75f 8065 24c9 8065 bdb3        .i`...._.e$..e..
0x0030   0801 031f 05cc 32bc 761f 73e3 0000 0001        ......2.v.s.....
0x0040   0000 0000 0000 0000 0000 0000 0000 0000        ................
0x0050   0000                                           ..


The length (bytes 3 and 4 of the packets) of the first packet is 576 (0x0240),
but 16386 (0x4002) in the second.

It's probably a one line fix once the offending section of code is located.

Paul
-- 
Paul Dokas                                         dokas at cs.umn.edu
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."