[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4163FC71-3A20-4484-8CDC-FA22D4FA72CF@lurchi.franken.de>
Date: Thu, 12 Jan 2017 11:53:17 +0100
From: Michael Tuexen <Michael.Tuexen@...chi.franken.de>
To: David Laight <David.Laight@...LAB.COM>
Cc: Sun Paul <paulrbk@...il.com>, Neil Horman <nhorman@...driver.com>,
"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
> On 12 Jan 2017, at 10:51, David Laight <David.Laight@...LAB.COM> wrote:
>
> From: Sun Paul [mailto:paulrbk@...il.com]
>> Sent: 12 January 2017 09:31
>> Let me clear the understanding. below is the flow.
>>
>> 1. Client sends to Linux Router: 192.168.206.83 -> 192.168.206.56,
>> 2. Linux router sends to SERVER where the source IP is unchanged:
>> 192.168.206.83 -> 192.168.206.66
>>
>> My question here is why SERVER cannot response this INIT chunk?
>
> Probably because the IP addresses embedded in the SCTP packet
> don't match the ones in the IP header.
I don't know if it matters on the linux implementation, but it shouldn't.
An SCTP endpoint should consider the source address of the packet containing
the INIT chunk and all the addresses listed in the INIT chunk as valid peer
addresses.
Could we get a .pcap file of the packet containing the INIT chunk captured
at the server? I would expect an INIT-ACK or and ABORT. If that is not sent,
the checksum was wrong or some kind of packet filtering is active on the
server...
Best regards
Michael
>
> David
>
> N§ēæėrļyúčØbēXŽķĮ§vØ^)Þš{.nĮ+·Ĩ{ąąËi{ayš.ĘÚë,j.ĒfĢĒ·hāzđ.ŪwĨĒļ.Ē·Ķj:+vĻwčjØmķĸū.ŦęįzZ+ųÝĒj"ú!
Powered by blists - more mailing lists