packet->transport->asoc = NULL in sctp_packet_transmit

packet->transport->asoc = NULL in sctp_packet_transmit

[Fabian Bergmark]

I'm adding experimental support for UDP encapsulation of SCTP packets.
I got most of if working well. However, I noticed a NULL pointer
dereference in sctp_packet_transmit as I assumed that
packet->transport->asoc weren't NULL so I tried to access tunneling
information that I store in packet->transport->asoc->ep->base. In what
circumstances is asoc NULL in sctp_packet_transmit?

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Neil Horman]

On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
> I'm adding experimental support for UDP encapsulation of SCTP packets.
> I got most of if working well. However, I noticed a NULL pointer
> dereference in sctp_packet_transmit as I assumed that
> packet->transport->asoc weren't NULL so I tried to access tunneling
> information that I store in packet->transport->asoc->ep->base. In what
> circumstances is asoc NULL in sctp_packet_transmit?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

There may be others, but the case that comes immediately to mind is when you
have an error in the construction of a new association (e.g. a state cookie, or
an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
packet with no assoction associated.

Neil

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Fabian Bergmark]

Thanks. I solved the issue by having a per-transport tunnel.

The code can be found here:
https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp

As this is the first time i write kernel code, I would really
appreciate if someone looked at it.
The encapsulation seems to work fine (inspected in wireshark), but I'm
not sure if I close/free everything correctly.

2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com>:
> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
>> I'm adding experimental support for UDP encapsulation of SCTP packets.
>> I got most of if working well. However, I noticed a NULL pointer
>> dereference in sctp_packet_transmit as I assumed that
>> packet->transport->asoc weren't NULL so I tried to access tunneling
>> information that I store in packet->transport->asoc->ep->base. In what
>> circumstances is asoc NULL in sctp_packet_transmit?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> There may be others, but the case that comes immediately to mind is when you
> have an error in the construction of a new association (e.g. a state cookie, or
> an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
> packet with no assoction associated.
>
> Neil
>

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Fabian Bergmark]

I'm now working on support for multi-homing. I noticed that when the
client has multiple interfaces, the client would treat the HEARTBEAT
sent by the server as ootb and abort. When I tried to compare to the
vanilla SCTP version I saw the same behavior.
My setup is a laptop with two network interfaces (192.168.2.64,
192.168.2.168) acting as the client, a router (192.168.2.1) that
forwards protocol 132 to my stationary. My stationary has one
interface (192.168.2.9). The client connects on the routers external
IP (178.16.218.41)
Server log: http://pastebin.com/FE667m6t
Clientl log: http://pastebin.com/vu2YYkWJ

Is this a bug, and if so, is it fixed in a recent commit? Both
computers are running recent kernels (client 4.5.4-1 and server
4.6.3-1)

2016-07-19 16:42 GMT+02:00 Fabian Bergmark <fabian.bergmark@gmail.com>:
> Thanks. I solved the issue by having a per-transport tunnel.
>
> The code can be found here:
> https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
>
> As this is the first time i write kernel code, I would really
> appreciate if someone looked at it.
> The encapsulation seems to work fine (inspected in wireshark), but I'm
> not sure if I close/free everything correctly.
>
> 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com>:
>> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
>>> I'm adding experimental support for UDP encapsulation of SCTP packets.
>>> I got most of if working well. However, I noticed a NULL pointer
>>> dereference in sctp_packet_transmit as I assumed that
>>> packet->transport->asoc weren't NULL so I tried to access tunneling
>>> information that I store in packet->transport->asoc->ep->base. In what
>>> circumstances is asoc NULL in sctp_packet_transmit?
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> There may be others, but the case that comes immediately to mind is when you
>> have an error in the construction of a new association (e.g. a state cookie, or
>> an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
>> packet with no assoction associated.
>>
>> Neil
>>

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Marcelo Ricardo Leitner]

On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
> I'm now working on support for multi-homing. I noticed that when the
> client has multiple interfaces, the client would treat the HEARTBEAT
> sent by the server as ootb and abort. When I tried to compare to the
> vanilla SCTP version I saw the same behavior.
> My setup is a laptop with two network interfaces (192.168.2.64,
> 192.168.2.168) acting as the client, a router (192.168.2.1) that
> forwards protocol 132 to my stationary. My stationary has one
> interface (192.168.2.9). The client connects on the routers external
> IP (178.16.218.41)

First of all, such setup requires some other adjustments on ip
routes/rules/arp sysctl so you can actually use the two interfaces on
the same subnet, otherwise Linux will end up issuing packets with src
192.168.2.64 on the interface with 192.168.2.168, or vice-versa. Same
thing will happen on input, as it will reply ARP request on the first
interface to receive the ARP request.

I'd recommend you to switch to a true multi-homed situation, it's easier
to get right and more alike to real world situations.

You may even use netns for this, or virtual machines. Both would work.

> Server log: http://pastebin.com/FE667m6t
> Clientl log: http://pastebin.com/vu2YYkWJ
> 
> Is this a bug, and if so, is it fixed in a recent commit? Both
> computers are running recent kernels (client 4.5.4-1 and server
> 4.6.3-1)

The heartbeat was sent using 192.168.2.9 addr and not the external IP.
Was this address negotiated on INIT handshake? It's the first hit of it
on client log. If you don't bind the socket to a single IP address, it
will use all addresses available on the host.

Note that, if you are binding the socket to specific interfaces, what I
mentioned in the beginning may also be affecting it, as sctp_rcv() will
enforce that the packet came in through the right interface.

  Marcelo

> 
> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark <fabian.bergmark@gmail.com>:
> > Thanks. I solved the issue by having a per-transport tunnel.
> >
> > The code can be found here:
> > https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
> >
> > As this is the first time i write kernel code, I would really
> > appreciate if someone looked at it.
> > The encapsulation seems to work fine (inspected in wireshark), but I'm
> > not sure if I close/free everything correctly.
> >
> > 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com>:
> >> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
> >>> I'm adding experimental support for UDP encapsulation of SCTP packets.
> >>> I got most of if working well. However, I noticed a NULL pointer
> >>> dereference in sctp_packet_transmit as I assumed that
> >>> packet->transport->asoc weren't NULL so I tried to access tunneling
> >>> information that I store in packet->transport->asoc->ep->base. In what
> >>> circumstances is asoc NULL in sctp_packet_transmit?
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> >> There may be others, but the case that comes immediately to mind is when you
> >> have an error in the construction of a new association (e.g. a state cookie, or
> >> an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
> >> packet with no assoction associated.
> >>
> >> Neil
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Fabian Bergmark]

Indeed the issue was solved by using virtual machines. The client no
longer treats the HEARTBEATS as OOTB.
My current setup is one VM (the server) which is bridged to my LAN. My
router is setup to forward all UDP traffic on port 5000 to the VM.
A second VM (the client) has two bridged interfaces (two tethering
mobile phones). The client connects to the server via the external IP
of the router.
This works fine. However, I noticed that the client only seems to use
one interface (probably the one with the lowest metric?). Looking
trough the debug log
of the client, it only mentions one IP (the one of the lower metric
interface). I thought SCTP would use all client interfaces? Is there
some configuration to achieve
this or doesn't SCTP support multi-homing in this setup?

2016-07-20 18:42 GMT+02:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
> On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
>> I'm now working on support for multi-homing. I noticed that when the
>> client has multiple interfaces, the client would treat the HEARTBEAT
>> sent by the server as ootb and abort. When I tried to compare to the
>> vanilla SCTP version I saw the same behavior.
>> My setup is a laptop with two network interfaces (192.168.2.64,
>> 192.168.2.168) acting as the client, a router (192.168.2.1) that
>> forwards protocol 132 to my stationary. My stationary has one
>> interface (192.168.2.9). The client connects on the routers external
>> IP (178.16.218.41)
>
> First of all, such setup requires some other adjustments on ip
> routes/rules/arp sysctl so you can actually use the two interfaces on
> the same subnet, otherwise Linux will end up issuing packets with src
> 192.168.2.64 on the interface with 192.168.2.168, or vice-versa. Same
> thing will happen on input, as it will reply ARP request on the first
> interface to receive the ARP request.
>
> I'd recommend you to switch to a true multi-homed situation, it's easier
> to get right and more alike to real world situations.
>
> You may even use netns for this, or virtual machines. Both would work.
>
>> Server log: http://pastebin.com/FE667m6t
>> Clientl log: http://pastebin.com/vu2YYkWJ
>>
>> Is this a bug, and if so, is it fixed in a recent commit? Both
>> computers are running recent kernels (client 4.5.4-1 and server
>> 4.6.3-1)
>
> The heartbeat was sent using 192.168.2.9 addr and not the external IP.
> Was this address negotiated on INIT handshake? It's the first hit of it
> on client log. If you don't bind the socket to a single IP address, it
> will use all addresses available on the host.
>
> Note that, if you are binding the socket to specific interfaces, what I
> mentioned in the beginning may also be affecting it, as sctp_rcv() will
> enforce that the packet came in through the right interface.
>
>   Marcelo
>
>>
>> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark <fabian.bergmark@gmail.com>:
>> > Thanks. I solved the issue by having a per-transport tunnel.
>> >
>> > The code can be found here:
>> > https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
>> >
>> > As this is the first time i write kernel code, I would really
>> > appreciate if someone looked at it.
>> > The encapsulation seems to work fine (inspected in wireshark), but I'm
>> > not sure if I close/free everything correctly.
>> >
>> > 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com>:
>> >> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
>> >>> I'm adding experimental support for UDP encapsulation of SCTP packets.
>> >>> I got most of if working well. However, I noticed a NULL pointer
>> >>> dereference in sctp_packet_transmit as I assumed that
>> >>> packet->transport->asoc weren't NULL so I tried to access tunneling
>> >>> information that I store in packet->transport->asoc->ep->base. In what
>> >>> circumstances is asoc NULL in sctp_packet_transmit?
>> >>> --
>> >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> >>> the body of a message to majordomo@vger.kernel.org
>> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >>>
>> >>
>> >> There may be others, but the case that comes immediately to mind is when you
>> >> have an error in the construction of a new association (e.g. a state cookie, or
>> >> an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
>> >> packet with no assoction associated.
>> >>
>> >> Neil
>> >>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Marcelo Ricardo Leitner]

Please don't top post..

On Thu, Jul 21, 2016 at 02:49:56PM +0200, Fabian Bergmark wrote:
> Indeed the issue was solved by using virtual machines. The client no
> longer treats the HEARTBEATS as OOTB.

Ok good.

> My current setup is one VM (the server) which is bridged to my LAN. My
> router is setup to forward all UDP traffic on port 5000 to the VM.
> A second VM (the client) has two bridged interfaces (two tethering
> mobile phones). The client connects to the server via the external IP
> of the router.

Ok. Yet, why don't you do it with 2 VMs, each with 2 NICs on distinct
subnets?

> This works fine. However, I noticed that the client only seems to use
> one interface (probably the one with the lowest metric?). Looking
> trough the debug log
> of the client, it only mentions one IP (the one of the lower metric
> interface). I thought SCTP would use all client interfaces? Is there
> some configuration to achieve

Take a traffic capture and check INIT and INIT_ACK packets, they will
contain which addresses the peer is announced.

> this or doesn't SCTP support multi-homing in this setup?

But yeah, as you are doing it, it looks more like multi-path than
multi-homing and it protects only part of your connection, as there is
some part of the path that is common to both routes. As I'm
understanding, both interfaces on the guest have a default route that
can reach the same IP address of the server. 

I couldn't get to a root cause on why but I didn't have much luck with
this setup either. If you manage to have 2 IPs for each peer, it should
work.

> 
> 2016-07-20 18:42 GMT+02:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
> > On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
> >> I'm now working on support for multi-homing. I noticed that when the
> >> client has multiple interfaces, the client would treat the HEARTBEAT
> >> sent by the server as ootb and abort. When I tried to compare to the
> >> vanilla SCTP version I saw the same behavior.
> >> My setup is a laptop with two network interfaces (192.168.2.64,
> >> 192.168.2.168) acting as the client, a router (192.168.2.1) that
> >> forwards protocol 132 to my stationary. My stationary has one
> >> interface (192.168.2.9). The client connects on the routers external
> >> IP (178.16.218.41)
> >
> > First of all, such setup requires some other adjustments on ip
> > routes/rules/arp sysctl so you can actually use the two interfaces on
> > the same subnet, otherwise Linux will end up issuing packets with src
> > 192.168.2.64 on the interface with 192.168.2.168, or vice-versa. Same
> > thing will happen on input, as it will reply ARP request on the first
> > interface to receive the ARP request.
> >
> > I'd recommend you to switch to a true multi-homed situation, it's easier
> > to get right and more alike to real world situations.
> >
> > You may even use netns for this, or virtual machines. Both would work.
> >
> >> Server log: http://pastebin.com/FE667m6t
> >> Clientl log: http://pastebin.com/vu2YYkWJ
> >>
> >> Is this a bug, and if so, is it fixed in a recent commit? Both
> >> computers are running recent kernels (client 4.5.4-1 and server
> >> 4.6.3-1)
> >
> > The heartbeat was sent using 192.168.2.9 addr and not the external IP.
> > Was this address negotiated on INIT handshake? It's the first hit of it
> > on client log. If you don't bind the socket to a single IP address, it
> > will use all addresses available on the host.
> >
> > Note that, if you are binding the socket to specific interfaces, what I
> > mentioned in the beginning may also be affecting it, as sctp_rcv() will
> > enforce that the packet came in through the right interface.
> >
> >   Marcelo
> >
> >>
> >> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark <fabian.bergmark@gmail.com>:
> >> > Thanks. I solved the issue by having a per-transport tunnel.
> >> >
> >> > The code can be found here:
> >> > https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
> >> >
> >> > As this is the first time i write kernel code, I would really
> >> > appreciate if someone looked at it.
> >> > The encapsulation seems to work fine (inspected in wireshark), but I'm
> >> > not sure if I close/free everything correctly.
> >> >
> >> > 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com>:
> >> >> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
> >> >>> I'm adding experimental support for UDP encapsulation of SCTP packets.
> >> >>> I got most of if working well. However, I noticed a NULL pointer
> >> >>> dereference in sctp_packet_transmit as I assumed that
> >> >>> packet->transport->asoc weren't NULL so I tried to access tunneling
> >> >>> information that I store in packet->transport->asoc->ep->base. In what
> >> >>> circumstances is asoc NULL in sctp_packet_transmit?
> >> >>> --
> >> >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> >> >>> the body of a message to majordomo@vger.kernel.org
> >> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >>>
> >> >>
> >> >> There may be others, but the case that comes immediately to mind is when you
> >> >> have an error in the construction of a new association (e.g. a state cookie, or
> >> >> an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
> >> >> packet with no assoction associated.
> >> >>
> >> >> Neil
> >> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Marcelo Ricardo Leitner]

Em 21-07-2016 16:56, Fabian Bergmark escreveu:
> I tried using virtual box nat networks but couldn't get it to work. It
> seemed like the host answered with ICMP port unreachable on the INIT ACK.
>
> Regarding multihoming. My setup will be a server with one interface and
> a client with several. I was hoping to achieve load balancing. Is CMP
> implemented in lksctp? If not, is there anyone working on that? I read

Concurrent Multipath Transfer you mean? No, and not even in the charts 
that I know of.

> that it's recently implemented in BSD. Is failover implemented in lksctp?

We are usually a few steps behind BSD regarding SCTP.

Yes, failover is implemented.

Currently, the application may set the primary addr for it and for the 
peer, but not much more than that. (SCTP_PRIMARY_ADDR, 
SCTP_SET_PEER_PRIMARY_ADDR)

I'm afraid lksctp won't match your goal for load balancing on sctp paths.

>
> Both interfaces of the client can reach the server IP. I could maybe
> create a secondary interface for the server and force traffic to that IP
> on the secondary IF. Is this necessary for failover/CMP to work?

As long as both peers have at least 2 IPs to talk to each other, it 
should work fine.

I have noted down to check this situation on having only 1 IP, will 
check when possible. Or maybe Neil or someone else knows better.

>
>
> On Jul 21, 2016 19:12, "Marcelo Ricardo Leitner"
> <marcelo.leitner@gmail.com <mailto:marcelo.leitner@gmail.com>> wrote:
>
>     Please don't top post..
>
>     On Thu, Jul 21, 2016 at 02:49:56PM +0200, Fabian Bergmark wrote:
>     > Indeed the issue was solved by using virtual machines. The client no
>     > longer treats the HEARTBEATS as OOTB.
>
>     Ok good.
>
>     > My current setup is one VM (the server) which is bridged to my LAN. My
>     > router is setup to forward all UDP traffic on port 5000 to the VM.
>     > A second VM (the client) has two bridged interfaces (two tethering
>     > mobile phones). The client connects to the server via the external IP
>     > of the router.
>
>     Ok. Yet, why don't you do it with 2 VMs, each with 2 NICs on distinct
>     subnets?
>
>     > This works fine. However, I noticed that the client only seems to use
>     > one interface (probably the one with the lowest metric?). Looking
>     > trough the debug log
>     > of the client, it only mentions one IP (the one of the lower metric
>     > interface). I thought SCTP would use all client interfaces? Is there
>     > some configuration to achieve
>
>     Take a traffic capture and check INIT and INIT_ACK packets, they will
>     contain which addresses the peer is announced.
>
>     > this or doesn't SCTP support multi-homing in this setup?
>
>     But yeah, as you are doing it, it looks more like multi-path than
>     multi-homing and it protects only part of your connection, as there is
>     some part of the path that is common to both routes. As I'm
>     understanding, both interfaces on the guest have a default route that
>     can reach the same IP address of the server.
>
>     I couldn't get to a root cause on why but I didn't have much luck with
>     this setup either. If you manage to have 2 IPs for each peer, it should
>     work.
>
>     >
>     > 2016-07-20 18:42 GMT+02:00 Marcelo Ricardo Leitner
>     <marcelo.leitner@gmail.com <mailto:marcelo.leitner@gmail.com>>:
>     > > On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
>     > >> I'm now working on support for multi-homing. I noticed that
>     when the
>     > >> client has multiple interfaces, the client would treat the
>     HEARTBEAT
>     > >> sent by the server as ootb and abort. When I tried to compare
>     to the
>     > >> vanilla SCTP version I saw the same behavior.
>     > >> My setup is a laptop with two network interfaces (192.168.2.64,
>     > >> 192.168.2.168) acting as the client, a router (192.168.2.1) that
>     > >> forwards protocol 132 to my stationary. My stationary has one
>     > >> interface (192.168.2.9). The client connects on the routers
>     external
>     > >> IP (178.16.218.41)
>     > >
>     > > First of all, such setup requires some other adjustments on ip
>     > > routes/rules/arp sysctl so you can actually use the two
>     interfaces on
>     > > the same subnet, otherwise Linux will end up issuing packets
>     with src
>     > > 192.168.2.64 on the interface with 192.168.2.168, or vice-versa.
>     Same
>     > > thing will happen on input, as it will reply ARP request on the
>     first
>     > > interface to receive the ARP request.
>     > >
>     > > I'd recommend you to switch to a true multi-homed situation,
>     it's easier
>     > > to get right and more alike to real world situations.
>     > >
>     > > You may even use netns for this, or virtual machines. Both would
>     work.
>     > >
>     > >> Server log: http://pastebin.com/FE667m6t
>     > >> Clientl log: http://pastebin.com/vu2YYkWJ
>     > >>
>     > >> Is this a bug, and if so, is it fixed in a recent commit? Both
>     > >> computers are running recent kernels (client 4.5.4-1 and server
>     > >> 4.6.3-1)
>     > >
>     > > The heartbeat was sent using 192.168.2.9 addr and not the
>     external IP.
>     > > Was this address negotiated on INIT handshake? It's the first
>     hit of it
>     > > on client log. If you don't bind the socket to a single IP
>     address, it
>     > > will use all addresses available on the host.
>     > >
>     > > Note that, if you are binding the socket to specific interfaces,
>     what I
>     > > mentioned in the beginning may also be affecting it, as
>     sctp_rcv() will
>     > > enforce that the packet came in through the right interface.
>     > >
>     > >   Marcelo
>     > >
>     > >>
>     > >> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark
>     <fabian.bergmark@gmail.com <mailto:fabian.bergmark@gmail.com>>:
>     > >> > Thanks. I solved the issue by having a per-transport tunnel.
>     > >> >
>     > >> > The code can be found here:
>     > >> >
>     https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
>     > >> >
>     > >> > As this is the first time i write kernel code, I would really
>     > >> > appreciate if someone looked at it.
>     > >> > The encapsulation seems to work fine (inspected in
>     wireshark), but I'm
>     > >> > not sure if I close/free everything correctly.
>     > >> >
>     > >> > 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com
>     <mailto:nhorman@tuxdriver.com>>:
>     > >> >> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
>     > >> >>> I'm adding experimental support for UDP encapsulation of
>     SCTP packets.
>     > >> >>> I got most of if working well. However, I noticed a NULL
>     pointer
>     > >> >>> dereference in sctp_packet_transmit as I assumed that
>     > >> >>> packet->transport->asoc weren't NULL so I tried to access
>     tunneling
>     > >> >>> information that I store in
>     packet->transport->asoc->ep->base. In what
>     > >> >>> circumstances is asoc NULL in sctp_packet_transmit?
>     > >> >>> --
>     > >> >>> To unsubscribe from this list: send the line "unsubscribe
>     linux-sctp" in
>     > >> >>> the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     > >> >>> More majordomo info at
>     http://vger.kernel.org/majordomo-info.html
>     > >> >>>
>     > >> >>
>     > >> >> There may be others, but the case that comes immediately to
>     mind is when you
>     > >> >> have an error in the construction of a new association (e.g.
>     a state cookie, or
>     > >> >> an abort during setup).  In those cases we call
>     sctp_ootb_pkt_new, which sends a
>     > >> >> packet with no assoction associated.
>     > >> >>
>     > >> >> Neil
>     > >> >>
>     > >> --
>     > >> To unsubscribe from this list: send the line "unsubscribe
>     linux-sctp" in
>     > >> the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     > >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>     > >>
>     > --
>     > To unsubscribe from this list: send the line "unsubscribe
>     linux-sctp" in
>     > the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>     >
>

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Fabian Bergmark]

I tried using virtual box nat networks but couldn't get it to work. It
seemed like the host answered with ICMP port unreachable on the INIT
ACK.

Regarding multihoming. My setup will be a server with one interface
and a client with several. I was hoping to achieve load balancing. Is
CMP implemented in lksctp? If not, is there anyone working on that? I
read that it's recently implemented in BSD. Is failover implemented in
lksctp?

Both interfaces of the client can reach the server IP. I could maybe
create a secondary interface for the server and force traffic to that
IP on the secondary IF. Is this necessary for failover/CMP to work?


2016-07-21 19:12 GMT+02:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
> Please don't top post..
>
> On Thu, Jul 21, 2016 at 02:49:56PM +0200, Fabian Bergmark wrote:
>> Indeed the issue was solved by using virtual machines. The client no
>> longer treats the HEARTBEATS as OOTB.
>
> Ok good.
>
>> My current setup is one VM (the server) which is bridged to my LAN. My
>> router is setup to forward all UDP traffic on port 5000 to the VM.
>> A second VM (the client) has two bridged interfaces (two tethering
>> mobile phones). The client connects to the server via the external IP
>> of the router.
>
> Ok. Yet, why don't you do it with 2 VMs, each with 2 NICs on distinct
> subnets?
>
>> This works fine. However, I noticed that the client only seems to use
>> one interface (probably the one with the lowest metric?). Looking
>> trough the debug log
>> of the client, it only mentions one IP (the one of the lower metric
>> interface). I thought SCTP would use all client interfaces? Is there
>> some configuration to achieve
>
> Take a traffic capture and check INIT and INIT_ACK packets, they will
> contain which addresses the peer is announced.
>
>> this or doesn't SCTP support multi-homing in this setup?
>
> But yeah, as you are doing it, it looks more like multi-path than
> multi-homing and it protects only part of your connection, as there is
> some part of the path that is common to both routes. As I'm
> understanding, both interfaces on the guest have a default route that
> can reach the same IP address of the server.
>
> I couldn't get to a root cause on why but I didn't have much luck with
> this setup either. If you manage to have 2 IPs for each peer, it should
> work.
>
>>
>> 2016-07-20 18:42 GMT+02:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
>> > On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
>> >> I'm now working on support for multi-homing. I noticed that when the
>> >> client has multiple interfaces, the client would treat the HEARTBEAT
>> >> sent by the server as ootb and abort. When I tried to compare to the
>> >> vanilla SCTP version I saw the same behavior.
>> >> My setup is a laptop with two network interfaces (192.168.2.64,
>> >> 192.168.2.168) acting as the client, a router (192.168.2.1) that
>> >> forwards protocol 132 to my stationary. My stationary has one
>> >> interface (192.168.2.9). The client connects on the routers external
>> >> IP (178.16.218.41)
>> >
>> > First of all, such setup requires some other adjustments on ip
>> > routes/rules/arp sysctl so you can actually use the two interfaces on
>> > the same subnet, otherwise Linux will end up issuing packets with src
>> > 192.168.2.64 on the interface with 192.168.2.168, or vice-versa. Same
>> > thing will happen on input, as it will reply ARP request on the first
>> > interface to receive the ARP request.
>> >
>> > I'd recommend you to switch to a true multi-homed situation, it's easier
>> > to get right and more alike to real world situations.
>> >
>> > You may even use netns for this, or virtual machines. Both would work.
>> >
>> >> Server log: http://pastebin.com/FE667m6t
>> >> Clientl log: http://pastebin.com/vu2YYkWJ
>> >>
>> >> Is this a bug, and if so, is it fixed in a recent commit? Both
>> >> computers are running recent kernels (client 4.5.4-1 and server
>> >> 4.6.3-1)
>> >
>> > The heartbeat was sent using 192.168.2.9 addr and not the external IP.
>> > Was this address negotiated on INIT handshake? It's the first hit of it
>> > on client log. If you don't bind the socket to a single IP address, it
>> > will use all addresses available on the host.
>> >
>> > Note that, if you are binding the socket to specific interfaces, what I
>> > mentioned in the beginning may also be affecting it, as sctp_rcv() will
>> > enforce that the packet came in through the right interface.
>> >
>> >   Marcelo
>> >
>> >>
>> >> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark <fabian.bergmark@gmail.com>:
>> >> > Thanks. I solved the issue by having a per-transport tunnel.
>> >> >
>> >> > The code can be found here:
>> >> > https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
>> >> >
>> >> > As this is the first time i write kernel code, I would really
>> >> > appreciate if someone looked at it.
>> >> > The encapsulation seems to work fine (inspected in wireshark), but I'm
>> >> > not sure if I close/free everything correctly.
>> >> >
>> >> > 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com>:
>> >> >> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark wrote:
>> >> >>> I'm adding experimental support for UDP encapsulation of SCTP packets.
>> >> >>> I got most of if working well. However, I noticed a NULL pointer
>> >> >>> dereference in sctp_packet_transmit as I assumed that
>> >> >>> packet->transport->asoc weren't NULL so I tried to access tunneling
>> >> >>> information that I store in packet->transport->asoc->ep->base. In what
>> >> >>> circumstances is asoc NULL in sctp_packet_transmit?
>> >> >>> --
>> >> >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> >> >>> the body of a message to majordomo@vger.kernel.org
>> >> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> >>>
>> >> >>
>> >> >> There may be others, but the case that comes immediately to mind is when you
>> >> >> have an error in the construction of a new association (e.g. a state cookie, or
>> >> >> an abort during setup).  In those cases we call sctp_ootb_pkt_new, which sends a
>> >> >> packet with no assoction associated.
>> >> >>
>> >> >> Neil
>> >> >>
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> >> the body of a message to majordomo@vger.kernel.org
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Fabian Bergmark]

I know there is a draft for CMT. Altrough I'm new to kernel dev I
would be willing to spend time on it if more devs are interested.

Regarding my UDP encaspsulation extension: I think it solves a mayor
issue namely old NAT boxes which prevents SCTP from becoming
widespread. I don't know how it would be integrated as an option in
lksctp. Right now it just encapsulates every packet. I think someone
more initiated would have to take a look at it.

2016-07-22 1:01 GMT+02:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
>
> Em 21-07-2016 16:56, Fabian Bergmark escreveu:
>>
>> I tried using virtual box nat networks but couldn't get it to work. It
>> seemed like the host answered with ICMP port unreachable on the INIT ACK.
>>
>> Regarding multihoming. My setup will be a server with one interface and
>> a client with several. I was hoping to achieve load balancing. Is CMP
>> implemented in lksctp? If not, is there anyone working on that? I read
>
>
> Concurrent Multipath Transfer you mean? No, and not even in the charts that
> I know of.
>
>> that it's recently implemented in BSD. Is failover implemented in lksctp?
>
>
> We are usually a few steps behind BSD regarding SCTP.
>
> Yes, failover is implemented.
>
> Currently, the application may set the primary addr for it and for the peer,
> but not much more than that. (SCTP_PRIMARY_ADDR, SCTP_SET_PEER_PRIMARY_ADDR)
>
> I'm afraid lksctp won't match your goal for load balancing on sctp paths.
>
>>
>> Both interfaces of the client can reach the server IP. I could maybe
>> create a secondary interface for the server and force traffic to that IP
>> on the secondary IF. Is this necessary for failover/CMP to work?
>
>
> As long as both peers have at least 2 IPs to talk to each other, it should
> work fine.
>
> I have noted down to check this situation on having only 1 IP, will check
> when possible. Or maybe Neil or someone else knows better.
>
>>
>>
>> On Jul 21, 2016 19:12, "Marcelo Ricardo Leitner"
>> <marcelo.leitner@gmail.com <mailto:marcelo.leitner@gmail.com>> wrote:
>>
>>     Please don't top post..
>>
>>     On Thu, Jul 21, 2016 at 02:49:56PM +0200, Fabian Bergmark wrote:
>>     > Indeed the issue was solved by using virtual machines. The client no
>>     > longer treats the HEARTBEATS as OOTB.
>>
>>     Ok good.
>>
>>     > My current setup is one VM (the server) which is bridged to my LAN.
>> My
>>     > router is setup to forward all UDP traffic on port 5000 to the VM.
>>     > A second VM (the client) has two bridged interfaces (two tethering
>>     > mobile phones). The client connects to the server via the external
>> IP
>>     > of the router.
>>
>>     Ok. Yet, why don't you do it with 2 VMs, each with 2 NICs on distinct
>>     subnets?
>>
>>     > This works fine. However, I noticed that the client only seems to
>> use
>>     > one interface (probably the one with the lowest metric?). Looking
>>     > trough the debug log
>>     > of the client, it only mentions one IP (the one of the lower metric
>>     > interface). I thought SCTP would use all client interfaces? Is there
>>     > some configuration to achieve
>>
>>     Take a traffic capture and check INIT and INIT_ACK packets, they will
>>     contain which addresses the peer is announced.
>>
>>     > this or doesn't SCTP support multi-homing in this setup?
>>
>>     But yeah, as you are doing it, it looks more like multi-path than
>>     multi-homing and it protects only part of your connection, as there is
>>     some part of the path that is common to both routes. As I'm
>>     understanding, both interfaces on the guest have a default route that
>>     can reach the same IP address of the server.
>>
>>     I couldn't get to a root cause on why but I didn't have much luck with
>>     this setup either. If you manage to have 2 IPs for each peer, it
>> should
>>     work.
>>
>>     >
>>     > 2016-07-20 18:42 GMT+02:00 Marcelo Ricardo Leitner
>>     <marcelo.leitner@gmail.com <mailto:marcelo.leitner@gmail.com>>:
>>
>>     > > On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
>>     > >> I'm now working on support for multi-homing. I noticed that
>>     when the
>>     > >> client has multiple interfaces, the client would treat the
>>     HEARTBEAT
>>     > >> sent by the server as ootb and abort. When I tried to compare
>>     to the
>>     > >> vanilla SCTP version I saw the same behavior.
>>     > >> My setup is a laptop with two network interfaces (192.168.2.64,
>>     > >> 192.168.2.168) acting as the client, a router (192.168.2.1) that
>>     > >> forwards protocol 132 to my stationary. My stationary has one
>>     > >> interface (192.168.2.9). The client connects on the routers
>>     external
>>     > >> IP (178.16.218.41)
>>     > >
>>     > > First of all, such setup requires some other adjustments on ip
>>     > > routes/rules/arp sysctl so you can actually use the two
>>     interfaces on
>>     > > the same subnet, otherwise Linux will end up issuing packets
>>     with src
>>     > > 192.168.2.64 on the interface with 192.168.2.168, or vice-versa.
>>     Same
>>     > > thing will happen on input, as it will reply ARP request on the
>>     first
>>     > > interface to receive the ARP request.
>>     > >
>>     > > I'd recommend you to switch to a true multi-homed situation,
>>     it's easier
>>     > > to get right and more alike to real world situations.
>>     > >
>>     > > You may even use netns for this, or virtual machines. Both would
>>     work.
>>     > >
>>     > >> Server log: http://pastebin.com/FE667m6t
>>     > >> Clientl log: http://pastebin.com/vu2YYkWJ
>>     > >>
>>     > >> Is this a bug, and if so, is it fixed in a recent commit? Both
>>     > >> computers are running recent kernels (client 4.5.4-1 and server
>>     > >> 4.6.3-1)
>>     > >
>>     > > The heartbeat was sent using 192.168.2.9 addr and not the
>>     external IP.
>>     > > Was this address negotiated on INIT handshake? It's the first
>>     hit of it
>>     > > on client log. If you don't bind the socket to a single IP
>>     address, it
>>     > > will use all addresses available on the host.
>>     > >
>>     > > Note that, if you are binding the socket to specific interfaces,
>>     what I
>>     > > mentioned in the beginning may also be affecting it, as
>>     sctp_rcv() will
>>     > > enforce that the packet came in through the right interface.
>>     > >
>>     > >   Marcelo
>>     > >
>>     > >>
>>     > >> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark
>>     <fabian.bergmark@gmail.com <mailto:fabian.bergmark@gmail.com>>:
>>     > >> > Thanks. I solved the issue by having a per-transport tunnel.
>>     > >> >
>>     > >> > The code can be found here:
>>     > >> >
>>
>> https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
>>     > >> >
>>     > >> > As this is the first time i write kernel code, I would really
>>     > >> > appreciate if someone looked at it.
>>     > >> > The encapsulation seems to work fine (inspected in
>>     wireshark), but I'm
>>     > >> > not sure if I close/free everything correctly.
>>     > >> >
>>     > >> > 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com
>>     <mailto:nhorman@tuxdriver.com>>:
>>     > >> >> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark
>> wrote:
>>     > >> >>> I'm adding experimental support for UDP encapsulation of
>>     SCTP packets.
>>     > >> >>> I got most of if working well. However, I noticed a NULL
>>     pointer
>>     > >> >>> dereference in sctp_packet_transmit as I assumed that
>>     > >> >>> packet->transport->asoc weren't NULL so I tried to access
>>     tunneling
>>     > >> >>> information that I store in
>>     packet->transport->asoc->ep->base. In what
>>     > >> >>> circumstances is asoc NULL in sctp_packet_transmit?
>>     > >> >>> --
>>     > >> >>> To unsubscribe from this list: send the line "unsubscribe
>>     linux-sctp" in
>>     > >> >>> the body of a message to majordomo@vger.kernel.org
>>     <mailto:majordomo@vger.kernel.org>
>>     > >> >>> More majordomo info at
>>     http://vger.kernel.org/majordomo-info.html
>>     > >> >>>
>>     > >> >>
>>     > >> >> There may be others, but the case that comes immediately to
>>     mind is when you
>>     > >> >> have an error in the construction of a new association (e.g.
>>     a state cookie, or
>>     > >> >> an abort during setup).  In those cases we call
>>     sctp_ootb_pkt_new, which sends a
>>     > >> >> packet with no assoction associated.
>>     > >> >>
>>     > >> >> Neil
>>     > >> >>
>>     > >> --
>>     > >> To unsubscribe from this list: send the line "unsubscribe
>>     linux-sctp" in
>>     > >> the body of a message to majordomo@vger.kernel.org
>>     <mailto:majordomo@vger.kernel.org>
>>     > >> More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>>     > >>
>>     > --
>>     > To unsubscribe from this list: send the line "unsubscribe
>>     linux-sctp" in
>>     > the body of a message to majordomo@vger.kernel.org
>>     <mailto:majordomo@vger.kernel.org>
>>     > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>     >
>>
>

Re: packet->transport->asoc = NULL in sctp_packet_transmit

[Michael Tuexen]

> On 24 Jul 2016, at 09:00, Fabian Bergmark <fabian.bergmark@gmail.com> wrote:
> 
> I know there is a draft for CMT. Altrough I'm new to kernel dev I
> would be willing to spend time on it if more devs are interested.
> 
> Regarding my UDP encaspsulation extension: I think it solves a mayor
> issue namely old NAT boxes which prevents SCTP from becoming
> widespread. I don't know how it would be integrated as an option in
> lksctp. Right now it just encapsulates every packet. I think someone
> more
> initiated would have to take a look at it.
Regarding UDP encapsulation, you can take a look at:
* https://tools.ietf.org/html/rfc6951
* https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-udp-encaps-cons-00
It also describes how to control this via the socket API.

Best regards
Michael
> 
> 2016-07-22 1:01 GMT+02:00 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>:
>> 
>> Em 21-07-2016 16:56, Fabian Bergmark escreveu:
>>> 
>>> I tried using virtual box nat networks but couldn't get it to work. It
>>> seemed like the host answered with ICMP port unreachable on the INIT ACK.
>>> 
>>> Regarding multihoming. My setup will be a server with one interface and
>>> a client with several. I was hoping to achieve load balancing. Is CMP
>>> implemented in lksctp? If not, is there anyone working on that? I read
>> 
>> 
>> Concurrent Multipath Transfer you mean? No, and not even in the charts that
>> I know of.
>> 
>>> that it's recently implemented in BSD. Is failover implemented in lksctp?
>> 
>> 
>> We are usually a few steps behind BSD regarding SCTP.
>> 
>> Yes, failover is implemented.
>> 
>> Currently, the application may set the primary addr for it and for the peer,
>> but not much more than that. (SCTP_PRIMARY_ADDR, SCTP_SET_PEER_PRIMARY_ADDR)
>> 
>> I'm afraid lksctp won't match your goal for load balancing on sctp paths.
>> 
>>> 
>>> Both interfaces of the client can reach the server IP. I could maybe
>>> create a secondary interface for the server and force traffic to that IP
>>> on the secondary IF. Is this necessary for failover/CMP to work?
>> 
>> 
>> As long as both peers have at least 2 IPs to talk to each other, it should
>> work fine.
>> 
>> I have noted down to check this situation on having only 1 IP, will check
>> when possible. Or maybe Neil or someone else knows better.
>> 
>>> 
>>> 
>>> On Jul 21, 2016 19:12, "Marcelo Ricardo Leitner"
>>> <marcelo.leitner@gmail.com <mailto:marcelo.leitner@gmail.com>> wrote:
>>> 
>>>    Please don't top post..
>>> 
>>>    On Thu, Jul 21, 2016 at 02:49:56PM +0200, Fabian Bergmark wrote:
>>>> Indeed the issue was solved by using virtual machines. The client no
>>>> longer treats the HEARTBEATS as OOTB.
>>> 
>>>    Ok good.
>>> 
>>>> My current setup is one VM (the server) which is bridged to my LAN.
>>> My
>>>> router is setup to forward all UDP traffic on port 5000 to the VM.
>>>> A second VM (the client) has two bridged interfaces (two tethering
>>>> mobile phones). The client connects to the server via the external
>>> IP
>>>> of the router.
>>> 
>>>    Ok. Yet, why don't you do it with 2 VMs, each with 2 NICs on distinct
>>>    subnets?
>>> 
>>>> This works fine. However, I noticed that the client only seems to
>>> use
>>>> one interface (probably the one with the lowest metric?). Looking
>>>> trough the debug log
>>>> of the client, it only mentions one IP (the one of the lower metric
>>>> interface). I thought SCTP would use all client interfaces? Is there
>>>> some configuration to achieve
>>> 
>>>    Take a traffic capture and check INIT and INIT_ACK packets, they will
>>>    contain which addresses the peer is announced.
>>> 
>>>> this or doesn't SCTP support multi-homing in this setup?
>>> 
>>>    But yeah, as you are doing it, it looks more like multi-path than
>>>    multi-homing and it protects only part of your connection, as there is
>>>    some part of the path that is common to both routes. As I'm
>>>    understanding, both interfaces on the guest have a default route that
>>>    can reach the same IP address of the server.
>>> 
>>>    I couldn't get to a root cause on why but I didn't have much luck with
>>>    this setup either. If you manage to have 2 IPs for each peer, it
>>> should
>>>    work.
>>> 
>>>> 
>>>> 2016-07-20 18:42 GMT+02:00 Marcelo Ricardo Leitner
>>>    <marcelo.leitner@gmail.com <mailto:marcelo.leitner@gmail.com>>:
>>> 
>>>>> On Wed, Jul 20, 2016 at 05:30:15PM +0200, Fabian Bergmark wrote:
>>>>>> I'm now working on support for multi-homing. I noticed that
>>>    when the
>>>>>> client has multiple interfaces, the client would treat the
>>>    HEARTBEAT
>>>>>> sent by the server as ootb and abort. When I tried to compare
>>>    to the
>>>>>> vanilla SCTP version I saw the same behavior.
>>>>>> My setup is a laptop with two network interfaces (192.168.2.64,
>>>>>> 192.168.2.168) acting as the client, a router (192.168.2.1) that
>>>>>> forwards protocol 132 to my stationary. My stationary has one
>>>>>> interface (192.168.2.9). The client connects on the routers
>>>    external
>>>>>> IP (178.16.218.41)
>>>>> 
>>>>> First of all, such setup requires some other adjustments on ip
>>>>> routes/rules/arp sysctl so you can actually use the two
>>>    interfaces on
>>>>> the same subnet, otherwise Linux will end up issuing packets
>>>    with src
>>>>> 192.168.2.64 on the interface with 192.168.2.168, or vice-versa.
>>>    Same
>>>>> thing will happen on input, as it will reply ARP request on the
>>>    first
>>>>> interface to receive the ARP request.
>>>>> 
>>>>> I'd recommend you to switch to a true multi-homed situation,
>>>    it's easier
>>>>> to get right and more alike to real world situations.
>>>>> 
>>>>> You may even use netns for this, or virtual machines. Both would
>>>    work.
>>>>> 
>>>>>> Server log: http://pastebin.com/FE667m6t
>>>>>> Clientl log: http://pastebin.com/vu2YYkWJ
>>>>>> 
>>>>>> Is this a bug, and if so, is it fixed in a recent commit? Both
>>>>>> computers are running recent kernels (client 4.5.4-1 and server
>>>>>> 4.6.3-1)
>>>>> 
>>>>> The heartbeat was sent using 192.168.2.9 addr and not the
>>>    external IP.
>>>>> Was this address negotiated on INIT handshake? It's the first
>>>    hit of it
>>>>> on client log. If you don't bind the socket to a single IP
>>>    address, it
>>>>> will use all addresses available on the host.
>>>>> 
>>>>> Note that, if you are binding the socket to specific interfaces,
>>>    what I
>>>>> mentioned in the beginning may also be affecting it, as
>>>    sctp_rcv() will
>>>>> enforce that the packet came in through the right interface.
>>>>> 
>>>>>  Marcelo
>>>>> 
>>>>>> 
>>>>>> 2016-07-19 16:42 GMT+02:00 Fabian Bergmark
>>>    <fabian.bergmark@gmail.com <mailto:fabian.bergmark@gmail.com>>:
>>>>>>> Thanks. I solved the issue by having a per-transport tunnel.
>>>>>>> 
>>>>>>> The code can be found here:
>>>>>>> 
>>> 
>>> https://github.com/fabianbergmark/linux-sctp/tree/v4.6-sctp-over-udp/net/sctp
>>>>>>> 
>>>>>>> As this is the first time i write kernel code, I would really
>>>>>>> appreciate if someone looked at it.
>>>>>>> The encapsulation seems to work fine (inspected in
>>>    wireshark), but I'm
>>>>>>> not sure if I close/free everything correctly.
>>>>>>> 
>>>>>>> 2016-07-19 14:31 GMT+02:00 Neil Horman <nhorman@tuxdriver.com
>>>    <mailto:nhorman@tuxdriver.com>>:
>>>>>>>> On Tue, Jul 19, 2016 at 12:15:47PM +0200, Fabian Bergmark
>>> wrote:
>>>>>>>>> I'm adding experimental support for UDP encapsulation of
>>>    SCTP packets.
>>>>>>>>> I got most of if working well. However, I noticed a NULL
>>>    pointer
>>>>>>>>> dereference in sctp_packet_transmit as I assumed that
>>>>>>>>> packet->transport->asoc weren't NULL so I tried to access
>>>    tunneling
>>>>>>>>> information that I store in
>>>    packet->transport->asoc->ep->base. In what
>>>>>>>>> circumstances is asoc NULL in sctp_packet_transmit?
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>    linux-sctp" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>    <mailto:majordomo@vger.kernel.org>
>>>>>>>>> More majordomo info at
>>>    http://vger.kernel.org/majordomo-info.html
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> There may be others, but the case that comes immediately to
>>>    mind is when you
>>>>>>>> have an error in the construction of a new association (e.g.
>>>    a state cookie, or
>>>>>>>> an abort during setup).  In those cases we call
>>>    sctp_ootb_pkt_new, which sends a
>>>>>>>> packet with no assoction associated.
>>>>>>>> 
>>>>>>>> Neil
>>>>>>>> 
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>    linux-sctp" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>    <mailto:majordomo@vger.kernel.org>
>>>>>> More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
>>>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>    linux-sctp" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>    <mailto:majordomo@vger.kernel.org>
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> 
>>> 
>> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html