Hi Pau and list, On Mon, Aug 24, 2020 at 12:00:27PM +0200, Pau Espin Pedrol wrote: > Quick similar scenario setup would be something like: > > SERVER: > server_fd = socket(AF_INET6, SCTP, STREAM); > sctp_bindx(server_fd, "127.0.0.1", "::1"); > listen(server_fd); accept(server_fd); > > CLIENT: > client_fd = socket(AF_INET6, SCTP, STREAM); > sctp_bindx(client_fd, "::1"); > sctp_connectx(client_fd, "::1"); > > And then after client connects ::1<->::1 and gains info about server's > 127.0.0.1 address, it tries to INIT 127.0.0.1->127.0.0.1 despite it was > never bound to 127.0.0.1. Thanks for reducing the example to the above. I think it should be pretty clear now. The client side kernel SCTP is misbehaving here. One minor amendment: I don't think it's a question of whether or not the client side socket ever was bound to 127.0.0.1. The key issue here is that the client side socket was not bound to any IPv4 address at all. Sidenote: What I also find puzzling is that both sockets in your example are created as AF_INET6 sockets, not as AF_UNSPEC. But let's stay focused on the actual problem here: A client-side socket being exclusively bound to IPv6 adresses attempting to send INIT chunks from an IPv4 address! -- - Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
