Subject: kern/17656: After other-host reboot, TCP ACKs being sent w/o ESP
To: None <gnats-bugs@gnats.netbsd.org>
From: None <wrstuden@netbsd.org>
List: netbsd-bugs
Date: 07/20/2002 00:20:27
>Number: 17656
>Category: kern
>Synopsis: After other-host reboot, TCP ACKs being sent w/o ESP
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jul 19 17:21:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Bill Studenmund
>Release: Mid-June 2002 macppc -current kernel
>Organization:
NetBSD
>Environment:
System: NetBSD tanis 1.6B NetBSD 1.6B (TANIS) #39: Thu Jun 20 19:16:56 PDT 2002 wrstuden@tanis:/y/src/sys/arch/macppc/compile/TANIS macppc
>Description:
I have a desktop macppc (with monitor) and a laptop i386.
Typically I work at the macppc and ssh to the laptop. I also direct
X back to the desktop. As I have IPsec/ESP set up between them,
xhost <laptop> suffices.
I rebooted the laptop, and I was then able to have X
programs connect to the desktop. I had ssh'd in and set
DISPLAY=<desktop>:0 . X programs would just time out trying to connect
to the display.
tcpdump shed some information:
# tcpdump -i wi0 -pn port 6000
tcpdump: listening on wi0
17:00:05.227262 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 4970> (DF)
17:00:08.219765 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 6 4970> (DF)
17:00:10.923185 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 11 4981> (DF)
17:00:14.218984 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 18 4981> (DF)
setkey -D -P on 10.0.0.2 for 10.0.0.7:
10.0.0.7[any] 10.0.0.2[any] any
in ipsec
esp/transport//require
spid=6 seq=1 pid=533
refcnt=5
10.0.0.2[any] 10.0.0.7[any] any
out ipsec
esp/transport//require
spid=5 seq=0 pid=533
refcnt=5
As I understand tcpdump, I should NOT be seeing anything, as the packets
tcpdump sees should be protocol ESP, not protocol TCP. So why is the
macppc sending unencrypted ACKs?
/etc/rc.d/ipsec reload "cured" the problem.
>How-To-Repeat:
I have seen this before.
Not sure. Have X clients log into an X server with the connection
covered by ESP. Reboot X client machine.
>Fix:
Not sure. I suspect that the problem is that the old IPsec policy
got tied to the X server listening socket, so that new connections
started with the wrong policy.
>Release-Note:
>Audit-Trail:
>Unformatted: