RFC 2960 support about usrsctp HOT 12 CLOSED

Sure. I'm not aware on interop problems between an RFC 2960 compliant and an RFC 4960 compliant implementation. If you run into problems, please let me know.
usrsctp shares a lot of code with the FreeBSD kernel implementation and that implementation is used in the SIGTRAN environment.

from usrsctp.

AFAIK the most important part if Adler-32 to CRC-32 migration. We should be able to respond to clients still using Adler-32 with Adler-32 to make it work.
A careful reading of rfc4460 is required to figure out all differences I guess.

from usrsctp.

You are right. But I haven't seen Adler-32 for a while. usrsctp supports https://www.ietf.org/rfc/rfc3309.txt.

from usrsctp.

I don’t know of any implementation that uses Adler-32. Even Cisco’s IOS
left that behind long ago (I don’t remember any option to turn it back on either).

Speaking as one of the authors of RFC 4460 whats in there (and 4960) is what
was supposed to be implemented. There were not specific changes to “make the protocol
different” instead it was corrections to the wording so that people could implement it
correctly and inter-operate.

R

On Jul 2, 2016, at 7:26 PM, Michael Tüxen [email protected] wrote:

You are right. But I haven't seen Adler-32 for a while. usrsctp supports https://www.ietf.org/rfc/rfc3309.txt.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Randall Stewart
[email protected]
803-317-4952

from usrsctp.

Indeed, it seems the checksum is not the issue we're seeing.

Let me give some background first. We have a Cisco ITP and clients connecting to it with SCTP/M3UA. Some clients support only RFC 2960 and when ITP is configured in RFC 4960 mode, these clients can't connect. So we have to switch ITP to 2960 mode allow these old clients to connect.

Now, we're looking to replace the ITP with something else and looking for a good stack. We're currently trying to figure out why does this incompatibility happen, so that we have a working solution after we replace the ITP. I'll get back when we have more information.

from usrsctp.

Capture the traffic of a working and a non-working association setup in a .pcap file. You can send them to me privately and I can have a look, if you want.

from usrsctp.

@tuexen Can I send a file to the tuexen fh-muenster de?

So, compatibility issues I see so far:

1. usrsctp ABORTs when it received ERROR about unrecognized TSN parameter, which breaks connectivity to 2960 nodes. Compare to Linux SCTP version ignores this ERROR and keeps working. I will send you traces for this.

2. We do need to support Adler32 because of clients with equipment purchased in early 2000's. The issue I was looking at above was not related to checksum, but there are other connections where it's used. Stop supporting them is not really an option. I don't see any harm in adding Adler32 as an option with a large warning that it must not be used unless it's a compatibility issue. You can even disable this option at compile time by default.

3. I've been told there is also an issue with chunks processing difference (probably https://tools.ietf.org/html/rfc4460#section-2.1 and similar), but I haven't seen a trace myself yet. It'll take some time to get a trace for this. May be you know what can be wrong there?

from usrsctp.

Sure, that is my email address.

Need to look into a tracefile regarding 1).

Regarding the second item, it could be added. Integration is something one has to think about. It could be compile time option, not sure if it is the best option. You really want to figure out if you can't upgrade the nodes to also support CRC32C. Even if you purchased the stuff in the 2000's, there is no software update available?

Regarding the third item, lets look at a tracefile.

from usrsctp.

1. Sent you the traces. One is using Ubuntu 14.04 x64 LTS (kernel 3.19.0-64-generic), another one is using usrsctp current master (5d59dde). I may be wrong, but my reading of RFC is that ERROR is not actually a fatal condition by itself and thus can be handled gracefully which is what Linux kernel seem to be doing. This allows us to connect to 2960 servers.

2. It's not our equipment - it's equipment from peers we're connecting. So we can't dictate them what to use, unfortunately. I believe it should be a runtime option, ideally on a per-socket basis, because one may have a mix of clients connected to the same STP.

from usrsctp.

Regarding the traces: Could it be that you run the userland stack usrsctp on a machine which has an SCTP stack in the kernel? This doesn't work. This is how I think it could happen:
When a packet is received, a copy of it is delivered to the usrsctp and you see the expected result. In addition, another copy of the packet is delivered to the kernel stack, which doesn't know about the association and therefore sends an ABORT.
So the basic question is: Are you running usrsctp on a machine, running Linux for example, which has an SCTP in the kernel, lsmod would tell you for the Linux example?
Adding again support of Adler32 which is deprecated since September 2002, is a different beast. It could be done in principal, not sure I actually want it. Adding automatic detection is a possibility, it was done at around that time a lot.
@stewrtrs What do you think?

from usrsctp.

Well

I don’t think I want to add support for Adler32.. It is hard for me to believe any equipment out
there does it since it changed very very quickly (for the IETF). It seems to me to be
reverse progress and not something I am really willing to support.

R

On Jul 3, 2016, at 1:35 PM, Michael Tüxen [email protected] wrote:

Regarding the traces: Could it be that you run the userland stack usrsctp on a machine which has an SCTP stack in the kernel? This doesn't work. This is how I think it could happen:
When a packet is received, a copy of it is delivered to the usrsctp and you see the expected result. In addition, another copy of the packet is delivered to the kernel stack, which doesn't know about the association and therefore sends an ABORT.
So the basic question is: Are you running usrsctp on a machine, running Linux for example, which has an SCTP in the kernel, lsmod would tell you for the Linux example?
Adding again support of Adler32 which is deprecated since September 2002, is a different beast. It could be done in principal, not sure I actually want it. Adding automatic detection is a possibility, it was done at around that time a lot.
@stewrtrs What do you think?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Randall Stewart
[email protected]
803-317-4952

from usrsctp.

@tuexen That was indeed the case. I tried without 'sctp' kernel module and it works beautifully, thank you!

@tuexen @stewrtrs Unfortunately, there is still equipment out there working on Adler32 even today. Which is an issue for carriers who has a lot of interconnections. I know it doesn't feel right and I wouldn't want to support outdated and known-to-be-bad standard, but that's a requirement coming from practice. I would appreciate if you could add this. It's a minor effort with a significant practical outcome.

from usrsctp.