linux-kernel - RE: Problem on SCTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB025A97E@AcuExch.aculab.com>
Date:   Mon, 9 Jan 2017 09:51:47 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Sun Paul' <paulrbk@...il.com>, Neil Horman <nhorman@...driver.com>
CC:     "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: Problem on SCTP

From: Sun Paul
> Sent: 09 January 2017 02:08

> >> I am setting up a lab where the SCTP traffics from  client is passing
> >> through a linux router before reaching to the SCTP server running
> >> LKSCTP.
> >>
> >> The linux router did not change the source address of the client, so
> >> when it arrived to the SCTP server, the source address is the oriingal
> >> one.
>
> the INIT chunk arrive on the SERVER, but then no response. the
> application that using in SERVER is the same as the other test.
> 
> I noticed one thing in Ethernet frame of the incoming packet on the
> SERVER compared to the one captured from the client is the LG bit on
> the source address.
> 
> The LG bit is set to 0 on the request packet received in the
> SERVER,but it is 0 from the one originated on the client. willl it be
> the root cause?

Which addresses are you talking about, and what do you mean by the LG bit?

Is your linux 'router' just routing (ie IP forwarding) or is it doing NAT?
If it is changing the IP addresses then the addresses inside some SCTP
chunks also need changing.

	David