TCP and natd issues

[Gary Allan]

Just completed a buildworld and install of DragonFly head 12/12/04 
12:00pm and it shows exactly the same behavior with natd and TCP 
connections as the current stable.

"tcpdump" is now working correctly and does not cause packet loss or 
lockups.

Attached is a small tcpdump from vr1 (router) and an ethereal capture 
from vr0 (desktop) from an attempt to view Google in a webrowser.

Running "Telnet <mailserver> 25" works without problems. Again only TCP 
traffic with a window size of 65535 seems to have this problem.

[This is the only common thing I can identify from traffic originating 
from PuTTY, Mozilla, IE, Thunderbird and Outlook.]

I'm tempted to compile snapshots from the past until I can find the 
commits that break things. Unfortunately my machine takes a while to do 
full buildworlds, any educated guesses as to when this may have been 
introduced are appreciated.

Regards

G.A.

hsu at XXXXXXXXXX wrote:
> Hi, can you check if a kernel between Dec 16 and Dec 20 works?  I suspect
> the breakage was before that, but want to rule out the huge commit I
> made on Dec 21.
>
> The other big networking changes went in on Dec 14, so a Dec 13 kernel
> would also be worth trying.
>
> Thanks.
>
> 							Jeffrey
>
Problems.

1. Using IPFW2 and natd does not process certain TCP connections correctly.

2. Running "tcpdump -i vr1" causes all traffic to be dropped.

When IPFW2 is configured for NAPT with natd I'm seeing certain TCP 
traffic blocked. I've used ethereal to capture the traffic from my 
desktop and the only pattern I can see is that all outgoing TCP traffic 
with a window size of 65535 never gets a response. (IE, FireFox, 
Outlook, Thunderbird). TCP connections using lower window sizes proceed 
normally ("telnet <mymailserver> 25" for example). UDP and ICMP traffic 
are also unaffected.

                      vr0     vr1
  [desktop]----------[ DragonFly ]----------[   Modem   ]--- NET
192.168.50.100      50.1        20.4      192.168.20.1
Here the ipfw logging shows responses from www.google.com and nat taking 
place. You can see that the packet from google was mapped back to 
192.168.50.100 but it was never actually received by my machine!

ipfw: 100 Divert 8668 TCP 66.102.11.104:80 192.168.20.4:1215 in via vr1
ipfw: 200 Accept TCP 66.102.11.104:80 192.168.50.100:1215 in via vr1
ipfw: 100 Divert 8668 TCP 66.102.11.104:80 192.168.50.100:1215 out via vr0
ipfw: 200 Accept TCP 66.102.11.104:80 192.168.50.100:1215 out via vr0
Also running tcpdump on the machine causes all network traffic passing 
through the box to be dropped until the tcpdump process is killed at the 
console. (as all SSH sessions drop out!)

The setup is identical to a FreeBSD 4.10 box that is working without 
issues. The machine is running DragonFly stable compiled 22-Dec-04.

Diagnostics

I've disabled SACK.
Bridging the interfaces works as expected.
I'm compiling the kernel to remove custom options and try under pf.
I can provide configs and traces to anyone interested, any help in 
resolving this would be appreciated.

Regards

G.A