Subject: Re: kern/7368: ipnat not rewriting PORT command 100% of time
To: Andrew Brown <firstname.lastname@example.org>
From: Olaf Seibert <email@example.com>
Date: 04/15/1999 22:14:46
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"
> 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 'Rhialto' Seibert - firstname.lastname@example.org. ---- Unauthorized duplication,
\X/ .kun.nl ---- while sometimes necessary, is never as good as the real thing.