> On 24 Jul 2016, at 09:00, Fabian Bergmark <fabian.bergmark@xxxxxxxxx> 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@xxxxxxxxx>: >> >> 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@xxxxxxxxx <mailto:marcelo.leitner@xxxxxxxxx>> 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@xxxxxxxxx <mailto:marcelo.leitner@xxxxxxxxx>>: >>> >>>>> 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@xxxxxxxxx <mailto:fabian.bergmark@xxxxxxxxx>>: >>>>>>> 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@xxxxxxxxxxxxx >>> <mailto:nhorman@xxxxxxxxxxxxx>>: >>>>>>>> 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@xxxxxxxxxxxxxxx >>> <mailto:majordomo@xxxxxxxxxxxxxxx> >>>>>>>>> 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@xxxxxxxxxxxxxxx >>> <mailto:majordomo@xxxxxxxxxxxxxxx> >>>>>> 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@xxxxxxxxxxxxxxx >>> <mailto:majordomo@xxxxxxxxxxxxxxx> >>>> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
