* Strange problem with SCTP+IPv6 @ 2020-06-21 15:56 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-21 15:56 UTC (permalink / raw) To: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp Cc: linux-kernel I've stumbled upon a strange problem with SCTP and IPv6. If I create an sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, then I make a connection to it using ::1, the connection will drop after 2.5 seconds with an ECONNRESET error. It only happens on SCTP, it doesn't have the issue if you connect to a full IPv6 address instead of ::1, and it doesn't happen if you don't set IPV6_V6ONLY. I have verified current end of tree kernel.org. I tried on an ARM system and x86_64. I haven't dug into the kernel to see if I could find anything yet, but I thought I would go ahead and report it. I am attaching a reproducer. Basically, compile the following code: gcc -g -o sctptest -Wall sctptest.c and run it in one window as a server: ./sctptest a (Pass in any option to be the server) and run the following in another window as the client: ./sctptest It disconnects after about 2.5 seconds. If it works, it should just sit there forever. -corey #include <stdio.h> #include <stdbool.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/select.h> #include <arpa/inet.h> #include <netinet/sctp.h> #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> static int getaddr(const char *addr, const char *port, bool listen, struct addrinfo **rai) { struct addrinfo *ai, hints; memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_ADDRCONFIG; if (listen) hints.ai_flags |= AI_PASSIVE; hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_STREAM; hints.ai_protocol = IPPROTO_SCTP; if (getaddrinfo(addr, port, &hints, &ai)) { perror("getaddrinfo"); return -1; } *rai = ai; return 0; } static int waitread(int s) { char data[1]; ssize_t rv; rv = read(s, data, sizeof(data)); if (rv == -1) { perror("read"); return -1; } printf("Read %d bytes\n", (int) rv); return 0; } static int do_server(void) { int err, ls, s, optval; struct addrinfo *ai; printf("Server\n"); err = getaddr("::", "3023", true, &ai); if (err) return err; ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (ls == -1) { perror("socket"); return -1; } optval = 1; if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, (void *)&optval, sizeof(optval)) == -1) { perror("setsockopt reuseaddr"); return -1; } /* Comment this out and it will work. */ if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, sizeof(optval)) == -1) { perror("setsockopt ipv6 only"); return -1; } err = bind(ls, ai->ai_addr, ai->ai_addrlen); if (err == -1) { perror("bind"); return -1; } err = listen(ls, 5); if (err == -1) { perror("listen"); return -1; } s = accept(ls, NULL, NULL); if (s == -1) { perror("accept"); return -1; } close(ls); err = waitread(s); close(s); return err; } static int do_client(void) { int err, s; struct addrinfo *ai; printf("Client\n"); err = getaddr("::1", "3023", false, &ai); if (err) return err; s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (s == -1) { perror("socket"); return -1; } err = connect(s, ai->ai_addr, ai->ai_addrlen); if (err == -1) { perror("connect"); return -1; } err = waitread(s); close(s); return err; } int main(int argc, char *argv[]) { int err; if (argc > 1) err = do_server(); else err = do_client(); return !!err; } ^ permalink raw reply [flat|nested] 55+ messages in thread
* Strange problem with SCTP+IPv6 @ 2020-06-21 15:56 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-21 15:56 UTC (permalink / raw) To: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp Cc: linux-kernel I've stumbled upon a strange problem with SCTP and IPv6. If I create an sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, then I make a connection to it using ::1, the connection will drop after 2.5 seconds with an ECONNRESET error. It only happens on SCTP, it doesn't have the issue if you connect to a full IPv6 address instead of ::1, and it doesn't happen if you don't set IPV6_V6ONLY. I have verified current end of tree kernel.org. I tried on an ARM system and x86_64. I haven't dug into the kernel to see if I could find anything yet, but I thought I would go ahead and report it. I am attaching a reproducer. Basically, compile the following code: gcc -g -o sctptest -Wall sctptest.c and run it in one window as a server: ./sctptest a (Pass in any option to be the server) and run the following in another window as the client: ./sctptest It disconnects after about 2.5 seconds. If it works, it should just sit there forever. -corey #include <stdio.h> #include <stdbool.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/select.h> #include <arpa/inet.h> #include <netinet/sctp.h> #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> static int getaddr(const char *addr, const char *port, bool listen, struct addrinfo **rai) { struct addrinfo *ai, hints; memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_ADDRCONFIG; if (listen) hints.ai_flags |= AI_PASSIVE; hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_STREAM; hints.ai_protocol = IPPROTO_SCTP; if (getaddrinfo(addr, port, &hints, &ai)) { perror("getaddrinfo"); return -1; } *rai = ai; return 0; } static int waitread(int s) { char data[1]; ssize_t rv; rv = read(s, data, sizeof(data)); if (rv = -1) { perror("read"); return -1; } printf("Read %d bytes\n", (int) rv); return 0; } static int do_server(void) { int err, ls, s, optval; struct addrinfo *ai; printf("Server\n"); err = getaddr("::", "3023", true, &ai); if (err) return err; ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (ls = -1) { perror("socket"); return -1; } optval = 1; if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, (void *)&optval, sizeof(optval)) = -1) { perror("setsockopt reuseaddr"); return -1; } /* Comment this out and it will work. */ if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, sizeof(optval)) = -1) { perror("setsockopt ipv6 only"); return -1; } err = bind(ls, ai->ai_addr, ai->ai_addrlen); if (err = -1) { perror("bind"); return -1; } err = listen(ls, 5); if (err = -1) { perror("listen"); return -1; } s = accept(ls, NULL, NULL); if (s = -1) { perror("accept"); return -1; } close(ls); err = waitread(s); close(s); return err; } static int do_client(void) { int err, s; struct addrinfo *ai; printf("Client\n"); err = getaddr("::1", "3023", false, &ai); if (err) return err; s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (s = -1) { perror("socket"); return -1; } err = connect(s, ai->ai_addr, ai->ai_addrlen); if (err = -1) { perror("connect"); return -1; } err = waitread(s); close(s); return err; } int main(int argc, char *argv[]) { int err; if (argc > 1) err = do_server(); else err = do_client(); return !!err; } ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-21 15:56 ` Corey Minyard @ 2020-06-22 12:01 ` Xin Long -1 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-22 11:52 UTC (permalink / raw) To: minyard Cc: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > I've stumbled upon a strange problem with SCTP and IPv6. If I create an > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > then I make a connection to it using ::1, the connection will drop after > 2.5 seconds with an ECONNRESET error. > > It only happens on SCTP, it doesn't have the issue if you connect to a > full IPv6 address instead of ::1, and it doesn't happen if you don't > set IPV6_V6ONLY. I have verified current end of tree kernel.org. > I tried on an ARM system and x86_64. > > I haven't dug into the kernel to see if I could find anything yet, but I > thought I would go ahead and report it. I am attaching a reproducer. > Basically, compile the following code: The code only set IPV6_V6ONLY on server side, so the client side will still bind all the local ipv4 addresses (as you didn't call bind() to bind any specific addresses ). Then after the connection is created, the client will send HB on the v4 paths to the server. The server will abort the connection, as it can't support v4. So you can work around it by either: - set IPV6_V6ONLY on client side. or - bind to the specific v6 addresses on the client side. I don't see RFC said something about this. So it may not be a good idea to change the current behaviour to not establish the connection in this case, which may cause regression. > > gcc -g -o sctptest -Wall sctptest.c > > and run it in one window as a server: > > ./sctptest a > > (Pass in any option to be the server) and run the following in another > window as the client: > > ./sctptest > > It disconnects after about 2.5 seconds. If it works, it should just sit > there forever. > > -corey > > > #include <stdio.h> > #include <stdbool.h> > #include <string.h> > #include <unistd.h> > #include <fcntl.h> > #include <sys/select.h> > #include <arpa/inet.h> > #include <netinet/sctp.h> > #include <sys/types.h> > #include <sys/socket.h> > #include <netdb.h> > > static int > getaddr(const char *addr, const char *port, bool listen, > struct addrinfo **rai) > { > struct addrinfo *ai, hints; > > memset(&hints, 0, sizeof(hints)); > hints.ai_flags = AI_ADDRCONFIG; > if (listen) > hints.ai_flags |= AI_PASSIVE; > hints.ai_family = AF_UNSPEC; > hints.ai_socktype = SOCK_STREAM; > hints.ai_protocol = IPPROTO_SCTP; > if (getaddrinfo(addr, port, &hints, &ai)) { > perror("getaddrinfo"); > return -1; > } > > *rai = ai; > return 0; > } > > static int > waitread(int s) > { > char data[1]; > ssize_t rv; > > rv = read(s, data, sizeof(data)); > if (rv = -1) { > perror("read"); > return -1; > } > printf("Read %d bytes\n", (int) rv); > return 0; > } > > static int > do_server(void) > { > int err, ls, s, optval; > struct addrinfo *ai; > > printf("Server\n"); > > err = getaddr("::", "3023", true, &ai); > if (err) > return err; > > ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > if (ls = -1) { > perror("socket"); > return -1; > } > > optval = 1; > if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > (void *)&optval, sizeof(optval)) = -1) { > perror("setsockopt reuseaddr"); > return -1; > } > > /* Comment this out and it will work. */ > if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > sizeof(optval)) = -1) { > perror("setsockopt ipv6 only"); > return -1; > } > > err = bind(ls, ai->ai_addr, ai->ai_addrlen); > if (err = -1) { > perror("bind"); > return -1; > } > > err = listen(ls, 5); > if (err = -1) { > perror("listen"); > return -1; > } > > s = accept(ls, NULL, NULL); > if (s = -1) { > perror("accept"); > return -1; > } > > close(ls); > > err = waitread(s); > close(s); > return err; > } > > static int > do_client(void) > { > int err, s; > struct addrinfo *ai; > > printf("Client\n"); > > err = getaddr("::1", "3023", false, &ai); > if (err) > return err; > > s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > if (s = -1) { > perror("socket"); > return -1; > } > > err = connect(s, ai->ai_addr, ai->ai_addrlen); > if (err = -1) { > perror("connect"); > return -1; > } > > err = waitread(s); > close(s); > return err; > } > > int > main(int argc, char *argv[]) > { > int err; > > if (argc > 1) > err = do_server(); > else > err = do_client(); > return !!err; > } > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-22 12:01 ` Xin Long 0 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-22 12:01 UTC (permalink / raw) To: minyard Cc: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > I've stumbled upon a strange problem with SCTP and IPv6. If I create an > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > then I make a connection to it using ::1, the connection will drop after > 2.5 seconds with an ECONNRESET error. > > It only happens on SCTP, it doesn't have the issue if you connect to a > full IPv6 address instead of ::1, and it doesn't happen if you don't > set IPV6_V6ONLY. I have verified current end of tree kernel.org. > I tried on an ARM system and x86_64. > > I haven't dug into the kernel to see if I could find anything yet, but I > thought I would go ahead and report it. I am attaching a reproducer. > Basically, compile the following code: The code only set IPV6_V6ONLY on server side, so the client side will still bind all the local ipv4 addresses (as you didn't call bind() to bind any specific addresses ). Then after the connection is created, the client will send HB on the v4 paths to the server. The server will abort the connection, as it can't support v4. So you can work around it by either: - set IPV6_V6ONLY on client side. or - bind to the specific v6 addresses on the client side. I don't see RFC said something about this. So it may not be a good idea to change the current behaviour to not establish the connection in this case, which may cause regression. > > gcc -g -o sctptest -Wall sctptest.c > > and run it in one window as a server: > > ./sctptest a > > (Pass in any option to be the server) and run the following in another > window as the client: > > ./sctptest > > It disconnects after about 2.5 seconds. If it works, it should just sit > there forever. > > -corey > > > #include <stdio.h> > #include <stdbool.h> > #include <string.h> > #include <unistd.h> > #include <fcntl.h> > #include <sys/select.h> > #include <arpa/inet.h> > #include <netinet/sctp.h> > #include <sys/types.h> > #include <sys/socket.h> > #include <netdb.h> > > static int > getaddr(const char *addr, const char *port, bool listen, > struct addrinfo **rai) > { > struct addrinfo *ai, hints; > > memset(&hints, 0, sizeof(hints)); > hints.ai_flags = AI_ADDRCONFIG; > if (listen) > hints.ai_flags |= AI_PASSIVE; > hints.ai_family = AF_UNSPEC; > hints.ai_socktype = SOCK_STREAM; > hints.ai_protocol = IPPROTO_SCTP; > if (getaddrinfo(addr, port, &hints, &ai)) { > perror("getaddrinfo"); > return -1; > } > > *rai = ai; > return 0; > } > > static int > waitread(int s) > { > char data[1]; > ssize_t rv; > > rv = read(s, data, sizeof(data)); > if (rv == -1) { > perror("read"); > return -1; > } > printf("Read %d bytes\n", (int) rv); > return 0; > } > > static int > do_server(void) > { > int err, ls, s, optval; > struct addrinfo *ai; > > printf("Server\n"); > > err = getaddr("::", "3023", true, &ai); > if (err) > return err; > > ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > if (ls == -1) { > perror("socket"); > return -1; > } > > optval = 1; > if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > (void *)&optval, sizeof(optval)) == -1) { > perror("setsockopt reuseaddr"); > return -1; > } > > /* Comment this out and it will work. */ > if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > sizeof(optval)) == -1) { > perror("setsockopt ipv6 only"); > return -1; > } > > err = bind(ls, ai->ai_addr, ai->ai_addrlen); > if (err == -1) { > perror("bind"); > return -1; > } > > err = listen(ls, 5); > if (err == -1) { > perror("listen"); > return -1; > } > > s = accept(ls, NULL, NULL); > if (s == -1) { > perror("accept"); > return -1; > } > > close(ls); > > err = waitread(s); > close(s); > return err; > } > > static int > do_client(void) > { > int err, s; > struct addrinfo *ai; > > printf("Client\n"); > > err = getaddr("::1", "3023", false, &ai); > if (err) > return err; > > s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > if (s == -1) { > perror("socket"); > return -1; > } > > err = connect(s, ai->ai_addr, ai->ai_addrlen); > if (err == -1) { > perror("connect"); > return -1; > } > > err = waitread(s); > close(s); > return err; > } > > int > main(int argc, char *argv[]) > { > int err; > > if (argc > 1) > err = do_server(); > else > err = do_client(); > return !!err; > } > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-22 12:01 ` Xin Long @ 2020-06-22 12:32 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-22 12:32 UTC (permalink / raw) To: Xin Long Cc: minyard, Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML > On 22. Jun 2020, at 14:01, Xin Long <lucien.xin@gmail.com> wrote: > > On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >> >> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >> then I make a connection to it using ::1, the connection will drop after >> 2.5 seconds with an ECONNRESET error. >> >> It only happens on SCTP, it doesn't have the issue if you connect to a >> full IPv6 address instead of ::1, and it doesn't happen if you don't >> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >> I tried on an ARM system and x86_64. >> >> I haven't dug into the kernel to see if I could find anything yet, but I >> thought I would go ahead and report it. I am attaching a reproducer. >> Basically, compile the following code: > The code only set IPV6_V6ONLY on server side, so the client side will > still bind all the local ipv4 addresses (as you didn't call bind() to > bind any specific addresses ). Then after the connection is created, Let's focus on the loopback addresses ::1 and 127.0.0.1. So the server will only use ::1. The client will send an INIT from ::1 to ::1 and lists 127.0.0.1 and ::1. That is what I would expect. Is that happening? The server would respond with an INIT-ACK from ::1 to ::1 and would not list any IP addresses. Especially not 127.0.0.1, since it is IPv6 only. After the association has beed established, the client can't send any IPv4 packet to the server, since the server did not announce any. The server can't send any IPv4 packets since it is IPv6 only. This is what I would expect and this scenario should just work. What am I missing? Best regards Michael > the client will send HB on the v4 paths to the server. The server > will abort the connection, as it can't support v4. > > So you can work around it by either: > > - set IPV6_V6ONLY on client side. > > or > > - bind to the specific v6 addresses on the client side. > > I don't see RFC said something about this. > So it may not be a good idea to change the current behaviour > to not establish the connection in this case, which may cause regression. > >> >> gcc -g -o sctptest -Wall sctptest.c >> >> and run it in one window as a server: >> >> ./sctptest a >> >> (Pass in any option to be the server) and run the following in another >> window as the client: >> >> ./sctptest >> >> It disconnects after about 2.5 seconds. If it works, it should just sit >> there forever. >> >> -corey >> >> >> #include <stdio.h> >> #include <stdbool.h> >> #include <string.h> >> #include <unistd.h> >> #include <fcntl.h> >> #include <sys/select.h> >> #include <arpa/inet.h> >> #include <netinet/sctp.h> >> #include <sys/types.h> >> #include <sys/socket.h> >> #include <netdb.h> >> >> static int >> getaddr(const char *addr, const char *port, bool listen, >> struct addrinfo **rai) >> { >> struct addrinfo *ai, hints; >> >> memset(&hints, 0, sizeof(hints)); >> hints.ai_flags = AI_ADDRCONFIG; >> if (listen) >> hints.ai_flags |= AI_PASSIVE; >> hints.ai_family = AF_UNSPEC; >> hints.ai_socktype = SOCK_STREAM; >> hints.ai_protocol = IPPROTO_SCTP; >> if (getaddrinfo(addr, port, &hints, &ai)) { >> perror("getaddrinfo"); >> return -1; >> } >> >> *rai = ai; >> return 0; >> } >> >> static int >> waitread(int s) >> { >> char data[1]; >> ssize_t rv; >> >> rv = read(s, data, sizeof(data)); >> if (rv == -1) { >> perror("read"); >> return -1; >> } >> printf("Read %d bytes\n", (int) rv); >> return 0; >> } >> >> static int >> do_server(void) >> { >> int err, ls, s, optval; >> struct addrinfo *ai; >> >> printf("Server\n"); >> >> err = getaddr("::", "3023", true, &ai); >> if (err) >> return err; >> >> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >> if (ls == -1) { >> perror("socket"); >> return -1; >> } >> >> optval = 1; >> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, >> (void *)&optval, sizeof(optval)) == -1) { >> perror("setsockopt reuseaddr"); >> return -1; >> } >> >> /* Comment this out and it will work. */ >> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, >> sizeof(optval)) == -1) { >> perror("setsockopt ipv6 only"); >> return -1; >> } >> >> err = bind(ls, ai->ai_addr, ai->ai_addrlen); >> if (err == -1) { >> perror("bind"); >> return -1; >> } >> >> err = listen(ls, 5); >> if (err == -1) { >> perror("listen"); >> return -1; >> } >> >> s = accept(ls, NULL, NULL); >> if (s == -1) { >> perror("accept"); >> return -1; >> } >> >> close(ls); >> >> err = waitread(s); >> close(s); >> return err; >> } >> >> static int >> do_client(void) >> { >> int err, s; >> struct addrinfo *ai; >> >> printf("Client\n"); >> >> err = getaddr("::1", "3023", false, &ai); >> if (err) >> return err; >> >> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >> if (s == -1) { >> perror("socket"); >> return -1; >> } >> >> err = connect(s, ai->ai_addr, ai->ai_addrlen); >> if (err == -1) { >> perror("connect"); >> return -1; >> } >> >> err = waitread(s); >> close(s); >> return err; >> } >> >> int >> main(int argc, char *argv[]) >> { >> int err; >> >> if (argc > 1) >> err = do_server(); >> else >> err = do_client(); >> return !!err; >> } >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-22 12:32 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-22 12:32 UTC (permalink / raw) To: Xin Long Cc: minyard, Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML > On 22. Jun 2020, at 14:01, Xin Long <lucien.xin@gmail.com> wrote: > > On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >> >> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >> then I make a connection to it using ::1, the connection will drop after >> 2.5 seconds with an ECONNRESET error. >> >> It only happens on SCTP, it doesn't have the issue if you connect to a >> full IPv6 address instead of ::1, and it doesn't happen if you don't >> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >> I tried on an ARM system and x86_64. >> >> I haven't dug into the kernel to see if I could find anything yet, but I >> thought I would go ahead and report it. I am attaching a reproducer. >> Basically, compile the following code: > The code only set IPV6_V6ONLY on server side, so the client side will > still bind all the local ipv4 addresses (as you didn't call bind() to > bind any specific addresses ). Then after the connection is created, Let's focus on the loopback addresses ::1 and 127.0.0.1. So the server will only use ::1. The client will send an INIT from ::1 to ::1 and lists 127.0.0.1 and ::1. That is what I would expect. Is that happening? The server would respond with an INIT-ACK from ::1 to ::1 and would not list any IP addresses. Especially not 127.0.0.1, since it is IPv6 only. After the association has beed established, the client can't send any IPv4 packet to the server, since the server did not announce any. The server can't send any IPv4 packets since it is IPv6 only. This is what I would expect and this scenario should just work. What am I missing? Best regards Michael > the client will send HB on the v4 paths to the server. The server > will abort the connection, as it can't support v4. > > So you can work around it by either: > > - set IPV6_V6ONLY on client side. > > or > > - bind to the specific v6 addresses on the client side. > > I don't see RFC said something about this. > So it may not be a good idea to change the current behaviour > to not establish the connection in this case, which may cause regression. > >> >> gcc -g -o sctptest -Wall sctptest.c >> >> and run it in one window as a server: >> >> ./sctptest a >> >> (Pass in any option to be the server) and run the following in another >> window as the client: >> >> ./sctptest >> >> It disconnects after about 2.5 seconds. If it works, it should just sit >> there forever. >> >> -corey >> >> >> #include <stdio.h> >> #include <stdbool.h> >> #include <string.h> >> #include <unistd.h> >> #include <fcntl.h> >> #include <sys/select.h> >> #include <arpa/inet.h> >> #include <netinet/sctp.h> >> #include <sys/types.h> >> #include <sys/socket.h> >> #include <netdb.h> >> >> static int >> getaddr(const char *addr, const char *port, bool listen, >> struct addrinfo **rai) >> { >> struct addrinfo *ai, hints; >> >> memset(&hints, 0, sizeof(hints)); >> hints.ai_flags = AI_ADDRCONFIG; >> if (listen) >> hints.ai_flags |= AI_PASSIVE; >> hints.ai_family = AF_UNSPEC; >> hints.ai_socktype = SOCK_STREAM; >> hints.ai_protocol = IPPROTO_SCTP; >> if (getaddrinfo(addr, port, &hints, &ai)) { >> perror("getaddrinfo"); >> return -1; >> } >> >> *rai = ai; >> return 0; >> } >> >> static int >> waitread(int s) >> { >> char data[1]; >> ssize_t rv; >> >> rv = read(s, data, sizeof(data)); >> if (rv = -1) { >> perror("read"); >> return -1; >> } >> printf("Read %d bytes\n", (int) rv); >> return 0; >> } >> >> static int >> do_server(void) >> { >> int err, ls, s, optval; >> struct addrinfo *ai; >> >> printf("Server\n"); >> >> err = getaddr("::", "3023", true, &ai); >> if (err) >> return err; >> >> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >> if (ls = -1) { >> perror("socket"); >> return -1; >> } >> >> optval = 1; >> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, >> (void *)&optval, sizeof(optval)) = -1) { >> perror("setsockopt reuseaddr"); >> return -1; >> } >> >> /* Comment this out and it will work. */ >> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, >> sizeof(optval)) = -1) { >> perror("setsockopt ipv6 only"); >> return -1; >> } >> >> err = bind(ls, ai->ai_addr, ai->ai_addrlen); >> if (err = -1) { >> perror("bind"); >> return -1; >> } >> >> err = listen(ls, 5); >> if (err = -1) { >> perror("listen"); >> return -1; >> } >> >> s = accept(ls, NULL, NULL); >> if (s = -1) { >> perror("accept"); >> return -1; >> } >> >> close(ls); >> >> err = waitread(s); >> close(s); >> return err; >> } >> >> static int >> do_client(void) >> { >> int err, s; >> struct addrinfo *ai; >> >> printf("Client\n"); >> >> err = getaddr("::1", "3023", false, &ai); >> if (err) >> return err; >> >> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >> if (s = -1) { >> perror("socket"); >> return -1; >> } >> >> err = connect(s, ai->ai_addr, ai->ai_addrlen); >> if (err = -1) { >> perror("connect"); >> return -1; >> } >> >> err = waitread(s); >> close(s); >> return err; >> } >> >> int >> main(int argc, char *argv[]) >> { >> int err; >> >> if (argc > 1) >> err = do_server(); >> else >> err = do_client(); >> return !!err; >> } >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-22 12:01 ` Xin Long @ 2020-06-22 16:57 ` Corey Minyard -1 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-22 16:57 UTC (permalink / raw) To: Xin Long Cc: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > then I make a connection to it using ::1, the connection will drop after > > 2.5 seconds with an ECONNRESET error. > > > > It only happens on SCTP, it doesn't have the issue if you connect to a > > full IPv6 address instead of ::1, and it doesn't happen if you don't > > set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > I tried on an ARM system and x86_64. > > > > I haven't dug into the kernel to see if I could find anything yet, but I > > thought I would go ahead and report it. I am attaching a reproducer. > > Basically, compile the following code: > The code only set IPV6_V6ONLY on server side, so the client side will > still bind all the local ipv4 addresses (as you didn't call bind() to > bind any specific addresses ). Then after the connection is created, > the client will send HB on the v4 paths to the server. The server > will abort the connection, as it can't support v4. > > So you can work around it by either: > > - set IPV6_V6ONLY on client side. > > or > > - bind to the specific v6 addresses on the client side. > > I don't see RFC said something about this. > So it may not be a good idea to change the current behaviour > to not establish the connection in this case, which may cause regression. Ok, I understand this. It's a little strange, but I see why it works this way. Thanks, -corey > > > > > gcc -g -o sctptest -Wall sctptest.c > > > > and run it in one window as a server: > > > > ./sctptest a > > > > (Pass in any option to be the server) and run the following in another > > window as the client: > > > > ./sctptest > > > > It disconnects after about 2.5 seconds. If it works, it should just sit > > there forever. > > > > -corey > > > > > > #include <stdio.h> > > #include <stdbool.h> > > #include <string.h> > > #include <unistd.h> > > #include <fcntl.h> > > #include <sys/select.h> > > #include <arpa/inet.h> > > #include <netinet/sctp.h> > > #include <sys/types.h> > > #include <sys/socket.h> > > #include <netdb.h> > > > > static int > > getaddr(const char *addr, const char *port, bool listen, > > struct addrinfo **rai) > > { > > struct addrinfo *ai, hints; > > > > memset(&hints, 0, sizeof(hints)); > > hints.ai_flags = AI_ADDRCONFIG; > > if (listen) > > hints.ai_flags |= AI_PASSIVE; > > hints.ai_family = AF_UNSPEC; > > hints.ai_socktype = SOCK_STREAM; > > hints.ai_protocol = IPPROTO_SCTP; > > if (getaddrinfo(addr, port, &hints, &ai)) { > > perror("getaddrinfo"); > > return -1; > > } > > > > *rai = ai; > > return 0; > > } > > > > static int > > waitread(int s) > > { > > char data[1]; > > ssize_t rv; > > > > rv = read(s, data, sizeof(data)); > > if (rv == -1) { > > perror("read"); > > return -1; > > } > > printf("Read %d bytes\n", (int) rv); > > return 0; > > } > > > > static int > > do_server(void) > > { > > int err, ls, s, optval; > > struct addrinfo *ai; > > > > printf("Server\n"); > > > > err = getaddr("::", "3023", true, &ai); > > if (err) > > return err; > > > > ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > if (ls == -1) { > > perror("socket"); > > return -1; > > } > > > > optval = 1; > > if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > (void *)&optval, sizeof(optval)) == -1) { > > perror("setsockopt reuseaddr"); > > return -1; > > } > > > > /* Comment this out and it will work. */ > > if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > sizeof(optval)) == -1) { > > perror("setsockopt ipv6 only"); > > return -1; > > } > > > > err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > if (err == -1) { > > perror("bind"); > > return -1; > > } > > > > err = listen(ls, 5); > > if (err == -1) { > > perror("listen"); > > return -1; > > } > > > > s = accept(ls, NULL, NULL); > > if (s == -1) { > > perror("accept"); > > return -1; > > } > > > > close(ls); > > > > err = waitread(s); > > close(s); > > return err; > > } > > > > static int > > do_client(void) > > { > > int err, s; > > struct addrinfo *ai; > > > > printf("Client\n"); > > > > err = getaddr("::1", "3023", false, &ai); > > if (err) > > return err; > > > > s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > if (s == -1) { > > perror("socket"); > > return -1; > > } > > > > err = connect(s, ai->ai_addr, ai->ai_addrlen); > > if (err == -1) { > > perror("connect"); > > return -1; > > } > > > > err = waitread(s); > > close(s); > > return err; > > } > > > > int > > main(int argc, char *argv[]) > > { > > int err; > > > > if (argc > 1) > > err = do_server(); > > else > > err = do_client(); > > return !!err; > > } > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-22 16:57 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-22 16:57 UTC (permalink / raw) To: Xin Long Cc: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > then I make a connection to it using ::1, the connection will drop after > > 2.5 seconds with an ECONNRESET error. > > > > It only happens on SCTP, it doesn't have the issue if you connect to a > > full IPv6 address instead of ::1, and it doesn't happen if you don't > > set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > I tried on an ARM system and x86_64. > > > > I haven't dug into the kernel to see if I could find anything yet, but I > > thought I would go ahead and report it. I am attaching a reproducer. > > Basically, compile the following code: > The code only set IPV6_V6ONLY on server side, so the client side will > still bind all the local ipv4 addresses (as you didn't call bind() to > bind any specific addresses ). Then after the connection is created, > the client will send HB on the v4 paths to the server. The server > will abort the connection, as it can't support v4. > > So you can work around it by either: > > - set IPV6_V6ONLY on client side. > > or > > - bind to the specific v6 addresses on the client side. > > I don't see RFC said something about this. > So it may not be a good idea to change the current behaviour > to not establish the connection in this case, which may cause regression. Ok, I understand this. It's a little strange, but I see why it works this way. Thanks, -corey > > > > > gcc -g -o sctptest -Wall sctptest.c > > > > and run it in one window as a server: > > > > ./sctptest a > > > > (Pass in any option to be the server) and run the following in another > > window as the client: > > > > ./sctptest > > > > It disconnects after about 2.5 seconds. If it works, it should just sit > > there forever. > > > > -corey > > > > > > #include <stdio.h> > > #include <stdbool.h> > > #include <string.h> > > #include <unistd.h> > > #include <fcntl.h> > > #include <sys/select.h> > > #include <arpa/inet.h> > > #include <netinet/sctp.h> > > #include <sys/types.h> > > #include <sys/socket.h> > > #include <netdb.h> > > > > static int > > getaddr(const char *addr, const char *port, bool listen, > > struct addrinfo **rai) > > { > > struct addrinfo *ai, hints; > > > > memset(&hints, 0, sizeof(hints)); > > hints.ai_flags = AI_ADDRCONFIG; > > if (listen) > > hints.ai_flags |= AI_PASSIVE; > > hints.ai_family = AF_UNSPEC; > > hints.ai_socktype = SOCK_STREAM; > > hints.ai_protocol = IPPROTO_SCTP; > > if (getaddrinfo(addr, port, &hints, &ai)) { > > perror("getaddrinfo"); > > return -1; > > } > > > > *rai = ai; > > return 0; > > } > > > > static int > > waitread(int s) > > { > > char data[1]; > > ssize_t rv; > > > > rv = read(s, data, sizeof(data)); > > if (rv = -1) { > > perror("read"); > > return -1; > > } > > printf("Read %d bytes\n", (int) rv); > > return 0; > > } > > > > static int > > do_server(void) > > { > > int err, ls, s, optval; > > struct addrinfo *ai; > > > > printf("Server\n"); > > > > err = getaddr("::", "3023", true, &ai); > > if (err) > > return err; > > > > ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > if (ls = -1) { > > perror("socket"); > > return -1; > > } > > > > optval = 1; > > if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > (void *)&optval, sizeof(optval)) = -1) { > > perror("setsockopt reuseaddr"); > > return -1; > > } > > > > /* Comment this out and it will work. */ > > if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > sizeof(optval)) = -1) { > > perror("setsockopt ipv6 only"); > > return -1; > > } > > > > err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > if (err = -1) { > > perror("bind"); > > return -1; > > } > > > > err = listen(ls, 5); > > if (err = -1) { > > perror("listen"); > > return -1; > > } > > > > s = accept(ls, NULL, NULL); > > if (s = -1) { > > perror("accept"); > > return -1; > > } > > > > close(ls); > > > > err = waitread(s); > > close(s); > > return err; > > } > > > > static int > > do_client(void) > > { > > int err, s; > > struct addrinfo *ai; > > > > printf("Client\n"); > > > > err = getaddr("::1", "3023", false, &ai); > > if (err) > > return err; > > > > s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > if (s = -1) { > > perror("socket"); > > return -1; > > } > > > > err = connect(s, ai->ai_addr, ai->ai_addrlen); > > if (err = -1) { > > perror("connect"); > > return -1; > > } > > > > err = waitread(s); > > close(s); > > return err; > > } > > > > int > > main(int argc, char *argv[]) > > { > > int err; > > > > if (argc > 1) > > err = do_server(); > > else > > err = do_client(); > > return !!err; > > } > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-22 16:57 ` Corey Minyard @ 2020-06-22 18:01 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-22 18:01 UTC (permalink / raw) To: minyard Cc: Xin Long, Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>> >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>> then I make a connection to it using ::1, the connection will drop after >>> 2.5 seconds with an ECONNRESET error. >>> >>> It only happens on SCTP, it doesn't have the issue if you connect to a >>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>> I tried on an ARM system and x86_64. >>> >>> I haven't dug into the kernel to see if I could find anything yet, but I >>> thought I would go ahead and report it. I am attaching a reproducer. >>> Basically, compile the following code: >> The code only set IPV6_V6ONLY on server side, so the client side will >> still bind all the local ipv4 addresses (as you didn't call bind() to >> bind any specific addresses ). Then after the connection is created, >> the client will send HB on the v4 paths to the server. The server >> will abort the connection, as it can't support v4. >> >> So you can work around it by either: >> >> - set IPV6_V6ONLY on client side. >> >> or >> >> - bind to the specific v6 addresses on the client side. >> >> I don't see RFC said something about this. >> So it may not be a good idea to change the current behaviour >> to not establish the connection in this case, which may cause regression. > > Ok, I understand this. It's a little strange, but I see why it works > this way. I don't. I would expect it to work as I described in my email. Could someone explain me how and why it is behaving different from my expectation? Best regards Michael > > Thanks, > > -corey > >> >>> >>> gcc -g -o sctptest -Wall sctptest.c >>> >>> and run it in one window as a server: >>> >>> ./sctptest a >>> >>> (Pass in any option to be the server) and run the following in another >>> window as the client: >>> >>> ./sctptest >>> >>> It disconnects after about 2.5 seconds. If it works, it should just sit >>> there forever. >>> >>> -corey >>> >>> >>> #include <stdio.h> >>> #include <stdbool.h> >>> #include <string.h> >>> #include <unistd.h> >>> #include <fcntl.h> >>> #include <sys/select.h> >>> #include <arpa/inet.h> >>> #include <netinet/sctp.h> >>> #include <sys/types.h> >>> #include <sys/socket.h> >>> #include <netdb.h> >>> >>> static int >>> getaddr(const char *addr, const char *port, bool listen, >>> struct addrinfo **rai) >>> { >>> struct addrinfo *ai, hints; >>> >>> memset(&hints, 0, sizeof(hints)); >>> hints.ai_flags = AI_ADDRCONFIG; >>> if (listen) >>> hints.ai_flags |= AI_PASSIVE; >>> hints.ai_family = AF_UNSPEC; >>> hints.ai_socktype = SOCK_STREAM; >>> hints.ai_protocol = IPPROTO_SCTP; >>> if (getaddrinfo(addr, port, &hints, &ai)) { >>> perror("getaddrinfo"); >>> return -1; >>> } >>> >>> *rai = ai; >>> return 0; >>> } >>> >>> static int >>> waitread(int s) >>> { >>> char data[1]; >>> ssize_t rv; >>> >>> rv = read(s, data, sizeof(data)); >>> if (rv == -1) { >>> perror("read"); >>> return -1; >>> } >>> printf("Read %d bytes\n", (int) rv); >>> return 0; >>> } >>> >>> static int >>> do_server(void) >>> { >>> int err, ls, s, optval; >>> struct addrinfo *ai; >>> >>> printf("Server\n"); >>> >>> err = getaddr("::", "3023", true, &ai); >>> if (err) >>> return err; >>> >>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>> if (ls == -1) { >>> perror("socket"); >>> return -1; >>> } >>> >>> optval = 1; >>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, >>> (void *)&optval, sizeof(optval)) == -1) { >>> perror("setsockopt reuseaddr"); >>> return -1; >>> } >>> >>> /* Comment this out and it will work. */ >>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, >>> sizeof(optval)) == -1) { >>> perror("setsockopt ipv6 only"); >>> return -1; >>> } >>> >>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); >>> if (err == -1) { >>> perror("bind"); >>> return -1; >>> } >>> >>> err = listen(ls, 5); >>> if (err == -1) { >>> perror("listen"); >>> return -1; >>> } >>> >>> s = accept(ls, NULL, NULL); >>> if (s == -1) { >>> perror("accept"); >>> return -1; >>> } >>> >>> close(ls); >>> >>> err = waitread(s); >>> close(s); >>> return err; >>> } >>> >>> static int >>> do_client(void) >>> { >>> int err, s; >>> struct addrinfo *ai; >>> >>> printf("Client\n"); >>> >>> err = getaddr("::1", "3023", false, &ai); >>> if (err) >>> return err; >>> >>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>> if (s == -1) { >>> perror("socket"); >>> return -1; >>> } >>> >>> err = connect(s, ai->ai_addr, ai->ai_addrlen); >>> if (err == -1) { >>> perror("connect"); >>> return -1; >>> } >>> >>> err = waitread(s); >>> close(s); >>> return err; >>> } >>> >>> int >>> main(int argc, char *argv[]) >>> { >>> int err; >>> >>> if (argc > 1) >>> err = do_server(); >>> else >>> err = do_client(); >>> return !!err; >>> } >>> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-22 18:01 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-22 18:01 UTC (permalink / raw) To: minyard Cc: Xin Long, Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp, LKML > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>> >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>> then I make a connection to it using ::1, the connection will drop after >>> 2.5 seconds with an ECONNRESET error. >>> >>> It only happens on SCTP, it doesn't have the issue if you connect to a >>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>> I tried on an ARM system and x86_64. >>> >>> I haven't dug into the kernel to see if I could find anything yet, but I >>> thought I would go ahead and report it. I am attaching a reproducer. >>> Basically, compile the following code: >> The code only set IPV6_V6ONLY on server side, so the client side will >> still bind all the local ipv4 addresses (as you didn't call bind() to >> bind any specific addresses ). Then after the connection is created, >> the client will send HB on the v4 paths to the server. The server >> will abort the connection, as it can't support v4. >> >> So you can work around it by either: >> >> - set IPV6_V6ONLY on client side. >> >> or >> >> - bind to the specific v6 addresses on the client side. >> >> I don't see RFC said something about this. >> So it may not be a good idea to change the current behaviour >> to not establish the connection in this case, which may cause regression. > > Ok, I understand this. It's a little strange, but I see why it works > this way. I don't. I would expect it to work as I described in my email. Could someone explain me how and why it is behaving different from my expectation? Best regards Michael > > Thanks, > > -corey > >> >>> >>> gcc -g -o sctptest -Wall sctptest.c >>> >>> and run it in one window as a server: >>> >>> ./sctptest a >>> >>> (Pass in any option to be the server) and run the following in another >>> window as the client: >>> >>> ./sctptest >>> >>> It disconnects after about 2.5 seconds. If it works, it should just sit >>> there forever. >>> >>> -corey >>> >>> >>> #include <stdio.h> >>> #include <stdbool.h> >>> #include <string.h> >>> #include <unistd.h> >>> #include <fcntl.h> >>> #include <sys/select.h> >>> #include <arpa/inet.h> >>> #include <netinet/sctp.h> >>> #include <sys/types.h> >>> #include <sys/socket.h> >>> #include <netdb.h> >>> >>> static int >>> getaddr(const char *addr, const char *port, bool listen, >>> struct addrinfo **rai) >>> { >>> struct addrinfo *ai, hints; >>> >>> memset(&hints, 0, sizeof(hints)); >>> hints.ai_flags = AI_ADDRCONFIG; >>> if (listen) >>> hints.ai_flags |= AI_PASSIVE; >>> hints.ai_family = AF_UNSPEC; >>> hints.ai_socktype = SOCK_STREAM; >>> hints.ai_protocol = IPPROTO_SCTP; >>> if (getaddrinfo(addr, port, &hints, &ai)) { >>> perror("getaddrinfo"); >>> return -1; >>> } >>> >>> *rai = ai; >>> return 0; >>> } >>> >>> static int >>> waitread(int s) >>> { >>> char data[1]; >>> ssize_t rv; >>> >>> rv = read(s, data, sizeof(data)); >>> if (rv = -1) { >>> perror("read"); >>> return -1; >>> } >>> printf("Read %d bytes\n", (int) rv); >>> return 0; >>> } >>> >>> static int >>> do_server(void) >>> { >>> int err, ls, s, optval; >>> struct addrinfo *ai; >>> >>> printf("Server\n"); >>> >>> err = getaddr("::", "3023", true, &ai); >>> if (err) >>> return err; >>> >>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>> if (ls = -1) { >>> perror("socket"); >>> return -1; >>> } >>> >>> optval = 1; >>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, >>> (void *)&optval, sizeof(optval)) = -1) { >>> perror("setsockopt reuseaddr"); >>> return -1; >>> } >>> >>> /* Comment this out and it will work. */ >>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, >>> sizeof(optval)) = -1) { >>> perror("setsockopt ipv6 only"); >>> return -1; >>> } >>> >>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); >>> if (err = -1) { >>> perror("bind"); >>> return -1; >>> } >>> >>> err = listen(ls, 5); >>> if (err = -1) { >>> perror("listen"); >>> return -1; >>> } >>> >>> s = accept(ls, NULL, NULL); >>> if (s = -1) { >>> perror("accept"); >>> return -1; >>> } >>> >>> close(ls); >>> >>> err = waitread(s); >>> close(s); >>> return err; >>> } >>> >>> static int >>> do_client(void) >>> { >>> int err, s; >>> struct addrinfo *ai; >>> >>> printf("Client\n"); >>> >>> err = getaddr("::1", "3023", false, &ai); >>> if (err) >>> return err; >>> >>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>> if (s = -1) { >>> perror("socket"); >>> return -1; >>> } >>> >>> err = connect(s, ai->ai_addr, ai->ai_addrlen); >>> if (err = -1) { >>> perror("connect"); >>> return -1; >>> } >>> >>> err = waitread(s); >>> close(s); >>> return err; >>> } >>> >>> int >>> main(int argc, char *argv[]) >>> { >>> int err; >>> >>> if (argc > 1) >>> err = do_server(); >>> else >>> err = do_client(); >>> return !!err; >>> } >>> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-22 18:01 ` Michael Tuexen @ 2020-06-22 18:32 ` Marcelo Ricardo Leitner -1 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-22 18:32 UTC (permalink / raw) To: Michael Tuexen Cc: minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>> > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>> then I make a connection to it using ::1, the connection will drop after > >>> 2.5 seconds with an ECONNRESET error. > >>> > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>> I tried on an ARM system and x86_64. > >>> > >>> I haven't dug into the kernel to see if I could find anything yet, but I > >>> thought I would go ahead and report it. I am attaching a reproducer. > >>> Basically, compile the following code: > >> The code only set IPV6_V6ONLY on server side, so the client side will > >> still bind all the local ipv4 addresses (as you didn't call bind() to > >> bind any specific addresses ). Then after the connection is created, > >> the client will send HB on the v4 paths to the server. The server > >> will abort the connection, as it can't support v4. > >> > >> So you can work around it by either: > >> > >> - set IPV6_V6ONLY on client side. > >> > >> or > >> > >> - bind to the specific v6 addresses on the client side. > >> > >> I don't see RFC said something about this. > >> So it may not be a good idea to change the current behaviour > >> to not establish the connection in this case, which may cause regression. > > > > Ok, I understand this. It's a little strange, but I see why it works > > this way. > I don't. I would expect it to work as I described in my email. > Could someone explain me how and why it is behaving different from > my expectation? It looks like a bug to me. Testing with this test app here, I can see the INIT_ACK being sent with a bunch of ipv4 addresses in it and that's unexpected for a v6only socket. As is, it's the server saying "I'm available at these other addresses too, but not." Thanks, Marcelo > > Best regards > Michael > > > > Thanks, > > > > -corey > > > >> > >>> > >>> gcc -g -o sctptest -Wall sctptest.c > >>> > >>> and run it in one window as a server: > >>> > >>> ./sctptest a > >>> > >>> (Pass in any option to be the server) and run the following in another > >>> window as the client: > >>> > >>> ./sctptest > >>> > >>> It disconnects after about 2.5 seconds. If it works, it should just sit > >>> there forever. > >>> > >>> -corey > >>> > >>> > >>> #include <stdio.h> > >>> #include <stdbool.h> > >>> #include <string.h> > >>> #include <unistd.h> > >>> #include <fcntl.h> > >>> #include <sys/select.h> > >>> #include <arpa/inet.h> > >>> #include <netinet/sctp.h> > >>> #include <sys/types.h> > >>> #include <sys/socket.h> > >>> #include <netdb.h> > >>> > >>> static int > >>> getaddr(const char *addr, const char *port, bool listen, > >>> struct addrinfo **rai) > >>> { > >>> struct addrinfo *ai, hints; > >>> > >>> memset(&hints, 0, sizeof(hints)); > >>> hints.ai_flags = AI_ADDRCONFIG; > >>> if (listen) > >>> hints.ai_flags |= AI_PASSIVE; > >>> hints.ai_family = AF_UNSPEC; > >>> hints.ai_socktype = SOCK_STREAM; > >>> hints.ai_protocol = IPPROTO_SCTP; > >>> if (getaddrinfo(addr, port, &hints, &ai)) { > >>> perror("getaddrinfo"); > >>> return -1; > >>> } > >>> > >>> *rai = ai; > >>> return 0; > >>> } > >>> > >>> static int > >>> waitread(int s) > >>> { > >>> char data[1]; > >>> ssize_t rv; > >>> > >>> rv = read(s, data, sizeof(data)); > >>> if (rv == -1) { > >>> perror("read"); > >>> return -1; > >>> } > >>> printf("Read %d bytes\n", (int) rv); > >>> return 0; > >>> } > >>> > >>> static int > >>> do_server(void) > >>> { > >>> int err, ls, s, optval; > >>> struct addrinfo *ai; > >>> > >>> printf("Server\n"); > >>> > >>> err = getaddr("::", "3023", true, &ai); > >>> if (err) > >>> return err; > >>> > >>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>> if (ls == -1) { > >>> perror("socket"); > >>> return -1; > >>> } > >>> > >>> optval = 1; > >>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > >>> (void *)&optval, sizeof(optval)) == -1) { > >>> perror("setsockopt reuseaddr"); > >>> return -1; > >>> } > >>> > >>> /* Comment this out and it will work. */ > >>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > >>> sizeof(optval)) == -1) { > >>> perror("setsockopt ipv6 only"); > >>> return -1; > >>> } > >>> > >>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > >>> if (err == -1) { > >>> perror("bind"); > >>> return -1; > >>> } > >>> > >>> err = listen(ls, 5); > >>> if (err == -1) { > >>> perror("listen"); > >>> return -1; > >>> } > >>> > >>> s = accept(ls, NULL, NULL); > >>> if (s == -1) { > >>> perror("accept"); > >>> return -1; > >>> } > >>> > >>> close(ls); > >>> > >>> err = waitread(s); > >>> close(s); > >>> return err; > >>> } > >>> > >>> static int > >>> do_client(void) > >>> { > >>> int err, s; > >>> struct addrinfo *ai; > >>> > >>> printf("Client\n"); > >>> > >>> err = getaddr("::1", "3023", false, &ai); > >>> if (err) > >>> return err; > >>> > >>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>> if (s == -1) { > >>> perror("socket"); > >>> return -1; > >>> } > >>> > >>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > >>> if (err == -1) { > >>> perror("connect"); > >>> return -1; > >>> } > >>> > >>> err = waitread(s); > >>> close(s); > >>> return err; > >>> } > >>> > >>> int > >>> main(int argc, char *argv[]) > >>> { > >>> int err; > >>> > >>> if (argc > 1) > >>> err = do_server(); > >>> else > >>> err = do_client(); > >>> return !!err; > >>> } > >>> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-22 18:32 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-22 18:32 UTC (permalink / raw) To: Michael Tuexen Cc: minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>> > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>> then I make a connection to it using ::1, the connection will drop after > >>> 2.5 seconds with an ECONNRESET error. > >>> > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>> I tried on an ARM system and x86_64. > >>> > >>> I haven't dug into the kernel to see if I could find anything yet, but I > >>> thought I would go ahead and report it. I am attaching a reproducer. > >>> Basically, compile the following code: > >> The code only set IPV6_V6ONLY on server side, so the client side will > >> still bind all the local ipv4 addresses (as you didn't call bind() to > >> bind any specific addresses ). Then after the connection is created, > >> the client will send HB on the v4 paths to the server. The server > >> will abort the connection, as it can't support v4. > >> > >> So you can work around it by either: > >> > >> - set IPV6_V6ONLY on client side. > >> > >> or > >> > >> - bind to the specific v6 addresses on the client side. > >> > >> I don't see RFC said something about this. > >> So it may not be a good idea to change the current behaviour > >> to not establish the connection in this case, which may cause regression. > > > > Ok, I understand this. It's a little strange, but I see why it works > > this way. > I don't. I would expect it to work as I described in my email. > Could someone explain me how and why it is behaving different from > my expectation? It looks like a bug to me. Testing with this test app here, I can see the INIT_ACK being sent with a bunch of ipv4 addresses in it and that's unexpected for a v6only socket. As is, it's the server saying "I'm available at these other addresses too, but not." Thanks, Marcelo > > Best regards > Michael > > > > Thanks, > > > > -corey > > > >> > >>> > >>> gcc -g -o sctptest -Wall sctptest.c > >>> > >>> and run it in one window as a server: > >>> > >>> ./sctptest a > >>> > >>> (Pass in any option to be the server) and run the following in another > >>> window as the client: > >>> > >>> ./sctptest > >>> > >>> It disconnects after about 2.5 seconds. If it works, it should just sit > >>> there forever. > >>> > >>> -corey > >>> > >>> > >>> #include <stdio.h> > >>> #include <stdbool.h> > >>> #include <string.h> > >>> #include <unistd.h> > >>> #include <fcntl.h> > >>> #include <sys/select.h> > >>> #include <arpa/inet.h> > >>> #include <netinet/sctp.h> > >>> #include <sys/types.h> > >>> #include <sys/socket.h> > >>> #include <netdb.h> > >>> > >>> static int > >>> getaddr(const char *addr, const char *port, bool listen, > >>> struct addrinfo **rai) > >>> { > >>> struct addrinfo *ai, hints; > >>> > >>> memset(&hints, 0, sizeof(hints)); > >>> hints.ai_flags = AI_ADDRCONFIG; > >>> if (listen) > >>> hints.ai_flags |= AI_PASSIVE; > >>> hints.ai_family = AF_UNSPEC; > >>> hints.ai_socktype = SOCK_STREAM; > >>> hints.ai_protocol = IPPROTO_SCTP; > >>> if (getaddrinfo(addr, port, &hints, &ai)) { > >>> perror("getaddrinfo"); > >>> return -1; > >>> } > >>> > >>> *rai = ai; > >>> return 0; > >>> } > >>> > >>> static int > >>> waitread(int s) > >>> { > >>> char data[1]; > >>> ssize_t rv; > >>> > >>> rv = read(s, data, sizeof(data)); > >>> if (rv = -1) { > >>> perror("read"); > >>> return -1; > >>> } > >>> printf("Read %d bytes\n", (int) rv); > >>> return 0; > >>> } > >>> > >>> static int > >>> do_server(void) > >>> { > >>> int err, ls, s, optval; > >>> struct addrinfo *ai; > >>> > >>> printf("Server\n"); > >>> > >>> err = getaddr("::", "3023", true, &ai); > >>> if (err) > >>> return err; > >>> > >>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>> if (ls = -1) { > >>> perror("socket"); > >>> return -1; > >>> } > >>> > >>> optval = 1; > >>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > >>> (void *)&optval, sizeof(optval)) = -1) { > >>> perror("setsockopt reuseaddr"); > >>> return -1; > >>> } > >>> > >>> /* Comment this out and it will work. */ > >>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > >>> sizeof(optval)) = -1) { > >>> perror("setsockopt ipv6 only"); > >>> return -1; > >>> } > >>> > >>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > >>> if (err = -1) { > >>> perror("bind"); > >>> return -1; > >>> } > >>> > >>> err = listen(ls, 5); > >>> if (err = -1) { > >>> perror("listen"); > >>> return -1; > >>> } > >>> > >>> s = accept(ls, NULL, NULL); > >>> if (s = -1) { > >>> perror("accept"); > >>> return -1; > >>> } > >>> > >>> close(ls); > >>> > >>> err = waitread(s); > >>> close(s); > >>> return err; > >>> } > >>> > >>> static int > >>> do_client(void) > >>> { > >>> int err, s; > >>> struct addrinfo *ai; > >>> > >>> printf("Client\n"); > >>> > >>> err = getaddr("::1", "3023", false, &ai); > >>> if (err) > >>> return err; > >>> > >>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>> if (s = -1) { > >>> perror("socket"); > >>> return -1; > >>> } > >>> > >>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > >>> if (err = -1) { > >>> perror("connect"); > >>> return -1; > >>> } > >>> > >>> err = waitread(s); > >>> close(s); > >>> return err; > >>> } > >>> > >>> int > >>> main(int argc, char *argv[]) > >>> { > >>> int err; > >>> > >>> if (argc > 1) > >>> err = do_server(); > >>> else > >>> err = do_client(); > >>> return !!err; > >>> } > >>> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-22 18:32 ` Marcelo Ricardo Leitner @ 2020-06-22 18:34 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-22 18:34 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>> >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>> then I make a connection to it using ::1, the connection will drop after >>>>> 2.5 seconds with an ECONNRESET error. >>>>> >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>> I tried on an ARM system and x86_64. >>>>> >>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>> Basically, compile the following code: >>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>> bind any specific addresses ). Then after the connection is created, >>>> the client will send HB on the v4 paths to the server. The server >>>> will abort the connection, as it can't support v4. >>>> >>>> So you can work around it by either: >>>> >>>> - set IPV6_V6ONLY on client side. >>>> >>>> or >>>> >>>> - bind to the specific v6 addresses on the client side. >>>> >>>> I don't see RFC said something about this. >>>> So it may not be a good idea to change the current behaviour >>>> to not establish the connection in this case, which may cause regression. >>> >>> Ok, I understand this. It's a little strange, but I see why it works >>> this way. >> I don't. I would expect it to work as I described in my email. >> Could someone explain me how and why it is behaving different from >> my expectation? > > It looks like a bug to me. Testing with this test app here, I can see > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > that's unexpected for a v6only socket. As is, it's the server saying > "I'm available at these other addresses too, but not." I agree. Best regards Michael > > Thanks, > Marcelo > >> >> Best regards >> Michael >>> >>> Thanks, >>> >>> -corey >>> >>>> >>>>> >>>>> gcc -g -o sctptest -Wall sctptest.c >>>>> >>>>> and run it in one window as a server: >>>>> >>>>> ./sctptest a >>>>> >>>>> (Pass in any option to be the server) and run the following in another >>>>> window as the client: >>>>> >>>>> ./sctptest >>>>> >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit >>>>> there forever. >>>>> >>>>> -corey >>>>> >>>>> >>>>> #include <stdio.h> >>>>> #include <stdbool.h> >>>>> #include <string.h> >>>>> #include <unistd.h> >>>>> #include <fcntl.h> >>>>> #include <sys/select.h> >>>>> #include <arpa/inet.h> >>>>> #include <netinet/sctp.h> >>>>> #include <sys/types.h> >>>>> #include <sys/socket.h> >>>>> #include <netdb.h> >>>>> >>>>> static int >>>>> getaddr(const char *addr, const char *port, bool listen, >>>>> struct addrinfo **rai) >>>>> { >>>>> struct addrinfo *ai, hints; >>>>> >>>>> memset(&hints, 0, sizeof(hints)); >>>>> hints.ai_flags = AI_ADDRCONFIG; >>>>> if (listen) >>>>> hints.ai_flags |= AI_PASSIVE; >>>>> hints.ai_family = AF_UNSPEC; >>>>> hints.ai_socktype = SOCK_STREAM; >>>>> hints.ai_protocol = IPPROTO_SCTP; >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { >>>>> perror("getaddrinfo"); >>>>> return -1; >>>>> } >>>>> >>>>> *rai = ai; >>>>> return 0; >>>>> } >>>>> >>>>> static int >>>>> waitread(int s) >>>>> { >>>>> char data[1]; >>>>> ssize_t rv; >>>>> >>>>> rv = read(s, data, sizeof(data)); >>>>> if (rv == -1) { >>>>> perror("read"); >>>>> return -1; >>>>> } >>>>> printf("Read %d bytes\n", (int) rv); >>>>> return 0; >>>>> } >>>>> >>>>> static int >>>>> do_server(void) >>>>> { >>>>> int err, ls, s, optval; >>>>> struct addrinfo *ai; >>>>> >>>>> printf("Server\n"); >>>>> >>>>> err = getaddr("::", "3023", true, &ai); >>>>> if (err) >>>>> return err; >>>>> >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>>>> if (ls == -1) { >>>>> perror("socket"); >>>>> return -1; >>>>> } >>>>> >>>>> optval = 1; >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, >>>>> (void *)&optval, sizeof(optval)) == -1) { >>>>> perror("setsockopt reuseaddr"); >>>>> return -1; >>>>> } >>>>> >>>>> /* Comment this out and it will work. */ >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, >>>>> sizeof(optval)) == -1) { >>>>> perror("setsockopt ipv6 only"); >>>>> return -1; >>>>> } >>>>> >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); >>>>> if (err == -1) { >>>>> perror("bind"); >>>>> return -1; >>>>> } >>>>> >>>>> err = listen(ls, 5); >>>>> if (err == -1) { >>>>> perror("listen"); >>>>> return -1; >>>>> } >>>>> >>>>> s = accept(ls, NULL, NULL); >>>>> if (s == -1) { >>>>> perror("accept"); >>>>> return -1; >>>>> } >>>>> >>>>> close(ls); >>>>> >>>>> err = waitread(s); >>>>> close(s); >>>>> return err; >>>>> } >>>>> >>>>> static int >>>>> do_client(void) >>>>> { >>>>> int err, s; >>>>> struct addrinfo *ai; >>>>> >>>>> printf("Client\n"); >>>>> >>>>> err = getaddr("::1", "3023", false, &ai); >>>>> if (err) >>>>> return err; >>>>> >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>>>> if (s == -1) { >>>>> perror("socket"); >>>>> return -1; >>>>> } >>>>> >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); >>>>> if (err == -1) { >>>>> perror("connect"); >>>>> return -1; >>>>> } >>>>> >>>>> err = waitread(s); >>>>> close(s); >>>>> return err; >>>>> } >>>>> >>>>> int >>>>> main(int argc, char *argv[]) >>>>> { >>>>> int err; >>>>> >>>>> if (argc > 1) >>>>> err = do_server(); >>>>> else >>>>> err = do_client(); >>>>> return !!err; >>>>> } >>>>> >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-22 18:34 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-22 18:34 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>> >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>> then I make a connection to it using ::1, the connection will drop after >>>>> 2.5 seconds with an ECONNRESET error. >>>>> >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>> I tried on an ARM system and x86_64. >>>>> >>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>> Basically, compile the following code: >>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>> bind any specific addresses ). Then after the connection is created, >>>> the client will send HB on the v4 paths to the server. The server >>>> will abort the connection, as it can't support v4. >>>> >>>> So you can work around it by either: >>>> >>>> - set IPV6_V6ONLY on client side. >>>> >>>> or >>>> >>>> - bind to the specific v6 addresses on the client side. >>>> >>>> I don't see RFC said something about this. >>>> So it may not be a good idea to change the current behaviour >>>> to not establish the connection in this case, which may cause regression. >>> >>> Ok, I understand this. It's a little strange, but I see why it works >>> this way. >> I don't. I would expect it to work as I described in my email. >> Could someone explain me how and why it is behaving different from >> my expectation? > > It looks like a bug to me. Testing with this test app here, I can see > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > that's unexpected for a v6only socket. As is, it's the server saying > "I'm available at these other addresses too, but not." I agree. Best regards Michael > > Thanks, > Marcelo > >> >> Best regards >> Michael >>> >>> Thanks, >>> >>> -corey >>> >>>> >>>>> >>>>> gcc -g -o sctptest -Wall sctptest.c >>>>> >>>>> and run it in one window as a server: >>>>> >>>>> ./sctptest a >>>>> >>>>> (Pass in any option to be the server) and run the following in another >>>>> window as the client: >>>>> >>>>> ./sctptest >>>>> >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit >>>>> there forever. >>>>> >>>>> -corey >>>>> >>>>> >>>>> #include <stdio.h> >>>>> #include <stdbool.h> >>>>> #include <string.h> >>>>> #include <unistd.h> >>>>> #include <fcntl.h> >>>>> #include <sys/select.h> >>>>> #include <arpa/inet.h> >>>>> #include <netinet/sctp.h> >>>>> #include <sys/types.h> >>>>> #include <sys/socket.h> >>>>> #include <netdb.h> >>>>> >>>>> static int >>>>> getaddr(const char *addr, const char *port, bool listen, >>>>> struct addrinfo **rai) >>>>> { >>>>> struct addrinfo *ai, hints; >>>>> >>>>> memset(&hints, 0, sizeof(hints)); >>>>> hints.ai_flags = AI_ADDRCONFIG; >>>>> if (listen) >>>>> hints.ai_flags |= AI_PASSIVE; >>>>> hints.ai_family = AF_UNSPEC; >>>>> hints.ai_socktype = SOCK_STREAM; >>>>> hints.ai_protocol = IPPROTO_SCTP; >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { >>>>> perror("getaddrinfo"); >>>>> return -1; >>>>> } >>>>> >>>>> *rai = ai; >>>>> return 0; >>>>> } >>>>> >>>>> static int >>>>> waitread(int s) >>>>> { >>>>> char data[1]; >>>>> ssize_t rv; >>>>> >>>>> rv = read(s, data, sizeof(data)); >>>>> if (rv = -1) { >>>>> perror("read"); >>>>> return -1; >>>>> } >>>>> printf("Read %d bytes\n", (int) rv); >>>>> return 0; >>>>> } >>>>> >>>>> static int >>>>> do_server(void) >>>>> { >>>>> int err, ls, s, optval; >>>>> struct addrinfo *ai; >>>>> >>>>> printf("Server\n"); >>>>> >>>>> err = getaddr("::", "3023", true, &ai); >>>>> if (err) >>>>> return err; >>>>> >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>>>> if (ls = -1) { >>>>> perror("socket"); >>>>> return -1; >>>>> } >>>>> >>>>> optval = 1; >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, >>>>> (void *)&optval, sizeof(optval)) = -1) { >>>>> perror("setsockopt reuseaddr"); >>>>> return -1; >>>>> } >>>>> >>>>> /* Comment this out and it will work. */ >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, >>>>> sizeof(optval)) = -1) { >>>>> perror("setsockopt ipv6 only"); >>>>> return -1; >>>>> } >>>>> >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); >>>>> if (err = -1) { >>>>> perror("bind"); >>>>> return -1; >>>>> } >>>>> >>>>> err = listen(ls, 5); >>>>> if (err = -1) { >>>>> perror("listen"); >>>>> return -1; >>>>> } >>>>> >>>>> s = accept(ls, NULL, NULL); >>>>> if (s = -1) { >>>>> perror("accept"); >>>>> return -1; >>>>> } >>>>> >>>>> close(ls); >>>>> >>>>> err = waitread(s); >>>>> close(s); >>>>> return err; >>>>> } >>>>> >>>>> static int >>>>> do_client(void) >>>>> { >>>>> int err, s; >>>>> struct addrinfo *ai; >>>>> >>>>> printf("Client\n"); >>>>> >>>>> err = getaddr("::1", "3023", false, &ai); >>>>> if (err) >>>>> return err; >>>>> >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); >>>>> if (s = -1) { >>>>> perror("socket"); >>>>> return -1; >>>>> } >>>>> >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); >>>>> if (err = -1) { >>>>> perror("connect"); >>>>> return -1; >>>>> } >>>>> >>>>> err = waitread(s); >>>>> close(s); >>>>> return err; >>>>> } >>>>> >>>>> int >>>>> main(int argc, char *argv[]) >>>>> { >>>>> int err; >>>>> >>>>> if (argc > 1) >>>>> err = do_server(); >>>>> else >>>>> err = do_client(); >>>>> return !!err; >>>>> } >>>>> >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-22 18:34 ` Michael Tuexen @ 2020-06-23 10:13 ` Xin Long -1 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-23 10:13 UTC (permalink / raw) To: Michael Tuexen Cc: Marcelo Ricardo Leitner, minyard, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote: > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > >>> > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>>>> > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>>>> then I make a connection to it using ::1, the connection will drop after > >>>>> 2.5 seconds with an ECONNRESET error. > >>>>> > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>>>> I tried on an ARM system and x86_64. > >>>>> > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > >>>>> Basically, compile the following code: > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > >>>> bind any specific addresses ). Then after the connection is created, > >>>> the client will send HB on the v4 paths to the server. The server > >>>> will abort the connection, as it can't support v4. > >>>> > >>>> So you can work around it by either: > >>>> > >>>> - set IPV6_V6ONLY on client side. > >>>> > >>>> or > >>>> > >>>> - bind to the specific v6 addresses on the client side. > >>>> > >>>> I don't see RFC said something about this. > >>>> So it may not be a good idea to change the current behaviour > >>>> to not establish the connection in this case, which may cause regression. > >>> > >>> Ok, I understand this. It's a little strange, but I see why it works > >>> this way. > >> I don't. I would expect it to work as I described in my email. > >> Could someone explain me how and why it is behaving different from > >> my expectation? > > > > It looks like a bug to me. Testing with this test app here, I can see > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > that's unexpected for a v6only socket. As is, it's the server saying > > "I'm available at these other addresses too, but not." > I agree. Then we need a fix in sctp_bind_addrs_to_raw(): @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, addrparms = retval; list_for_each_entry(addr, &bp->address_list, list) { + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && + (AF_INET == addr->a.sa.sa_family)) + continue; af = sctp_get_af_specific(addr->a.v4.sin_family); len = af->to_addr_param(&addr->a, &rawaddr); memcpy(addrparms.v, &rawaddr, len); > > Best regards > Michael > > > > Thanks, > > Marcelo > > > >> > >> Best regards > >> Michael > >>> > >>> Thanks, > >>> > >>> -corey > >>> > >>>> > >>>>> > >>>>> gcc -g -o sctptest -Wall sctptest.c > >>>>> > >>>>> and run it in one window as a server: > >>>>> > >>>>> ./sctptest a > >>>>> > >>>>> (Pass in any option to be the server) and run the following in another > >>>>> window as the client: > >>>>> > >>>>> ./sctptest > >>>>> > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > >>>>> there forever. > >>>>> > >>>>> -corey > >>>>> > >>>>> > >>>>> #include <stdio.h> > >>>>> #include <stdbool.h> > >>>>> #include <string.h> > >>>>> #include <unistd.h> > >>>>> #include <fcntl.h> > >>>>> #include <sys/select.h> > >>>>> #include <arpa/inet.h> > >>>>> #include <netinet/sctp.h> > >>>>> #include <sys/types.h> > >>>>> #include <sys/socket.h> > >>>>> #include <netdb.h> > >>>>> > >>>>> static int > >>>>> getaddr(const char *addr, const char *port, bool listen, > >>>>> struct addrinfo **rai) > >>>>> { > >>>>> struct addrinfo *ai, hints; > >>>>> > >>>>> memset(&hints, 0, sizeof(hints)); > >>>>> hints.ai_flags = AI_ADDRCONFIG; > >>>>> if (listen) > >>>>> hints.ai_flags |= AI_PASSIVE; > >>>>> hints.ai_family = AF_UNSPEC; > >>>>> hints.ai_socktype = SOCK_STREAM; > >>>>> hints.ai_protocol = IPPROTO_SCTP; > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > >>>>> perror("getaddrinfo"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> *rai = ai; > >>>>> return 0; > >>>>> } > >>>>> > >>>>> static int > >>>>> waitread(int s) > >>>>> { > >>>>> char data[1]; > >>>>> ssize_t rv; > >>>>> > >>>>> rv = read(s, data, sizeof(data)); > >>>>> if (rv == -1) { > >>>>> perror("read"); > >>>>> return -1; > >>>>> } > >>>>> printf("Read %d bytes\n", (int) rv); > >>>>> return 0; > >>>>> } > >>>>> > >>>>> static int > >>>>> do_server(void) > >>>>> { > >>>>> int err, ls, s, optval; > >>>>> struct addrinfo *ai; > >>>>> > >>>>> printf("Server\n"); > >>>>> > >>>>> err = getaddr("::", "3023", true, &ai); > >>>>> if (err) > >>>>> return err; > >>>>> > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>>>> if (ls == -1) { > >>>>> perror("socket"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> optval = 1; > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > >>>>> (void *)&optval, sizeof(optval)) == -1) { > >>>>> perror("setsockopt reuseaddr"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> /* Comment this out and it will work. */ > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > >>>>> sizeof(optval)) == -1) { > >>>>> perror("setsockopt ipv6 only"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > >>>>> if (err == -1) { > >>>>> perror("bind"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = listen(ls, 5); > >>>>> if (err == -1) { > >>>>> perror("listen"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> s = accept(ls, NULL, NULL); > >>>>> if (s == -1) { > >>>>> perror("accept"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> close(ls); > >>>>> > >>>>> err = waitread(s); > >>>>> close(s); > >>>>> return err; > >>>>> } > >>>>> > >>>>> static int > >>>>> do_client(void) > >>>>> { > >>>>> int err, s; > >>>>> struct addrinfo *ai; > >>>>> > >>>>> printf("Client\n"); > >>>>> > >>>>> err = getaddr("::1", "3023", false, &ai); > >>>>> if (err) > >>>>> return err; > >>>>> > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>>>> if (s == -1) { > >>>>> perror("socket"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > >>>>> if (err == -1) { > >>>>> perror("connect"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = waitread(s); > >>>>> close(s); > >>>>> return err; > >>>>> } > >>>>> > >>>>> int > >>>>> main(int argc, char *argv[]) > >>>>> { > >>>>> int err; > >>>>> > >>>>> if (argc > 1) > >>>>> err = do_server(); > >>>>> else > >>>>> err = do_client(); > >>>>> return !!err; > >>>>> } > >>>>> > >> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 10:13 ` Xin Long 0 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-23 10:13 UTC (permalink / raw) To: Michael Tuexen Cc: Marcelo Ricardo Leitner, minyard, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote: > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > >>> > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>>>> > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>>>> then I make a connection to it using ::1, the connection will drop after > >>>>> 2.5 seconds with an ECONNRESET error. > >>>>> > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>>>> I tried on an ARM system and x86_64. > >>>>> > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > >>>>> Basically, compile the following code: > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > >>>> bind any specific addresses ). Then after the connection is created, > >>>> the client will send HB on the v4 paths to the server. The server > >>>> will abort the connection, as it can't support v4. > >>>> > >>>> So you can work around it by either: > >>>> > >>>> - set IPV6_V6ONLY on client side. > >>>> > >>>> or > >>>> > >>>> - bind to the specific v6 addresses on the client side. > >>>> > >>>> I don't see RFC said something about this. > >>>> So it may not be a good idea to change the current behaviour > >>>> to not establish the connection in this case, which may cause regression. > >>> > >>> Ok, I understand this. It's a little strange, but I see why it works > >>> this way. > >> I don't. I would expect it to work as I described in my email. > >> Could someone explain me how and why it is behaving different from > >> my expectation? > > > > It looks like a bug to me. Testing with this test app here, I can see > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > that's unexpected for a v6only socket. As is, it's the server saying > > "I'm available at these other addresses too, but not." > I agree. Then we need a fix in sctp_bind_addrs_to_raw(): @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, addrparms = retval; list_for_each_entry(addr, &bp->address_list, list) { + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && + (AF_INET = addr->a.sa.sa_family)) + continue; af = sctp_get_af_specific(addr->a.v4.sin_family); len = af->to_addr_param(&addr->a, &rawaddr); memcpy(addrparms.v, &rawaddr, len); > > Best regards > Michael > > > > Thanks, > > Marcelo > > > >> > >> Best regards > >> Michael > >>> > >>> Thanks, > >>> > >>> -corey > >>> > >>>> > >>>>> > >>>>> gcc -g -o sctptest -Wall sctptest.c > >>>>> > >>>>> and run it in one window as a server: > >>>>> > >>>>> ./sctptest a > >>>>> > >>>>> (Pass in any option to be the server) and run the following in another > >>>>> window as the client: > >>>>> > >>>>> ./sctptest > >>>>> > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > >>>>> there forever. > >>>>> > >>>>> -corey > >>>>> > >>>>> > >>>>> #include <stdio.h> > >>>>> #include <stdbool.h> > >>>>> #include <string.h> > >>>>> #include <unistd.h> > >>>>> #include <fcntl.h> > >>>>> #include <sys/select.h> > >>>>> #include <arpa/inet.h> > >>>>> #include <netinet/sctp.h> > >>>>> #include <sys/types.h> > >>>>> #include <sys/socket.h> > >>>>> #include <netdb.h> > >>>>> > >>>>> static int > >>>>> getaddr(const char *addr, const char *port, bool listen, > >>>>> struct addrinfo **rai) > >>>>> { > >>>>> struct addrinfo *ai, hints; > >>>>> > >>>>> memset(&hints, 0, sizeof(hints)); > >>>>> hints.ai_flags = AI_ADDRCONFIG; > >>>>> if (listen) > >>>>> hints.ai_flags |= AI_PASSIVE; > >>>>> hints.ai_family = AF_UNSPEC; > >>>>> hints.ai_socktype = SOCK_STREAM; > >>>>> hints.ai_protocol = IPPROTO_SCTP; > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > >>>>> perror("getaddrinfo"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> *rai = ai; > >>>>> return 0; > >>>>> } > >>>>> > >>>>> static int > >>>>> waitread(int s) > >>>>> { > >>>>> char data[1]; > >>>>> ssize_t rv; > >>>>> > >>>>> rv = read(s, data, sizeof(data)); > >>>>> if (rv = -1) { > >>>>> perror("read"); > >>>>> return -1; > >>>>> } > >>>>> printf("Read %d bytes\n", (int) rv); > >>>>> return 0; > >>>>> } > >>>>> > >>>>> static int > >>>>> do_server(void) > >>>>> { > >>>>> int err, ls, s, optval; > >>>>> struct addrinfo *ai; > >>>>> > >>>>> printf("Server\n"); > >>>>> > >>>>> err = getaddr("::", "3023", true, &ai); > >>>>> if (err) > >>>>> return err; > >>>>> > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>>>> if (ls = -1) { > >>>>> perror("socket"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> optval = 1; > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > >>>>> (void *)&optval, sizeof(optval)) = -1) { > >>>>> perror("setsockopt reuseaddr"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> /* Comment this out and it will work. */ > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > >>>>> sizeof(optval)) = -1) { > >>>>> perror("setsockopt ipv6 only"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > >>>>> if (err = -1) { > >>>>> perror("bind"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = listen(ls, 5); > >>>>> if (err = -1) { > >>>>> perror("listen"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> s = accept(ls, NULL, NULL); > >>>>> if (s = -1) { > >>>>> perror("accept"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> close(ls); > >>>>> > >>>>> err = waitread(s); > >>>>> close(s); > >>>>> return err; > >>>>> } > >>>>> > >>>>> static int > >>>>> do_client(void) > >>>>> { > >>>>> int err, s; > >>>>> struct addrinfo *ai; > >>>>> > >>>>> printf("Client\n"); > >>>>> > >>>>> err = getaddr("::1", "3023", false, &ai); > >>>>> if (err) > >>>>> return err; > >>>>> > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > >>>>> if (s = -1) { > >>>>> perror("socket"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > >>>>> if (err = -1) { > >>>>> perror("connect"); > >>>>> return -1; > >>>>> } > >>>>> > >>>>> err = waitread(s); > >>>>> close(s); > >>>>> return err; > >>>>> } > >>>>> > >>>>> int > >>>>> main(int argc, char *argv[]) > >>>>> { > >>>>> int err; > >>>>> > >>>>> if (argc > 1) > >>>>> err = do_server(); > >>>>> else > >>>>> err = do_client(); > >>>>> return !!err; > >>>>> } > >>>>> > >> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 10:13 ` Xin Long @ 2020-06-23 13:29 ` Corey Minyard -1 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-23 13:29 UTC (permalink / raw) To: Xin Long Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > >>> > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > >>>>> > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > >>>>> then I make a connection to it using ::1, the connection will drop after > > >>>>> 2.5 seconds with an ECONNRESET error. > > >>>>> > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > >>>>> I tried on an ARM system and x86_64. > > >>>>> > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > >>>>> Basically, compile the following code: > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > >>>> bind any specific addresses ). Then after the connection is created, > > >>>> the client will send HB on the v4 paths to the server. The server > > >>>> will abort the connection, as it can't support v4. > > >>>> > > >>>> So you can work around it by either: > > >>>> > > >>>> - set IPV6_V6ONLY on client side. > > >>>> > > >>>> or > > >>>> > > >>>> - bind to the specific v6 addresses on the client side. > > >>>> > > >>>> I don't see RFC said something about this. > > >>>> So it may not be a good idea to change the current behaviour > > >>>> to not establish the connection in this case, which may cause regression. > > >>> > > >>> Ok, I understand this. It's a little strange, but I see why it works > > >>> this way. > > >> I don't. I would expect it to work as I described in my email. > > >> Could someone explain me how and why it is behaving different from > > >> my expectation? > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > that's unexpected for a v6only socket. As is, it's the server saying > > > "I'm available at these other addresses too, but not." > > I agree. > Then we need a fix in sctp_bind_addrs_to_raw(): > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > struct sctp_bind_addr *bp, > addrparms = retval; > > list_for_each_entry(addr, &bp->address_list, list) { > + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && > + (AF_INET == addr->a.sa.sa_family)) > + continue; This does not compile in the latest mainline. sk is not defined. Also, if you could send a normal git patch, that would be easier to manage. Thanks, -corey > af = sctp_get_af_specific(addr->a.v4.sin_family); > len = af->to_addr_param(&addr->a, &rawaddr); > memcpy(addrparms.v, &rawaddr, len); > > > > > Best regards > > Michael > > > > > > Thanks, > > > Marcelo > > > > > >> > > >> Best regards > > >> Michael > > >>> > > >>> Thanks, > > >>> > > >>> -corey > > >>> > > >>>> > > >>>>> > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > >>>>> > > >>>>> and run it in one window as a server: > > >>>>> > > >>>>> ./sctptest a > > >>>>> > > >>>>> (Pass in any option to be the server) and run the following in another > > >>>>> window as the client: > > >>>>> > > >>>>> ./sctptest > > >>>>> > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > >>>>> there forever. > > >>>>> > > >>>>> -corey > > >>>>> > > >>>>> > > >>>>> #include <stdio.h> > > >>>>> #include <stdbool.h> > > >>>>> #include <string.h> > > >>>>> #include <unistd.h> > > >>>>> #include <fcntl.h> > > >>>>> #include <sys/select.h> > > >>>>> #include <arpa/inet.h> > > >>>>> #include <netinet/sctp.h> > > >>>>> #include <sys/types.h> > > >>>>> #include <sys/socket.h> > > >>>>> #include <netdb.h> > > >>>>> > > >>>>> static int > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > >>>>> struct addrinfo **rai) > > >>>>> { > > >>>>> struct addrinfo *ai, hints; > > >>>>> > > >>>>> memset(&hints, 0, sizeof(hints)); > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > >>>>> if (listen) > > >>>>> hints.ai_flags |= AI_PASSIVE; > > >>>>> hints.ai_family = AF_UNSPEC; > > >>>>> hints.ai_socktype = SOCK_STREAM; > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > >>>>> perror("getaddrinfo"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> *rai = ai; > > >>>>> return 0; > > >>>>> } > > >>>>> > > >>>>> static int > > >>>>> waitread(int s) > > >>>>> { > > >>>>> char data[1]; > > >>>>> ssize_t rv; > > >>>>> > > >>>>> rv = read(s, data, sizeof(data)); > > >>>>> if (rv == -1) { > > >>>>> perror("read"); > > >>>>> return -1; > > >>>>> } > > >>>>> printf("Read %d bytes\n", (int) rv); > > >>>>> return 0; > > >>>>> } > > >>>>> > > >>>>> static int > > >>>>> do_server(void) > > >>>>> { > > >>>>> int err, ls, s, optval; > > >>>>> struct addrinfo *ai; > > >>>>> > > >>>>> printf("Server\n"); > > >>>>> > > >>>>> err = getaddr("::", "3023", true, &ai); > > >>>>> if (err) > > >>>>> return err; > > >>>>> > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > >>>>> if (ls == -1) { > > >>>>> perror("socket"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> optval = 1; > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > >>>>> (void *)&optval, sizeof(optval)) == -1) { > > >>>>> perror("setsockopt reuseaddr"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> /* Comment this out and it will work. */ > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > >>>>> sizeof(optval)) == -1) { > > >>>>> perror("setsockopt ipv6 only"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > >>>>> if (err == -1) { > > >>>>> perror("bind"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = listen(ls, 5); > > >>>>> if (err == -1) { > > >>>>> perror("listen"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> s = accept(ls, NULL, NULL); > > >>>>> if (s == -1) { > > >>>>> perror("accept"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> close(ls); > > >>>>> > > >>>>> err = waitread(s); > > >>>>> close(s); > > >>>>> return err; > > >>>>> } > > >>>>> > > >>>>> static int > > >>>>> do_client(void) > > >>>>> { > > >>>>> int err, s; > > >>>>> struct addrinfo *ai; > > >>>>> > > >>>>> printf("Client\n"); > > >>>>> > > >>>>> err = getaddr("::1", "3023", false, &ai); > > >>>>> if (err) > > >>>>> return err; > > >>>>> > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > >>>>> if (s == -1) { > > >>>>> perror("socket"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > >>>>> if (err == -1) { > > >>>>> perror("connect"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = waitread(s); > > >>>>> close(s); > > >>>>> return err; > > >>>>> } > > >>>>> > > >>>>> int > > >>>>> main(int argc, char *argv[]) > > >>>>> { > > >>>>> int err; > > >>>>> > > >>>>> if (argc > 1) > > >>>>> err = do_server(); > > >>>>> else > > >>>>> err = do_client(); > > >>>>> return !!err; > > >>>>> } > > >>>>> > > >> > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 13:29 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-23 13:29 UTC (permalink / raw) To: Xin Long Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > >>> > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > >>>>> > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > >>>>> then I make a connection to it using ::1, the connection will drop after > > >>>>> 2.5 seconds with an ECONNRESET error. > > >>>>> > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > >>>>> I tried on an ARM system and x86_64. > > >>>>> > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > >>>>> Basically, compile the following code: > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > >>>> bind any specific addresses ). Then after the connection is created, > > >>>> the client will send HB on the v4 paths to the server. The server > > >>>> will abort the connection, as it can't support v4. > > >>>> > > >>>> So you can work around it by either: > > >>>> > > >>>> - set IPV6_V6ONLY on client side. > > >>>> > > >>>> or > > >>>> > > >>>> - bind to the specific v6 addresses on the client side. > > >>>> > > >>>> I don't see RFC said something about this. > > >>>> So it may not be a good idea to change the current behaviour > > >>>> to not establish the connection in this case, which may cause regression. > > >>> > > >>> Ok, I understand this. It's a little strange, but I see why it works > > >>> this way. > > >> I don't. I would expect it to work as I described in my email. > > >> Could someone explain me how and why it is behaving different from > > >> my expectation? > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > that's unexpected for a v6only socket. As is, it's the server saying > > > "I'm available at these other addresses too, but not." > > I agree. > Then we need a fix in sctp_bind_addrs_to_raw(): > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > struct sctp_bind_addr *bp, > addrparms = retval; > > list_for_each_entry(addr, &bp->address_list, list) { > + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && > + (AF_INET = addr->a.sa.sa_family)) > + continue; This does not compile in the latest mainline. sk is not defined. Also, if you could send a normal git patch, that would be easier to manage. Thanks, -corey > af = sctp_get_af_specific(addr->a.v4.sin_family); > len = af->to_addr_param(&addr->a, &rawaddr); > memcpy(addrparms.v, &rawaddr, len); > > > > > Best regards > > Michael > > > > > > Thanks, > > > Marcelo > > > > > >> > > >> Best regards > > >> Michael > > >>> > > >>> Thanks, > > >>> > > >>> -corey > > >>> > > >>>> > > >>>>> > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > >>>>> > > >>>>> and run it in one window as a server: > > >>>>> > > >>>>> ./sctptest a > > >>>>> > > >>>>> (Pass in any option to be the server) and run the following in another > > >>>>> window as the client: > > >>>>> > > >>>>> ./sctptest > > >>>>> > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > >>>>> there forever. > > >>>>> > > >>>>> -corey > > >>>>> > > >>>>> > > >>>>> #include <stdio.h> > > >>>>> #include <stdbool.h> > > >>>>> #include <string.h> > > >>>>> #include <unistd.h> > > >>>>> #include <fcntl.h> > > >>>>> #include <sys/select.h> > > >>>>> #include <arpa/inet.h> > > >>>>> #include <netinet/sctp.h> > > >>>>> #include <sys/types.h> > > >>>>> #include <sys/socket.h> > > >>>>> #include <netdb.h> > > >>>>> > > >>>>> static int > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > >>>>> struct addrinfo **rai) > > >>>>> { > > >>>>> struct addrinfo *ai, hints; > > >>>>> > > >>>>> memset(&hints, 0, sizeof(hints)); > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > >>>>> if (listen) > > >>>>> hints.ai_flags |= AI_PASSIVE; > > >>>>> hints.ai_family = AF_UNSPEC; > > >>>>> hints.ai_socktype = SOCK_STREAM; > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > >>>>> perror("getaddrinfo"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> *rai = ai; > > >>>>> return 0; > > >>>>> } > > >>>>> > > >>>>> static int > > >>>>> waitread(int s) > > >>>>> { > > >>>>> char data[1]; > > >>>>> ssize_t rv; > > >>>>> > > >>>>> rv = read(s, data, sizeof(data)); > > >>>>> if (rv = -1) { > > >>>>> perror("read"); > > >>>>> return -1; > > >>>>> } > > >>>>> printf("Read %d bytes\n", (int) rv); > > >>>>> return 0; > > >>>>> } > > >>>>> > > >>>>> static int > > >>>>> do_server(void) > > >>>>> { > > >>>>> int err, ls, s, optval; > > >>>>> struct addrinfo *ai; > > >>>>> > > >>>>> printf("Server\n"); > > >>>>> > > >>>>> err = getaddr("::", "3023", true, &ai); > > >>>>> if (err) > > >>>>> return err; > > >>>>> > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > >>>>> if (ls = -1) { > > >>>>> perror("socket"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> optval = 1; > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > >>>>> (void *)&optval, sizeof(optval)) = -1) { > > >>>>> perror("setsockopt reuseaddr"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> /* Comment this out and it will work. */ > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > >>>>> sizeof(optval)) = -1) { > > >>>>> perror("setsockopt ipv6 only"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > >>>>> if (err = -1) { > > >>>>> perror("bind"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = listen(ls, 5); > > >>>>> if (err = -1) { > > >>>>> perror("listen"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> s = accept(ls, NULL, NULL); > > >>>>> if (s = -1) { > > >>>>> perror("accept"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> close(ls); > > >>>>> > > >>>>> err = waitread(s); > > >>>>> close(s); > > >>>>> return err; > > >>>>> } > > >>>>> > > >>>>> static int > > >>>>> do_client(void) > > >>>>> { > > >>>>> int err, s; > > >>>>> struct addrinfo *ai; > > >>>>> > > >>>>> printf("Client\n"); > > >>>>> > > >>>>> err = getaddr("::1", "3023", false, &ai); > > >>>>> if (err) > > >>>>> return err; > > >>>>> > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > >>>>> if (s = -1) { > > >>>>> perror("socket"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > >>>>> if (err = -1) { > > >>>>> perror("connect"); > > >>>>> return -1; > > >>>>> } > > >>>>> > > >>>>> err = waitread(s); > > >>>>> close(s); > > >>>>> return err; > > >>>>> } > > >>>>> > > >>>>> int > > >>>>> main(int argc, char *argv[]) > > >>>>> { > > >>>>> int err; > > >>>>> > > >>>>> if (argc > 1) > > >>>>> err = do_server(); > > >>>>> else > > >>>>> err = do_client(); > > >>>>> return !!err; > > >>>>> } > > >>>>> > > >> > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 13:29 ` Corey Minyard @ 2020-06-23 15:40 ` Xin Long -1 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-23 15:40 UTC (permalink / raw) To: minyard Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard <minyard@acm.org> wrote: > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > >>> > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > >>>>> > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > >>>>> then I make a connection to it using ::1, the connection will drop after > > > >>>>> 2.5 seconds with an ECONNRESET error. > > > >>>>> > > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > >>>>> I tried on an ARM system and x86_64. > > > >>>>> > > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > > >>>>> Basically, compile the following code: > > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > > >>>> bind any specific addresses ). Then after the connection is created, > > > >>>> the client will send HB on the v4 paths to the server. The server > > > >>>> will abort the connection, as it can't support v4. > > > >>>> > > > >>>> So you can work around it by either: > > > >>>> > > > >>>> - set IPV6_V6ONLY on client side. > > > >>>> > > > >>>> or > > > >>>> > > > >>>> - bind to the specific v6 addresses on the client side. > > > >>>> > > > >>>> I don't see RFC said something about this. > > > >>>> So it may not be a good idea to change the current behaviour > > > >>>> to not establish the connection in this case, which may cause regression. > > > >>> > > > >>> Ok, I understand this. It's a little strange, but I see why it works > > > >>> this way. > > > >> I don't. I would expect it to work as I described in my email. > > > >> Could someone explain me how and why it is behaving different from > > > >> my expectation? > > > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > > that's unexpected for a v6only socket. As is, it's the server saying > > > > "I'm available at these other addresses too, but not." > > > I agree. > > Then we need a fix in sctp_bind_addrs_to_raw(): > > > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > > struct sctp_bind_addr *bp, > > addrparms = retval; > > > > list_for_each_entry(addr, &bp->address_list, list) { > > + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && > > + (AF_INET == addr->a.sa.sa_family)) > > + continue; > > This does not compile in the latest mainline. sk is not defined. > Also, if you could send a normal git patch, that would be easier to > manage. sorry, that was just the code to show the idea. For the compilable one, pls see: https://paste.centos.org/view/49f5ff5a Thanks. > > Thanks, > > -corey > > > af = sctp_get_af_specific(addr->a.v4.sin_family); > > len = af->to_addr_param(&addr->a, &rawaddr); > > memcpy(addrparms.v, &rawaddr, len); > > > > > > > > Best regards > > > Michael > > > > > > > > Thanks, > > > > Marcelo > > > > > > > >> > > > >> Best regards > > > >> Michael > > > >>> > > > >>> Thanks, > > > >>> > > > >>> -corey > > > >>> > > > >>>> > > > >>>>> > > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > > >>>>> > > > >>>>> and run it in one window as a server: > > > >>>>> > > > >>>>> ./sctptest a > > > >>>>> > > > >>>>> (Pass in any option to be the server) and run the following in another > > > >>>>> window as the client: > > > >>>>> > > > >>>>> ./sctptest > > > >>>>> > > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > > >>>>> there forever. > > > >>>>> > > > >>>>> -corey > > > >>>>> > > > >>>>> > > > >>>>> #include <stdio.h> > > > >>>>> #include <stdbool.h> > > > >>>>> #include <string.h> > > > >>>>> #include <unistd.h> > > > >>>>> #include <fcntl.h> > > > >>>>> #include <sys/select.h> > > > >>>>> #include <arpa/inet.h> > > > >>>>> #include <netinet/sctp.h> > > > >>>>> #include <sys/types.h> > > > >>>>> #include <sys/socket.h> > > > >>>>> #include <netdb.h> > > > >>>>> > > > >>>>> static int > > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > > >>>>> struct addrinfo **rai) > > > >>>>> { > > > >>>>> struct addrinfo *ai, hints; > > > >>>>> > > > >>>>> memset(&hints, 0, sizeof(hints)); > > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > > >>>>> if (listen) > > > >>>>> hints.ai_flags |= AI_PASSIVE; > > > >>>>> hints.ai_family = AF_UNSPEC; > > > >>>>> hints.ai_socktype = SOCK_STREAM; > > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > > >>>>> perror("getaddrinfo"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> *rai = ai; > > > >>>>> return 0; > > > >>>>> } > > > >>>>> > > > >>>>> static int > > > >>>>> waitread(int s) > > > >>>>> { > > > >>>>> char data[1]; > > > >>>>> ssize_t rv; > > > >>>>> > > > >>>>> rv = read(s, data, sizeof(data)); > > > >>>>> if (rv == -1) { > > > >>>>> perror("read"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> printf("Read %d bytes\n", (int) rv); > > > >>>>> return 0; > > > >>>>> } > > > >>>>> > > > >>>>> static int > > > >>>>> do_server(void) > > > >>>>> { > > > >>>>> int err, ls, s, optval; > > > >>>>> struct addrinfo *ai; > > > >>>>> > > > >>>>> printf("Server\n"); > > > >>>>> > > > >>>>> err = getaddr("::", "3023", true, &ai); > > > >>>>> if (err) > > > >>>>> return err; > > > >>>>> > > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > >>>>> if (ls == -1) { > > > >>>>> perror("socket"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> optval = 1; > > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > > >>>>> (void *)&optval, sizeof(optval)) == -1) { > > > >>>>> perror("setsockopt reuseaddr"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> /* Comment this out and it will work. */ > > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > > >>>>> sizeof(optval)) == -1) { > > > >>>>> perror("setsockopt ipv6 only"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > > >>>>> if (err == -1) { > > > >>>>> perror("bind"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = listen(ls, 5); > > > >>>>> if (err == -1) { > > > >>>>> perror("listen"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> s = accept(ls, NULL, NULL); > > > >>>>> if (s == -1) { > > > >>>>> perror("accept"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> close(ls); > > > >>>>> > > > >>>>> err = waitread(s); > > > >>>>> close(s); > > > >>>>> return err; > > > >>>>> } > > > >>>>> > > > >>>>> static int > > > >>>>> do_client(void) > > > >>>>> { > > > >>>>> int err, s; > > > >>>>> struct addrinfo *ai; > > > >>>>> > > > >>>>> printf("Client\n"); > > > >>>>> > > > >>>>> err = getaddr("::1", "3023", false, &ai); > > > >>>>> if (err) > > > >>>>> return err; > > > >>>>> > > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > >>>>> if (s == -1) { > > > >>>>> perror("socket"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > > >>>>> if (err == -1) { > > > >>>>> perror("connect"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = waitread(s); > > > >>>>> close(s); > > > >>>>> return err; > > > >>>>> } > > > >>>>> > > > >>>>> int > > > >>>>> main(int argc, char *argv[]) > > > >>>>> { > > > >>>>> int err; > > > >>>>> > > > >>>>> if (argc > 1) > > > >>>>> err = do_server(); > > > >>>>> else > > > >>>>> err = do_client(); > > > >>>>> return !!err; > > > >>>>> } > > > >>>>> > > > >> > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 15:40 ` Xin Long 0 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-23 15:40 UTC (permalink / raw) To: minyard Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard <minyard@acm.org> wrote: > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > >>> > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > >>>>> > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > >>>>> then I make a connection to it using ::1, the connection will drop after > > > >>>>> 2.5 seconds with an ECONNRESET error. > > > >>>>> > > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > >>>>> I tried on an ARM system and x86_64. > > > >>>>> > > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > > >>>>> Basically, compile the following code: > > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > > >>>> bind any specific addresses ). Then after the connection is created, > > > >>>> the client will send HB on the v4 paths to the server. The server > > > >>>> will abort the connection, as it can't support v4. > > > >>>> > > > >>>> So you can work around it by either: > > > >>>> > > > >>>> - set IPV6_V6ONLY on client side. > > > >>>> > > > >>>> or > > > >>>> > > > >>>> - bind to the specific v6 addresses on the client side. > > > >>>> > > > >>>> I don't see RFC said something about this. > > > >>>> So it may not be a good idea to change the current behaviour > > > >>>> to not establish the connection in this case, which may cause regression. > > > >>> > > > >>> Ok, I understand this. It's a little strange, but I see why it works > > > >>> this way. > > > >> I don't. I would expect it to work as I described in my email. > > > >> Could someone explain me how and why it is behaving different from > > > >> my expectation? > > > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > > that's unexpected for a v6only socket. As is, it's the server saying > > > > "I'm available at these other addresses too, but not." > > > I agree. > > Then we need a fix in sctp_bind_addrs_to_raw(): > > > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > > struct sctp_bind_addr *bp, > > addrparms = retval; > > > > list_for_each_entry(addr, &bp->address_list, list) { > > + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && > > + (AF_INET = addr->a.sa.sa_family)) > > + continue; > > This does not compile in the latest mainline. sk is not defined. > Also, if you could send a normal git patch, that would be easier to > manage. sorry, that was just the code to show the idea. For the compilable one, pls see: https://paste.centos.org/view/49f5ff5a Thanks. > > Thanks, > > -corey > > > af = sctp_get_af_specific(addr->a.v4.sin_family); > > len = af->to_addr_param(&addr->a, &rawaddr); > > memcpy(addrparms.v, &rawaddr, len); > > > > > > > > Best regards > > > Michael > > > > > > > > Thanks, > > > > Marcelo > > > > > > > >> > > > >> Best regards > > > >> Michael > > > >>> > > > >>> Thanks, > > > >>> > > > >>> -corey > > > >>> > > > >>>> > > > >>>>> > > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > > >>>>> > > > >>>>> and run it in one window as a server: > > > >>>>> > > > >>>>> ./sctptest a > > > >>>>> > > > >>>>> (Pass in any option to be the server) and run the following in another > > > >>>>> window as the client: > > > >>>>> > > > >>>>> ./sctptest > > > >>>>> > > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > > >>>>> there forever. > > > >>>>> > > > >>>>> -corey > > > >>>>> > > > >>>>> > > > >>>>> #include <stdio.h> > > > >>>>> #include <stdbool.h> > > > >>>>> #include <string.h> > > > >>>>> #include <unistd.h> > > > >>>>> #include <fcntl.h> > > > >>>>> #include <sys/select.h> > > > >>>>> #include <arpa/inet.h> > > > >>>>> #include <netinet/sctp.h> > > > >>>>> #include <sys/types.h> > > > >>>>> #include <sys/socket.h> > > > >>>>> #include <netdb.h> > > > >>>>> > > > >>>>> static int > > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > > >>>>> struct addrinfo **rai) > > > >>>>> { > > > >>>>> struct addrinfo *ai, hints; > > > >>>>> > > > >>>>> memset(&hints, 0, sizeof(hints)); > > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > > >>>>> if (listen) > > > >>>>> hints.ai_flags |= AI_PASSIVE; > > > >>>>> hints.ai_family = AF_UNSPEC; > > > >>>>> hints.ai_socktype = SOCK_STREAM; > > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > > >>>>> perror("getaddrinfo"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> *rai = ai; > > > >>>>> return 0; > > > >>>>> } > > > >>>>> > > > >>>>> static int > > > >>>>> waitread(int s) > > > >>>>> { > > > >>>>> char data[1]; > > > >>>>> ssize_t rv; > > > >>>>> > > > >>>>> rv = read(s, data, sizeof(data)); > > > >>>>> if (rv = -1) { > > > >>>>> perror("read"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> printf("Read %d bytes\n", (int) rv); > > > >>>>> return 0; > > > >>>>> } > > > >>>>> > > > >>>>> static int > > > >>>>> do_server(void) > > > >>>>> { > > > >>>>> int err, ls, s, optval; > > > >>>>> struct addrinfo *ai; > > > >>>>> > > > >>>>> printf("Server\n"); > > > >>>>> > > > >>>>> err = getaddr("::", "3023", true, &ai); > > > >>>>> if (err) > > > >>>>> return err; > > > >>>>> > > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > >>>>> if (ls = -1) { > > > >>>>> perror("socket"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> optval = 1; > > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > > >>>>> (void *)&optval, sizeof(optval)) = -1) { > > > >>>>> perror("setsockopt reuseaddr"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> /* Comment this out and it will work. */ > > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > > >>>>> sizeof(optval)) = -1) { > > > >>>>> perror("setsockopt ipv6 only"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > > >>>>> if (err = -1) { > > > >>>>> perror("bind"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = listen(ls, 5); > > > >>>>> if (err = -1) { > > > >>>>> perror("listen"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> s = accept(ls, NULL, NULL); > > > >>>>> if (s = -1) { > > > >>>>> perror("accept"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> close(ls); > > > >>>>> > > > >>>>> err = waitread(s); > > > >>>>> close(s); > > > >>>>> return err; > > > >>>>> } > > > >>>>> > > > >>>>> static int > > > >>>>> do_client(void) > > > >>>>> { > > > >>>>> int err, s; > > > >>>>> struct addrinfo *ai; > > > >>>>> > > > >>>>> printf("Client\n"); > > > >>>>> > > > >>>>> err = getaddr("::1", "3023", false, &ai); > > > >>>>> if (err) > > > >>>>> return err; > > > >>>>> > > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > >>>>> if (s = -1) { > > > >>>>> perror("socket"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > > >>>>> if (err = -1) { > > > >>>>> perror("connect"); > > > >>>>> return -1; > > > >>>>> } > > > >>>>> > > > >>>>> err = waitread(s); > > > >>>>> close(s); > > > >>>>> return err; > > > >>>>> } > > > >>>>> > > > >>>>> int > > > >>>>> main(int argc, char *argv[]) > > > >>>>> { > > > >>>>> int err; > > > >>>>> > > > >>>>> if (argc > 1) > > > >>>>> err = do_server(); > > > >>>>> else > > > >>>>> err = do_client(); > > > >>>>> return !!err; > > > >>>>> } > > > >>>>> > > > >> > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 15:40 ` Xin Long @ 2020-06-23 16:00 ` Corey Minyard -1 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-23 16:00 UTC (permalink / raw) To: Xin Long Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote: > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard <minyard@acm.org> wrote: > > > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > > > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > >>> > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > >>>>> > > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > > >>>>> then I make a connection to it using ::1, the connection will drop after > > > > >>>>> 2.5 seconds with an ECONNRESET error. > > > > >>>>> > > > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > > >>>>> I tried on an ARM system and x86_64. > > > > >>>>> > > > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > > > >>>>> Basically, compile the following code: > > > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > > > >>>> bind any specific addresses ). Then after the connection is created, > > > > >>>> the client will send HB on the v4 paths to the server. The server > > > > >>>> will abort the connection, as it can't support v4. > > > > >>>> > > > > >>>> So you can work around it by either: > > > > >>>> > > > > >>>> - set IPV6_V6ONLY on client side. > > > > >>>> > > > > >>>> or > > > > >>>> > > > > >>>> - bind to the specific v6 addresses on the client side. > > > > >>>> > > > > >>>> I don't see RFC said something about this. > > > > >>>> So it may not be a good idea to change the current behaviour > > > > >>>> to not establish the connection in this case, which may cause regression. > > > > >>> > > > > >>> Ok, I understand this. It's a little strange, but I see why it works > > > > >>> this way. > > > > >> I don't. I would expect it to work as I described in my email. > > > > >> Could someone explain me how and why it is behaving different from > > > > >> my expectation? > > > > > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > > > that's unexpected for a v6only socket. As is, it's the server saying > > > > > "I'm available at these other addresses too, but not." > > > > I agree. > > > Then we need a fix in sctp_bind_addrs_to_raw(): > > > > > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > > > struct sctp_bind_addr *bp, > > > addrparms = retval; > > > > > > list_for_each_entry(addr, &bp->address_list, list) { > > > + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && > > > + (AF_INET == addr->a.sa.sa_family)) > > > + continue; > > > > This does not compile in the latest mainline. sk is not defined. > > Also, if you could send a normal git patch, that would be easier to > > manage. > sorry, that was just the code to show the idea. > > For the compilable one, pls see: > https://paste.centos.org/view/49f5ff5a The kernel community runs on patches. It's hard to talk about changes if you put things in pastbin type of stuff. Please send full complete patches in emails. I will do that in a moment. Anyway, are use sure every bp passed into sctp_bind_addrs_to_raw() is &asoc->base.bind_addr? It's passed in to sctp_make_init() and the passed to sctp_bind_addrs_to_raw(). If this is the case, you can remove it from the parameters of sctp_make_init(). But I suspect it's passed in for a reason. Anyway, I have a patch I have compiled and tested, I will send that. -corey > > Thanks. > > > > Thanks, > > > > -corey > > > > > af = sctp_get_af_specific(addr->a.v4.sin_family); > > > len = af->to_addr_param(&addr->a, &rawaddr); > > > memcpy(addrparms.v, &rawaddr, len); > > > > > > > > > > > Best regards > > > > Michael > > > > > > > > > > Thanks, > > > > > Marcelo > > > > > > > > > >> > > > > >> Best regards > > > > >> Michael > > > > >>> > > > > >>> Thanks, > > > > >>> > > > > >>> -corey > > > > >>> > > > > >>>> > > > > >>>>> > > > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > > > >>>>> > > > > >>>>> and run it in one window as a server: > > > > >>>>> > > > > >>>>> ./sctptest a > > > > >>>>> > > > > >>>>> (Pass in any option to be the server) and run the following in another > > > > >>>>> window as the client: > > > > >>>>> > > > > >>>>> ./sctptest > > > > >>>>> > > > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > > > >>>>> there forever. > > > > >>>>> > > > > >>>>> -corey > > > > >>>>> > > > > >>>>> > > > > >>>>> #include <stdio.h> > > > > >>>>> #include <stdbool.h> > > > > >>>>> #include <string.h> > > > > >>>>> #include <unistd.h> > > > > >>>>> #include <fcntl.h> > > > > >>>>> #include <sys/select.h> > > > > >>>>> #include <arpa/inet.h> > > > > >>>>> #include <netinet/sctp.h> > > > > >>>>> #include <sys/types.h> > > > > >>>>> #include <sys/socket.h> > > > > >>>>> #include <netdb.h> > > > > >>>>> > > > > >>>>> static int > > > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > > > >>>>> struct addrinfo **rai) > > > > >>>>> { > > > > >>>>> struct addrinfo *ai, hints; > > > > >>>>> > > > > >>>>> memset(&hints, 0, sizeof(hints)); > > > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > > > >>>>> if (listen) > > > > >>>>> hints.ai_flags |= AI_PASSIVE; > > > > >>>>> hints.ai_family = AF_UNSPEC; > > > > >>>>> hints.ai_socktype = SOCK_STREAM; > > > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > > > >>>>> perror("getaddrinfo"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> *rai = ai; > > > > >>>>> return 0; > > > > >>>>> } > > > > >>>>> > > > > >>>>> static int > > > > >>>>> waitread(int s) > > > > >>>>> { > > > > >>>>> char data[1]; > > > > >>>>> ssize_t rv; > > > > >>>>> > > > > >>>>> rv = read(s, data, sizeof(data)); > > > > >>>>> if (rv == -1) { > > > > >>>>> perror("read"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> printf("Read %d bytes\n", (int) rv); > > > > >>>>> return 0; > > > > >>>>> } > > > > >>>>> > > > > >>>>> static int > > > > >>>>> do_server(void) > > > > >>>>> { > > > > >>>>> int err, ls, s, optval; > > > > >>>>> struct addrinfo *ai; > > > > >>>>> > > > > >>>>> printf("Server\n"); > > > > >>>>> > > > > >>>>> err = getaddr("::", "3023", true, &ai); > > > > >>>>> if (err) > > > > >>>>> return err; > > > > >>>>> > > > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > >>>>> if (ls == -1) { > > > > >>>>> perror("socket"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> optval = 1; > > > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > > > >>>>> (void *)&optval, sizeof(optval)) == -1) { > > > > >>>>> perror("setsockopt reuseaddr"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> /* Comment this out and it will work. */ > > > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > > > >>>>> sizeof(optval)) == -1) { > > > > >>>>> perror("setsockopt ipv6 only"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > > > >>>>> if (err == -1) { > > > > >>>>> perror("bind"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = listen(ls, 5); > > > > >>>>> if (err == -1) { > > > > >>>>> perror("listen"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> s = accept(ls, NULL, NULL); > > > > >>>>> if (s == -1) { > > > > >>>>> perror("accept"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> close(ls); > > > > >>>>> > > > > >>>>> err = waitread(s); > > > > >>>>> close(s); > > > > >>>>> return err; > > > > >>>>> } > > > > >>>>> > > > > >>>>> static int > > > > >>>>> do_client(void) > > > > >>>>> { > > > > >>>>> int err, s; > > > > >>>>> struct addrinfo *ai; > > > > >>>>> > > > > >>>>> printf("Client\n"); > > > > >>>>> > > > > >>>>> err = getaddr("::1", "3023", false, &ai); > > > > >>>>> if (err) > > > > >>>>> return err; > > > > >>>>> > > > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > >>>>> if (s == -1) { > > > > >>>>> perror("socket"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > > > >>>>> if (err == -1) { > > > > >>>>> perror("connect"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = waitread(s); > > > > >>>>> close(s); > > > > >>>>> return err; > > > > >>>>> } > > > > >>>>> > > > > >>>>> int > > > > >>>>> main(int argc, char *argv[]) > > > > >>>>> { > > > > >>>>> int err; > > > > >>>>> > > > > >>>>> if (argc > 1) > > > > >>>>> err = do_server(); > > > > >>>>> else > > > > >>>>> err = do_client(); > > > > >>>>> return !!err; > > > > >>>>> } > > > > >>>>> > > > > >> > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 16:00 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-23 16:00 UTC (permalink / raw) To: Xin Long Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote: > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard <minyard@acm.org> wrote: > > > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > > > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > >>> > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > >>>>> > > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > > >>>>> then I make a connection to it using ::1, the connection will drop after > > > > >>>>> 2.5 seconds with an ECONNRESET error. > > > > >>>>> > > > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > > >>>>> I tried on an ARM system and x86_64. > > > > >>>>> > > > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > > > >>>>> Basically, compile the following code: > > > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > > > >>>> bind any specific addresses ). Then after the connection is created, > > > > >>>> the client will send HB on the v4 paths to the server. The server > > > > >>>> will abort the connection, as it can't support v4. > > > > >>>> > > > > >>>> So you can work around it by either: > > > > >>>> > > > > >>>> - set IPV6_V6ONLY on client side. > > > > >>>> > > > > >>>> or > > > > >>>> > > > > >>>> - bind to the specific v6 addresses on the client side. > > > > >>>> > > > > >>>> I don't see RFC said something about this. > > > > >>>> So it may not be a good idea to change the current behaviour > > > > >>>> to not establish the connection in this case, which may cause regression. > > > > >>> > > > > >>> Ok, I understand this. It's a little strange, but I see why it works > > > > >>> this way. > > > > >> I don't. I would expect it to work as I described in my email. > > > > >> Could someone explain me how and why it is behaving different from > > > > >> my expectation? > > > > > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > > > that's unexpected for a v6only socket. As is, it's the server saying > > > > > "I'm available at these other addresses too, but not." > > > > I agree. > > > Then we need a fix in sctp_bind_addrs_to_raw(): > > > > > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > > > struct sctp_bind_addr *bp, > > > addrparms = retval; > > > > > > list_for_each_entry(addr, &bp->address_list, list) { > > > + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && > > > + (AF_INET = addr->a.sa.sa_family)) > > > + continue; > > > > This does not compile in the latest mainline. sk is not defined. > > Also, if you could send a normal git patch, that would be easier to > > manage. > sorry, that was just the code to show the idea. > > For the compilable one, pls see: > https://paste.centos.org/view/49f5ff5a The kernel community runs on patches. It's hard to talk about changes if you put things in pastbin type of stuff. Please send full complete patches in emails. I will do that in a moment. Anyway, are use sure every bp passed into sctp_bind_addrs_to_raw() is &asoc->base.bind_addr? It's passed in to sctp_make_init() and the passed to sctp_bind_addrs_to_raw(). If this is the case, you can remove it from the parameters of sctp_make_init(). But I suspect it's passed in for a reason. Anyway, I have a patch I have compiled and tested, I will send that. -corey > > Thanks. > > > > Thanks, > > > > -corey > > > > > af = sctp_get_af_specific(addr->a.v4.sin_family); > > > len = af->to_addr_param(&addr->a, &rawaddr); > > > memcpy(addrparms.v, &rawaddr, len); > > > > > > > > > > > Best regards > > > > Michael > > > > > > > > > > Thanks, > > > > > Marcelo > > > > > > > > > >> > > > > >> Best regards > > > > >> Michael > > > > >>> > > > > >>> Thanks, > > > > >>> > > > > >>> -corey > > > > >>> > > > > >>>> > > > > >>>>> > > > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > > > >>>>> > > > > >>>>> and run it in one window as a server: > > > > >>>>> > > > > >>>>> ./sctptest a > > > > >>>>> > > > > >>>>> (Pass in any option to be the server) and run the following in another > > > > >>>>> window as the client: > > > > >>>>> > > > > >>>>> ./sctptest > > > > >>>>> > > > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > > > >>>>> there forever. > > > > >>>>> > > > > >>>>> -corey > > > > >>>>> > > > > >>>>> > > > > >>>>> #include <stdio.h> > > > > >>>>> #include <stdbool.h> > > > > >>>>> #include <string.h> > > > > >>>>> #include <unistd.h> > > > > >>>>> #include <fcntl.h> > > > > >>>>> #include <sys/select.h> > > > > >>>>> #include <arpa/inet.h> > > > > >>>>> #include <netinet/sctp.h> > > > > >>>>> #include <sys/types.h> > > > > >>>>> #include <sys/socket.h> > > > > >>>>> #include <netdb.h> > > > > >>>>> > > > > >>>>> static int > > > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > > > >>>>> struct addrinfo **rai) > > > > >>>>> { > > > > >>>>> struct addrinfo *ai, hints; > > > > >>>>> > > > > >>>>> memset(&hints, 0, sizeof(hints)); > > > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > > > >>>>> if (listen) > > > > >>>>> hints.ai_flags |= AI_PASSIVE; > > > > >>>>> hints.ai_family = AF_UNSPEC; > > > > >>>>> hints.ai_socktype = SOCK_STREAM; > > > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > > > >>>>> perror("getaddrinfo"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> *rai = ai; > > > > >>>>> return 0; > > > > >>>>> } > > > > >>>>> > > > > >>>>> static int > > > > >>>>> waitread(int s) > > > > >>>>> { > > > > >>>>> char data[1]; > > > > >>>>> ssize_t rv; > > > > >>>>> > > > > >>>>> rv = read(s, data, sizeof(data)); > > > > >>>>> if (rv = -1) { > > > > >>>>> perror("read"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> printf("Read %d bytes\n", (int) rv); > > > > >>>>> return 0; > > > > >>>>> } > > > > >>>>> > > > > >>>>> static int > > > > >>>>> do_server(void) > > > > >>>>> { > > > > >>>>> int err, ls, s, optval; > > > > >>>>> struct addrinfo *ai; > > > > >>>>> > > > > >>>>> printf("Server\n"); > > > > >>>>> > > > > >>>>> err = getaddr("::", "3023", true, &ai); > > > > >>>>> if (err) > > > > >>>>> return err; > > > > >>>>> > > > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > >>>>> if (ls = -1) { > > > > >>>>> perror("socket"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> optval = 1; > > > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > > > >>>>> (void *)&optval, sizeof(optval)) = -1) { > > > > >>>>> perror("setsockopt reuseaddr"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> /* Comment this out and it will work. */ > > > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > > > >>>>> sizeof(optval)) = -1) { > > > > >>>>> perror("setsockopt ipv6 only"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > > > >>>>> if (err = -1) { > > > > >>>>> perror("bind"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = listen(ls, 5); > > > > >>>>> if (err = -1) { > > > > >>>>> perror("listen"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> s = accept(ls, NULL, NULL); > > > > >>>>> if (s = -1) { > > > > >>>>> perror("accept"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> close(ls); > > > > >>>>> > > > > >>>>> err = waitread(s); > > > > >>>>> close(s); > > > > >>>>> return err; > > > > >>>>> } > > > > >>>>> > > > > >>>>> static int > > > > >>>>> do_client(void) > > > > >>>>> { > > > > >>>>> int err, s; > > > > >>>>> struct addrinfo *ai; > > > > >>>>> > > > > >>>>> printf("Client\n"); > > > > >>>>> > > > > >>>>> err = getaddr("::1", "3023", false, &ai); > > > > >>>>> if (err) > > > > >>>>> return err; > > > > >>>>> > > > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > >>>>> if (s = -1) { > > > > >>>>> perror("socket"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > > > >>>>> if (err = -1) { > > > > >>>>> perror("connect"); > > > > >>>>> return -1; > > > > >>>>> } > > > > >>>>> > > > > >>>>> err = waitread(s); > > > > >>>>> close(s); > > > > >>>>> return err; > > > > >>>>> } > > > > >>>>> > > > > >>>>> int > > > > >>>>> main(int argc, char *argv[]) > > > > >>>>> { > > > > >>>>> int err; > > > > >>>>> > > > > >>>>> if (argc > 1) > > > > >>>>> err = do_server(); > > > > >>>>> else > > > > >>>>> err = do_client(); > > > > >>>>> return !!err; > > > > >>>>> } > > > > >>>>> > > > > >> > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 16:00 ` Corey Minyard @ 2020-06-24 6:58 ` Xin Long -1 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-24 6:58 UTC (permalink / raw) To: minyard Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Wed, Jun 24, 2020 at 12:00 AM Corey Minyard <minyard@acm.org> wrote: > > On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote: > > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard <minyard@acm.org> wrote: > > > > > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > > > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > > > > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > > > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > >>> > > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > > >>>>> > > > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > > > >>>>> then I make a connection to it using ::1, the connection will drop after > > > > > >>>>> 2.5 seconds with an ECONNRESET error. > > > > > >>>>> > > > > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > > > >>>>> I tried on an ARM system and x86_64. > > > > > >>>>> > > > > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > > > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > > > > >>>>> Basically, compile the following code: > > > > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > > > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > > > > >>>> bind any specific addresses ). Then after the connection is created, > > > > > >>>> the client will send HB on the v4 paths to the server. The server > > > > > >>>> will abort the connection, as it can't support v4. > > > > > >>>> > > > > > >>>> So you can work around it by either: > > > > > >>>> > > > > > >>>> - set IPV6_V6ONLY on client side. > > > > > >>>> > > > > > >>>> or > > > > > >>>> > > > > > >>>> - bind to the specific v6 addresses on the client side. > > > > > >>>> > > > > > >>>> I don't see RFC said something about this. > > > > > >>>> So it may not be a good idea to change the current behaviour > > > > > >>>> to not establish the connection in this case, which may cause regression. > > > > > >>> > > > > > >>> Ok, I understand this. It's a little strange, but I see why it works > > > > > >>> this way. > > > > > >> I don't. I would expect it to work as I described in my email. > > > > > >> Could someone explain me how and why it is behaving different from > > > > > >> my expectation? > > > > > > > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > > > > that's unexpected for a v6only socket. As is, it's the server saying > > > > > > "I'm available at these other addresses too, but not." > > > > > I agree. > > > > Then we need a fix in sctp_bind_addrs_to_raw(): > > > > > > > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > > > > struct sctp_bind_addr *bp, > > > > addrparms = retval; > > > > > > > > list_for_each_entry(addr, &bp->address_list, list) { > > > > + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && > > > > + (AF_INET == addr->a.sa.sa_family)) > > > > + continue; > > > > > > This does not compile in the latest mainline. sk is not defined. > > > Also, if you could send a normal git patch, that would be easier to > > > manage. > > sorry, that was just the code to show the idea. > > > > For the compilable one, pls see: > > https://paste.centos.org/view/49f5ff5a > > The kernel community runs on patches. It's hard to talk about changes > if you put things in pastbin type of stuff. Please send full complete > patches in emails. I will do that in a moment. I thought you wanted a temporary patch to run your test. The final patch still needs some change, like drop the *bp param even from sctp_make_init(). > > Anyway, are use sure every bp passed into sctp_bind_addrs_to_raw() > is &asoc->base.bind_addr? It's passed in to sctp_make_init() and the > passed to sctp_bind_addrs_to_raw(). If this is the case, you can remove > it from the parameters of sctp_make_init(). But I suspect it's passed > in for a reason. This is not difficult to track. path 1: sctp_sf_do_5_2_6_stale()/sctp_sf_do_prm_asoc()/ sctp_sf_t1_init_timer_expire() -> sctp_make_init() -> sctp_bind_addrs_to_raw() path 2: sctp_make_init_ack() -> sctp_bind_addrs_to_raw(). If you think there must be a reason for this, I think it's they may just pass a minimal-structure pointer. > > Anyway, I have a patch I have compiled and tested, I will send that. > > -corey > > > > > Thanks. > > > > > > Thanks, > > > > > > -corey > > > > > > > af = sctp_get_af_specific(addr->a.v4.sin_family); > > > > len = af->to_addr_param(&addr->a, &rawaddr); > > > > memcpy(addrparms.v, &rawaddr, len); > > > > > > > > > > > > > > Best regards > > > > > Michael > > > > > > > > > > > > Thanks, > > > > > > Marcelo > > > > > > > > > > > >> > > > > > >> Best regards > > > > > >> Michael > > > > > >>> > > > > > >>> Thanks, > > > > > >>> > > > > > >>> -corey > > > > > >>> > > > > > >>>> > > > > > >>>>> > > > > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > > > > >>>>> > > > > > >>>>> and run it in one window as a server: > > > > > >>>>> > > > > > >>>>> ./sctptest a > > > > > >>>>> > > > > > >>>>> (Pass in any option to be the server) and run the following in another > > > > > >>>>> window as the client: > > > > > >>>>> > > > > > >>>>> ./sctptest > > > > > >>>>> > > > > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > > > > >>>>> there forever. > > > > > >>>>> > > > > > >>>>> -corey > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> #include <stdio.h> > > > > > >>>>> #include <stdbool.h> > > > > > >>>>> #include <string.h> > > > > > >>>>> #include <unistd.h> > > > > > >>>>> #include <fcntl.h> > > > > > >>>>> #include <sys/select.h> > > > > > >>>>> #include <arpa/inet.h> > > > > > >>>>> #include <netinet/sctp.h> > > > > > >>>>> #include <sys/types.h> > > > > > >>>>> #include <sys/socket.h> > > > > > >>>>> #include <netdb.h> > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > > > > >>>>> struct addrinfo **rai) > > > > > >>>>> { > > > > > >>>>> struct addrinfo *ai, hints; > > > > > >>>>> > > > > > >>>>> memset(&hints, 0, sizeof(hints)); > > > > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > > > > >>>>> if (listen) > > > > > >>>>> hints.ai_flags |= AI_PASSIVE; > > > > > >>>>> hints.ai_family = AF_UNSPEC; > > > > > >>>>> hints.ai_socktype = SOCK_STREAM; > > > > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > > > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > > > > >>>>> perror("getaddrinfo"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> *rai = ai; > > > > > >>>>> return 0; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> waitread(int s) > > > > > >>>>> { > > > > > >>>>> char data[1]; > > > > > >>>>> ssize_t rv; > > > > > >>>>> > > > > > >>>>> rv = read(s, data, sizeof(data)); > > > > > >>>>> if (rv == -1) { > > > > > >>>>> perror("read"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> printf("Read %d bytes\n", (int) rv); > > > > > >>>>> return 0; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> do_server(void) > > > > > >>>>> { > > > > > >>>>> int err, ls, s, optval; > > > > > >>>>> struct addrinfo *ai; > > > > > >>>>> > > > > > >>>>> printf("Server\n"); > > > > > >>>>> > > > > > >>>>> err = getaddr("::", "3023", true, &ai); > > > > > >>>>> if (err) > > > > > >>>>> return err; > > > > > >>>>> > > > > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > > >>>>> if (ls == -1) { > > > > > >>>>> perror("socket"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> optval = 1; > > > > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > > > > >>>>> (void *)&optval, sizeof(optval)) == -1) { > > > > > >>>>> perror("setsockopt reuseaddr"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> /* Comment this out and it will work. */ > > > > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > > > > >>>>> sizeof(optval)) == -1) { > > > > > >>>>> perror("setsockopt ipv6 only"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > > > > >>>>> if (err == -1) { > > > > > >>>>> perror("bind"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = listen(ls, 5); > > > > > >>>>> if (err == -1) { > > > > > >>>>> perror("listen"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> s = accept(ls, NULL, NULL); > > > > > >>>>> if (s == -1) { > > > > > >>>>> perror("accept"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> close(ls); > > > > > >>>>> > > > > > >>>>> err = waitread(s); > > > > > >>>>> close(s); > > > > > >>>>> return err; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> do_client(void) > > > > > >>>>> { > > > > > >>>>> int err, s; > > > > > >>>>> struct addrinfo *ai; > > > > > >>>>> > > > > > >>>>> printf("Client\n"); > > > > > >>>>> > > > > > >>>>> err = getaddr("::1", "3023", false, &ai); > > > > > >>>>> if (err) > > > > > >>>>> return err; > > > > > >>>>> > > > > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > > >>>>> if (s == -1) { > > > > > >>>>> perror("socket"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > > > > >>>>> if (err == -1) { > > > > > >>>>> perror("connect"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = waitread(s); > > > > > >>>>> close(s); > > > > > >>>>> return err; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> int > > > > > >>>>> main(int argc, char *argv[]) > > > > > >>>>> { > > > > > >>>>> int err; > > > > > >>>>> > > > > > >>>>> if (argc > 1) > > > > > >>>>> err = do_server(); > > > > > >>>>> else > > > > > >>>>> err = do_client(); > > > > > >>>>> return !!err; > > > > > >>>>> } > > > > > >>>>> > > > > > >> > > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-24 6:58 ` Xin Long 0 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-24 6:58 UTC (permalink / raw) To: minyard Cc: Michael Tuexen, Marcelo Ricardo Leitner, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Wed, Jun 24, 2020 at 12:00 AM Corey Minyard <minyard@acm.org> wrote: > > On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote: > > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard <minyard@acm.org> wrote: > > > > > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote: > > > > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen > > > > <Michael.Tuexen@lurchi.franken.de> wrote: > > > > > > > > > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > >>> > > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > > >>>>> > > > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > > > >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > > > >>>>> then I make a connection to it using ::1, the connection will drop after > > > > > >>>>> 2.5 seconds with an ECONNRESET error. > > > > > >>>>> > > > > > >>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > > > >>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > > > >>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > > > >>>>> I tried on an ARM system and x86_64. > > > > > >>>>> > > > > > >>>>> I haven't dug into the kernel to see if I could find anything yet, but I > > > > > >>>>> thought I would go ahead and report it. I am attaching a reproducer. > > > > > >>>>> Basically, compile the following code: > > > > > >>>> The code only set IPV6_V6ONLY on server side, so the client side will > > > > > >>>> still bind all the local ipv4 addresses (as you didn't call bind() to > > > > > >>>> bind any specific addresses ). Then after the connection is created, > > > > > >>>> the client will send HB on the v4 paths to the server. The server > > > > > >>>> will abort the connection, as it can't support v4. > > > > > >>>> > > > > > >>>> So you can work around it by either: > > > > > >>>> > > > > > >>>> - set IPV6_V6ONLY on client side. > > > > > >>>> > > > > > >>>> or > > > > > >>>> > > > > > >>>> - bind to the specific v6 addresses on the client side. > > > > > >>>> > > > > > >>>> I don't see RFC said something about this. > > > > > >>>> So it may not be a good idea to change the current behaviour > > > > > >>>> to not establish the connection in this case, which may cause regression. > > > > > >>> > > > > > >>> Ok, I understand this. It's a little strange, but I see why it works > > > > > >>> this way. > > > > > >> I don't. I would expect it to work as I described in my email. > > > > > >> Could someone explain me how and why it is behaving different from > > > > > >> my expectation? > > > > > > > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > > > > that's unexpected for a v6only socket. As is, it's the server saying > > > > > > "I'm available at these other addresses too, but not." > > > > > I agree. > > > > Then we need a fix in sctp_bind_addrs_to_raw(): > > > > > > > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > > > > struct sctp_bind_addr *bp, > > > > addrparms = retval; > > > > > > > > list_for_each_entry(addr, &bp->address_list, list) { > > > > + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && > > > > + (AF_INET = addr->a.sa.sa_family)) > > > > + continue; > > > > > > This does not compile in the latest mainline. sk is not defined. > > > Also, if you could send a normal git patch, that would be easier to > > > manage. > > sorry, that was just the code to show the idea. > > > > For the compilable one, pls see: > > https://paste.centos.org/view/49f5ff5a > > The kernel community runs on patches. It's hard to talk about changes > if you put things in pastbin type of stuff. Please send full complete > patches in emails. I will do that in a moment. I thought you wanted a temporary patch to run your test. The final patch still needs some change, like drop the *bp param even from sctp_make_init(). > > Anyway, are use sure every bp passed into sctp_bind_addrs_to_raw() > is &asoc->base.bind_addr? It's passed in to sctp_make_init() and the > passed to sctp_bind_addrs_to_raw(). If this is the case, you can remove > it from the parameters of sctp_make_init(). But I suspect it's passed > in for a reason. This is not difficult to track. path 1: sctp_sf_do_5_2_6_stale()/sctp_sf_do_prm_asoc()/ sctp_sf_t1_init_timer_expire() -> sctp_make_init() -> sctp_bind_addrs_to_raw() path 2: sctp_make_init_ack() -> sctp_bind_addrs_to_raw(). If you think there must be a reason for this, I think it's they may just pass a minimal-structure pointer. > > Anyway, I have a patch I have compiled and tested, I will send that. > > -corey > > > > > Thanks. > > > > > > Thanks, > > > > > > -corey > > > > > > > af = sctp_get_af_specific(addr->a.v4.sin_family); > > > > len = af->to_addr_param(&addr->a, &rawaddr); > > > > memcpy(addrparms.v, &rawaddr, len); > > > > > > > > > > > > > > Best regards > > > > > Michael > > > > > > > > > > > > Thanks, > > > > > > Marcelo > > > > > > > > > > > >> > > > > > >> Best regards > > > > > >> Michael > > > > > >>> > > > > > >>> Thanks, > > > > > >>> > > > > > >>> -corey > > > > > >>> > > > > > >>>> > > > > > >>>>> > > > > > >>>>> gcc -g -o sctptest -Wall sctptest.c > > > > > >>>>> > > > > > >>>>> and run it in one window as a server: > > > > > >>>>> > > > > > >>>>> ./sctptest a > > > > > >>>>> > > > > > >>>>> (Pass in any option to be the server) and run the following in another > > > > > >>>>> window as the client: > > > > > >>>>> > > > > > >>>>> ./sctptest > > > > > >>>>> > > > > > >>>>> It disconnects after about 2.5 seconds. If it works, it should just sit > > > > > >>>>> there forever. > > > > > >>>>> > > > > > >>>>> -corey > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> #include <stdio.h> > > > > > >>>>> #include <stdbool.h> > > > > > >>>>> #include <string.h> > > > > > >>>>> #include <unistd.h> > > > > > >>>>> #include <fcntl.h> > > > > > >>>>> #include <sys/select.h> > > > > > >>>>> #include <arpa/inet.h> > > > > > >>>>> #include <netinet/sctp.h> > > > > > >>>>> #include <sys/types.h> > > > > > >>>>> #include <sys/socket.h> > > > > > >>>>> #include <netdb.h> > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> getaddr(const char *addr, const char *port, bool listen, > > > > > >>>>> struct addrinfo **rai) > > > > > >>>>> { > > > > > >>>>> struct addrinfo *ai, hints; > > > > > >>>>> > > > > > >>>>> memset(&hints, 0, sizeof(hints)); > > > > > >>>>> hints.ai_flags = AI_ADDRCONFIG; > > > > > >>>>> if (listen) > > > > > >>>>> hints.ai_flags |= AI_PASSIVE; > > > > > >>>>> hints.ai_family = AF_UNSPEC; > > > > > >>>>> hints.ai_socktype = SOCK_STREAM; > > > > > >>>>> hints.ai_protocol = IPPROTO_SCTP; > > > > > >>>>> if (getaddrinfo(addr, port, &hints, &ai)) { > > > > > >>>>> perror("getaddrinfo"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> *rai = ai; > > > > > >>>>> return 0; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> waitread(int s) > > > > > >>>>> { > > > > > >>>>> char data[1]; > > > > > >>>>> ssize_t rv; > > > > > >>>>> > > > > > >>>>> rv = read(s, data, sizeof(data)); > > > > > >>>>> if (rv = -1) { > > > > > >>>>> perror("read"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> printf("Read %d bytes\n", (int) rv); > > > > > >>>>> return 0; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> do_server(void) > > > > > >>>>> { > > > > > >>>>> int err, ls, s, optval; > > > > > >>>>> struct addrinfo *ai; > > > > > >>>>> > > > > > >>>>> printf("Server\n"); > > > > > >>>>> > > > > > >>>>> err = getaddr("::", "3023", true, &ai); > > > > > >>>>> if (err) > > > > > >>>>> return err; > > > > > >>>>> > > > > > >>>>> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > > >>>>> if (ls = -1) { > > > > > >>>>> perror("socket"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> optval = 1; > > > > > >>>>> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, > > > > > >>>>> (void *)&optval, sizeof(optval)) = -1) { > > > > > >>>>> perror("setsockopt reuseaddr"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> /* Comment this out and it will work. */ > > > > > >>>>> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval, > > > > > >>>>> sizeof(optval)) = -1) { > > > > > >>>>> perror("setsockopt ipv6 only"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = bind(ls, ai->ai_addr, ai->ai_addrlen); > > > > > >>>>> if (err = -1) { > > > > > >>>>> perror("bind"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = listen(ls, 5); > > > > > >>>>> if (err = -1) { > > > > > >>>>> perror("listen"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> s = accept(ls, NULL, NULL); > > > > > >>>>> if (s = -1) { > > > > > >>>>> perror("accept"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> close(ls); > > > > > >>>>> > > > > > >>>>> err = waitread(s); > > > > > >>>>> close(s); > > > > > >>>>> return err; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> static int > > > > > >>>>> do_client(void) > > > > > >>>>> { > > > > > >>>>> int err, s; > > > > > >>>>> struct addrinfo *ai; > > > > > >>>>> > > > > > >>>>> printf("Client\n"); > > > > > >>>>> > > > > > >>>>> err = getaddr("::1", "3023", false, &ai); > > > > > >>>>> if (err) > > > > > >>>>> return err; > > > > > >>>>> > > > > > >>>>> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > > > > > >>>>> if (s = -1) { > > > > > >>>>> perror("socket"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = connect(s, ai->ai_addr, ai->ai_addrlen); > > > > > >>>>> if (err = -1) { > > > > > >>>>> perror("connect"); > > > > > >>>>> return -1; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> err = waitread(s); > > > > > >>>>> close(s); > > > > > >>>>> return err; > > > > > >>>>> } > > > > > >>>>> > > > > > >>>>> int > > > > > >>>>> main(int argc, char *argv[]) > > > > > >>>>> { > > > > > >>>>> int err; > > > > > >>>>> > > > > > >>>>> if (argc > 1) > > > > > >>>>> err = do_server(); > > > > > >>>>> else > > > > > >>>>> err = do_client(); > > > > > >>>>> return !!err; > > > > > >>>>> } > > > > > >>>>> > > > > > >> > > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: Strange problem with SCTP+IPv6 2020-06-23 10:13 ` Xin Long @ 2020-06-26 16:13 ` David Laight -1 siblings, 0 replies; 55+ messages in thread From: David Laight @ 2020-06-26 16:13 UTC (permalink / raw) To: 'Xin Long', Michael Tuexen Cc: Marcelo Ricardo Leitner, minyard, Vlad Yasevich, Neil Horman, linux-sctp, LKML From: Xin Long > Sent: 23 June 2020 11:14 > > > It looks like a bug to me. Testing with this test app here, I can see > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > that's unexpected for a v6only socket. As is, it's the server saying > > > "I'm available at these other addresses too, but not." > > I agree. > Then we need a fix in sctp_bind_addrs_to_raw(): > > @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const > struct sctp_bind_addr *bp, > addrparms = retval; > > list_for_each_entry(addr, &bp->address_list, list) { > + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && > + (AF_INET == addr->a.sa.sa_family)) > + continue; > af = sctp_get_af_specific(addr->a.v4.sin_family); > len = af->to_addr_param(&addr->a, &rawaddr); > memcpy(addrparms.v, &rawaddr, len); Thought. Does it make any sense to offer addresses in the INIT_ACK that don't have routes to those proposed in the received INIT? 'routes' probably isn't exactly the right word. You probably only want the local address that will be used as the source address for the probes. Or, at least, sources addresses that could be used for the probes. So if the INIT only contains IPv6 addresses should the INIT_ACK ever contain IPv4 ones. David. - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: Strange problem with SCTP+IPv6 @ 2020-06-26 16:13 ` David Laight 0 siblings, 0 replies; 55+ messages in thread From: David Laight @ 2020-06-26 16:13 UTC (permalink / raw) To: 'Xin Long', Michael Tuexen Cc: Marcelo Ricardo Leitner, minyard, Vlad Yasevich, Neil Horman, linux-sctp, LKML RnJvbTogWGluIExvbmcNCj4gU2VudDogMjMgSnVuZSAyMDIwIDExOjE0DQo+ID4gPiBJdCBsb29r cyBsaWtlIGEgYnVnIHRvIG1lLiBUZXN0aW5nIHdpdGggdGhpcyB0ZXN0IGFwcCBoZXJlLCBJIGNh biBzZWUNCj4gPiA+IHRoZSBJTklUX0FDSyBiZWluZyBzZW50IHdpdGggYSBidW5jaCBvZiBpcHY0 IGFkZHJlc3NlcyBpbiBpdCBhbmQNCj4gPiA+IHRoYXQncyB1bmV4cGVjdGVkIGZvciBhIHY2b25s eSBzb2NrZXQuIEFzIGlzLCBpdCdzIHRoZSBzZXJ2ZXIgc2F5aW5nDQo+ID4gPiAiSSdtIGF2YWls YWJsZSBhdCB0aGVzZSBvdGhlciBhZGRyZXNzZXMgdG9vLCBidXQgbm90LiINCj4gPiBJIGFncmVl Lg0KPiBUaGVuIHdlIG5lZWQgYSBmaXggaW4gc2N0cF9iaW5kX2FkZHJzX3RvX3JhdygpOg0KPiAN Cj4gQEAgLTIzOCw2ICsyNDAsOSBAQCB1bmlvbiBzY3RwX3BhcmFtcyBzY3RwX2JpbmRfYWRkcnNf dG9fcmF3KGNvbnN0DQo+IHN0cnVjdCBzY3RwX2JpbmRfYWRkciAqYnAsDQo+ICAgICAgICAgYWRk cnBhcm1zID0gcmV0dmFsOw0KPiANCj4gICAgICAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGFkZHIs ICZicC0+YWRkcmVzc19saXN0LCBsaXN0KSB7DQo+ICsgICAgICAgICAgICAgICBpZiAoKFBGX0lO RVQ2ID09IHNrLT5za19mYW1pbHkpICYmIGluZXRfdjZfaXB2Nm9ubHkoc2spICYmDQo+ICsgICAg ICAgICAgICAgICAgICAgKEFGX0lORVQgPT0gYWRkci0+YS5zYS5zYV9mYW1pbHkpKQ0KPiArICAg ICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgIGFmID0gc2N0 cF9nZXRfYWZfc3BlY2lmaWMoYWRkci0+YS52NC5zaW5fZmFtaWx5KTsNCj4gICAgICAgICAgICAg ICAgIGxlbiA9IGFmLT50b19hZGRyX3BhcmFtKCZhZGRyLT5hLCAmcmF3YWRkcik7DQo+ICAgICAg ICAgICAgICAgICBtZW1jcHkoYWRkcnBhcm1zLnYsICZyYXdhZGRyLCBsZW4pOw0KDQpUaG91Z2h0 Lg0KDQpEb2VzIGl0IG1ha2UgYW55IHNlbnNlIHRvIG9mZmVyIGFkZHJlc3NlcyBpbiB0aGUgSU5J VF9BQ0sgdGhhdCBkb24ndA0KaGF2ZSByb3V0ZXMgdG8gdGhvc2UgcHJvcG9zZWQgaW4gdGhlIHJl Y2VpdmVkIElOSVQ/DQoNCidyb3V0ZXMnIHByb2JhYmx5IGlzbid0IGV4YWN0bHkgdGhlIHJpZ2h0 IHdvcmQuDQpZb3UgcHJvYmFibHkgb25seSB3YW50IHRoZSBsb2NhbCBhZGRyZXNzIHRoYXQgd2ls bCBiZSB1c2VkDQphcyB0aGUgc291cmNlIGFkZHJlc3MgZm9yIHRoZSBwcm9iZXMuDQpPciwgYXQg bGVhc3QsIHNvdXJjZXMgYWRkcmVzc2VzIHRoYXQgY291bGQgYmUgdXNlZCBmb3IgdGhlIHByb2Jl cy4NCg0KU28gaWYgdGhlIElOSVQgb25seSBjb250YWlucyBJUHY2IGFkZHJlc3NlcyBzaG91bGQg dGhlIElOSVRfQUNLDQpldmVyIGNvbnRhaW4gSVB2NCBvbmVzLg0KDQoJRGF2aWQuDQoNCi0NClJl Z2lzdGVyZWQgQWRkcmVzcyBMYWtlc2lkZSwgQnJhbWxleSBSb2FkLCBNb3VudCBGYXJtLCBNaWx0 b24gS2V5bmVzLCBNSzEgMVBULCBVSw0KUmVnaXN0cmF0aW9uIE5vOiAxMzk3Mzg2IChXYWxlcykN Cg= ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-26 16:13 ` David Laight @ 2020-06-26 16:27 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-26 16:27 UTC (permalink / raw) To: David Laight Cc: Xin Long, Marcelo Ricardo Leitner, minyard, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 26. Jun 2020, at 18:13, David Laight <David.Laight@ACULAB.COM> wrote: > > From: Xin Long >> Sent: 23 June 2020 11:14 >>>> It looks like a bug to me. Testing with this test app here, I can see >>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>> that's unexpected for a v6only socket. As is, it's the server saying >>>> "I'm available at these other addresses too, but not." >>> I agree. >> Then we need a fix in sctp_bind_addrs_to_raw(): >> >> @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const >> struct sctp_bind_addr *bp, >> addrparms = retval; >> >> list_for_each_entry(addr, &bp->address_list, list) { >> + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && >> + (AF_INET == addr->a.sa.sa_family)) >> + continue; >> af = sctp_get_af_specific(addr->a.v4.sin_family); >> len = af->to_addr_param(&addr->a, &rawaddr); >> memcpy(addrparms.v, &rawaddr, len); > > Thought. > > Does it make any sense to offer addresses in the INIT_ACK that don't > have routes to those proposed in the received INIT? > > 'routes' probably isn't exactly the right word. > You probably only want the local address that will be used > as the source address for the probes. > Or, at least, sources addresses that could be used for the probes. > > So if the INIT only contains IPv6 addresses should the INIT_ACK > ever contain IPv4 ones. The client (if it not using an IPv6 socket having IPv6 only enabled) could add an IPv4 address during the lifetime of the association by using the address reconfiguration extension. What could be done is to not send IPv4 addresses if the INIT contains a Supported Address Types parameter indicating IPv6, but not IPv4 support. As a client you might want to send this parameter, when the IPv6 socket has enabled the IPV6_ONLY socket option. Also if the client uses an IPv4 socket, it can indicate in the Supported Address Parameter that it only support IPv4, and the server does not need to list IPv6 addresses. Best regards Michael > > David. > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-26 16:27 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-26 16:27 UTC (permalink / raw) To: David Laight Cc: Xin Long, Marcelo Ricardo Leitner, minyard, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 26. Jun 2020, at 18:13, David Laight <David.Laight@ACULAB.COM> wrote: > > From: Xin Long >> Sent: 23 June 2020 11:14 >>>> It looks like a bug to me. Testing with this test app here, I can see >>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>> that's unexpected for a v6only socket. As is, it's the server saying >>>> "I'm available at these other addresses too, but not." >>> I agree. >> Then we need a fix in sctp_bind_addrs_to_raw(): >> >> @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const >> struct sctp_bind_addr *bp, >> addrparms = retval; >> >> list_for_each_entry(addr, &bp->address_list, list) { >> + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && >> + (AF_INET = addr->a.sa.sa_family)) >> + continue; >> af = sctp_get_af_specific(addr->a.v4.sin_family); >> len = af->to_addr_param(&addr->a, &rawaddr); >> memcpy(addrparms.v, &rawaddr, len); > > Thought. > > Does it make any sense to offer addresses in the INIT_ACK that don't > have routes to those proposed in the received INIT? > > 'routes' probably isn't exactly the right word. > You probably only want the local address that will be used > as the source address for the probes. > Or, at least, sources addresses that could be used for the probes. > > So if the INIT only contains IPv6 addresses should the INIT_ACK > ever contain IPv4 ones. The client (if it not using an IPv6 socket having IPv6 only enabled) could add an IPv4 address during the lifetime of the association by using the address reconfiguration extension. What could be done is to not send IPv4 addresses if the INIT contains a Supported Address Types parameter indicating IPv6, but not IPv4 support. As a client you might want to send this parameter, when the IPv6 socket has enabled the IPV6_ONLY socket option. Also if the client uses an IPv4 socket, it can indicate in the Supported Address Parameter that it only support IPv4, and the server does not need to list IPv6 addresses. Best regards Michael > > David. > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: Strange problem with SCTP+IPv6 2020-06-22 18:32 ` Marcelo Ricardo Leitner (?) (?) @ 2020-06-23 13:17 ` David Laight 2020-06-23 16:04 ` minyard ` (2 more replies) -1 siblings, 3 replies; 55+ messages in thread From: David Laight @ 2020-06-23 13:17 UTC (permalink / raw) To: 'Marcelo Ricardo Leitner', Michael Tuexen Cc: minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML From: Marcelo Ricardo Leitner > Sent: 22 June 2020 19:33 > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > >>> > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > >>> then I make a connection to it using ::1, the connection will drop after > > >>> 2.5 seconds with an ECONNRESET error. > > >>> > > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > >>> I tried on an ARM system and x86_64. > > >>> > > >>> I haven't dug into the kernel to see if I could find anything yet, but I > > >>> thought I would go ahead and report it. I am attaching a reproducer. > > >>> Basically, compile the following code: > > >> The code only set IPV6_V6ONLY on server side, so the client side will > > >> still bind all the local ipv4 addresses (as you didn't call bind() to > > >> bind any specific addresses ). Then after the connection is created, > > >> the client will send HB on the v4 paths to the server. The server > > >> will abort the connection, as it can't support v4. > > >> > > >> So you can work around it by either: > > >> > > >> - set IPV6_V6ONLY on client side. > > >> > > >> or > > >> > > >> - bind to the specific v6 addresses on the client side. > > >> > > >> I don't see RFC said something about this. > > >> So it may not be a good idea to change the current behaviour > > >> to not establish the connection in this case, which may cause regression. > > > > > > Ok, I understand this. It's a little strange, but I see why it works > > > this way. > > I don't. I would expect it to work as I described in my email. > > Could someone explain me how and why it is behaving different from > > my expectation? > > It looks like a bug to me. Testing with this test app here, I can see > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > that's unexpected for a v6only socket. As is, it's the server saying > "I'm available at these other addresses too, but not." Does it even make sense to mix IPv4 and IPv6 addresses on the same connection? I don't remember ever seeing both types of address in a message, but may not have looked. I also wonder whether the connection should be dropped for an error response on a path that has never been validated. OTOH the whole 'multi-homing' part of SCTP sucks. The IP addresses a server needs to bind to depend on where the incoming connection will come from. A local connection may be able to use a 192.168.x.x address but a remote connection must not - as it may be defined locally at the remote system. But both connections can come into the public (routable) address. We have to tell customers to explicitly configure the local IP addresses - which means the application has to know what they are. Fortunately these apps are pretty static - usually M3UA. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-23 13:17 ` David Laight @ 2020-06-23 16:04 ` minyard 2020-06-23 16:17 ` Corey Minyard 2020-06-23 17:09 ` Michael Tuexen 2 siblings, 0 replies; 55+ messages in thread From: minyard @ 2020-06-23 16:04 UTC (permalink / raw) To: Xin Long, Michael Tuexen Cc: Marcelo Ricardo Leitner, Yasevich, Neil Horman, linux-sctp, linux-kernel, Corey Minyard From: Corey Minyard <cminyard@mvista.com> If a socket was set ipv6only, it would still send IPv4 addresses in the init and init ack packets. So don't add IPv4 addresses to ipv6only sockets. Based on a patch by Xin Long <lucien.xin@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> --- I have tested this and it seem to fix the issue. However, I'm wondering if it might be better to fix it where the addresses are put into the association as opposed to where they are put into the message. include/net/sctp/structs.h | 3 ++- net/sctp/bind_addr.c | 7 ++++++- net/sctp/sm_make_chunk.c | 5 +++-- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h index fb42c90348d3..1e839bf4eaa7 100644 --- a/include/net/sctp/structs.h +++ b/include/net/sctp/structs.h @@ -1190,7 +1190,8 @@ union sctp_addr *sctp_find_unmatch_addr(struct sctp_bind_addr *bp, const union sctp_addr *addrs, int addrcnt, struct sctp_sock *opt); -union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, +union sctp_params sctp_bind_addrs_to_raw(const struct sctp_association *asoc, + const struct sctp_bind_addr *bp, int *addrs_len, gfp_t gfp); int sctp_raw_to_bind_addrs(struct sctp_bind_addr *bp, __u8 *raw, int len, diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c index 53bc61537f44..3f5b448f2127 100644 --- a/net/sctp/bind_addr.c +++ b/net/sctp/bind_addr.c @@ -202,7 +202,8 @@ int sctp_del_bind_addr(struct sctp_bind_addr *bp, union sctp_addr *del_addr) * * The second argument is the return value for the length. */ -union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, +union sctp_params sctp_bind_addrs_to_raw(const struct sctp_association *asoc, + const struct sctp_bind_addr *bp, int *addrs_len, gfp_t gfp) { @@ -214,6 +215,7 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, struct sctp_sockaddr_entry *addr; struct list_head *pos; struct sctp_af *af; + struct sock *sk = asoc->base.sk; addrparms_len = 0; len = 0; @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, addrparms = retval; list_for_each_entry(addr, &bp->address_list, list) { + if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) && + (AF_INET == addr->a.sa.sa_family)) + continue; af = sctp_get_af_specific(addr->a.v4.sin_family); len = af->to_addr_param(&addr->a, &rawaddr); memcpy(addrparms.v, &rawaddr, len); diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 47910470e532..6e1a6af40779 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -230,7 +230,7 @@ struct sctp_chunk *sctp_make_init(const struct sctp_association *asoc, */ /* Convert the provided bind address list to raw format. */ - addrs = sctp_bind_addrs_to_raw(bp, &addrs_len, gfp); + addrs = sctp_bind_addrs_to_raw(asoc, bp, &addrs_len, gfp); init.init_tag = htonl(asoc->c.my_vtag); init.a_rwnd = htonl(asoc->rwnd); @@ -397,7 +397,8 @@ struct sctp_chunk *sctp_make_init_ack(const struct sctp_association *asoc, int addrs_len; /* Note: there may be no addresses to embed. */ - addrs = sctp_bind_addrs_to_raw(&asoc->base.bind_addr, &addrs_len, gfp); + addrs = sctp_bind_addrs_to_raw(asoc, &asoc->base.bind_addr, + &addrs_len, gfp); initack.init_tag = htonl(asoc->c.my_vtag); initack.a_rwnd = htonl(asoc->rwnd); -- 2.17.1 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket @ 2020-06-23 16:04 ` minyard 0 siblings, 0 replies; 55+ messages in thread From: minyard @ 2020-06-23 16:04 UTC (permalink / raw) To: Xin Long, Michael Tuexen Cc: Marcelo Ricardo Leitner, Yasevich, Neil Horman, linux-sctp, linux-kernel, Corey Minyard From: Corey Minyard <cminyard@mvista.com> If a socket was set ipv6only, it would still send IPv4 addresses in the init and init ack packets. So don't add IPv4 addresses to ipv6only sockets. Based on a patch by Xin Long <lucien.xin@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> --- I have tested this and it seem to fix the issue. However, I'm wondering if it might be better to fix it where the addresses are put into the association as opposed to where they are put into the message. include/net/sctp/structs.h | 3 ++- net/sctp/bind_addr.c | 7 ++++++- net/sctp/sm_make_chunk.c | 5 +++-- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h index fb42c90348d3..1e839bf4eaa7 100644 --- a/include/net/sctp/structs.h +++ b/include/net/sctp/structs.h @@ -1190,7 +1190,8 @@ union sctp_addr *sctp_find_unmatch_addr(struct sctp_bind_addr *bp, const union sctp_addr *addrs, int addrcnt, struct sctp_sock *opt); -union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, +union sctp_params sctp_bind_addrs_to_raw(const struct sctp_association *asoc, + const struct sctp_bind_addr *bp, int *addrs_len, gfp_t gfp); int sctp_raw_to_bind_addrs(struct sctp_bind_addr *bp, __u8 *raw, int len, diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c index 53bc61537f44..3f5b448f2127 100644 --- a/net/sctp/bind_addr.c +++ b/net/sctp/bind_addr.c @@ -202,7 +202,8 @@ int sctp_del_bind_addr(struct sctp_bind_addr *bp, union sctp_addr *del_addr) * * The second argument is the return value for the length. */ -union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, +union sctp_params sctp_bind_addrs_to_raw(const struct sctp_association *asoc, + const struct sctp_bind_addr *bp, int *addrs_len, gfp_t gfp) { @@ -214,6 +215,7 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, struct sctp_sockaddr_entry *addr; struct list_head *pos; struct sctp_af *af; + struct sock *sk = asoc->base.sk; addrparms_len = 0; len = 0; @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp, addrparms = retval; list_for_each_entry(addr, &bp->address_list, list) { + if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) && + (AF_INET = addr->a.sa.sa_family)) + continue; af = sctp_get_af_specific(addr->a.v4.sin_family); len = af->to_addr_param(&addr->a, &rawaddr); memcpy(addrparms.v, &rawaddr, len); diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 47910470e532..6e1a6af40779 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -230,7 +230,7 @@ struct sctp_chunk *sctp_make_init(const struct sctp_association *asoc, */ /* Convert the provided bind address list to raw format. */ - addrs = sctp_bind_addrs_to_raw(bp, &addrs_len, gfp); + addrs = sctp_bind_addrs_to_raw(asoc, bp, &addrs_len, gfp); init.init_tag = htonl(asoc->c.my_vtag); init.a_rwnd = htonl(asoc->rwnd); @@ -397,7 +397,8 @@ struct sctp_chunk *sctp_make_init_ack(const struct sctp_association *asoc, int addrs_len; /* Note: there may be no addresses to embed. */ - addrs = sctp_bind_addrs_to_raw(&asoc->base.bind_addr, &addrs_len, gfp); + addrs = sctp_bind_addrs_to_raw(asoc, &asoc->base.bind_addr, + &addrs_len, gfp); initack.init_tag = htonl(asoc->c.my_vtag); initack.a_rwnd = htonl(asoc->rwnd); -- 2.17.1 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-23 16:04 ` minyard @ 2020-06-24 20:31 ` Marcelo Ricardo Leitner -1 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-24 20:31 UTC (permalink / raw) To: minyard Cc: Xin Long, Michael Tuexen, Yasevich, Neil Horman, linux-sctp, linux-kernel, Corey Minyard On Tue, Jun 23, 2020 at 11:04:17AM -0500, minyard@acm.org wrote: > From: Corey Minyard <cminyard@mvista.com> > > If a socket was set ipv6only, it would still send IPv4 addresses in the > init and init ack packets. So don't add IPv4 addresses to ipv6only > sockets. > > Based on a patch by Xin Long <lucien.xin@gmail.com> > > Signed-off-by: Corey Minyard <cminyard@mvista.com> > --- > I have tested this and it seem to fix the issue. However, I'm wondering > if it might be better to fix it where the addresses are put into the > association as opposed to where they are put into the message. Yes, it is. It even highlights why this issue was there in the first place. Sending a patch right after this email. Marcelo ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket @ 2020-06-24 20:31 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-24 20:31 UTC (permalink / raw) To: minyard Cc: Xin Long, Michael Tuexen, Yasevich, Neil Horman, linux-sctp, linux-kernel, Corey Minyard On Tue, Jun 23, 2020 at 11:04:17AM -0500, minyard@acm.org wrote: > From: Corey Minyard <cminyard@mvista.com> > > If a socket was set ipv6only, it would still send IPv4 addresses in the > init and init ack packets. So don't add IPv4 addresses to ipv6only > sockets. > > Based on a patch by Xin Long <lucien.xin@gmail.com> > > Signed-off-by: Corey Minyard <cminyard@mvista.com> > --- > I have tested this and it seem to fix the issue. However, I'm wondering > if it might be better to fix it where the addresses are put into the > association as opposed to where they are put into the message. Yes, it is. It even highlights why this issue was there in the first place. Sending a patch right after this email. Marcelo ^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH net] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-23 16:04 ` minyard @ 2020-06-24 20:34 ` Marcelo Ricardo Leitner -1 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-24 20:34 UTC (permalink / raw) To: netdev Cc: Xin Long, Michael Tuexen, Yasevich, Neil Horman, linux-sctp, linux-kernel, Corey Minyard If a socket is set ipv6only, it will still send IPv4 addresses in the INIT and INIT_ACK packets. This potentially misleads the peer into using them, which then would cause association termination. The fix is to not add IPv4 addresses to ipv6only sockets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> --- include/net/sctp/constants.h | 8 +++++--- net/sctp/associola.c | 5 ++++- net/sctp/bind_addr.c | 1 + net/sctp/protocol.c | 3 ++- 4 files changed, 12 insertions(+), 5 deletions(-) diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h index 15b4d9aec7ff278e67a7183f10c14be237227d6b..122d9e2d8dfde33b787d575fc42d454732550698 100644 --- a/include/net/sctp/constants.h +++ b/include/net/sctp/constants.h @@ -353,11 +353,13 @@ enum { ipv4_is_anycast_6to4(a)) /* Flags used for the bind address copy functions. */ -#define SCTP_ADDR6_ALLOWED 0x00000001 /* IPv6 address is allowed by +#define SCTP_ADDR4_ALLOWED 0x00000001 /* IPv4 address is allowed by local sock family */ -#define SCTP_ADDR4_PEERSUPP 0x00000002 /* IPv4 address is supported by +#define SCTP_ADDR6_ALLOWED 0x00000002 /* IPv6 address is allowed by + local sock family */ +#define SCTP_ADDR4_PEERSUPP 0x00000004 /* IPv4 address is supported by peer */ -#define SCTP_ADDR6_PEERSUPP 0x00000004 /* IPv6 address is supported by +#define SCTP_ADDR6_PEERSUPP 0x00000008 /* IPv6 address is supported by peer */ /* Reasons to retransmit. */ diff --git a/net/sctp/associola.c b/net/sctp/associola.c index 72315137d7e7f20d5182291ef4b01102f030078b..8d735461fa196567ab19c583703aad098ef8e240 100644 --- a/net/sctp/associola.c +++ b/net/sctp/associola.c @@ -1565,12 +1565,15 @@ void sctp_assoc_rwnd_decrease(struct sctp_association *asoc, unsigned int len) int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *asoc, enum sctp_scope scope, gfp_t gfp) { + struct sock *sk = asoc->base.sk; int flags; /* Use scoping rules to determine the subset of addresses from * the endpoint. */ - flags = (PF_INET6 == asoc->base.sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; + flags = (PF_INET6 == sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; + if (!inet_v6_ipv6only(sk)) + flags |= SCTP_ADDR4_ALLOWED; if (asoc->peer.ipv4_address) flags |= SCTP_ADDR4_PEERSUPP; if (asoc->peer.ipv6_address) diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c index 53bc61537f44f4e766c417fcef72234df52ecd04..701c5a4e441d9c248df9472f22db5b78987f9e44 100644 --- a/net/sctp/bind_addr.c +++ b/net/sctp/bind_addr.c @@ -461,6 +461,7 @@ static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest, * well as the remote peer. */ if ((((AF_INET == addr->sa.sa_family) && + (flags & SCTP_ADDR4_ALLOWED) && (flags & SCTP_ADDR4_PEERSUPP))) || (((AF_INET6 == addr->sa.sa_family) && (flags & SCTP_ADDR6_ALLOWED) && diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c index 092d1afdee0d23cd974210839310fbf406dd443f..cde29f3c7fb3c40ee117636fa3b4b7f0a03e4fba 100644 --- a/net/sctp/protocol.c +++ b/net/sctp/protocol.c @@ -148,7 +148,8 @@ int sctp_copy_local_addr_list(struct net *net, struct sctp_bind_addr *bp, * sock as well as the remote peer. */ if (addr->a.sa.sa_family == AF_INET && - !(copy_flags & SCTP_ADDR4_PEERSUPP)) + (!(copy_flags & SCTP_ADDR4_ALLOWED) || + !(copy_flags & SCTP_ADDR4_PEERSUPP))) continue; if (addr->a.sa.sa_family == AF_INET6 && (!(copy_flags & SCTP_ADDR6_ALLOWED) || -- 2.25.4 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH net] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket @ 2020-06-24 20:34 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-24 20:34 UTC (permalink / raw) To: netdev Cc: Xin Long, Michael Tuexen, Yasevich, Neil Horman, linux-sctp, linux-kernel, Corey Minyard If a socket is set ipv6only, it will still send IPv4 addresses in the INIT and INIT_ACK packets. This potentially misleads the peer into using them, which then would cause association termination. The fix is to not add IPv4 addresses to ipv6only sockets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> --- include/net/sctp/constants.h | 8 +++++--- net/sctp/associola.c | 5 ++++- net/sctp/bind_addr.c | 1 + net/sctp/protocol.c | 3 ++- 4 files changed, 12 insertions(+), 5 deletions(-) diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h index 15b4d9aec7ff278e67a7183f10c14be237227d6b..122d9e2d8dfde33b787d575fc42d454732550698 100644 --- a/include/net/sctp/constants.h +++ b/include/net/sctp/constants.h @@ -353,11 +353,13 @@ enum { ipv4_is_anycast_6to4(a)) /* Flags used for the bind address copy functions. */ -#define SCTP_ADDR6_ALLOWED 0x00000001 /* IPv6 address is allowed by +#define SCTP_ADDR4_ALLOWED 0x00000001 /* IPv4 address is allowed by local sock family */ -#define SCTP_ADDR4_PEERSUPP 0x00000002 /* IPv4 address is supported by +#define SCTP_ADDR6_ALLOWED 0x00000002 /* IPv6 address is allowed by + local sock family */ +#define SCTP_ADDR4_PEERSUPP 0x00000004 /* IPv4 address is supported by peer */ -#define SCTP_ADDR6_PEERSUPP 0x00000004 /* IPv6 address is supported by +#define SCTP_ADDR6_PEERSUPP 0x00000008 /* IPv6 address is supported by peer */ /* Reasons to retransmit. */ diff --git a/net/sctp/associola.c b/net/sctp/associola.c index 72315137d7e7f20d5182291ef4b01102f030078b..8d735461fa196567ab19c583703aad098ef8e240 100644 --- a/net/sctp/associola.c +++ b/net/sctp/associola.c @@ -1565,12 +1565,15 @@ void sctp_assoc_rwnd_decrease(struct sctp_association *asoc, unsigned int len) int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *asoc, enum sctp_scope scope, gfp_t gfp) { + struct sock *sk = asoc->base.sk; int flags; /* Use scoping rules to determine the subset of addresses from * the endpoint. */ - flags = (PF_INET6 = asoc->base.sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; + flags = (PF_INET6 = sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; + if (!inet_v6_ipv6only(sk)) + flags |= SCTP_ADDR4_ALLOWED; if (asoc->peer.ipv4_address) flags |= SCTP_ADDR4_PEERSUPP; if (asoc->peer.ipv6_address) diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c index 53bc61537f44f4e766c417fcef72234df52ecd04..701c5a4e441d9c248df9472f22db5b78987f9e44 100644 --- a/net/sctp/bind_addr.c +++ b/net/sctp/bind_addr.c @@ -461,6 +461,7 @@ static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest, * well as the remote peer. */ if ((((AF_INET = addr->sa.sa_family) && + (flags & SCTP_ADDR4_ALLOWED) && (flags & SCTP_ADDR4_PEERSUPP))) || (((AF_INET6 = addr->sa.sa_family) && (flags & SCTP_ADDR6_ALLOWED) && diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c index 092d1afdee0d23cd974210839310fbf406dd443f..cde29f3c7fb3c40ee117636fa3b4b7f0a03e4fba 100644 --- a/net/sctp/protocol.c +++ b/net/sctp/protocol.c @@ -148,7 +148,8 @@ int sctp_copy_local_addr_list(struct net *net, struct sctp_bind_addr *bp, * sock as well as the remote peer. */ if (addr->a.sa.sa_family = AF_INET && - !(copy_flags & SCTP_ADDR4_PEERSUPP)) + (!(copy_flags & SCTP_ADDR4_ALLOWED) || + !(copy_flags & SCTP_ADDR4_PEERSUPP))) continue; if (addr->a.sa.sa_family = AF_INET6 && (!(copy_flags & SCTP_ADDR6_ALLOWED) || -- 2.25.4 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH net] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-24 20:34 ` Marcelo Ricardo Leitner @ 2020-06-24 20:53 ` Corey Minyard -1 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-24 20:53 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: netdev, Xin Long, Michael Tuexen, Yasevich, Neil Horman, linux-sctp, linux-kernel On Wed, Jun 24, 2020 at 05:34:18PM -0300, Marcelo Ricardo Leitner wrote: > If a socket is set ipv6only, it will still send IPv4 addresses in the > INIT and INIT_ACK packets. This potentially misleads the peer into using > them, which then would cause association termination. > > The fix is to not add IPv4 addresses to ipv6only sockets. Fixes the issue for me. Tested-by: Corey Minyard <cminyard@mvista.com> Thanks a bunch. -corey > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Reported-by: Corey Minyard <cminyard@mvista.com> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > --- > include/net/sctp/constants.h | 8 +++++--- > net/sctp/associola.c | 5 ++++- > net/sctp/bind_addr.c | 1 + > net/sctp/protocol.c | 3 ++- > 4 files changed, 12 insertions(+), 5 deletions(-) > > diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h > index 15b4d9aec7ff278e67a7183f10c14be237227d6b..122d9e2d8dfde33b787d575fc42d454732550698 100644 > --- a/include/net/sctp/constants.h > +++ b/include/net/sctp/constants.h > @@ -353,11 +353,13 @@ enum { > ipv4_is_anycast_6to4(a)) > > /* Flags used for the bind address copy functions. */ > -#define SCTP_ADDR6_ALLOWED 0x00000001 /* IPv6 address is allowed by > +#define SCTP_ADDR4_ALLOWED 0x00000001 /* IPv4 address is allowed by > local sock family */ > -#define SCTP_ADDR4_PEERSUPP 0x00000002 /* IPv4 address is supported by > +#define SCTP_ADDR6_ALLOWED 0x00000002 /* IPv6 address is allowed by > + local sock family */ > +#define SCTP_ADDR4_PEERSUPP 0x00000004 /* IPv4 address is supported by > peer */ > -#define SCTP_ADDR6_PEERSUPP 0x00000004 /* IPv6 address is supported by > +#define SCTP_ADDR6_PEERSUPP 0x00000008 /* IPv6 address is supported by > peer */ > > /* Reasons to retransmit. */ > diff --git a/net/sctp/associola.c b/net/sctp/associola.c > index 72315137d7e7f20d5182291ef4b01102f030078b..8d735461fa196567ab19c583703aad098ef8e240 100644 > --- a/net/sctp/associola.c > +++ b/net/sctp/associola.c > @@ -1565,12 +1565,15 @@ void sctp_assoc_rwnd_decrease(struct sctp_association *asoc, unsigned int len) > int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *asoc, > enum sctp_scope scope, gfp_t gfp) > { > + struct sock *sk = asoc->base.sk; > int flags; > > /* Use scoping rules to determine the subset of addresses from > * the endpoint. > */ > - flags = (PF_INET6 == asoc->base.sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; > + flags = (PF_INET6 == sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; > + if (!inet_v6_ipv6only(sk)) > + flags |= SCTP_ADDR4_ALLOWED; > if (asoc->peer.ipv4_address) > flags |= SCTP_ADDR4_PEERSUPP; > if (asoc->peer.ipv6_address) > diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c > index 53bc61537f44f4e766c417fcef72234df52ecd04..701c5a4e441d9c248df9472f22db5b78987f9e44 100644 > --- a/net/sctp/bind_addr.c > +++ b/net/sctp/bind_addr.c > @@ -461,6 +461,7 @@ static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest, > * well as the remote peer. > */ > if ((((AF_INET == addr->sa.sa_family) && > + (flags & SCTP_ADDR4_ALLOWED) && > (flags & SCTP_ADDR4_PEERSUPP))) || > (((AF_INET6 == addr->sa.sa_family) && > (flags & SCTP_ADDR6_ALLOWED) && > diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c > index 092d1afdee0d23cd974210839310fbf406dd443f..cde29f3c7fb3c40ee117636fa3b4b7f0a03e4fba 100644 > --- a/net/sctp/protocol.c > +++ b/net/sctp/protocol.c > @@ -148,7 +148,8 @@ int sctp_copy_local_addr_list(struct net *net, struct sctp_bind_addr *bp, > * sock as well as the remote peer. > */ > if (addr->a.sa.sa_family == AF_INET && > - !(copy_flags & SCTP_ADDR4_PEERSUPP)) > + (!(copy_flags & SCTP_ADDR4_ALLOWED) || > + !(copy_flags & SCTP_ADDR4_PEERSUPP))) > continue; > if (addr->a.sa.sa_family == AF_INET6 && > (!(copy_flags & SCTP_ADDR6_ALLOWED) || > -- > 2.25.4 > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH net] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket @ 2020-06-24 20:53 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-24 20:53 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: netdev, Xin Long, Michael Tuexen, Yasevich, Neil Horman, linux-sctp, linux-kernel On Wed, Jun 24, 2020 at 05:34:18PM -0300, Marcelo Ricardo Leitner wrote: > If a socket is set ipv6only, it will still send IPv4 addresses in the > INIT and INIT_ACK packets. This potentially misleads the peer into using > them, which then would cause association termination. > > The fix is to not add IPv4 addresses to ipv6only sockets. Fixes the issue for me. Tested-by: Corey Minyard <cminyard@mvista.com> Thanks a bunch. -corey > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Reported-by: Corey Minyard <cminyard@mvista.com> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > --- > include/net/sctp/constants.h | 8 +++++--- > net/sctp/associola.c | 5 ++++- > net/sctp/bind_addr.c | 1 + > net/sctp/protocol.c | 3 ++- > 4 files changed, 12 insertions(+), 5 deletions(-) > > diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h > index 15b4d9aec7ff278e67a7183f10c14be237227d6b..122d9e2d8dfde33b787d575fc42d454732550698 100644 > --- a/include/net/sctp/constants.h > +++ b/include/net/sctp/constants.h > @@ -353,11 +353,13 @@ enum { > ipv4_is_anycast_6to4(a)) > > /* Flags used for the bind address copy functions. */ > -#define SCTP_ADDR6_ALLOWED 0x00000001 /* IPv6 address is allowed by > +#define SCTP_ADDR4_ALLOWED 0x00000001 /* IPv4 address is allowed by > local sock family */ > -#define SCTP_ADDR4_PEERSUPP 0x00000002 /* IPv4 address is supported by > +#define SCTP_ADDR6_ALLOWED 0x00000002 /* IPv6 address is allowed by > + local sock family */ > +#define SCTP_ADDR4_PEERSUPP 0x00000004 /* IPv4 address is supported by > peer */ > -#define SCTP_ADDR6_PEERSUPP 0x00000004 /* IPv6 address is supported by > +#define SCTP_ADDR6_PEERSUPP 0x00000008 /* IPv6 address is supported by > peer */ > > /* Reasons to retransmit. */ > diff --git a/net/sctp/associola.c b/net/sctp/associola.c > index 72315137d7e7f20d5182291ef4b01102f030078b..8d735461fa196567ab19c583703aad098ef8e240 100644 > --- a/net/sctp/associola.c > +++ b/net/sctp/associola.c > @@ -1565,12 +1565,15 @@ void sctp_assoc_rwnd_decrease(struct sctp_association *asoc, unsigned int len) > int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *asoc, > enum sctp_scope scope, gfp_t gfp) > { > + struct sock *sk = asoc->base.sk; > int flags; > > /* Use scoping rules to determine the subset of addresses from > * the endpoint. > */ > - flags = (PF_INET6 = asoc->base.sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; > + flags = (PF_INET6 = sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0; > + if (!inet_v6_ipv6only(sk)) > + flags |= SCTP_ADDR4_ALLOWED; > if (asoc->peer.ipv4_address) > flags |= SCTP_ADDR4_PEERSUPP; > if (asoc->peer.ipv6_address) > diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c > index 53bc61537f44f4e766c417fcef72234df52ecd04..701c5a4e441d9c248df9472f22db5b78987f9e44 100644 > --- a/net/sctp/bind_addr.c > +++ b/net/sctp/bind_addr.c > @@ -461,6 +461,7 @@ static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest, > * well as the remote peer. > */ > if ((((AF_INET = addr->sa.sa_family) && > + (flags & SCTP_ADDR4_ALLOWED) && > (flags & SCTP_ADDR4_PEERSUPP))) || > (((AF_INET6 = addr->sa.sa_family) && > (flags & SCTP_ADDR6_ALLOWED) && > diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c > index 092d1afdee0d23cd974210839310fbf406dd443f..cde29f3c7fb3c40ee117636fa3b4b7f0a03e4fba 100644 > --- a/net/sctp/protocol.c > +++ b/net/sctp/protocol.c > @@ -148,7 +148,8 @@ int sctp_copy_local_addr_list(struct net *net, struct sctp_bind_addr *bp, > * sock as well as the remote peer. > */ > if (addr->a.sa.sa_family = AF_INET && > - !(copy_flags & SCTP_ADDR4_PEERSUPP)) > + (!(copy_flags & SCTP_ADDR4_ALLOWED) || > + !(copy_flags & SCTP_ADDR4_PEERSUPP))) > continue; > if (addr->a.sa.sa_family = AF_INET6 && > (!(copy_flags & SCTP_ADDR6_ALLOWED) || > -- > 2.25.4 > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH net] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket 2020-06-24 20:34 ` Marcelo Ricardo Leitner @ 2020-06-25 23:12 ` David Miller -1 siblings, 0 replies; 55+ messages in thread From: David Miller @ 2020-06-25 23:12 UTC (permalink / raw) To: marcelo.leitner Cc: netdev, lucien.xin, Michael.Tuexen, vyasevich, nhorman, linux-sctp, linux-kernel, cminyard From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Date: Wed, 24 Jun 2020 17:34:18 -0300 > If a socket is set ipv6only, it will still send IPv4 addresses in the > INIT and INIT_ACK packets. This potentially misleads the peer into using > them, which then would cause association termination. > > The fix is to not add IPv4 addresses to ipv6only sockets. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Reported-by: Corey Minyard <cminyard@mvista.com> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Applied and queued up for -stable, thank you. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH net] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket @ 2020-06-25 23:12 ` David Miller 0 siblings, 0 replies; 55+ messages in thread From: David Miller @ 2020-06-25 23:12 UTC (permalink / raw) To: marcelo.leitner Cc: netdev, lucien.xin, Michael.Tuexen, vyasevich, nhorman, linux-sctp, linux-kernel, cminyard From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Date: Wed, 24 Jun 2020 17:34:18 -0300 > If a socket is set ipv6only, it will still send IPv4 addresses in the > INIT and INIT_ACK packets. This potentially misleads the peer into using > them, which then would cause association termination. > > The fix is to not add IPv4 addresses to ipv6only sockets. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Reported-by: Corey Minyard <cminyard@mvista.com> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Applied and queued up for -stable, thank you. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 13:17 ` David Laight @ 2020-06-23 16:17 ` Corey Minyard 2020-06-23 16:17 ` Corey Minyard 2020-06-23 17:09 ` Michael Tuexen 2 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-23 16:17 UTC (permalink / raw) To: David Laight Cc: 'Marcelo Ricardo Leitner', Michael Tuexen, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > From: Marcelo Ricardo Leitner > > Sent: 22 June 2020 19:33 > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > >>> > > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > >>> then I make a connection to it using ::1, the connection will drop after > > > >>> 2.5 seconds with an ECONNRESET error. > > > >>> > > > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > >>> I tried on an ARM system and x86_64. > > > >>> > > > >>> I haven't dug into the kernel to see if I could find anything yet, but I > > > >>> thought I would go ahead and report it. I am attaching a reproducer. > > > >>> Basically, compile the following code: > > > >> The code only set IPV6_V6ONLY on server side, so the client side will > > > >> still bind all the local ipv4 addresses (as you didn't call bind() to > > > >> bind any specific addresses ). Then after the connection is created, > > > >> the client will send HB on the v4 paths to the server. The server > > > >> will abort the connection, as it can't support v4. > > > >> > > > >> So you can work around it by either: > > > >> > > > >> - set IPV6_V6ONLY on client side. > > > >> > > > >> or > > > >> > > > >> - bind to the specific v6 addresses on the client side. > > > >> > > > >> I don't see RFC said something about this. > > > >> So it may not be a good idea to change the current behaviour > > > >> to not establish the connection in this case, which may cause regression. > > > > > > > > Ok, I understand this. It's a little strange, but I see why it works > > > > this way. > > > I don't. I would expect it to work as I described in my email. > > > Could someone explain me how and why it is behaving different from > > > my expectation? > > > > It looks like a bug to me. Testing with this test app here, I can see > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > that's unexpected for a v6only socket. As is, it's the server saying > > "I'm available at these other addresses too, but not." > > Does it even make sense to mix IPv4 and IPv6 addresses on the same > connection? > I don't remember ever seeing both types of address in a message, > but may not have looked. That's an interesting question. Do the RFCs say anything? I would assume it was ok unless ipv6only was set. > > I also wonder whether the connection should be dropped for an error > response on a path that has never been validated. That actually bothered me a bit more. Shouldn't it stay up if any path is up? That's kind of the whole point of multihoming. > > OTOH the whole 'multi-homing' part of SCTP sucks. I don't think so. > The IP addresses a server needs to bind to depend on where the > incoming connection will come from. > A local connection may be able to use a 192.168.x.x address > but a remote connection must not - as it may be defined locally > at the remote system. > But both connections can come into the public (routable) address. > We have to tell customers to explicitly configure the local IP > addresses - which means the application has to know what they are. > Fortunately these apps are pretty static - usually M3UA. Umm, no, If you have a private address, it better be behind a firewall, and the firewall should handle rewriting the packet to fix the addresses. It doesn't appear that Linux netfilter does this. There is a TODO in the code for this. But that's how it *should* work. -corey > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 16:17 ` Corey Minyard 0 siblings, 0 replies; 55+ messages in thread From: Corey Minyard @ 2020-06-23 16:17 UTC (permalink / raw) To: David Laight Cc: 'Marcelo Ricardo Leitner', Michael Tuexen, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > From: Marcelo Ricardo Leitner > > Sent: 22 June 2020 19:33 > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > >>> > > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > >>> then I make a connection to it using ::1, the connection will drop after > > > >>> 2.5 seconds with an ECONNRESET error. > > > >>> > > > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > >>> I tried on an ARM system and x86_64. > > > >>> > > > >>> I haven't dug into the kernel to see if I could find anything yet, but I > > > >>> thought I would go ahead and report it. I am attaching a reproducer. > > > >>> Basically, compile the following code: > > > >> The code only set IPV6_V6ONLY on server side, so the client side will > > > >> still bind all the local ipv4 addresses (as you didn't call bind() to > > > >> bind any specific addresses ). Then after the connection is created, > > > >> the client will send HB on the v4 paths to the server. The server > > > >> will abort the connection, as it can't support v4. > > > >> > > > >> So you can work around it by either: > > > >> > > > >> - set IPV6_V6ONLY on client side. > > > >> > > > >> or > > > >> > > > >> - bind to the specific v6 addresses on the client side. > > > >> > > > >> I don't see RFC said something about this. > > > >> So it may not be a good idea to change the current behaviour > > > >> to not establish the connection in this case, which may cause regression. > > > > > > > > Ok, I understand this. It's a little strange, but I see why it works > > > > this way. > > > I don't. I would expect it to work as I described in my email. > > > Could someone explain me how and why it is behaving different from > > > my expectation? > > > > It looks like a bug to me. Testing with this test app here, I can see > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > that's unexpected for a v6only socket. As is, it's the server saying > > "I'm available at these other addresses too, but not." > > Does it even make sense to mix IPv4 and IPv6 addresses on the same > connection? > I don't remember ever seeing both types of address in a message, > but may not have looked. That's an interesting question. Do the RFCs say anything? I would assume it was ok unless ipv6only was set. > > I also wonder whether the connection should be dropped for an error > response on a path that has never been validated. That actually bothered me a bit more. Shouldn't it stay up if any path is up? That's kind of the whole point of multihoming. > > OTOH the whole 'multi-homing' part of SCTP sucks. I don't think so. > The IP addresses a server needs to bind to depend on where the > incoming connection will come from. > A local connection may be able to use a 192.168.x.x address > but a remote connection must not - as it may be defined locally > at the remote system. > But both connections can come into the public (routable) address. > We have to tell customers to explicitly configure the local IP > addresses - which means the application has to know what they are. > Fortunately these apps are pretty static - usually M3UA. Umm, no, If you have a private address, it better be behind a firewall, and the firewall should handle rewriting the packet to fix the addresses. It doesn't appear that Linux netfilter does this. There is a TODO in the code for this. But that's how it *should* work. -corey > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 16:17 ` Corey Minyard @ 2020-06-23 21:21 ` 'Marcelo Ricardo Leitner' -1 siblings, 0 replies; 55+ messages in thread From: 'Marcelo Ricardo Leitner' @ 2020-06-23 21:21 UTC (permalink / raw) To: Corey Minyard Cc: David Laight, Michael Tuexen, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: > On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > > From: Marcelo Ricardo Leitner > > > Sent: 22 June 2020 19:33 > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > >>> > > > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > > >>> then I make a connection to it using ::1, the connection will drop after > > > > >>> 2.5 seconds with an ECONNRESET error. > > > > >>> > > > > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > > >>> I tried on an ARM system and x86_64. > > > > >>> > > > > >>> I haven't dug into the kernel to see if I could find anything yet, but I > > > > >>> thought I would go ahead and report it. I am attaching a reproducer. > > > > >>> Basically, compile the following code: > > > > >> The code only set IPV6_V6ONLY on server side, so the client side will > > > > >> still bind all the local ipv4 addresses (as you didn't call bind() to > > > > >> bind any specific addresses ). Then after the connection is created, > > > > >> the client will send HB on the v4 paths to the server. The server > > > > >> will abort the connection, as it can't support v4. > > > > >> > > > > >> So you can work around it by either: > > > > >> > > > > >> - set IPV6_V6ONLY on client side. > > > > >> > > > > >> or > > > > >> > > > > >> - bind to the specific v6 addresses on the client side. > > > > >> > > > > >> I don't see RFC said something about this. > > > > >> So it may not be a good idea to change the current behaviour > > > > >> to not establish the connection in this case, which may cause regression. > > > > > > > > > > Ok, I understand this. It's a little strange, but I see why it works > > > > > this way. > > > > I don't. I would expect it to work as I described in my email. > > > > Could someone explain me how and why it is behaving different from > > > > my expectation? > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > that's unexpected for a v6only socket. As is, it's the server saying > > > "I'm available at these other addresses too, but not." > > > > Does it even make sense to mix IPv4 and IPv6 addresses on the same > > connection? > > I don't remember ever seeing both types of address in a message, > > but may not have looked. > > That's an interesting question. Do the RFCs say anything? I would > assume it was ok unless ipv6only was set. > > > > > I also wonder whether the connection should be dropped for an error > > response on a path that has never been validated. > > That actually bothered me a bit more. Shouldn't it stay up if any path > is up? That's kind of the whole point of multihoming. Michael explained it on the other email. What he described is what I observed in my tests. > > > > > OTOH the whole 'multi-homing' part of SCTP sucks. > > I don't think so. > > > The IP addresses a server needs to bind to depend on where the > > incoming connection will come from. > > A local connection may be able to use a 192.168.x.x address > > but a remote connection must not - as it may be defined locally > > at the remote system. > > But both connections can come into the public (routable) address. > > We have to tell customers to explicitly configure the local IP > > addresses - which means the application has to know what they are. > > Fortunately these apps are pretty static - usually M3UA. > > Umm, no, If you have a private address, it better be behind a firewall, > and the firewall should handle rewriting the packet to fix the addresses. > > It doesn't appear that Linux netfilter does this. There is a TODO in > the code for this. But that's how it *should* work. Right, we don't support SCTP aware NAT [1]. 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 Marcelo > > -corey > > > > > David > > > > - > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > > Registration No: 1397386 (Wales) > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 21:21 ` 'Marcelo Ricardo Leitner' 0 siblings, 0 replies; 55+ messages in thread From: 'Marcelo Ricardo Leitner' @ 2020-06-23 21:21 UTC (permalink / raw) To: Corey Minyard Cc: David Laight, Michael Tuexen, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: > On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > > From: Marcelo Ricardo Leitner > > > Sent: 22 June 2020 19:33 > > > On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > > > > On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > > > > >>> > > > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > > > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > > > > >>> then I make a connection to it using ::1, the connection will drop after > > > > >>> 2.5 seconds with an ECONNRESET error. > > > > >>> > > > > >>> It only happens on SCTP, it doesn't have the issue if you connect to a > > > > >>> full IPv6 address instead of ::1, and it doesn't happen if you don't > > > > >>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > > > > >>> I tried on an ARM system and x86_64. > > > > >>> > > > > >>> I haven't dug into the kernel to see if I could find anything yet, but I > > > > >>> thought I would go ahead and report it. I am attaching a reproducer. > > > > >>> Basically, compile the following code: > > > > >> The code only set IPV6_V6ONLY on server side, so the client side will > > > > >> still bind all the local ipv4 addresses (as you didn't call bind() to > > > > >> bind any specific addresses ). Then after the connection is created, > > > > >> the client will send HB on the v4 paths to the server. The server > > > > >> will abort the connection, as it can't support v4. > > > > >> > > > > >> So you can work around it by either: > > > > >> > > > > >> - set IPV6_V6ONLY on client side. > > > > >> > > > > >> or > > > > >> > > > > >> - bind to the specific v6 addresses on the client side. > > > > >> > > > > >> I don't see RFC said something about this. > > > > >> So it may not be a good idea to change the current behaviour > > > > >> to not establish the connection in this case, which may cause regression. > > > > > > > > > > Ok, I understand this. It's a little strange, but I see why it works > > > > > this way. > > > > I don't. I would expect it to work as I described in my email. > > > > Could someone explain me how and why it is behaving different from > > > > my expectation? > > > > > > It looks like a bug to me. Testing with this test app here, I can see > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > that's unexpected for a v6only socket. As is, it's the server saying > > > "I'm available at these other addresses too, but not." > > > > Does it even make sense to mix IPv4 and IPv6 addresses on the same > > connection? > > I don't remember ever seeing both types of address in a message, > > but may not have looked. > > That's an interesting question. Do the RFCs say anything? I would > assume it was ok unless ipv6only was set. > > > > > I also wonder whether the connection should be dropped for an error > > response on a path that has never been validated. > > That actually bothered me a bit more. Shouldn't it stay up if any path > is up? That's kind of the whole point of multihoming. Michael explained it on the other email. What he described is what I observed in my tests. > > > > > OTOH the whole 'multi-homing' part of SCTP sucks. > > I don't think so. > > > The IP addresses a server needs to bind to depend on where the > > incoming connection will come from. > > A local connection may be able to use a 192.168.x.x address > > but a remote connection must not - as it may be defined locally > > at the remote system. > > But both connections can come into the public (routable) address. > > We have to tell customers to explicitly configure the local IP > > addresses - which means the application has to know what they are. > > Fortunately these apps are pretty static - usually M3UA. > > Umm, no, If you have a private address, it better be behind a firewall, > and the firewall should handle rewriting the packet to fix the addresses. > > It doesn't appear that Linux netfilter does this. There is a TODO in > the code for this. But that's how it *should* work. Right, we don't support SCTP aware NAT [1]. 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 Marcelo > > -corey > > > > > David > > > > - > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > > Registration No: 1397386 (Wales) > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 21:21 ` 'Marcelo Ricardo Leitner' @ 2020-06-23 21:24 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-23 21:24 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: Corey Minyard, David Laight, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: >> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: >>> From: Marcelo Ricardo Leitner >>>> Sent: 22 June 2020 19:33 >>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>>>> >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>>>> >>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>>>> 2.5 seconds with an ECONNRESET error. >>>>>>>> >>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>>>> I tried on an ARM system and x86_64. >>>>>>>> >>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>>>> Basically, compile the following code: >>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>>>> bind any specific addresses ). Then after the connection is created, >>>>>>> the client will send HB on the v4 paths to the server. The server >>>>>>> will abort the connection, as it can't support v4. >>>>>>> >>>>>>> So you can work around it by either: >>>>>>> >>>>>>> - set IPV6_V6ONLY on client side. >>>>>>> >>>>>>> or >>>>>>> >>>>>>> - bind to the specific v6 addresses on the client side. >>>>>>> >>>>>>> I don't see RFC said something about this. >>>>>>> So it may not be a good idea to change the current behaviour >>>>>>> to not establish the connection in this case, which may cause regression. >>>>>> >>>>>> Ok, I understand this. It's a little strange, but I see why it works >>>>>> this way. >>>>> I don't. I would expect it to work as I described in my email. >>>>> Could someone explain me how and why it is behaving different from >>>>> my expectation? >>>> >>>> It looks like a bug to me. Testing with this test app here, I can see >>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>> that's unexpected for a v6only socket. As is, it's the server saying >>>> "I'm available at these other addresses too, but not." >>> >>> Does it even make sense to mix IPv4 and IPv6 addresses on the same >>> connection? >>> I don't remember ever seeing both types of address in a message, >>> but may not have looked. >> >> That's an interesting question. Do the RFCs say anything? I would >> assume it was ok unless ipv6only was set. >> >>> >>> I also wonder whether the connection should be dropped for an error >>> response on a path that has never been validated. >> >> That actually bothered me a bit more. Shouldn't it stay up if any path >> is up? That's kind of the whole point of multihoming. > > Michael explained it on the other email. What he described is what I > observed in my tests. > >> >>> >>> OTOH the whole 'multi-homing' part of SCTP sucks. >> >> I don't think so. >> >>> The IP addresses a server needs to bind to depend on where the >>> incoming connection will come from. >>> A local connection may be able to use a 192.168.x.x address >>> but a remote connection must not - as it may be defined locally >>> at the remote system. >>> But both connections can come into the public (routable) address. >>> We have to tell customers to explicitly configure the local IP >>> addresses - which means the application has to know what they are. >>> Fortunately these apps are pretty static - usually M3UA. >> >> Umm, no, If you have a private address, it better be behind a firewall, >> and the firewall should handle rewriting the packet to fix the addresses. >> >> It doesn't appear that Linux netfilter does this. There is a TODO in >> the code for this. But that's how it *should* work. > > Right, we don't support SCTP aware NAT [1]. > > 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 Another possibility for NAT traversal is UDP encapsulation... Best regards Michael > > Marcelo > >> >> -corey >> >>> >>> David >>> >>> - >>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>> Registration No: 1397386 (Wales) >>> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 21:24 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-23 21:24 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: Corey Minyard, David Laight, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: >> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: >>> From: Marcelo Ricardo Leitner >>>> Sent: 22 June 2020 19:33 >>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>>>> >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>>>> >>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>>>> 2.5 seconds with an ECONNRESET error. >>>>>>>> >>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>>>> I tried on an ARM system and x86_64. >>>>>>>> >>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>>>> Basically, compile the following code: >>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>>>> bind any specific addresses ). Then after the connection is created, >>>>>>> the client will send HB on the v4 paths to the server. The server >>>>>>> will abort the connection, as it can't support v4. >>>>>>> >>>>>>> So you can work around it by either: >>>>>>> >>>>>>> - set IPV6_V6ONLY on client side. >>>>>>> >>>>>>> or >>>>>>> >>>>>>> - bind to the specific v6 addresses on the client side. >>>>>>> >>>>>>> I don't see RFC said something about this. >>>>>>> So it may not be a good idea to change the current behaviour >>>>>>> to not establish the connection in this case, which may cause regression. >>>>>> >>>>>> Ok, I understand this. It's a little strange, but I see why it works >>>>>> this way. >>>>> I don't. I would expect it to work as I described in my email. >>>>> Could someone explain me how and why it is behaving different from >>>>> my expectation? >>>> >>>> It looks like a bug to me. Testing with this test app here, I can see >>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>> that's unexpected for a v6only socket. As is, it's the server saying >>>> "I'm available at these other addresses too, but not." >>> >>> Does it even make sense to mix IPv4 and IPv6 addresses on the same >>> connection? >>> I don't remember ever seeing both types of address in a message, >>> but may not have looked. >> >> That's an interesting question. Do the RFCs say anything? I would >> assume it was ok unless ipv6only was set. >> >>> >>> I also wonder whether the connection should be dropped for an error >>> response on a path that has never been validated. >> >> That actually bothered me a bit more. Shouldn't it stay up if any path >> is up? That's kind of the whole point of multihoming. > > Michael explained it on the other email. What he described is what I > observed in my tests. > >> >>> >>> OTOH the whole 'multi-homing' part of SCTP sucks. >> >> I don't think so. >> >>> The IP addresses a server needs to bind to depend on where the >>> incoming connection will come from. >>> A local connection may be able to use a 192.168.x.x address >>> but a remote connection must not - as it may be defined locally >>> at the remote system. >>> But both connections can come into the public (routable) address. >>> We have to tell customers to explicitly configure the local IP >>> addresses - which means the application has to know what they are. >>> Fortunately these apps are pretty static - usually M3UA. >> >> Umm, no, If you have a private address, it better be behind a firewall, >> and the firewall should handle rewriting the packet to fix the addresses. >> >> It doesn't appear that Linux netfilter does this. There is a TODO in >> the code for this. But that's how it *should* work. > > Right, we don't support SCTP aware NAT [1]. > > 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 Another possibility for NAT traversal is UDP encapsulation... Best regards Michael > > Marcelo > >> >> -corey >> >>> >>> David >>> >>> - >>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>> Registration No: 1397386 (Wales) >>> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 21:24 ` Michael Tuexen @ 2020-06-23 21:31 ` Marcelo Ricardo Leitner -1 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-23 21:31 UTC (permalink / raw) To: Michael Tuexen Cc: Corey Minyard, David Laight, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: > > On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: > >> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > >>> From: Marcelo Ricardo Leitner > >>>> Sent: 22 June 2020 19:33 > >>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > >>>>>> > >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>>>>>>> > >>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>>>>>>> then I make a connection to it using ::1, the connection will drop after > >>>>>>>> 2.5 seconds with an ECONNRESET error. > >>>>>>>> > >>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>>>>>>> I tried on an ARM system and x86_64. > >>>>>>>> > >>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I > >>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. > >>>>>>>> Basically, compile the following code: > >>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will > >>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to > >>>>>>> bind any specific addresses ). Then after the connection is created, > >>>>>>> the client will send HB on the v4 paths to the server. The server > >>>>>>> will abort the connection, as it can't support v4. > >>>>>>> > >>>>>>> So you can work around it by either: > >>>>>>> > >>>>>>> - set IPV6_V6ONLY on client side. > >>>>>>> > >>>>>>> or > >>>>>>> > >>>>>>> - bind to the specific v6 addresses on the client side. > >>>>>>> > >>>>>>> I don't see RFC said something about this. > >>>>>>> So it may not be a good idea to change the current behaviour > >>>>>>> to not establish the connection in this case, which may cause regression. > >>>>>> > >>>>>> Ok, I understand this. It's a little strange, but I see why it works > >>>>>> this way. > >>>>> I don't. I would expect it to work as I described in my email. > >>>>> Could someone explain me how and why it is behaving different from > >>>>> my expectation? > >>>> > >>>> It looks like a bug to me. Testing with this test app here, I can see > >>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and > >>>> that's unexpected for a v6only socket. As is, it's the server saying > >>>> "I'm available at these other addresses too, but not." > >>> > >>> Does it even make sense to mix IPv4 and IPv6 addresses on the same > >>> connection? > >>> I don't remember ever seeing both types of address in a message, > >>> but may not have looked. > >> > >> That's an interesting question. Do the RFCs say anything? I would > >> assume it was ok unless ipv6only was set. > >> > >>> > >>> I also wonder whether the connection should be dropped for an error > >>> response on a path that has never been validated. > >> > >> That actually bothered me a bit more. Shouldn't it stay up if any path > >> is up? That's kind of the whole point of multihoming. > > > > Michael explained it on the other email. What he described is what I > > observed in my tests. > > > >> > >>> > >>> OTOH the whole 'multi-homing' part of SCTP sucks. > >> > >> I don't think so. > >> > >>> The IP addresses a server needs to bind to depend on where the > >>> incoming connection will come from. > >>> A local connection may be able to use a 192.168.x.x address > >>> but a remote connection must not - as it may be defined locally > >>> at the remote system. > >>> But both connections can come into the public (routable) address. > >>> We have to tell customers to explicitly configure the local IP > >>> addresses - which means the application has to know what they are. > >>> Fortunately these apps are pretty static - usually M3UA. > >> > >> Umm, no, If you have a private address, it better be behind a firewall, > >> and the firewall should handle rewriting the packet to fix the addresses. > >> > >> It doesn't appear that Linux netfilter does this. There is a TODO in > >> the code for this. But that's how it *should* work. > > > > Right, we don't support SCTP aware NAT [1]. > > > > 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 > The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 Thanks! > > Another possibility for NAT traversal is UDP encapsulation... Also not supported.. :-] Best regards, Marcelo > > Best regards > Michael > > > > Marcelo > > > >> > >> -corey > >> > >>> > >>> David > >>> > >>> - > >>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > >>> Registration No: 1397386 (Wales) > >>> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 21:31 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 55+ messages in thread From: Marcelo Ricardo Leitner @ 2020-06-23 21:31 UTC (permalink / raw) To: Michael Tuexen Cc: Corey Minyard, David Laight, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: > > On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: > >> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > >>> From: Marcelo Ricardo Leitner > >>>> Sent: 22 June 2020 19:33 > >>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > >>>>>> > >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>>>>>>> > >>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>>>>>>> then I make a connection to it using ::1, the connection will drop after > >>>>>>>> 2.5 seconds with an ECONNRESET error. > >>>>>>>> > >>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>>>>>>> I tried on an ARM system and x86_64. > >>>>>>>> > >>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I > >>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. > >>>>>>>> Basically, compile the following code: > >>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will > >>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to > >>>>>>> bind any specific addresses ). Then after the connection is created, > >>>>>>> the client will send HB on the v4 paths to the server. The server > >>>>>>> will abort the connection, as it can't support v4. > >>>>>>> > >>>>>>> So you can work around it by either: > >>>>>>> > >>>>>>> - set IPV6_V6ONLY on client side. > >>>>>>> > >>>>>>> or > >>>>>>> > >>>>>>> - bind to the specific v6 addresses on the client side. > >>>>>>> > >>>>>>> I don't see RFC said something about this. > >>>>>>> So it may not be a good idea to change the current behaviour > >>>>>>> to not establish the connection in this case, which may cause regression. > >>>>>> > >>>>>> Ok, I understand this. It's a little strange, but I see why it works > >>>>>> this way. > >>>>> I don't. I would expect it to work as I described in my email. > >>>>> Could someone explain me how and why it is behaving different from > >>>>> my expectation? > >>>> > >>>> It looks like a bug to me. Testing with this test app here, I can see > >>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and > >>>> that's unexpected for a v6only socket. As is, it's the server saying > >>>> "I'm available at these other addresses too, but not." > >>> > >>> Does it even make sense to mix IPv4 and IPv6 addresses on the same > >>> connection? > >>> I don't remember ever seeing both types of address in a message, > >>> but may not have looked. > >> > >> That's an interesting question. Do the RFCs say anything? I would > >> assume it was ok unless ipv6only was set. > >> > >>> > >>> I also wonder whether the connection should be dropped for an error > >>> response on a path that has never been validated. > >> > >> That actually bothered me a bit more. Shouldn't it stay up if any path > >> is up? That's kind of the whole point of multihoming. > > > > Michael explained it on the other email. What he described is what I > > observed in my tests. > > > >> > >>> > >>> OTOH the whole 'multi-homing' part of SCTP sucks. > >> > >> I don't think so. > >> > >>> The IP addresses a server needs to bind to depend on where the > >>> incoming connection will come from. > >>> A local connection may be able to use a 192.168.x.x address > >>> but a remote connection must not - as it may be defined locally > >>> at the remote system. > >>> But both connections can come into the public (routable) address. > >>> We have to tell customers to explicitly configure the local IP > >>> addresses - which means the application has to know what they are. > >>> Fortunately these apps are pretty static - usually M3UA. > >> > >> Umm, no, If you have a private address, it better be behind a firewall, > >> and the firewall should handle rewriting the packet to fix the addresses. > >> > >> It doesn't appear that Linux netfilter does this. There is a TODO in > >> the code for this. But that's how it *should* work. > > > > Right, we don't support SCTP aware NAT [1]. > > > > 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 > The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 Thanks! > > Another possibility for NAT traversal is UDP encapsulation... Also not supported.. :-] Best regards, Marcelo > > Best regards > Michael > > > > Marcelo > > > >> > >> -corey > >> > >>> > >>> David > >>> > >>> - > >>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > >>> Registration No: 1397386 (Wales) > >>> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 21:31 ` Marcelo Ricardo Leitner @ 2020-06-23 21:48 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-23 21:48 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: Corey Minyard, David Laight, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: >>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: >>> >>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: >>>> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: >>>>> From: Marcelo Ricardo Leitner >>>>>> Sent: 22 June 2020 19:33 >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>>>>>> >>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>>>>>> >>>>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>>>>>> 2.5 seconds with an ECONNRESET error. >>>>>>>>>> >>>>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>>>>>> I tried on an ARM system and x86_64. >>>>>>>>>> >>>>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>>>>>> Basically, compile the following code: >>>>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>>>>>> bind any specific addresses ). Then after the connection is created, >>>>>>>>> the client will send HB on the v4 paths to the server. The server >>>>>>>>> will abort the connection, as it can't support v4. >>>>>>>>> >>>>>>>>> So you can work around it by either: >>>>>>>>> >>>>>>>>> - set IPV6_V6ONLY on client side. >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> - bind to the specific v6 addresses on the client side. >>>>>>>>> >>>>>>>>> I don't see RFC said something about this. >>>>>>>>> So it may not be a good idea to change the current behaviour >>>>>>>>> to not establish the connection in this case, which may cause regression. >>>>>>>> >>>>>>>> Ok, I understand this. It's a little strange, but I see why it works >>>>>>>> this way. >>>>>>> I don't. I would expect it to work as I described in my email. >>>>>>> Could someone explain me how and why it is behaving different from >>>>>>> my expectation? >>>>>> >>>>>> It looks like a bug to me. Testing with this test app here, I can see >>>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>>>> that's unexpected for a v6only socket. As is, it's the server saying >>>>>> "I'm available at these other addresses too, but not." >>>>> >>>>> Does it even make sense to mix IPv4 and IPv6 addresses on the same >>>>> connection? >>>>> I don't remember ever seeing both types of address in a message, >>>>> but may not have looked. >>>> >>>> That's an interesting question. Do the RFCs say anything? I would >>>> assume it was ok unless ipv6only was set. >>>> >>>>> >>>>> I also wonder whether the connection should be dropped for an error >>>>> response on a path that has never been validated. >>>> >>>> That actually bothered me a bit more. Shouldn't it stay up if any path >>>> is up? That's kind of the whole point of multihoming. >>> >>> Michael explained it on the other email. What he described is what I >>> observed in my tests. >>> >>>> >>>>> >>>>> OTOH the whole 'multi-homing' part of SCTP sucks. >>>> >>>> I don't think so. >>>> >>>>> The IP addresses a server needs to bind to depend on where the >>>>> incoming connection will come from. >>>>> A local connection may be able to use a 192.168.x.x address >>>>> but a remote connection must not - as it may be defined locally >>>>> at the remote system. >>>>> But both connections can come into the public (routable) address. >>>>> We have to tell customers to explicitly configure the local IP >>>>> addresses - which means the application has to know what they are. >>>>> Fortunately these apps are pretty static - usually M3UA. >>>> >>>> Umm, no, If you have a private address, it better be behind a firewall, >>>> and the firewall should handle rewriting the packet to fix the addresses. >>>> >>>> It doesn't appear that Linux netfilter does this. There is a TODO in >>>> the code for this. But that's how it *should* work. >>> >>> Right, we don't support SCTP aware NAT [1]. >>> >>> 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 >> The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 > > Thanks! > >> >> Another possibility for NAT traversal is UDP encapsulation... > > Also not supported.. :-] But maybe someone wants to implement it. It is supported by FreeBSD, if you need a peer for testing. Or the userland stack usrsctp supports it. Then you do not need root privileges to run it. Best regards Michael > > Best regards, > Marcelo > >> >> Best regards >> Michael >>> >>> Marcelo >>> >>>> >>>> -corey >>>> >>>>> >>>>> David >>>>> >>>>> - >>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>>>> Registration No: 1397386 (Wales) >>>>> >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 21:48 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-23 21:48 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: Corey Minyard, David Laight, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: >>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: >>> >>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: >>>> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: >>>>> From: Marcelo Ricardo Leitner >>>>>> Sent: 22 June 2020 19:33 >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>>>>>> >>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>>>>>> >>>>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>>>>>> 2.5 seconds with an ECONNRESET error. >>>>>>>>>> >>>>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>>>>>> I tried on an ARM system and x86_64. >>>>>>>>>> >>>>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>>>>>> Basically, compile the following code: >>>>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>>>>>> bind any specific addresses ). Then after the connection is created, >>>>>>>>> the client will send HB on the v4 paths to the server. The server >>>>>>>>> will abort the connection, as it can't support v4. >>>>>>>>> >>>>>>>>> So you can work around it by either: >>>>>>>>> >>>>>>>>> - set IPV6_V6ONLY on client side. >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> - bind to the specific v6 addresses on the client side. >>>>>>>>> >>>>>>>>> I don't see RFC said something about this. >>>>>>>>> So it may not be a good idea to change the current behaviour >>>>>>>>> to not establish the connection in this case, which may cause regression. >>>>>>>> >>>>>>>> Ok, I understand this. It's a little strange, but I see why it works >>>>>>>> this way. >>>>>>> I don't. I would expect it to work as I described in my email. >>>>>>> Could someone explain me how and why it is behaving different from >>>>>>> my expectation? >>>>>> >>>>>> It looks like a bug to me. Testing with this test app here, I can see >>>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>>>> that's unexpected for a v6only socket. As is, it's the server saying >>>>>> "I'm available at these other addresses too, but not." >>>>> >>>>> Does it even make sense to mix IPv4 and IPv6 addresses on the same >>>>> connection? >>>>> I don't remember ever seeing both types of address in a message, >>>>> but may not have looked. >>>> >>>> That's an interesting question. Do the RFCs say anything? I would >>>> assume it was ok unless ipv6only was set. >>>> >>>>> >>>>> I also wonder whether the connection should be dropped for an error >>>>> response on a path that has never been validated. >>>> >>>> That actually bothered me a bit more. Shouldn't it stay up if any path >>>> is up? That's kind of the whole point of multihoming. >>> >>> Michael explained it on the other email. What he described is what I >>> observed in my tests. >>> >>>> >>>>> >>>>> OTOH the whole 'multi-homing' part of SCTP sucks. >>>> >>>> I don't think so. >>>> >>>>> The IP addresses a server needs to bind to depend on where the >>>>> incoming connection will come from. >>>>> A local connection may be able to use a 192.168.x.x address >>>>> but a remote connection must not - as it may be defined locally >>>>> at the remote system. >>>>> But both connections can come into the public (routable) address. >>>>> We have to tell customers to explicitly configure the local IP >>>>> addresses - which means the application has to know what they are. >>>>> Fortunately these apps are pretty static - usually M3UA. >>>> >>>> Umm, no, If you have a private address, it better be behind a firewall, >>>> and the firewall should handle rewriting the packet to fix the addresses. >>>> >>>> It doesn't appear that Linux netfilter does this. There is a TODO in >>>> the code for this. But that's how it *should* work. >>> >>> Right, we don't support SCTP aware NAT [1]. >>> >>> 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 >> The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 > > Thanks! > >> >> Another possibility for NAT traversal is UDP encapsulation... > > Also not supported.. :-] But maybe someone wants to implement it. It is supported by FreeBSD, if you need a peer for testing. Or the userland stack usrsctp supports it. Then you do not need root privileges to run it. Best regards Michael > > Best regards, > Marcelo > >> >> Best regards >> Michael >>> >>> Marcelo >>> >>>> >>>> -corey >>>> >>>>> >>>>> David >>>>> >>>>> - >>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>>>> Registration No: 1397386 (Wales) >>>>> >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 21:48 ` Michael Tuexen @ 2020-06-24 7:25 ` Xin Long -1 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-24 7:25 UTC (permalink / raw) To: Michael Tuexen Cc: Marcelo Ricardo Leitner, Corey Minyard, David Laight, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote: > > > On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: > >>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > >>> > >>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: > >>>> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > >>>>> From: Marcelo Ricardo Leitner > >>>>>> Sent: 22 June 2020 19:33 > >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > >>>>>>>> > >>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>>>>>>>>> > >>>>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>>>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>>>>>>>>> then I make a connection to it using ::1, the connection will drop after > >>>>>>>>>> 2.5 seconds with an ECONNRESET error. > >>>>>>>>>> > >>>>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>>>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>>>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>>>>>>>>> I tried on an ARM system and x86_64. > >>>>>>>>>> > >>>>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I > >>>>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. > >>>>>>>>>> Basically, compile the following code: > >>>>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will > >>>>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to > >>>>>>>>> bind any specific addresses ). Then after the connection is created, > >>>>>>>>> the client will send HB on the v4 paths to the server. The server > >>>>>>>>> will abort the connection, as it can't support v4. > >>>>>>>>> > >>>>>>>>> So you can work around it by either: > >>>>>>>>> > >>>>>>>>> - set IPV6_V6ONLY on client side. > >>>>>>>>> > >>>>>>>>> or > >>>>>>>>> > >>>>>>>>> - bind to the specific v6 addresses on the client side. > >>>>>>>>> > >>>>>>>>> I don't see RFC said something about this. > >>>>>>>>> So it may not be a good idea to change the current behaviour > >>>>>>>>> to not establish the connection in this case, which may cause regression. > >>>>>>>> > >>>>>>>> Ok, I understand this. It's a little strange, but I see why it works > >>>>>>>> this way. > >>>>>>> I don't. I would expect it to work as I described in my email. > >>>>>>> Could someone explain me how and why it is behaving different from > >>>>>>> my expectation? > >>>>>> > >>>>>> It looks like a bug to me. Testing with this test app here, I can see > >>>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and > >>>>>> that's unexpected for a v6only socket. As is, it's the server saying > >>>>>> "I'm available at these other addresses too, but not." > >>>>> > >>>>> Does it even make sense to mix IPv4 and IPv6 addresses on the same > >>>>> connection? > >>>>> I don't remember ever seeing both types of address in a message, > >>>>> but may not have looked. > >>>> > >>>> That's an interesting question. Do the RFCs say anything? I would > >>>> assume it was ok unless ipv6only was set. > >>>> > >>>>> > >>>>> I also wonder whether the connection should be dropped for an error > >>>>> response on a path that has never been validated. > >>>> > >>>> That actually bothered me a bit more. Shouldn't it stay up if any path > >>>> is up? That's kind of the whole point of multihoming. > >>> > >>> Michael explained it on the other email. What he described is what I > >>> observed in my tests. > >>> > >>>> > >>>>> > >>>>> OTOH the whole 'multi-homing' part of SCTP sucks. > >>>> > >>>> I don't think so. > >>>> > >>>>> The IP addresses a server needs to bind to depend on where the > >>>>> incoming connection will come from. > >>>>> A local connection may be able to use a 192.168.x.x address > >>>>> but a remote connection must not - as it may be defined locally > >>>>> at the remote system. > >>>>> But both connections can come into the public (routable) address. > >>>>> We have to tell customers to explicitly configure the local IP > >>>>> addresses - which means the application has to know what they are. > >>>>> Fortunately these apps are pretty static - usually M3UA. > >>>> > >>>> Umm, no, If you have a private address, it better be behind a firewall, > >>>> and the firewall should handle rewriting the packet to fix the addresses. > >>>> > >>>> It doesn't appear that Linux netfilter does this. There is a TODO in > >>>> the code for this. But that's how it *should* work. > >>> > >>> Right, we don't support SCTP aware NAT [1]. > >>> > >>> 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 > >> The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 > > > > Thanks! > > > >> > >> Another possibility for NAT traversal is UDP encapsulation... > > > > Also not supported.. :-] > But maybe someone wants to implement it. It is supported by FreeBSD, if you > need a peer for testing. Or the userland stack usrsctp supports it. Then you > do not need root privileges to run it. You mean SCTP_REMOTE_UDP_ENCAPS_PORT sockopt, right? We have this in our to-do list. I mixed rfc6951 with the userland one. Will prioritize this feature. Thanks. > > Best regards > Michael > > > > Best regards, > > Marcelo > > > >> > >> Best regards > >> Michael > >>> > >>> Marcelo > >>> > >>>> > >>>> -corey > >>>> > >>>>> > >>>>> David > >>>>> > >>>>> - > >>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > >>>>> Registration No: 1397386 (Wales) > >>>>> > >> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-24 7:25 ` Xin Long 0 siblings, 0 replies; 55+ messages in thread From: Xin Long @ 2020-06-24 7:25 UTC (permalink / raw) To: Michael Tuexen Cc: Marcelo Ricardo Leitner, Corey Minyard, David Laight, Vlad Yasevich, Neil Horman, linux-sctp, LKML On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote: > > > On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > > > On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: > >>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > >>> > >>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: > >>>> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: > >>>>> From: Marcelo Ricardo Leitner > >>>>>> Sent: 22 June 2020 19:33 > >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: > >>>>>>>> > >>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: > >>>>>>>>>> > >>>>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >>>>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >>>>>>>>>> then I make a connection to it using ::1, the connection will drop after > >>>>>>>>>> 2.5 seconds with an ECONNRESET error. > >>>>>>>>>> > >>>>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a > >>>>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't > >>>>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. > >>>>>>>>>> I tried on an ARM system and x86_64. > >>>>>>>>>> > >>>>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I > >>>>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. > >>>>>>>>>> Basically, compile the following code: > >>>>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will > >>>>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to > >>>>>>>>> bind any specific addresses ). Then after the connection is created, > >>>>>>>>> the client will send HB on the v4 paths to the server. The server > >>>>>>>>> will abort the connection, as it can't support v4. > >>>>>>>>> > >>>>>>>>> So you can work around it by either: > >>>>>>>>> > >>>>>>>>> - set IPV6_V6ONLY on client side. > >>>>>>>>> > >>>>>>>>> or > >>>>>>>>> > >>>>>>>>> - bind to the specific v6 addresses on the client side. > >>>>>>>>> > >>>>>>>>> I don't see RFC said something about this. > >>>>>>>>> So it may not be a good idea to change the current behaviour > >>>>>>>>> to not establish the connection in this case, which may cause regression. > >>>>>>>> > >>>>>>>> Ok, I understand this. It's a little strange, but I see why it works > >>>>>>>> this way. > >>>>>>> I don't. I would expect it to work as I described in my email. > >>>>>>> Could someone explain me how and why it is behaving different from > >>>>>>> my expectation? > >>>>>> > >>>>>> It looks like a bug to me. Testing with this test app here, I can see > >>>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and > >>>>>> that's unexpected for a v6only socket. As is, it's the server saying > >>>>>> "I'm available at these other addresses too, but not." > >>>>> > >>>>> Does it even make sense to mix IPv4 and IPv6 addresses on the same > >>>>> connection? > >>>>> I don't remember ever seeing both types of address in a message, > >>>>> but may not have looked. > >>>> > >>>> That's an interesting question. Do the RFCs say anything? I would > >>>> assume it was ok unless ipv6only was set. > >>>> > >>>>> > >>>>> I also wonder whether the connection should be dropped for an error > >>>>> response on a path that has never been validated. > >>>> > >>>> That actually bothered me a bit more. Shouldn't it stay up if any path > >>>> is up? That's kind of the whole point of multihoming. > >>> > >>> Michael explained it on the other email. What he described is what I > >>> observed in my tests. > >>> > >>>> > >>>>> > >>>>> OTOH the whole 'multi-homing' part of SCTP sucks. > >>>> > >>>> I don't think so. > >>>> > >>>>> The IP addresses a server needs to bind to depend on where the > >>>>> incoming connection will come from. > >>>>> A local connection may be able to use a 192.168.x.x address > >>>>> but a remote connection must not - as it may be defined locally > >>>>> at the remote system. > >>>>> But both connections can come into the public (routable) address. > >>>>> We have to tell customers to explicitly configure the local IP > >>>>> addresses - which means the application has to know what they are. > >>>>> Fortunately these apps are pretty static - usually M3UA. > >>>> > >>>> Umm, no, If you have a private address, it better be behind a firewall, > >>>> and the firewall should handle rewriting the packet to fix the addresses. > >>>> > >>>> It doesn't appear that Linux netfilter does this. There is a TODO in > >>>> the code for this. But that's how it *should* work. > >>> > >>> Right, we don't support SCTP aware NAT [1]. > >>> > >>> 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 > >> The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 > > > > Thanks! > > > >> > >> Another possibility for NAT traversal is UDP encapsulation... > > > > Also not supported.. :-] > But maybe someone wants to implement it. It is supported by FreeBSD, if you > need a peer for testing. Or the userland stack usrsctp supports it. Then you > do not need root privileges to run it. You mean SCTP_REMOTE_UDP_ENCAPS_PORT sockopt, right? We have this in our to-do list. I mixed rfc6951 with the userland one. Will prioritize this feature. Thanks. > > Best regards > Michael > > > > Best regards, > > Marcelo > > > >> > >> Best regards > >> Michael > >>> > >>> Marcelo > >>> > >>>> > >>>> -corey > >>>> > >>>>> > >>>>> David > >>>>> > >>>>> - > >>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > >>>>> Registration No: 1397386 (Wales) > >>>>> > >> > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-24 7:25 ` Xin Long @ 2020-06-24 9:18 ` Michael Tuexen -1 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-24 9:18 UTC (permalink / raw) To: Xin Long Cc: Marcelo Ricardo Leitner, Corey Minyard, David Laight, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 24. Jun 2020, at 09:25, Xin Long <lucien.xin@gmail.com> wrote: > > On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen > <michael.tuexen@lurchi.franken.de> wrote: >> >>> On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: >>> >>> On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: >>>>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: >>>>> >>>>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: >>>>>> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: >>>>>>> From: Marcelo Ricardo Leitner >>>>>>>> Sent: 22 June 2020 19:33 >>>>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>>>>>>>> >>>>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>>>>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>>>>>>>> 2.5 seconds with an ECONNRESET error. >>>>>>>>>>>> >>>>>>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>>>>>>>> I tried on an ARM system and x86_64. >>>>>>>>>>>> >>>>>>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>>>>>>>> Basically, compile the following code: >>>>>>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>>>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>>>>>>>> bind any specific addresses ). Then after the connection is created, >>>>>>>>>>> the client will send HB on the v4 paths to the server. The server >>>>>>>>>>> will abort the connection, as it can't support v4. >>>>>>>>>>> >>>>>>>>>>> So you can work around it by either: >>>>>>>>>>> >>>>>>>>>>> - set IPV6_V6ONLY on client side. >>>>>>>>>>> >>>>>>>>>>> or >>>>>>>>>>> >>>>>>>>>>> - bind to the specific v6 addresses on the client side. >>>>>>>>>>> >>>>>>>>>>> I don't see RFC said something about this. >>>>>>>>>>> So it may not be a good idea to change the current behaviour >>>>>>>>>>> to not establish the connection in this case, which may cause regression. >>>>>>>>>> >>>>>>>>>> Ok, I understand this. It's a little strange, but I see why it works >>>>>>>>>> this way. >>>>>>>>> I don't. I would expect it to work as I described in my email. >>>>>>>>> Could someone explain me how and why it is behaving different from >>>>>>>>> my expectation? >>>>>>>> >>>>>>>> It looks like a bug to me. Testing with this test app here, I can see >>>>>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>>>>>> that's unexpected for a v6only socket. As is, it's the server saying >>>>>>>> "I'm available at these other addresses too, but not." >>>>>>> >>>>>>> Does it even make sense to mix IPv4 and IPv6 addresses on the same >>>>>>> connection? >>>>>>> I don't remember ever seeing both types of address in a message, >>>>>>> but may not have looked. >>>>>> >>>>>> That's an interesting question. Do the RFCs say anything? I would >>>>>> assume it was ok unless ipv6only was set. >>>>>> >>>>>>> >>>>>>> I also wonder whether the connection should be dropped for an error >>>>>>> response on a path that has never been validated. >>>>>> >>>>>> That actually bothered me a bit more. Shouldn't it stay up if any path >>>>>> is up? That's kind of the whole point of multihoming. >>>>> >>>>> Michael explained it on the other email. What he described is what I >>>>> observed in my tests. >>>>> >>>>>> >>>>>>> >>>>>>> OTOH the whole 'multi-homing' part of SCTP sucks. >>>>>> >>>>>> I don't think so. >>>>>> >>>>>>> The IP addresses a server needs to bind to depend on where the >>>>>>> incoming connection will come from. >>>>>>> A local connection may be able to use a 192.168.x.x address >>>>>>> but a remote connection must not - as it may be defined locally >>>>>>> at the remote system. >>>>>>> But both connections can come into the public (routable) address. >>>>>>> We have to tell customers to explicitly configure the local IP >>>>>>> addresses - which means the application has to know what they are. >>>>>>> Fortunately these apps are pretty static - usually M3UA. >>>>>> >>>>>> Umm, no, If you have a private address, it better be behind a firewall, >>>>>> and the firewall should handle rewriting the packet to fix the addresses. >>>>>> >>>>>> It doesn't appear that Linux netfilter does this. There is a TODO in >>>>>> the code for this. But that's how it *should* work. >>>>> >>>>> Right, we don't support SCTP aware NAT [1]. >>>>> >>>>> 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 >>>> The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 >>> >>> Thanks! >>> >>>> >>>> Another possibility for NAT traversal is UDP encapsulation... >>> >>> Also not supported.. :-] >> But maybe someone wants to implement it. It is supported by FreeBSD, if you >> need a peer for testing. Or the userland stack usrsctp supports it. Then you >> do not need root privileges to run it. > You mean SCTP_REMOTE_UDP_ENCAPS_PORT sockopt, right? > We have this in our to-do list. I mixed rfc6951 with the userland one. > Will prioritize this feature. Thanks. Great to hear. When implementing RFC 6951 support, please take https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-udp-encaps-cons-02 into account. It is still valid and will be pushed further after RFC 4960bis is done. Best regards Michael > >> >> Best regards >> Michael >>> >>> Best regards, >>> Marcelo >>> >>>> >>>> Best regards >>>> Michael >>>>> >>>>> Marcelo >>>>> >>>>>> >>>>>> -corey >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> - >>>>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>>>>>> Registration No: 1397386 (Wales) >>>>>>> >>>> >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-24 9:18 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-24 9:18 UTC (permalink / raw) To: Xin Long Cc: Marcelo Ricardo Leitner, Corey Minyard, David Laight, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 24. Jun 2020, at 09:25, Xin Long <lucien.xin@gmail.com> wrote: > > On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen > <michael.tuexen@lurchi.franken.de> wrote: >> >>> On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: >>> >>> On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote: >>>>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: >>>>> >>>>> On Tue, Jun 23, 2020 at 11:17:56AM -0500, Corey Minyard wrote: >>>>>> On Tue, Jun 23, 2020 at 01:17:28PM +0000, David Laight wrote: >>>>>>> From: Marcelo Ricardo Leitner >>>>>>>> Sent: 22 June 2020 19:33 >>>>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>>>>>>>> >>>>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>>>>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>>>>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>>>>>>>> 2.5 seconds with an ECONNRESET error. >>>>>>>>>>>> >>>>>>>>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>>>>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>>>>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>>>>>>>> I tried on an ARM system and x86_64. >>>>>>>>>>>> >>>>>>>>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>>>>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>>>>>>>> Basically, compile the following code: >>>>>>>>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>>>>>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>>>>>>>> bind any specific addresses ). Then after the connection is created, >>>>>>>>>>> the client will send HB on the v4 paths to the server. The server >>>>>>>>>>> will abort the connection, as it can't support v4. >>>>>>>>>>> >>>>>>>>>>> So you can work around it by either: >>>>>>>>>>> >>>>>>>>>>> - set IPV6_V6ONLY on client side. >>>>>>>>>>> >>>>>>>>>>> or >>>>>>>>>>> >>>>>>>>>>> - bind to the specific v6 addresses on the client side. >>>>>>>>>>> >>>>>>>>>>> I don't see RFC said something about this. >>>>>>>>>>> So it may not be a good idea to change the current behaviour >>>>>>>>>>> to not establish the connection in this case, which may cause regression. >>>>>>>>>> >>>>>>>>>> Ok, I understand this. It's a little strange, but I see why it works >>>>>>>>>> this way. >>>>>>>>> I don't. I would expect it to work as I described in my email. >>>>>>>>> Could someone explain me how and why it is behaving different from >>>>>>>>> my expectation? >>>>>>>> >>>>>>>> It looks like a bug to me. Testing with this test app here, I can see >>>>>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >>>>>>>> that's unexpected for a v6only socket. As is, it's the server saying >>>>>>>> "I'm available at these other addresses too, but not." >>>>>>> >>>>>>> Does it even make sense to mix IPv4 and IPv6 addresses on the same >>>>>>> connection? >>>>>>> I don't remember ever seeing both types of address in a message, >>>>>>> but may not have looked. >>>>>> >>>>>> That's an interesting question. Do the RFCs say anything? I would >>>>>> assume it was ok unless ipv6only was set. >>>>>> >>>>>>> >>>>>>> I also wonder whether the connection should be dropped for an error >>>>>>> response on a path that has never been validated. >>>>>> >>>>>> That actually bothered me a bit more. Shouldn't it stay up if any path >>>>>> is up? That's kind of the whole point of multihoming. >>>>> >>>>> Michael explained it on the other email. What he described is what I >>>>> observed in my tests. >>>>> >>>>>> >>>>>>> >>>>>>> OTOH the whole 'multi-homing' part of SCTP sucks. >>>>>> >>>>>> I don't think so. >>>>>> >>>>>>> The IP addresses a server needs to bind to depend on where the >>>>>>> incoming connection will come from. >>>>>>> A local connection may be able to use a 192.168.x.x address >>>>>>> but a remote connection must not - as it may be defined locally >>>>>>> at the remote system. >>>>>>> But both connections can come into the public (routable) address. >>>>>>> We have to tell customers to explicitly configure the local IP >>>>>>> addresses - which means the application has to know what they are. >>>>>>> Fortunately these apps are pretty static - usually M3UA. >>>>>> >>>>>> Umm, no, If you have a private address, it better be behind a firewall, >>>>>> and the firewall should handle rewriting the packet to fix the addresses. >>>>>> >>>>>> It doesn't appear that Linux netfilter does this. There is a TODO in >>>>>> the code for this. But that's how it *should* work. >>>>> >>>>> Right, we don't support SCTP aware NAT [1]. >>>>> >>>>> 1.https://tools.ietf.org/html/draft-stewart-behave-sctpnat-04 >>>> The current version is: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16 >>> >>> Thanks! >>> >>>> >>>> Another possibility for NAT traversal is UDP encapsulation... >>> >>> Also not supported.. :-] >> But maybe someone wants to implement it. It is supported by FreeBSD, if you >> need a peer for testing. Or the userland stack usrsctp supports it. Then you >> do not need root privileges to run it. > You mean SCTP_REMOTE_UDP_ENCAPS_PORT sockopt, right? > We have this in our to-do list. I mixed rfc6951 with the userland one. > Will prioritize this feature. Thanks. Great to hear. When implementing RFC 6951 support, please take https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-udp-encaps-cons-02 into account. It is still valid and will be pushed further after RFC 4960bis is done. Best regards Michael > >> >> Best regards >> Michael >>> >>> Best regards, >>> Marcelo >>> >>>> >>>> Best regards >>>> Michael >>>>> >>>>> Marcelo >>>>> >>>>>> >>>>>> -corey >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> - >>>>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>>>>>> Registration No: 1397386 (Wales) >>>>>>> >>>> >> ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 2020-06-23 13:17 ` David Laight @ 2020-06-23 17:09 ` Michael Tuexen 2020-06-23 16:17 ` Corey Minyard 2020-06-23 17:09 ` Michael Tuexen 2 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-23 17:09 UTC (permalink / raw) To: David Laight Cc: Marcelo Ricardo Leitner, minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 23. Jun 2020, at 15:17, David Laight <David.Laight@ACULAB.COM> wrote: > > From: Marcelo Ricardo Leitner >> Sent: 22 June 2020 19:33 >> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>> >>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>> >>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>> 2.5 seconds with an ECONNRESET error. >>>>>> >>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>> I tried on an ARM system and x86_64. >>>>>> >>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>> Basically, compile the following code: >>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>> bind any specific addresses ). Then after the connection is created, >>>>> the client will send HB on the v4 paths to the server. The server >>>>> will abort the connection, as it can't support v4. >>>>> >>>>> So you can work around it by either: >>>>> >>>>> - set IPV6_V6ONLY on client side. >>>>> >>>>> or >>>>> >>>>> - bind to the specific v6 addresses on the client side. >>>>> >>>>> I don't see RFC said something about this. >>>>> So it may not be a good idea to change the current behaviour >>>>> to not establish the connection in this case, which may cause regression. >>>> >>>> Ok, I understand this. It's a little strange, but I see why it works >>>> this way. >>> I don't. I would expect it to work as I described in my email. >>> Could someone explain me how and why it is behaving different from >>> my expectation? >> >> It looks like a bug to me. Testing with this test app here, I can see >> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >> that's unexpected for a v6only socket. As is, it's the server saying >> "I'm available at these other addresses too, but not." > > Does it even make sense to mix IPv4 and IPv6 addresses on the same > connection? Sure, if you have an IPv6 socket, which has not enabled the IPV6ONLY socket option. > I don't remember ever seeing both types of address in a message, > but may not have looked. > > I also wonder whether the connection should be dropped for an error > response on a path that has never been validated. Assuming that it is not an ERROR chunk which comes back, but an ABORT, this should happen as long as the verification tag is OK. > > OTOH the whole 'multi-homing' part of SCTP sucks. > The IP addresses a server needs to bind to depend on where the > incoming connection will come from. Not sure what this means. The application can bind a wildcard address or a specific subset. However, when an INIT comes in, the INIT-ACK might contain only a subset of there due to scoping. > A local connection may be able to use a 192.168.x.x address > but a remote connection must not - as it may be defined locally > at the remote system. Yepp. Not sure what you can do about it. > But both connections can come into the public (routable) address. > We have to tell customers to explicitly configure the local IP > addresses - which means the application has to know what they are. > Fortunately these apps are pretty static - usually M3UA. Please note that in SIGRTRAN scenarios you normally not have NATs involved as you have usually in setups used at home. Best regards Michael > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Strange problem with SCTP+IPv6 @ 2020-06-23 17:09 ` Michael Tuexen 0 siblings, 0 replies; 55+ messages in thread From: Michael Tuexen @ 2020-06-23 17:09 UTC (permalink / raw) To: David Laight Cc: Marcelo Ricardo Leitner, minyard, Xin Long, Vlad Yasevich, Neil Horman, linux-sctp, LKML > On 23. Jun 2020, at 15:17, David Laight <David.Laight@ACULAB.COM> wrote: > > From: Marcelo Ricardo Leitner >> Sent: 22 June 2020 19:33 >> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>> On 22. Jun 2020, at 18:57, Corey Minyard <minyard@acm.org> wrote: >>>> >>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard <minyard@acm.org> wrote: >>>>>> >>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>> then I make a connection to it using ::1, the connection will drop after >>>>>> 2.5 seconds with an ECONNRESET error. >>>>>> >>>>>> It only happens on SCTP, it doesn't have the issue if you connect to a >>>>>> full IPv6 address instead of ::1, and it doesn't happen if you don't >>>>>> set IPV6_V6ONLY. I have verified current end of tree kernel.org. >>>>>> I tried on an ARM system and x86_64. >>>>>> >>>>>> I haven't dug into the kernel to see if I could find anything yet, but I >>>>>> thought I would go ahead and report it. I am attaching a reproducer. >>>>>> Basically, compile the following code: >>>>> The code only set IPV6_V6ONLY on server side, so the client side will >>>>> still bind all the local ipv4 addresses (as you didn't call bind() to >>>>> bind any specific addresses ). Then after the connection is created, >>>>> the client will send HB on the v4 paths to the server. The server >>>>> will abort the connection, as it can't support v4. >>>>> >>>>> So you can work around it by either: >>>>> >>>>> - set IPV6_V6ONLY on client side. >>>>> >>>>> or >>>>> >>>>> - bind to the specific v6 addresses on the client side. >>>>> >>>>> I don't see RFC said something about this. >>>>> So it may not be a good idea to change the current behaviour >>>>> to not establish the connection in this case, which may cause regression. >>>> >>>> Ok, I understand this. It's a little strange, but I see why it works >>>> this way. >>> I don't. I would expect it to work as I described in my email. >>> Could someone explain me how and why it is behaving different from >>> my expectation? >> >> It looks like a bug to me. Testing with this test app here, I can see >> the INIT_ACK being sent with a bunch of ipv4 addresses in it and >> that's unexpected for a v6only socket. As is, it's the server saying >> "I'm available at these other addresses too, but not." > > Does it even make sense to mix IPv4 and IPv6 addresses on the same > connection? Sure, if you have an IPv6 socket, which has not enabled the IPV6ONLY socket option. > I don't remember ever seeing both types of address in a message, > but may not have looked. > > I also wonder whether the connection should be dropped for an error > response on a path that has never been validated. Assuming that it is not an ERROR chunk which comes back, but an ABORT, this should happen as long as the verification tag is OK. > > OTOH the whole 'multi-homing' part of SCTP sucks. > The IP addresses a server needs to bind to depend on where the > incoming connection will come from. Not sure what this means. The application can bind a wildcard address or a specific subset. However, when an INIT comes in, the INIT-ACK might contain only a subset of there due to scoping. > A local connection may be able to use a 192.168.x.x address > but a remote connection must not - as it may be defined locally > at the remote system. Yepp. Not sure what you can do about it. > But both connections can come into the public (routable) address. > We have to tell customers to explicitly configure the local IP > addresses - which means the application has to know what they are. > Fortunately these apps are pretty static - usually M3UA. Please note that in SIGRTRAN scenarios you normally not have NATs involved as you have usually in setups used at home. Best regards Michael > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2020-06-26 16:27 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-21 15:56 Strange problem with SCTP+IPv6 Corey Minyard 2020-06-21 15:56 ` Corey Minyard 2020-06-22 11:52 ` Xin Long 2020-06-22 12:01 ` Xin Long 2020-06-22 12:32 ` Michael Tuexen 2020-06-22 12:32 ` Michael Tuexen 2020-06-22 16:57 ` Corey Minyard 2020-06-22 16:57 ` Corey Minyard 2020-06-22 18:01 ` Michael Tuexen 2020-06-22 18:01 ` Michael Tuexen 2020-06-22 18:32 ` Marcelo Ricardo Leitner 2020-06-22 18:32 ` Marcelo Ricardo Leitner 2020-06-22 18:34 ` Michael Tuexen 2020-06-22 18:34 ` Michael Tuexen 2020-06-23 10:13 ` Xin Long 2020-06-23 10:13 ` Xin Long 2020-06-23 13:29 ` Corey Minyard 2020-06-23 13:29 ` Corey Minyard 2020-06-23 15:40 ` Xin Long 2020-06-23 15:40 ` Xin Long 2020-06-23 16:00 ` Corey Minyard 2020-06-23 16:00 ` Corey Minyard 2020-06-24 6:58 ` Xin Long 2020-06-24 6:58 ` Xin Long 2020-06-26 16:13 ` David Laight 2020-06-26 16:13 ` David Laight 2020-06-26 16:27 ` Michael Tuexen 2020-06-26 16:27 ` Michael Tuexen 2020-06-23 13:17 ` David Laight 2020-06-23 16:04 ` [PATCH] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket minyard 2020-06-23 16:04 ` minyard 2020-06-24 20:31 ` Marcelo Ricardo Leitner 2020-06-24 20:31 ` Marcelo Ricardo Leitner 2020-06-24 20:34 ` [PATCH net] " Marcelo Ricardo Leitner 2020-06-24 20:34 ` Marcelo Ricardo Leitner 2020-06-24 20:53 ` Corey Minyard 2020-06-24 20:53 ` Corey Minyard 2020-06-25 23:12 ` David Miller 2020-06-25 23:12 ` David Miller 2020-06-23 16:17 ` Strange problem with SCTP+IPv6 Corey Minyard 2020-06-23 16:17 ` Corey Minyard 2020-06-23 21:21 ` 'Marcelo Ricardo Leitner' 2020-06-23 21:21 ` 'Marcelo Ricardo Leitner' 2020-06-23 21:24 ` Michael Tuexen 2020-06-23 21:24 ` Michael Tuexen 2020-06-23 21:31 ` Marcelo Ricardo Leitner 2020-06-23 21:31 ` Marcelo Ricardo Leitner 2020-06-23 21:48 ` Michael Tuexen 2020-06-23 21:48 ` Michael Tuexen 2020-06-24 7:25 ` Xin Long 2020-06-24 7:25 ` Xin Long 2020-06-24 9:18 ` Michael Tuexen 2020-06-24 9:18 ` Michael Tuexen 2020-06-23 17:09 ` Michael Tuexen 2020-06-23 17:09 ` Michael Tuexen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.