ipv6 IPSEC TCP ISSUE

[Madhav Bhamidipati]

Hi,

I have enabled ipsec for telnet port and did a b2b telnet on ipv6. My
telnet gets closed all of a sudden at some point, happens when ipsec
is enabled, I have attached the tcpdump capture. Has anybody faced
with similar issue? which part of the code I need to look into? Any
clues on how to debug this issue are highly appreciated.

One more observation from the print log is as follows:

1. Feb 28 05:34:30: %S4810:0 %KERN-2-INT: tcp_output:1824 SEQ =
2058087702 ACK = -1213400781 len= 7
2. Feb 28 05:34:30: %S4810:0 %KERN-2-INT: tcp_output:1824 SEQ =
2058087693 ACK = -1213400781 len= 9
3. Feb 28 05:34:29: %S4810:0 %KERN-2-INT: tcp_output:1824 SEQ =
2058087693 ACK = -1213400793 len= 0
4. Feb 28 05:34:29: %S4810:0 %KERN-2-INT: tcp_output:1824 SEQ =
2058087672 ACK = -1213400796 len= 21
5. Feb 28 05:34:27: %S4810:0 %KERN-2-INT: tcp_output:1824 SEQ =
2058087675 ACK = -1213400796 len= 0
6. Feb 28 05:34:27: %S4810:0 %KERN-2-INT: tcp_output:1824 SEQ =
2058087672 ACK = -1213400814 len= 3


in line 6 and 4, they look like re transmission but length seems
differing, connection is breaking every time this scenario happens, is
it happening due to different lengths?


regards,
Madhav

[Greg Troxel]

Try disabling SACK and maybe PMTU-D. There might be a bug lurking
somehow in this confluence, but it's hard to tell.
(See the last month or so of archives for a TCP issue mouse was having.)

[Madhav Bhamidipati]

Thanks Greg,

First, I will try disabling these options, btw how do I disable
PMTU-D, for sack tcp_do_sack I made it 0,

some how through sysctl is not working in my setup.


regards,
Madhav

Post by Greg Troxel
Try disabling SACK and maybe PMTU-D. There might be a bug lurking
somehow in this confluence, but it's hard to tell.
(See the last month or so of archives for a TCP issue mouse was having.)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

PMTU is spelled "mtudisc" :-)

$ sysctl -a |egrep mtudisc
net.inet.ip.mtudisc = 1
net.inet.ip.mtudisctimeout = 600
net.inet6.icmp6.mtudisc_hiwat = 1280
net.inet6.icmp6.mtudisc_lowat = 256


You really need a working sysctl, though.

[Greg Troxel]

Still no luck on connection drops though I disabled SACK and mtudisc.
I have a question here:

In case of TCP re-transmission I am seeing that length is getting
changed, will that lead to a problem in the first place? Currently my
telnet sessions are getting closed when a re-transmission when a
different length happens. I my opinion is that the packet shouldn't
get changed on re-transmission in any respect, right?

TCP doesn't retransmit packets; it retransmits segments which are newly
assembled into packets. The new transmission being a different length
is a clue that the sender is doing PMTU-D. It could be that there is a
broken firewall involved, but it could be a bug in NetBSD.

So, my advice, which will require significant effort to follow, is:

take tcpdumps at both ends of the *entire connection*, using 'tcpdump
-w' to a file.

install xplot-devel from pkgsrc. Read all the READMEs.

Read the TCP specs, both base, congestion control and PMTU-D including
blackhole detection, if you don't already understand all of this well.

Do "tcpdump -S -tt -r SENDER | tcpdump2xplot".
Perhaps netbsd-6 tcpdump has changed; fix tcpdump2xplot and send a
pach if so.

Repeat in a different directory with the RECEIVER tcpdump.

Look at the plots: xplot -x -y -tile sender.xplot receiver.xplot,
so that you look at the same direction from two network places at the
same time. In particular, you want to understand loss, and TCP's
response to loss. Keep in mind that both data and acks can be lost.

[Mouse]

Post by Greg Troxel

Post by Madhav Bhamidipati
In case of TCP re-transmission I am seeing that length is getting
changed, [...]. I my opinion is that the packet shouldn't get
changed on re-transmission in any respect, right?

TCP doesn't retransmit packets; it retransmits segments which are
newly assembled into packets. The new transmission being a different
length is a clue that the sender is doing PMTU-D.

Maybe. It depends on what the lengths in question are. (I don't
recall seeing the original, so this may have been given there.)

Another possible explanation is that the first transmission was at the
end of the data available to send and more octets have been queued to
be sent in the meantime, in which case I think the stack may end up
sending both retransmitted data and new data in a single packet.

Another possibility is that it's PMTU black hole detection in action.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Madhav Bhamidipati]

Hi Greg,

Still no luck on connection drops though I disabled SACK and mtudisc.
I have a question here:


In case of TCP re-transmission I am seeing that length is getting
changed, will that lead to a problem in the first place? Currently my
telnet sessions are getting closed when a re-transmission when a
different length happens. I my opinion is that the packet shouldn't
get changed on re-transmission in any respect, right?



-Madhav

Post by Greg Troxel
PMTU is spelled "mtudisc" :-)
$ sysctl -a |egrep mtudisc
net.inet.ip.mtudisc = 1
net.inet.ip.mtudisctimeout = 600
net.inet6.icmp6.mtudisc_hiwat = 1280
net.inet6.icmp6.mtudisc_lowat = 256
You really need a working sysctl, though.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de