On Thu, 15 Apr 1999, Olaf Seibert wrote:

> I have the same problem (PORTs not being rewritten) with a FreeBSD
> 2.2.7 ftp client. It IS sending the PORT commands all in one go,
> but they are still not rewritten. I even tried the posted patch.
> 
> Here is a single packet, picked up with tcpdump, on the "outside"
> network:
> 
> 17:09:09.086327 ijmeer.ubc.kun.nl.1039 > polder.ubc.kun.nl.ftp: P 623641000:623641029(29) ack 1561472507 win 17376 <nop,nop,timestamp 6806 1769175> (DF) [tos 0x10]
>                          4510 0051 0a6d 4000 3f06 ff81 83ae 152c
>                          83ae 1520 040f 0015 252c 01a8 5d12 2dfb
>                          8018 43e0 549f 0000 0101 080a 0000 1a96
>                          001a fed7 504f 5254 2031 3331 2c31 3734
>                                    P O  R T    1  3  1 , 1  7 4
>                          2c32 3338 2c31 3030 2c31 3536 2c37 300d
> 	                 , 2  3 8  , 1  0  0 , 1  5 6  , 7  0
> 
> (with manual ascii dump)

After some recompile/reboot cycles, each time adding more printf()s,
I found out that the NAT thinks the (TCP) checksum of the packet is
bad. This happens in ip_proxy.c: ap_check(). Of course the checksum
is really OK, since the other end accepts the packets. An obvious
candidate for confusing the fr_tcpsum() function is the presence of
options. Unfortunately, the fr_tcpsum() function still looks a bit
bewildering to me so I can't say for sure, or suggest a fix yet.

I thought about just omitting the checksum test, for experimental
purposes, but that probably won't work anyway because the ckecksum is
recomputed and put in the packet just a few lines further down, and that
would make the packet unacceptable to the other end.

-Olaf.
--
___ Olaf 'Rhialto' Seibert - rhialto@polder.ubc. ---- Unauthorized duplication,
\X/ .kun.nl ---- while sometimes necessary, is never as good as the real thing.