SCTP abort_accept() error

[Vanegicloh J]

Dear all,

got nasty error when executed this code:

future<> abortTest() {
using namespace std::chrono_literals;
listen_options lo;

lo.proto = transport::SCTP;
lo.reuse_address = true;

auto l = seastar::listen(ipv4_addr{"127.0.0.1", 8081}, lo);

lg.info("Start accept");
(void)l.accept().then([](auto ar){ lg.info("OOPS"); }).handle_exception([](auto er) {});
co_await sleep(1s); // wait
lg.info("Accept started");
l.abort_accept();
co_await sleep(1s); // wait
}

This code works ok when i use TCP instead of SCTP.
Got this error on l.abort_accept() line:
unknown location(0): fatal error: in "abort_test": std::system_error: shutdown: Operation not supported

Thanks!

[Pavel Emelyanov]

This seems to be natural behavior of the kernel SCTP socket -- when it's in SYN_SENT
state the sctp_disconnect() just returns EOPNOTSUPP and that's it.

> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups "seastar-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to seastar-dev...@googlegroups.com <mailto:seastar-dev...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/seastar-dev/f4eb69a3-f2cd-473c-9f65-0e73371f8152n%40googlegroups.com <https://groups.google.com/d/msgid/seastar-dev/f4eb69a3-f2cd-473c-9f65-0e73371f8152n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Владимир Леонтьев]

So, as far as I understand, seastar api function server_socket::abort_accept have to abort accept. This function is the part of abstraction layer and supposed to be independent by protocol. But in case of SCTP this function just throws error.

Is there some valid way to implement  server_socket::abort_accept for SCTP?

For example, close the socket inside server_socket::abort_accept in case of SCTP, for TCP keep common behavior.

Thanks

[Pavel Emelyanov]

On 26.08.2022 10:23, Владимир Леонтьев wrote:
> So, as far as I understand, seastar api function server_socket::abort_accept have to abort accept. This function is the part of abstraction layer and supposed to be independent by protocol. But in case of SCTP this function just throws error.
>
> Is there some valid way to implement server_socket::abort_accept for SCTP?
> For example, close the socket inside server_socket::abort_accept in case of SCTP, for TCP keep common behavior.

I would say that seastar piggy-backs a fundamental feature-bug in the linux
kernel. The thing is that calling shutdown() on a not-connected socket (and
socket that's accept()-ed on is not connected) shouldn't happen. However, in
Linux "someone" decided that it would be a neat thread-safe way to abort
listeners. So we have what we have.

https://bugzilla.kernel.org/show_bug.cgi?id=106241

Closing a socket might not work, AFAIR (and the bug above confirms) closing()
a TCP socket doesn't abort accept()-ers. I pretty much admit that it's the
same for SCTP.

-- Pavel

> Thanks
> On Thursday, August 25, 2022 at 4:32:18 PM UTC+3 xe...@scylladb.com wrote:
>
>
>
> On 24.08.2022 16:52, Vanegicloh J wrote:
> > Dear all,
> > got nasty error when executed this code:
> >
> > future<> abortTest() {
> > using namespace std::chrono_literals;
> > listen_options lo;
> >
> > lo.proto = transport::SCTP;
> > lo.reuse_address = true;
> >
> > auto l = seastar::listen(ipv4_addr{"127.0.0.1", 8081}, lo);
> >

> > lg.info <http://lg.info>("Start accept");
> > (void)l.accept().then([](auto ar){ lg.info <http://lg.info>("OOPS"); }).handle_exception([](auto er) {});
> > co_await sleep(1s); // wait
> > lg.info <http://lg.info>("Accept started");

> > l.abort_accept();
> > co_await sleep(1s); // wait
> > }
> >
> > This code works ok when i use TCP instead of SCTP.
> > Got this error on l.abort_accept() line:
> > unknown location(0): fatal error: in "abort_test": std::system_error: shutdown: Operation not supported
>
> This seems to be natural behavior of the kernel SCTP socket -- when it's in SYN_SENT
> state the sctp_disconnect() just returns EOPNOTSUPP and that's it.
>
> > Thanks!
> >
> > --
> > You received this message because you are subscribed to the Google Groups "seastar-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to seastar-dev...@googlegroups.com <mailto:seastar-dev...@googlegroups.com>.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/seastar-dev/f4eb69a3-f2cd-473c-9f65-0e73371f8152n%40googlegroups.com <https://groups.google.com/d/msgid/seastar-dev/f4eb69a3-f2cd-473c-9f65-0e73371f8152n%40googlegroups.com> <https://groups.google.com/d/msgid/seastar-dev/f4eb69a3-f2cd-473c-9f65-0e73371f8152n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/seastar-dev/f4eb69a3-f2cd-473c-9f65-0e73371f8152n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google Groups "seastar-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to seastar-dev...@googlegroups.com <mailto:seastar-dev...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/seastar-dev/e5c94a12-5985-44aa-9680-b7857045022cn%40googlegroups.com <https://groups.google.com/d/msgid/seastar-dev/e5c94a12-5985-44aa-9680-b7857045022cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Niek Bouman]

I noticed that recently (July, 2024) someone addressed a related issue in the Linux kernel:

https://lore.kernel.org/netdev/171999662855.24990.17495213341...@kernel.org/T/

Not sure if that relates to this problem as well but interesting nonetheless.

Best,

Niek