SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

[Pau Espin Pedrol]

Hi all,

I just submitted the following SCTP bug in the kernel bugtracker. I
placed it under "IPV6" category since there's no "SCTP" category
available there. It may be worth asking whoever is in charge to add the
category so the relevant maintainer is assigned?

https://bugzilla.kernel.org/show_bug.cgi?id 8969

PS: I'm not registered to the ML, plese keep me in CC.

-- 
- Pau Espin Pedrol <pespin@sysmocom.de>         http://www.sysmocom.de/
===================================* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Re: SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

[Marcelo Ricardo Leitner]

Hi Pau,

On Thu, Aug 20, 2020 at 01:11:02PM +0200, Pau Espin Pedrol wrote:
> Hi all,
> 
> I just submitted the following SCTP bug in the kernel bugtracker. I
> placed it under "IPV6" category since there's no "SCTP" category
> available there. It may be worth asking whoever is in charge to add the
> category so the relevant maintainer is assigned?

We actually don't use that bugzilla.

> 
> https://bugzilla.kernel.org/show_bug.cgi?id 8969
> 
> PS: I'm not registered to the ML, plese keep me in CC.

Aye. But gotta say, you might want to subscribe. It's really low
volume, and will get you aware of recent fixes.

By your description in the bug, seems we fixed it in June. Can you
confirm that your kernel doesn't have this commit in?
471e39df96b9 ("sctp: Don't advertise IPv4 addresses if ipv6only is set
on the socket")

Regards,
Marcelo

Re: SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

[Pau Espin Pedrol]

Hi Marcelo,

Between my initial message and your response I updated my kernel to
Archlinux latest package version (5.8.3-arch1-1,
https://git.archlinux.org/linux.git/), which still shows the same bug I
mentioned in my previous message.

The commit you described is already contained in the kernel (it was
included upstream during v5.8-rc3).

Moreover, the description of the commit you shared doesn't seem to match
the issue I described. The issue I explained is about the kernel trying
to create further connections on an already ongoing association using a
local IPv4 address it was never bound to; the issue has nothing to do
with advertising of addresses (advertising is working correctly here IMHO).

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.

Regards,
Pau

-- 
- Pau Espin Pedrol <pespin@sysmocom.de>         http://www.sysmocom.de/
===================================* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Re: SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

[Pau Espin Pedrol]

Hi Andreas,

My point is that the failure is in the client, which is creating an
AF_INET6 socket and only binding on ::1, so it should never try to use
"127.0.0.1" as local IP imho. Your comments may apply to the server,
which is actually behaving fine.

On 8/24/20 12:12 PM, Andreas Fink wrote:
> The problem might be that your socket(AF_INET6,SCTP,STREAM) gives you an
> IPv6 only socket
> but you are binding an IPv4 address to it with sctp_bindx. This will
> probably fail and thus you are binding to "any".

It doesn't fail, I'm checking the result of sctp_bindx() and
/proc/net/sctp/eps I initially attached to the bug tracker shows it's
binding fine as expected.

> 
> If you want IPv4+IPv6 in one socket, you need to specify a IPv4 address
> in  IPv6 compatibility format
> So you should sctp_bindx to   "::ffff:127.0.0.1" not to  "127.0.0.1"
>  (well in any case you should pass a struck sockaddr_in6 and not a
> struct sockaddr_in)

Not really. I'm creating an addr buffer containing both struct
sockaddr_in and struct sockaddr_in6 (see [1] if interested) after having
looked at how libsctp and the kernel handle the sctp_bindx call, and
it's working fine as backed by what /proc/net/sctp/eps shows.

[1]
https://git.osmocom.org/libosmocore/tree/src/socket.c?idí42a889004730beb26ce61ee462244b2bad6be9#n470

-- 
- Pau Espin Pedrol <pespin@sysmocom.de>         http://www.sysmocom.de/
===================================* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Re: SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

[Pau Espin Pedrol]

Hi,

On 8/24/20 12:28 PM, Andreas Fink wrote:
> the server might tell it that it can also connect on 127.0.0.1 because
> of the advertized IPs maybe?
> 

Yes sure, that's happening, the server is advertising the 127.0.0.1 over
the conn established in ::1<->::1 because it is bound to that address
too, but that's fine imho.

The problem is the client attempting to connect to server's 127.0.0.1
despite being not bound to any IPv4 address, and specifically to 127.0.0.1.

-- 
- Pau Espin Pedrol <pespin@sysmocom.de>         http://www.sysmocom.de/
===================================* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Re: SCTP multi-homed association (::1)->(::1+127.0.0.1) attempting HEARTBEAT on 127.0.0.1->127.0.0.1

[Harald Welte]

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@gnumonks.org>           http://laforge.gnumonks.org/
======================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)