netdev - Odd SCTP behaviour after remote host reboot.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Oct 2013 11:19:39 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	<netdev@...r.kernel.org>
Subject: Odd SCTP behaviour after remote host reboot.

I've just been given a very odd Wireshark trace from a customer.

There is a single SCTP association with src_port==dst_port=5104 (m3ua).
The remote system is reset and establishes a new association with the
same port numbers.
(The trace shows init/init_ack/cookie/cookie_ack with new verification tags.)
However the data seems to have been linked back to the original socket!
There are no further packets sent with the old verification tag.

This isn't what I expect, and seems inappropriate for a reliable transport.

The kernel they are running is old - 2.6.18-164 RHEL 5 update 4 from 2009!
My guess is that it won't include any SCTP updates - so the latest RHEL 5
kernel (2.6.18-358) won't be any better.

Any idea when this might have been fixed?
If they want to use RH, the latest kernel is based on 2.6.32.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html