* Problem on SCTP
@ 2017-01-06 9:34 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-06 9:34 UTC (permalink / raw)
To: linux-sctp, linux-kernel
Hi
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.
however, I found that there is no response from the SCTP server, any
idea on this?
if I connect the client directly to the SCTP server, it do not have any issue.
help pls
rbk
^ permalink raw reply [flat|nested] 75+ messages in thread
* Problem on SCTP
@ 2017-01-06 9:34 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-06 9:34 UTC (permalink / raw)
To: linux-sctp, linux-kernel
Hi
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.
however, I found that there is no response from the SCTP server, any
idea on this?
if I connect the client directly to the SCTP server, it do not have any issue.
help pls
rbk
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-06 9:34 ` Sun Paul
@ 2017-01-06 11:43 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 75+ messages in thread
From: Marcelo Ricardo Leitner @ 2017-01-06 11:43 UTC (permalink / raw)
To: Sun Paul; +Cc: linux-sctp, linux-kernel
Hi,
On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
> Hi
>
> 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.
>
> however, I found that there is no response from the SCTP server, any
> idea on this?
>
> if I connect the client directly to the SCTP server, it do not have any issue.
This seems to be a routing issue then, specially if you're using
rp_filter. Make sure the server can reach that foreign address the
client uses.
Marcelo
>
> help pls
>
> rbk
> --
> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-06 11:43 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 75+ messages in thread
From: Marcelo Ricardo Leitner @ 2017-01-06 11:43 UTC (permalink / raw)
To: Sun Paul; +Cc: linux-sctp, linux-kernel
Hi,
On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
> Hi
>
> 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.
>
> however, I found that there is no response from the SCTP server, any
> idea on this?
>
> if I connect the client directly to the SCTP server, it do not have any issue.
This seems to be a routing issue then, specially if you're using
rp_filter. Make sure the server can reach that foreign address the
client uses.
Marcelo
>
> help pls
>
> rbk
> --
> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-06 9:34 ` Sun Paul
@ 2017-01-06 12:37 ` Neil Horman
-1 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-06 12:37 UTC (permalink / raw)
To: Sun Paul; +Cc: linux-sctp, linux-kernel
On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
> Hi
>
> 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.
>
> however, I found that there is no response from the SCTP server, any
> idea on this?
>
> if I connect the client directly to the SCTP server, it do not have any issue.
>
> help pls
>
> rbk
> --
> 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
>
Start with a tcpdump on the client and the server and attempt a connection,
check to see if the INIT and INIT-ACK chunks are arriving appropriately.
Neil
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-06 12:37 ` Neil Horman
0 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-06 12:37 UTC (permalink / raw)
To: Sun Paul; +Cc: linux-sctp, linux-kernel
On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
> Hi
>
> 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.
>
> however, I found that there is no response from the SCTP server, any
> idea on this?
>
> if I connect the client directly to the SCTP server, it do not have any issue.
>
> help pls
>
> rbk
> --
> 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
>
Start with a tcpdump on the client and the server and attempt a connection,
check to see if the INIT and INIT-ACK chunks are arriving appropriately.
Neil
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-06 11:43 ` Marcelo Ricardo Leitner
@ 2017-01-09 2:06 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 2:06 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: linux-sctp, linux-kernel
Hi
I actually have set the rp_filter to 2 already but still the same.
On Fri, Jan 6, 2017 at 7:43 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi,
>
> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>> Hi
>>
>> 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.
>>
>> however, I found that there is no response from the SCTP server, any
>> idea on this?
>>
>> if I connect the client directly to the SCTP server, it do not have any issue.
>
> This seems to be a routing issue then, specially if you're using
> rp_filter. Make sure the server can reach that foreign address the
> client uses.
>
> Marcelo
>
>>
>> help pls
>>
>> rbk
>> --
>> 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
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 2:06 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 2:06 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: linux-sctp, linux-kernel
Hi
I actually have set the rp_filter to 2 already but still the same.
On Fri, Jan 6, 2017 at 7:43 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi,
>
> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>> Hi
>>
>> 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.
>>
>> however, I found that there is no response from the SCTP server, any
>> idea on this?
>>
>> if I connect the client directly to the SCTP server, it do not have any issue.
>
> This seems to be a routing issue then, specially if you're using
> rp_filter. Make sure the server can reach that foreign address the
> client uses.
>
> Marcelo
>
>>
>> help pls
>>
>> rbk
>> --
>> 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
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-06 12:37 ` Neil Horman
@ 2017-01-09 2:08 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 2:08 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, linux-kernel
Hi
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?
On Fri, Jan 6, 2017 at 8:37 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>> Hi
>>
>> 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.
>>
>> however, I found that there is no response from the SCTP server, any
>> idea on this?
>>
>> if I connect the client directly to the SCTP server, it do not have any issue.
>>
>> help pls
>>
>> rbk
>> --
>> 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
>>
>
> Start with a tcpdump on the client and the server and attempt a connection,
> check to see if the INIT and INIT-ACK chunks are arriving appropriately.
>
> Neil
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 2:08 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 2:08 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, linux-kernel
Hi
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?
On Fri, Jan 6, 2017 at 8:37 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>> Hi
>>
>> 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.
>>
>> however, I found that there is no response from the SCTP server, any
>> idea on this?
>>
>> if I connect the client directly to the SCTP server, it do not have any issue.
>>
>> help pls
>>
>> rbk
>> --
>> 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
>>
>
> Start with a tcpdump on the client and the server and attempt a connection,
> check to see if the INIT and INIT-ACK chunks are arriving appropriately.
>
> Neil
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-09 2:08 ` Sun Paul
@ 2017-01-09 2:30 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 2:30 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, linux-kernel
OK. I actually verified the connectivity using SSH to port 22. it
works. so I do not have any idea why it has problem on SCTP.
need more help on this. is there anyway to enable debug? the version
that I am using is lksctp-tools-1.0.10-7
On Mon, Jan 9, 2017 at 10:08 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi
>
> 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?
>
>
>
> On Fri, Jan 6, 2017 at 8:37 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>>> Hi
>>>
>>> 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.
>>>
>>> however, I found that there is no response from the SCTP server, any
>>> idea on this?
>>>
>>> if I connect the client directly to the SCTP server, it do not have any issue.
>>>
>>> help pls
>>>
>>> rbk
>>> --
>>> 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
>>>
>>
>> Start with a tcpdump on the client and the server and attempt a connection,
>> check to see if the INIT and INIT-ACK chunks are arriving appropriately.
>>
>> Neil
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 2:30 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 2:30 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, linux-kernel
OK. I actually verified the connectivity using SSH to port 22. it
works. so I do not have any idea why it has problem on SCTP.
need more help on this. is there anyway to enable debug? the version
that I am using is lksctp-tools-1.0.10-7
On Mon, Jan 9, 2017 at 10:08 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi
>
> 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?
>
>
>
> On Fri, Jan 6, 2017 at 8:37 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>>> Hi
>>>
>>> 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.
>>>
>>> however, I found that there is no response from the SCTP server, any
>>> idea on this?
>>>
>>> if I connect the client directly to the SCTP server, it do not have any issue.
>>>
>>> help pls
>>>
>>> rbk
>>> --
>>> 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
>>>
>>
>> Start with a tcpdump on the client and the server and attempt a connection,
>> check to see if the INIT and INIT-ACK chunks are arriving appropriately.
>>
>> Neil
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: Problem on SCTP
2017-01-09 2:08 ` Sun Paul
@ 2017-01-09 9:51 ` David Laight
-1 siblings, 0 replies; 75+ messages in thread
From: David Laight @ 2017-01-09 9:51 UTC (permalink / raw)
To: 'Sun Paul', Neil Horman; +Cc: linux-sctp, linux-kernel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: Problem on SCTP
@ 2017-01-09 9:51 ` David Laight
0 siblings, 0 replies; 75+ messages in thread
From: David Laight @ 2017-01-09 9:51 UTC (permalink / raw)
To: 'Sun Paul', Neil Horman; +Cc: linux-sctp, linux-kernel
RnJvbTogU3VuIFBhdWwNCj4gU2VudDogMDkgSmFudWFyeSAyMDE3IDAyOjA4DQoNCj4gPj4gSSBh
bSBzZXR0aW5nIHVwIGEgbGFiIHdoZXJlIHRoZSBTQ1RQIHRyYWZmaWNzIGZyb20gIGNsaWVudCBp
cyBwYXNzaW5nDQo+ID4+IHRocm91Z2ggYSBsaW51eCByb3V0ZXIgYmVmb3JlIHJlYWNoaW5nIHRv
IHRoZSBTQ1RQIHNlcnZlciBydW5uaW5nDQo+ID4+IExLU0NUUC4NCj4gPj4NCj4gPj4gVGhlIGxp
bnV4IHJvdXRlciBkaWQgbm90IGNoYW5nZSB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIGNsaWVu
dCwgc28NCj4gPj4gd2hlbiBpdCBhcnJpdmVkIHRvIHRoZSBTQ1RQIHNlcnZlciwgdGhlIHNvdXJj
ZSBhZGRyZXNzIGlzIHRoZSBvcmlpbmdhbA0KPiA+PiBvbmUuDQo+DQo+IHRoZSBJTklUIGNodW5r
IGFycml2ZSBvbiB0aGUgU0VSVkVSLCBidXQgdGhlbiBubyByZXNwb25zZS4gdGhlDQo+IGFwcGxp
Y2F0aW9uIHRoYXQgdXNpbmcgaW4gU0VSVkVSIGlzIHRoZSBzYW1lIGFzIHRoZSBvdGhlciB0ZXN0
Lg0KPiANCj4gSSBub3RpY2VkIG9uZSB0aGluZyBpbiBFdGhlcm5ldCBmcmFtZSBvZiB0aGUgaW5j
b21pbmcgcGFja2V0IG9uIHRoZQ0KPiBTRVJWRVIgY29tcGFyZWQgdG8gdGhlIG9uZSBjYXB0dXJl
ZCBmcm9tIHRoZSBjbGllbnQgaXMgdGhlIExHIGJpdCBvbg0KPiB0aGUgc291cmNlIGFkZHJlc3Mu
DQo+IA0KPiBUaGUgTEcgYml0IGlzIHNldCB0byAwIG9uIHRoZSByZXF1ZXN0IHBhY2tldCByZWNl
aXZlZCBpbiB0aGUNCj4gU0VSVkVSLGJ1dCBpdCBpcyAwIGZyb20gdGhlIG9uZSBvcmlnaW5hdGVk
IG9uIHRoZSBjbGllbnQuIHdpbGxsIGl0IGJlDQo+IHRoZSByb290IGNhdXNlPw0KDQpXaGljaCBh
ZGRyZXNzZXMgYXJlIHlvdSB0YWxraW5nIGFib3V0LCBhbmQgd2hhdCBkbyB5b3UgbWVhbiBieSB0
aGUgTEcgYml0Pw0KDQpJcyB5b3VyIGxpbnV4ICdyb3V0ZXInIGp1c3Qgcm91dGluZyAoaWUgSVAg
Zm9yd2FyZGluZykgb3IgaXMgaXQgZG9pbmcgTkFUPw0KSWYgaXQgaXMgY2hhbmdpbmcgdGhlIElQ
IGFkZHJlc3NlcyB0aGVuIHRoZSBhZGRyZXNzZXMgaW5zaWRlIHNvbWUgU0NUUA0KY2h1bmtzIGFs
c28gbmVlZCBjaGFuZ2luZy4NCg0KCURhdmlkDQoNCg=
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-09 9:51 ` David Laight
@ 2017-01-09 10:00 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 10:00 UTC (permalink / raw)
To: David Laight; +Cc: Neil Horman, linux-sctp, linux-kernel
Hi
the linux router just change the destination, so it can arrive on the
the SERVER.
On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 10:00 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 10:00 UTC (permalink / raw)
To: David Laight; +Cc: Neil Horman, linux-sctp, linux-kernel
Hi
the linux router just change the destination, so it can arrive on the
the SERVER.
On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-09 10:00 ` Sun Paul
@ 2017-01-09 12:25 ` Neil Horman
-1 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-09 12:25 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> Hi
>
> the linux router just change the destination, so it can arrive on the
> the SERVER.
>
Please post the relevant snippets from the client and server tcpdump
operations
Neil
> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> > 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
> >
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 12:25 ` Neil Horman
0 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-09 12:25 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> Hi
>
> the linux router just change the destination, so it can arrive on the
> the SERVER.
>
Please post the relevant snippets from the client and server tcpdump
operations
Neil
> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> > 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
> >
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-09 12:25 ` Neil Horman
@ 2017-01-09 16:31 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 16:31 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
what kind of information do you need? the whole INIT packet?
On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> Hi
>>
>> the linux router just change the destination, so it can arrive on the
>> the SERVER.
>>
> Please post the relevant snippets from the client and server tcpdump
> operations
>
> Neil
>
>> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> > 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
>> >
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 16:31 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-09 16:31 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
what kind of information do you need? the whole INIT packet?
On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> Hi
>>
>> the linux router just change the destination, so it can arrive on the
>> the SERVER.
>>
> Please post the relevant snippets from the client and server tcpdump
> operations
>
> Neil
>
>> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> > 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
>> >
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-09 16:31 ` Sun Paul
@ 2017-01-09 19:18 ` Neil Horman
-1 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-09 19:18 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
> what kind of information do you need? the whole INIT packet?
>
That would be ideal.
> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> >> Hi
> >>
> >> the linux router just change the destination, so it can arrive on the
> >> the SERVER.
> >>
> > Please post the relevant snippets from the client and server tcpdump
> > operations
> >
> > Neil
> >
> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> >> > 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
> >> >
> >>
> --
> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-09 19:18 ` Neil Horman
0 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-09 19:18 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
> what kind of information do you need? the whole INIT packet?
>
That would be ideal.
> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> >> Hi
> >>
> >> the linux router just change the destination, so it can arrive on the
> >> the SERVER.
> >>
> > Please post the relevant snippets from the client and server tcpdump
> > operations
> >
> > Neil
> >
> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> >> > 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
> >> >
> >>
> --
> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-09 19:18 ` Neil Horman
@ 2017-01-10 1:30 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-10 1:30 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
Packet received (From client)
======================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
1 2017-01-06 08:52:49.662142 192.168.206.83 50001
192.168.206.65 SCTP 3868 98 INIT
CS0
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662142000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
Vmware_81:41:6b (00:50:56:81:41:6b)
Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: RealtekU_54:81:87 (52:54:00:54:81:87)
Address: RealtekU_54:81:87 (52:54:00:54:81:87)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: SCTP (132)
Header checksum: 0x1c3e [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.65
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xbaea49e5 (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>> what kind of information do you need? the whole INIT packet?
>>
> That would be ideal.
>
>> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> >> Hi
>> >>
>> >> the linux router just change the destination, so it can arrive on the
>> >> the SERVER.
>> >>
>> > Please post the relevant snippets from the client and server tcpdump
>> > operations
>> >
>> > Neil
>> >
>> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> >> > 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
>> >> >
>> >>
>> --
>> 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
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-10 1:30 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-10 1:30 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
Packet received (From client)
===========
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
1 2017-01-06 08:52:49.662142 192.168.206.83 50001
192.168.206.65 SCTP 3868 98 INIT
CS0
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662142000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
Vmware_81:41:6b (00:50:56:81:41:6b)
Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: RealtekU_54:81:87 (52:54:00:54:81:87)
Address: RealtekU_54:81:87 (52:54:00:54:81:87)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: SCTP (132)
Header checksum: 0x1c3e [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.65
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xbaea49e5 (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>> what kind of information do you need? the whole INIT packet?
>>
> That would be ideal.
>
>> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> >> Hi
>> >>
>> >> the linux router just change the destination, so it can arrive on the
>> >> the SERVER.
>> >>
>> > Please post the relevant snippets from the client and server tcpdump
>> > operations
>> >
>> > Neil
>> >
>> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> >> > 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
>> >> >
>> >>
>> --
>> 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
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-10 1:30 ` Sun Paul
@ 2017-01-10 1:31 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-10 1:31 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
Packet to SERVER
================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
2 2017-01-06 08:52:49.662321 192.168.206.83 50001
192.168.206.66 SCTP 3868 98 INIT
CS0
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Tue, Jan 10, 2017 at 9:30 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Packet received (From client)
> ======================
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
>
> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>>> what kind of information do you need? the whole INIT packet?
>>>
>> That would be ideal.
>>
>>> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>>> >> Hi
>>> >>
>>> >> the linux router just change the destination, so it can arrive on the
>>> >> the SERVER.
>>> >>
>>> > Please post the relevant snippets from the client and server tcpdump
>>> > operations
>>> >
>>> > Neil
>>> >
>>> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>>> >> > 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
>>> >> >
>>> >>
>>> --
>>> 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
>>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-10 1:31 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-10 1:31 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
Packet to SERVER
========
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
2 2017-01-06 08:52:49.662321 192.168.206.83 50001
192.168.206.66 SCTP 3868 98 INIT
CS0
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Tue, Jan 10, 2017 at 9:30 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Packet received (From client)
> ===========
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
>
> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>>> what kind of information do you need? the whole INIT packet?
>>>
>> That would be ideal.
>>
>>> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>>> >> Hi
>>> >>
>>> >> the linux router just change the destination, so it can arrive on the
>>> >> the SERVER.
>>> >>
>>> > Please post the relevant snippets from the client and server tcpdump
>>> > operations
>>> >
>>> > Neil
>>> >
>>> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>>> >> > 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
>>> >> >
>>> >>
>>> --
>>> 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
>>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-10 1:30 ` Sun Paul
@ 2017-01-10 14:33 ` Neil Horman
-1 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-10 14:33 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
> Packet received (From client)
> ======================
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
>
> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
> >> what kind of information do you need? the whole INIT packet?
> >>
> > That would be ideal.
> >
> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> >> >> Hi
> >> >>
> >> >> the linux router just change the destination, so it can arrive on the
> >> >> the SERVER.
> >> >>
> >> > Please post the relevant snippets from the client and server tcpdump
> >> > operations
> >> >
> >> > Neil
> >> >
> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> >> >> > 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
> >> >> >
> >> >>
> >> --
> >> 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
>
It looks like you have some destination NAT-ing going on in these packets. In
one trace your destination address is 192.168.206.65, and in the other its
192.168.206.66.
Neil
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-10 14:33 ` Neil Horman
0 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-10 14:33 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
> Packet received (From client)
> ===========
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
>
> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
> >> what kind of information do you need? the whole INIT packet?
> >>
> > That would be ideal.
> >
> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> >> >> Hi
> >> >>
> >> >> the linux router just change the destination, so it can arrive on the
> >> >> the SERVER.
> >> >>
> >> > Please post the relevant snippets from the client and server tcpdump
> >> > operations
> >> >
> >> > Neil
> >> >
> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> >> >> > 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
> >> >> >
> >> >>
> >> --
> >> 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
>
It looks like you have some destination NAT-ing going on in these packets. In
one trace your destination address is 192.168.206.65, and in the other its
192.168.206.66.
Neil
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-10 14:33 ` Neil Horman
@ 2017-01-11 8:39 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-11 8:39 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
yes. whenever the INIT packet send to 192.168.206.65, it will forward
to 192.168.206.66. My question is when this packet arrive to
192.168.206.66, why LKSCTP never pass to user level.
On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
>> Packet received (From client)
>> ======================
>>
>> No. Time Source SPort
>> Destination Protocol DPort Length Info
>> DSCP
>> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
>> 192.168.206.65 SCTP 3868 98 INIT
>> CS0
>>
>> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>> Encapsulation type: Ethernet (1)
>> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
>> [Time shift for this packet: 0.000000000 seconds]
>> Epoch Time: 1483692769.662142000 seconds
>> [Time delta from previous captured frame: 0.000000000 seconds]
>> [Time delta from previous displayed frame: 0.000000000 seconds]
>> [Time since reference or first frame: 0.000000000 seconds]
>> Frame Number: 1
>> Frame Length: 98 bytes (784 bits)
>> Capture Length: 98 bytes (784 bits)
>> [Frame is marked: False]
>> [Frame is ignored: False]
>> [Protocols in frame: eth:ethertype:ip:sctp]
>> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
>> Vmware_81:41:6b (00:50:56:81:41:6b)
>> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>> .... ..0. .... .... .... .... = LG bit: Globally unique
>> address (factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
>> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
>> .... ..1. .... .... .... .... = LG bit: Locally administered
>> address (this is NOT the factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Type: IPv4 (0x0800)
>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
>> 0100 .... = Version: 4
>> .... 0101 = Header Length: 20 bytes (5)
>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>> Transport codepoint '10' (2)
>> Total Length: 84
>> Identification: 0x0000 (0)
>> Flags: 0x02 (Don't Fragment)
>> 0... .... = Reserved bit: Not set
>> .1.. .... = Don't fragment: Set
>> ..0. .... = More fragments: Not set
>> Fragment offset: 0
>> Time to live: 64
>> Protocol: SCTP (132)
>> Header checksum: 0x1c3e [validation disabled]
>> [Good: False]
>> [Bad: False]
>> Source: 192.168.206.83
>> Destination: 192.168.206.65
>> [Source GeoIP: Unknown]
>> [Destination GeoIP: Unknown]
>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>> Port: 3868 (3868)
>> Source port: 50001
>> Destination port: 3868
>> Verification tag: 0x00000000
>> [Assocation index: 0]
>> Checksum: 0xbaea49e5 (not verified)
>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>> Chunk type: INIT (1)
>> 0... .... = Bit: Stop processing of the packet
>> .0.. .... = Bit: Do not report
>> Chunk flags: 0x00
>> Chunk length: 52
>> Initiate tag: 0xe79f40cb
>> Advertised receiver window credit (a_rwnd): 62464
>> Number of outbound streams: 3000
>> Number of inbound streams: 3000
>> Initial TSN: 176990880
>> IPv4 address parameter (Address: 192.168.206.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.206.83
>> IPv4 address parameter (Address: 192.168.1.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.1.83
>> Supported address types parameter (Supported types: IPv6, IPv4)
>> Parameter type: Supported address types (0x000c)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> Supported address type: IPv6 address (6)
>> Supported address type: IPv4 address (5)
>> ECN parameter
>> Parameter type: ECN (0x8000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 4
>> Forward TSN supported parameter
>> Parameter type: Forward TSN supported (0xc000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .1.. .... .... .... = Bit: Do report
>> Parameter length: 4
>>
>>
>> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>> >> what kind of information do you need? the whole INIT packet?
>> >>
>> > That would be ideal.
>> >
>> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> >> >> Hi
>> >> >>
>> >> >> the linux router just change the destination, so it can arrive on the
>> >> >> the SERVER.
>> >> >>
>> >> > Please post the relevant snippets from the client and server tcpdump
>> >> > operations
>> >> >
>> >> > Neil
>> >> >
>> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> >> >> > 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
>> >> >> >
>> >> >>
>> >> --
>> >> 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
>>
>
> It looks like you have some destination NAT-ing going on in these packets. In
> one trace your destination address is 192.168.206.65, and in the other its
> 192.168.206.66.
>
> Neil
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-11 8:39 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-11 8:39 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
yes. whenever the INIT packet send to 192.168.206.65, it will forward
to 192.168.206.66. My question is when this packet arrive to
192.168.206.66, why LKSCTP never pass to user level.
On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
>> Packet received (From client)
>> ===========
>>
>> No. Time Source SPort
>> Destination Protocol DPort Length Info
>> DSCP
>> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
>> 192.168.206.65 SCTP 3868 98 INIT
>> CS0
>>
>> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>> Encapsulation type: Ethernet (1)
>> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
>> [Time shift for this packet: 0.000000000 seconds]
>> Epoch Time: 1483692769.662142000 seconds
>> [Time delta from previous captured frame: 0.000000000 seconds]
>> [Time delta from previous displayed frame: 0.000000000 seconds]
>> [Time since reference or first frame: 0.000000000 seconds]
>> Frame Number: 1
>> Frame Length: 98 bytes (784 bits)
>> Capture Length: 98 bytes (784 bits)
>> [Frame is marked: False]
>> [Frame is ignored: False]
>> [Protocols in frame: eth:ethertype:ip:sctp]
>> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
>> Vmware_81:41:6b (00:50:56:81:41:6b)
>> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>> .... ..0. .... .... .... .... = LG bit: Globally unique
>> address (factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
>> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
>> .... ..1. .... .... .... .... = LG bit: Locally administered
>> address (this is NOT the factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Type: IPv4 (0x0800)
>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
>> 0100 .... = Version: 4
>> .... 0101 = Header Length: 20 bytes (5)
>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>> Transport codepoint '10' (2)
>> Total Length: 84
>> Identification: 0x0000 (0)
>> Flags: 0x02 (Don't Fragment)
>> 0... .... = Reserved bit: Not set
>> .1.. .... = Don't fragment: Set
>> ..0. .... = More fragments: Not set
>> Fragment offset: 0
>> Time to live: 64
>> Protocol: SCTP (132)
>> Header checksum: 0x1c3e [validation disabled]
>> [Good: False]
>> [Bad: False]
>> Source: 192.168.206.83
>> Destination: 192.168.206.65
>> [Source GeoIP: Unknown]
>> [Destination GeoIP: Unknown]
>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>> Port: 3868 (3868)
>> Source port: 50001
>> Destination port: 3868
>> Verification tag: 0x00000000
>> [Assocation index: 0]
>> Checksum: 0xbaea49e5 (not verified)
>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>> Chunk type: INIT (1)
>> 0... .... = Bit: Stop processing of the packet
>> .0.. .... = Bit: Do not report
>> Chunk flags: 0x00
>> Chunk length: 52
>> Initiate tag: 0xe79f40cb
>> Advertised receiver window credit (a_rwnd): 62464
>> Number of outbound streams: 3000
>> Number of inbound streams: 3000
>> Initial TSN: 176990880
>> IPv4 address parameter (Address: 192.168.206.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.206.83
>> IPv4 address parameter (Address: 192.168.1.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.1.83
>> Supported address types parameter (Supported types: IPv6, IPv4)
>> Parameter type: Supported address types (0x000c)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> Supported address type: IPv6 address (6)
>> Supported address type: IPv4 address (5)
>> ECN parameter
>> Parameter type: ECN (0x8000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 4
>> Forward TSN supported parameter
>> Parameter type: Forward TSN supported (0xc000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .1.. .... .... .... = Bit: Do report
>> Parameter length: 4
>>
>>
>> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>> >> what kind of information do you need? the whole INIT packet?
>> >>
>> > That would be ideal.
>> >
>> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> >> >> Hi
>> >> >>
>> >> >> the linux router just change the destination, so it can arrive on the
>> >> >> the SERVER.
>> >> >>
>> >> > Please post the relevant snippets from the client and server tcpdump
>> >> > operations
>> >> >
>> >> > Neil
>> >> >
>> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> >> >> > 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
>> >> >> >
>> >> >>
>> >> --
>> >> 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
>>
>
> It looks like you have some destination NAT-ing going on in these packets. In
> one trace your destination address is 192.168.206.65, and in the other its
> 192.168.206.66.
>
> Neil
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-11 8:39 ` Sun Paul
@ 2017-01-11 12:57 ` Neil Horman
-1 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-11 12:57 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Wed, Jan 11, 2017 at 04:39:29PM +0800, Sun Paul wrote:
> yes. whenever the INIT packet send to 192.168.206.65, it will forward
> to 192.168.206.66. My question is when this packet arrive to
> 192.168.206.66, why LKSCTP never pass to user level.
>
Yes....soo, unlike what you said before, there is some address translation to
take into account here. You need to be prepared for that:
https://docs.google.com/viewer?url=http://www.sigcomm.org/sites/default/files/ccr/papers/2009/January/1496091-1496095.pdf
Neil
> On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
> >> Packet received (From client)
> >> ======================
> >>
> >> No. Time Source SPort
> >> Destination Protocol DPort Length Info
> >> DSCP
> >> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> >> 192.168.206.65 SCTP 3868 98 INIT
> >> CS0
> >>
> >> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> >> Encapsulation type: Ethernet (1)
> >> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> >> [Time shift for this packet: 0.000000000 seconds]
> >> Epoch Time: 1483692769.662142000 seconds
> >> [Time delta from previous captured frame: 0.000000000 seconds]
> >> [Time delta from previous displayed frame: 0.000000000 seconds]
> >> [Time since reference or first frame: 0.000000000 seconds]
> >> Frame Number: 1
> >> Frame Length: 98 bytes (784 bits)
> >> Capture Length: 98 bytes (784 bits)
> >> [Frame is marked: False]
> >> [Frame is ignored: False]
> >> [Protocols in frame: eth:ethertype:ip:sctp]
> >> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> >> Vmware_81:41:6b (00:50:56:81:41:6b)
> >> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> >> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> >> .... ..0. .... .... .... .... = LG bit: Globally unique
> >> address (factory default)
> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> >> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> >> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> >> .... ..1. .... .... .... .... = LG bit: Locally administered
> >> address (this is NOT the factory default)
> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> >> Type: IPv4 (0x0800)
> >> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> >> 0100 .... = Version: 4
> >> .... 0101 = Header Length: 20 bytes (5)
> >> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> >> 0000 00.. = Differentiated Services Codepoint: Default (0)
> >> .... ..10 = Explicit Congestion Notification: ECN-Capable
> >> Transport codepoint '10' (2)
> >> Total Length: 84
> >> Identification: 0x0000 (0)
> >> Flags: 0x02 (Don't Fragment)
> >> 0... .... = Reserved bit: Not set
> >> .1.. .... = Don't fragment: Set
> >> ..0. .... = More fragments: Not set
> >> Fragment offset: 0
> >> Time to live: 64
> >> Protocol: SCTP (132)
> >> Header checksum: 0x1c3e [validation disabled]
> >> [Good: False]
> >> [Bad: False]
> >> Source: 192.168.206.83
> >> Destination: 192.168.206.65
> >> [Source GeoIP: Unknown]
> >> [Destination GeoIP: Unknown]
> >> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> >> Port: 3868 (3868)
> >> Source port: 50001
> >> Destination port: 3868
> >> Verification tag: 0x00000000
> >> [Assocation index: 0]
> >> Checksum: 0xbaea49e5 (not verified)
> >> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> >> Chunk type: INIT (1)
> >> 0... .... = Bit: Stop processing of the packet
> >> .0.. .... = Bit: Do not report
> >> Chunk flags: 0x00
> >> Chunk length: 52
> >> Initiate tag: 0xe79f40cb
> >> Advertised receiver window credit (a_rwnd): 62464
> >> Number of outbound streams: 3000
> >> Number of inbound streams: 3000
> >> Initial TSN: 176990880
> >> IPv4 address parameter (Address: 192.168.206.83)
> >> Parameter type: IPv4 address (0x0005)
> >> 0... .... .... .... = Bit: Stop processing of chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 8
> >> IP Version 4 address: 192.168.206.83
> >> IPv4 address parameter (Address: 192.168.1.83)
> >> Parameter type: IPv4 address (0x0005)
> >> 0... .... .... .... = Bit: Stop processing of chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 8
> >> IP Version 4 address: 192.168.1.83
> >> Supported address types parameter (Supported types: IPv6, IPv4)
> >> Parameter type: Supported address types (0x000c)
> >> 0... .... .... .... = Bit: Stop processing of chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 8
> >> Supported address type: IPv6 address (6)
> >> Supported address type: IPv4 address (5)
> >> ECN parameter
> >> Parameter type: ECN (0x8000)
> >> 1... .... .... .... = Bit: Skip parameter and continue
> >> processing of the chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 4
> >> Forward TSN supported parameter
> >> Parameter type: Forward TSN supported (0xc000)
> >> 1... .... .... .... = Bit: Skip parameter and continue
> >> processing of the chunk
> >> .1.. .... .... .... = Bit: Do report
> >> Parameter length: 4
> >>
> >>
> >> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
> >> >> what kind of information do you need? the whole INIT packet?
> >> >>
> >> > That would be ideal.
> >> >
> >> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> >> >> >> Hi
> >> >> >>
> >> >> >> the linux router just change the destination, so it can arrive on the
> >> >> >> the SERVER.
> >> >> >>
> >> >> > Please post the relevant snippets from the client and server tcpdump
> >> >> > operations
> >> >> >
> >> >> > Neil
> >> >> >
> >> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> >> >> >> > 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
> >> >> >> >
> >> >> >>
> >> >> --
> >> >> 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
> >>
> >
> > It looks like you have some destination NAT-ing going on in these packets. In
> > one trace your destination address is 192.168.206.65, and in the other its
> > 192.168.206.66.
> >
> > Neil
> >
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-11 12:57 ` Neil Horman
0 siblings, 0 replies; 75+ messages in thread
From: Neil Horman @ 2017-01-11 12:57 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, linux-sctp, linux-kernel
On Wed, Jan 11, 2017 at 04:39:29PM +0800, Sun Paul wrote:
> yes. whenever the INIT packet send to 192.168.206.65, it will forward
> to 192.168.206.66. My question is when this packet arrive to
> 192.168.206.66, why LKSCTP never pass to user level.
>
Yes....soo, unlike what you said before, there is some address translation to
take into account here. You need to be prepared for that:
https://docs.google.com/viewer?url=http://www.sigcomm.org/sites/default/files/ccr/papers/2009/January/1496091-1496095.pdf
Neil
> On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
> >> Packet received (From client)
> >> ===========
> >>
> >> No. Time Source SPort
> >> Destination Protocol DPort Length Info
> >> DSCP
> >> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> >> 192.168.206.65 SCTP 3868 98 INIT
> >> CS0
> >>
> >> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> >> Encapsulation type: Ethernet (1)
> >> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> >> [Time shift for this packet: 0.000000000 seconds]
> >> Epoch Time: 1483692769.662142000 seconds
> >> [Time delta from previous captured frame: 0.000000000 seconds]
> >> [Time delta from previous displayed frame: 0.000000000 seconds]
> >> [Time since reference or first frame: 0.000000000 seconds]
> >> Frame Number: 1
> >> Frame Length: 98 bytes (784 bits)
> >> Capture Length: 98 bytes (784 bits)
> >> [Frame is marked: False]
> >> [Frame is ignored: False]
> >> [Protocols in frame: eth:ethertype:ip:sctp]
> >> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> >> Vmware_81:41:6b (00:50:56:81:41:6b)
> >> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> >> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> >> .... ..0. .... .... .... .... = LG bit: Globally unique
> >> address (factory default)
> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> >> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> >> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> >> .... ..1. .... .... .... .... = LG bit: Locally administered
> >> address (this is NOT the factory default)
> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> >> Type: IPv4 (0x0800)
> >> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> >> 0100 .... = Version: 4
> >> .... 0101 = Header Length: 20 bytes (5)
> >> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> >> 0000 00.. = Differentiated Services Codepoint: Default (0)
> >> .... ..10 = Explicit Congestion Notification: ECN-Capable
> >> Transport codepoint '10' (2)
> >> Total Length: 84
> >> Identification: 0x0000 (0)
> >> Flags: 0x02 (Don't Fragment)
> >> 0... .... = Reserved bit: Not set
> >> .1.. .... = Don't fragment: Set
> >> ..0. .... = More fragments: Not set
> >> Fragment offset: 0
> >> Time to live: 64
> >> Protocol: SCTP (132)
> >> Header checksum: 0x1c3e [validation disabled]
> >> [Good: False]
> >> [Bad: False]
> >> Source: 192.168.206.83
> >> Destination: 192.168.206.65
> >> [Source GeoIP: Unknown]
> >> [Destination GeoIP: Unknown]
> >> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> >> Port: 3868 (3868)
> >> Source port: 50001
> >> Destination port: 3868
> >> Verification tag: 0x00000000
> >> [Assocation index: 0]
> >> Checksum: 0xbaea49e5 (not verified)
> >> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> >> Chunk type: INIT (1)
> >> 0... .... = Bit: Stop processing of the packet
> >> .0.. .... = Bit: Do not report
> >> Chunk flags: 0x00
> >> Chunk length: 52
> >> Initiate tag: 0xe79f40cb
> >> Advertised receiver window credit (a_rwnd): 62464
> >> Number of outbound streams: 3000
> >> Number of inbound streams: 3000
> >> Initial TSN: 176990880
> >> IPv4 address parameter (Address: 192.168.206.83)
> >> Parameter type: IPv4 address (0x0005)
> >> 0... .... .... .... = Bit: Stop processing of chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 8
> >> IP Version 4 address: 192.168.206.83
> >> IPv4 address parameter (Address: 192.168.1.83)
> >> Parameter type: IPv4 address (0x0005)
> >> 0... .... .... .... = Bit: Stop processing of chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 8
> >> IP Version 4 address: 192.168.1.83
> >> Supported address types parameter (Supported types: IPv6, IPv4)
> >> Parameter type: Supported address types (0x000c)
> >> 0... .... .... .... = Bit: Stop processing of chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 8
> >> Supported address type: IPv6 address (6)
> >> Supported address type: IPv4 address (5)
> >> ECN parameter
> >> Parameter type: ECN (0x8000)
> >> 1... .... .... .... = Bit: Skip parameter and continue
> >> processing of the chunk
> >> .0.. .... .... .... = Bit: Do not report
> >> Parameter length: 4
> >> Forward TSN supported parameter
> >> Parameter type: Forward TSN supported (0xc000)
> >> 1... .... .... .... = Bit: Skip parameter and continue
> >> processing of the chunk
> >> .1.. .... .... .... = Bit: Do report
> >> Parameter length: 4
> >>
> >>
> >> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
> >> >> what kind of information do you need? the whole INIT packet?
> >> >>
> >> > That would be ideal.
> >> >
> >> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
> >> >> >> Hi
> >> >> >>
> >> >> >> the linux router just change the destination, so it can arrive on the
> >> >> >> the SERVER.
> >> >> >>
> >> >> > Please post the relevant snippets from the client and server tcpdump
> >> >> > operations
> >> >> >
> >> >> > Neil
> >> >> >
> >> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
> >> >> >> > 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
> >> >> >> >
> >> >> >>
> >> >> --
> >> >> 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
> >>
> >
> > It looks like you have some destination NAT-ing going on in these packets. In
> > one trace your destination address is 192.168.206.65, and in the other its
> > 192.168.206.66.
> >
> > Neil
> >
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-11 12:57 ` Neil Horman
@ 2017-01-12 9:30 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-12 9:30 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
HI
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?
On Wed, Jan 11, 2017 at 8:57 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Wed, Jan 11, 2017 at 04:39:29PM +0800, Sun Paul wrote:
>> yes. whenever the INIT packet send to 192.168.206.65, it will forward
>> to 192.168.206.66. My question is when this packet arrive to
>> 192.168.206.66, why LKSCTP never pass to user level.
>>
>
> Yes....soo, unlike what you said before, there is some address translation to
> take into account here. You need to be prepared for that:
>
> https://docs.google.com/viewer?url=http://www.sigcomm.org/sites/default/files/ccr/papers/2009/January/1496091-1496095.pdf
>
> Neil
>
>> On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> > On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
>> >> Packet received (From client)
>> >> ======================
>> >>
>> >> No. Time Source SPort
>> >> Destination Protocol DPort Length Info
>> >> DSCP
>> >> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
>> >> 192.168.206.65 SCTP 3868 98 INIT
>> >> CS0
>> >>
>> >> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>> >> Encapsulation type: Ethernet (1)
>> >> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
>> >> [Time shift for this packet: 0.000000000 seconds]
>> >> Epoch Time: 1483692769.662142000 seconds
>> >> [Time delta from previous captured frame: 0.000000000 seconds]
>> >> [Time delta from previous displayed frame: 0.000000000 seconds]
>> >> [Time since reference or first frame: 0.000000000 seconds]
>> >> Frame Number: 1
>> >> Frame Length: 98 bytes (784 bits)
>> >> Capture Length: 98 bytes (784 bits)
>> >> [Frame is marked: False]
>> >> [Frame is ignored: False]
>> >> [Protocols in frame: eth:ethertype:ip:sctp]
>> >> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
>> >> Vmware_81:41:6b (00:50:56:81:41:6b)
>> >> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
>> >> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>> >> .... ..0. .... .... .... .... = LG bit: Globally unique
>> >> address (factory default)
>> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> >> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
>> >> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
>> >> .... ..1. .... .... .... .... = LG bit: Locally administered
>> >> address (this is NOT the factory default)
>> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> >> Type: IPv4 (0x0800)
>> >> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
>> >> 0100 .... = Version: 4
>> >> .... 0101 = Header Length: 20 bytes (5)
>> >> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>> >> 0000 00.. = Differentiated Services Codepoint: Default (0)
>> >> .... ..10 = Explicit Congestion Notification: ECN-Capable
>> >> Transport codepoint '10' (2)
>> >> Total Length: 84
>> >> Identification: 0x0000 (0)
>> >> Flags: 0x02 (Don't Fragment)
>> >> 0... .... = Reserved bit: Not set
>> >> .1.. .... = Don't fragment: Set
>> >> ..0. .... = More fragments: Not set
>> >> Fragment offset: 0
>> >> Time to live: 64
>> >> Protocol: SCTP (132)
>> >> Header checksum: 0x1c3e [validation disabled]
>> >> [Good: False]
>> >> [Bad: False]
>> >> Source: 192.168.206.83
>> >> Destination: 192.168.206.65
>> >> [Source GeoIP: Unknown]
>> >> [Destination GeoIP: Unknown]
>> >> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>> >> Port: 3868 (3868)
>> >> Source port: 50001
>> >> Destination port: 3868
>> >> Verification tag: 0x00000000
>> >> [Assocation index: 0]
>> >> Checksum: 0xbaea49e5 (not verified)
>> >> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>> >> Chunk type: INIT (1)
>> >> 0... .... = Bit: Stop processing of the packet
>> >> .0.. .... = Bit: Do not report
>> >> Chunk flags: 0x00
>> >> Chunk length: 52
>> >> Initiate tag: 0xe79f40cb
>> >> Advertised receiver window credit (a_rwnd): 62464
>> >> Number of outbound streams: 3000
>> >> Number of inbound streams: 3000
>> >> Initial TSN: 176990880
>> >> IPv4 address parameter (Address: 192.168.206.83)
>> >> Parameter type: IPv4 address (0x0005)
>> >> 0... .... .... .... = Bit: Stop processing of chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 8
>> >> IP Version 4 address: 192.168.206.83
>> >> IPv4 address parameter (Address: 192.168.1.83)
>> >> Parameter type: IPv4 address (0x0005)
>> >> 0... .... .... .... = Bit: Stop processing of chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 8
>> >> IP Version 4 address: 192.168.1.83
>> >> Supported address types parameter (Supported types: IPv6, IPv4)
>> >> Parameter type: Supported address types (0x000c)
>> >> 0... .... .... .... = Bit: Stop processing of chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 8
>> >> Supported address type: IPv6 address (6)
>> >> Supported address type: IPv4 address (5)
>> >> ECN parameter
>> >> Parameter type: ECN (0x8000)
>> >> 1... .... .... .... = Bit: Skip parameter and continue
>> >> processing of the chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 4
>> >> Forward TSN supported parameter
>> >> Parameter type: Forward TSN supported (0xc000)
>> >> 1... .... .... .... = Bit: Skip parameter and continue
>> >> processing of the chunk
>> >> .1.. .... .... .... = Bit: Do report
>> >> Parameter length: 4
>> >>
>> >>
>> >> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>> >> >> what kind of information do you need? the whole INIT packet?
>> >> >>
>> >> > That would be ideal.
>> >> >
>> >> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> >> >> >> Hi
>> >> >> >>
>> >> >> >> the linux router just change the destination, so it can arrive on the
>> >> >> >> the SERVER.
>> >> >> >>
>> >> >> > Please post the relevant snippets from the client and server tcpdump
>> >> >> > operations
>> >> >> >
>> >> >> > Neil
>> >> >> >
>> >> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> >> >> >> > 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
>> >> >> >> >
>> >> >> >>
>> >> >> --
>> >> >> 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
>> >>
>> >
>> > It looks like you have some destination NAT-ing going on in these packets. In
>> > one trace your destination address is 192.168.206.65, and in the other its
>> > 192.168.206.66.
>> >
>> > Neil
>> >
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-12 9:30 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-12 9:30 UTC (permalink / raw)
To: Neil Horman; +Cc: David Laight, linux-sctp, linux-kernel
HI
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?
On Wed, Jan 11, 2017 at 8:57 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Wed, Jan 11, 2017 at 04:39:29PM +0800, Sun Paul wrote:
>> yes. whenever the INIT packet send to 192.168.206.65, it will forward
>> to 192.168.206.66. My question is when this packet arrive to
>> 192.168.206.66, why LKSCTP never pass to user level.
>>
>
> Yes....soo, unlike what you said before, there is some address translation to
> take into account here. You need to be prepared for that:
>
> https://docs.google.com/viewer?url=http://www.sigcomm.org/sites/default/files/ccr/papers/2009/January/1496091-1496095.pdf
>
> Neil
>
>> On Tue, Jan 10, 2017 at 10:33 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> > On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:
>> >> Packet received (From client)
>> >> ===========
>> >>
>> >> No. Time Source SPort
>> >> Destination Protocol DPort Length Info
>> >> DSCP
>> >> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
>> >> 192.168.206.65 SCTP 3868 98 INIT
>> >> CS0
>> >>
>> >> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>> >> Encapsulation type: Ethernet (1)
>> >> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
>> >> [Time shift for this packet: 0.000000000 seconds]
>> >> Epoch Time: 1483692769.662142000 seconds
>> >> [Time delta from previous captured frame: 0.000000000 seconds]
>> >> [Time delta from previous displayed frame: 0.000000000 seconds]
>> >> [Time since reference or first frame: 0.000000000 seconds]
>> >> Frame Number: 1
>> >> Frame Length: 98 bytes (784 bits)
>> >> Capture Length: 98 bytes (784 bits)
>> >> [Frame is marked: False]
>> >> [Frame is ignored: False]
>> >> [Protocols in frame: eth:ethertype:ip:sctp]
>> >> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
>> >> Vmware_81:41:6b (00:50:56:81:41:6b)
>> >> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
>> >> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>> >> .... ..0. .... .... .... .... = LG bit: Globally unique
>> >> address (factory default)
>> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> >> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
>> >> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
>> >> .... ..1. .... .... .... .... = LG bit: Locally administered
>> >> address (this is NOT the factory default)
>> >> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> >> Type: IPv4 (0x0800)
>> >> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
>> >> 0100 .... = Version: 4
>> >> .... 0101 = Header Length: 20 bytes (5)
>> >> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>> >> 0000 00.. = Differentiated Services Codepoint: Default (0)
>> >> .... ..10 = Explicit Congestion Notification: ECN-Capable
>> >> Transport codepoint '10' (2)
>> >> Total Length: 84
>> >> Identification: 0x0000 (0)
>> >> Flags: 0x02 (Don't Fragment)
>> >> 0... .... = Reserved bit: Not set
>> >> .1.. .... = Don't fragment: Set
>> >> ..0. .... = More fragments: Not set
>> >> Fragment offset: 0
>> >> Time to live: 64
>> >> Protocol: SCTP (132)
>> >> Header checksum: 0x1c3e [validation disabled]
>> >> [Good: False]
>> >> [Bad: False]
>> >> Source: 192.168.206.83
>> >> Destination: 192.168.206.65
>> >> [Source GeoIP: Unknown]
>> >> [Destination GeoIP: Unknown]
>> >> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>> >> Port: 3868 (3868)
>> >> Source port: 50001
>> >> Destination port: 3868
>> >> Verification tag: 0x00000000
>> >> [Assocation index: 0]
>> >> Checksum: 0xbaea49e5 (not verified)
>> >> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>> >> Chunk type: INIT (1)
>> >> 0... .... = Bit: Stop processing of the packet
>> >> .0.. .... = Bit: Do not report
>> >> Chunk flags: 0x00
>> >> Chunk length: 52
>> >> Initiate tag: 0xe79f40cb
>> >> Advertised receiver window credit (a_rwnd): 62464
>> >> Number of outbound streams: 3000
>> >> Number of inbound streams: 3000
>> >> Initial TSN: 176990880
>> >> IPv4 address parameter (Address: 192.168.206.83)
>> >> Parameter type: IPv4 address (0x0005)
>> >> 0... .... .... .... = Bit: Stop processing of chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 8
>> >> IP Version 4 address: 192.168.206.83
>> >> IPv4 address parameter (Address: 192.168.1.83)
>> >> Parameter type: IPv4 address (0x0005)
>> >> 0... .... .... .... = Bit: Stop processing of chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 8
>> >> IP Version 4 address: 192.168.1.83
>> >> Supported address types parameter (Supported types: IPv6, IPv4)
>> >> Parameter type: Supported address types (0x000c)
>> >> 0... .... .... .... = Bit: Stop processing of chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 8
>> >> Supported address type: IPv6 address (6)
>> >> Supported address type: IPv4 address (5)
>> >> ECN parameter
>> >> Parameter type: ECN (0x8000)
>> >> 1... .... .... .... = Bit: Skip parameter and continue
>> >> processing of the chunk
>> >> .0.. .... .... .... = Bit: Do not report
>> >> Parameter length: 4
>> >> Forward TSN supported parameter
>> >> Parameter type: Forward TSN supported (0xc000)
>> >> 1... .... .... .... = Bit: Skip parameter and continue
>> >> processing of the chunk
>> >> .1.. .... .... .... = Bit: Do report
>> >> Parameter length: 4
>> >>
>> >>
>> >> On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >> > On Tue, Jan 10, 2017 at 12:31:01AM +0800, Sun Paul wrote:
>> >> >> what kind of information do you need? the whole INIT packet?
>> >> >>
>> >> > That would be ideal.
>> >> >
>> >> >> On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >> >> > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote:
>> >> >> >> Hi
>> >> >> >>
>> >> >> >> the linux router just change the destination, so it can arrive on the
>> >> >> >> the SERVER.
>> >> >> >>
>> >> >> > Please post the relevant snippets from the client and server tcpdump
>> >> >> > operations
>> >> >> >
>> >> >> > Neil
>> >> >> >
>> >> >> >> On Mon, Jan 9, 2017 at 5:51 PM, David Laight <David.Laight@aculab.com> wrote:
>> >> >> >> > 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
>> >> >> >> >
>> >> >> >>
>> >> >> --
>> >> >> 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
>> >>
>> >
>> > It looks like you have some destination NAT-ing going on in these packets. In
>> > one trace your destination address is 192.168.206.65, and in the other its
>> > 192.168.206.66.
>> >
>> > Neil
>> >
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: Problem on SCTP
2017-01-12 9:30 ` Sun Paul
@ 2017-01-12 9:51 ` David Laight
-1 siblings, 0 replies; 75+ messages in thread
From: David Laight @ 2017-01-12 9:51 UTC (permalink / raw)
To: 'Sun Paul', Neil Horman; +Cc: linux-sctp, linux-kernel
From: Sun Paul [mailto:paulrbk@gmail.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.
David
^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: Problem on SCTP
@ 2017-01-12 9:51 ` David Laight
0 siblings, 0 replies; 75+ messages in thread
From: David Laight @ 2017-01-12 9:51 UTC (permalink / raw)
To: 'Sun Paul', Neil Horman; +Cc: linux-sctp, linux-kernel
RnJvbTogU3VuIFBhdWwgW21haWx0bzpwYXVscmJrQGdtYWlsLmNvbV0NCj4gU2VudDogMTIgSmFu
dWFyeSAyMDE3IDA5OjMxDQo+IExldCBtZSBjbGVhciB0aGUgdW5kZXJzdGFuZGluZy4gYmVsb3cg
aXMgdGhlIGZsb3cuDQo+IA0KPiAxLiBDbGllbnQgc2VuZHMgdG8gTGludXggUm91dGVyOiAxOTIu
MTY4LjIwNi44MyAtPiAxOTIuMTY4LjIwNi41NiwNCj4gMi4gTGludXggcm91dGVyIHNlbmRzIHRv
IFNFUlZFUiB3aGVyZSB0aGUgc291cmNlIElQIGlzIHVuY2hhbmdlZDoNCj4gMTkyLjE2OC4yMDYu
ODMgLT4gMTkyLjE2OC4yMDYuNjYNCj4gDQo+IE15IHF1ZXN0aW9uIGhlcmUgaXMgd2h5IFNFUlZF
UiBjYW5ub3QgcmVzcG9uc2UgdGhpcyBJTklUIGNodW5rPw0KDQpQcm9iYWJseSBiZWNhdXNlIHRo
ZSBJUCBhZGRyZXNzZXMgZW1iZWRkZWQgaW4gdGhlIFNDVFAgcGFja2V0DQpkb24ndCBtYXRjaCB0
aGUgb25lcyBpbiB0aGUgSVAgaGVhZGVyLg0KDQoJRGF2aWQNCg0K
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-12 9:51 ` David Laight
@ 2017-01-12 10:53 ` Michael Tuexen
-1 siblings, 0 replies; 75+ messages in thread
From: Michael Tuexen @ 2017-01-12 10:53 UTC (permalink / raw)
To: David Laight; +Cc: Sun Paul, Neil Horman, linux-sctp, linux-kernel
> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>
> From: Sun Paul [mailto:paulrbk@gmail.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š\x1dʇڙë,j\aĒfĢĒ·hš‹āzđ\x1eŪwĨĒļ\fĒ·Ķj:+v‰ĻŠwčjØmķŸĸū\aŦ‘ęįzZ+ƒųšŽŠÝĒj"ú!
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-12 10:53 ` Michael Tuexen
0 siblings, 0 replies; 75+ messages in thread
From: Michael Tuexen @ 2017-01-12 10:53 UTC (permalink / raw)
To: David Laight; +Cc: Sun Paul, Neil Horman, linux-sctp, linux-kernel
> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>
> From: Sun Paul [mailto:paulrbk@gmail.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š\x1dʇڙë,j\aĒfĢĒ·hš‹āzđ\x1eŪwĨĒļ\fĒ·Ķj:+v‰ĻŠwčjØmķŸĸū\aŦ‘ęįzZ+ƒųšŽŠÝĒj"ú!
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-12 10:53 ` Michael Tuexen
@ 2017-01-13 3:27 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-13 3:27 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Hi All
below is the packet trace in text format.
Packet received (From client to router) [ Source IP: 192.168.206.83,
Destination IP: 192.168.206.65. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]
======================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
1 2017-01-06 08:52:49.662142 192.168.206.83 50001
192.168.206.65 SCTP 3868 98 INIT
CS0
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662142000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
Vmware_81:41:6b (00:50:56:81:41:6b)
Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: RealtekU_54:81:87 (52:54:00:54:81:87)
Address: RealtekU_54:81:87 (52:54:00:54:81:87)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: SCTP (132)
Header checksum: 0x1c3e [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.65
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xbaea49e5 (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Thu, Jan 12, 2017 at 6:53 PM, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
>> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>>
>> From: Sun Paul [mailto:paulrbk@gmail.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" ú!
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-13 3:27 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-13 3:27 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Hi All
below is the packet trace in text format.
Packet received (From client to router) [ Source IP: 192.168.206.83,
Destination IP: 192.168.206.65. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]
======================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
1 2017-01-06 08:52:49.662142 192.168.206.83 50001
192.168.206.65 SCTP 3868 98 INIT
CS0
Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662142000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
Vmware_81:41:6b (00:50:56:81:41:6b)
Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: RealtekU_54:81:87 (52:54:00:54:81:87)
Address: RealtekU_54:81:87 (52:54:00:54:81:87)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: SCTP (132)
Header checksum: 0x1c3e [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.65
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xbaea49e5 (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Thu, Jan 12, 2017 at 6:53 PM, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
>> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>>
>> From: Sun Paul [mailto:paulrbk@gmail.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" ú!
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-13 3:27 ` Sun Paul
@ 2017-01-13 3:27 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-13 3:27 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Packet to SERVER (from router to SERVER)[ Source IP: 192.168.206.83,
Destination IP: 192.168.206.66. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]
================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
2 2017-01-06 08:52:49.662321 192.168.206.83 50001
192.168.206.66 SCTP 3868 98 INIT
CS0
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi All
>
> below is the packet trace in text format.
>
>
> Packet received (From client to router) [ Source IP: 192.168.206.83,
> Destination IP: 192.168.206.65. the IPv4 address parameter is
> 192.168.206.83 and 192.168.1.83 ]
> ======================
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
> On Thu, Jan 12, 2017 at 6:53 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>>> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>>>
>>> From: Sun Paul [mailto:paulrbk@gmail.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" ú!
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-13 3:27 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-13 3:27 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Packet to SERVER (from router to SERVER)[ Source IP: 192.168.206.83,
Destination IP: 192.168.206.66. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]
================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
2 2017-01-06 08:52:49.662321 192.168.206.83 50001
192.168.206.66 SCTP 3868 98 INIT
CS0
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi All
>
> below is the packet trace in text format.
>
>
> Packet received (From client to router) [ Source IP: 192.168.206.83,
> Destination IP: 192.168.206.65. the IPv4 address parameter is
> 192.168.206.83 and 192.168.1.83 ]
> ======================
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
> On Thu, Jan 12, 2017 at 6:53 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>>> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>>>
>>> From: Sun Paul [mailto:paulrbk@gmail.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" ú!
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-13 3:27 ` Sun Paul
@ 2017-01-13 3:29 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-13 3:29 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Packet to SERVER (From router to SERVER) [ Source IP: 192.168.206.83,
Destination IP: 192.168.206.66. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]
================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
2 2017-01-06 08:52:49.662321 192.168.206.83 50001
192.168.206.66 SCTP 3868 98 INIT
CS0
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi All
>
> below is the packet trace in text format.
>
>
> Packet received (From client to router) [ Source IP: 192.168.206.83,
> Destination IP: 192.168.206.65. the IPv4 address parameter is
> 192.168.206.83 and 192.168.1.83 ]
> ======================
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
> On Thu, Jan 12, 2017 at 6:53 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>>> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>>>
>>> From: Sun Paul [mailto:paulrbk@gmail.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" ú!
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-13 3:29 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-01-13 3:29 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Packet to SERVER (From router to SERVER) [ Source IP: 192.168.206.83,
Destination IP: 192.168.206.66. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]
================
No. Time Source SPort
Destination Protocol DPort Length Info
DSCP
2 2017-01-06 08:52:49.662321 192.168.206.83 50001
192.168.206.66 SCTP 3868 98 INIT
CS0
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x00000000
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0... .... = Bit: Stop processing of the packet
.0.. .... = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0... .... .... .... = Bit: Stop processing of chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.0.. .... .... .... = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1... .... .... .... = Bit: Skip parameter and continue
processing of the chunk
.1.. .... .... .... = Bit: Do report
Parameter length: 4
On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi All
>
> below is the packet trace in text format.
>
>
> Packet received (From client to router) [ Source IP: 192.168.206.83,
> Destination IP: 192.168.206.65. the IPv4 address parameter is
> 192.168.206.83 and 192.168.1.83 ]
> ======================
>
> No. Time Source SPort
> Destination Protocol DPort Length Info
> DSCP
> 1 2017-01-06 08:52:49.662142 192.168.206.83 50001
> 192.168.206.65 SCTP 3868 98 INIT
> CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662142000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
> .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.65
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: SCTP (132)
> Header checksum: 0x1c3e [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.65
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xbaea49e5 (not verified)
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
>
> On Thu, Jan 12, 2017 at 6:53 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>>> On 12 Jan 2017, at 10:51, David Laight <David.Laight@ACULAB.COM> wrote:
>>>
>>> From: Sun Paul [mailto:paulrbk@gmail.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" ú!
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-13 3:29 ` Sun Paul
@ 2017-01-13 9:43 ` Michael Tuexen
-1 siblings, 0 replies; 75+ messages in thread
From: Michael Tuexen @ 2017-01-13 9:43 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Your router does NOT change any field in the SCTP packet, but the
SCTP checksum was modified from
Checksum: 0xbaea49e5 (not verified)
to
Checksum: 0xa9a86d3f (not verified)
At least one of these is wrong. Read the tracefiles in wireshark and
enable checksum validation and wireshark will tell you which one is
correct. (That is why I asked for .pcap file instead of a .txt).
My guess is that the initial checksum is correct and your box middlebox
not only changes the destination address and ttl field and header
checksum in the IP-header (which is expected) but also incorrectly the
SCTP checksum. Since no field in the SCTP packet has changed, the checksum
must be the same.
Best regards
Michael
> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>
> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662321000 seconds
> [Time delta from previous captured frame: 0.000179000 seconds]
> [Time delta from previous displayed frame: 0.000179000 seconds]
> [Time since reference or first frame: 0.000179000 seconds]
> Frame Number: 2
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 63
> Protocol: SCTP (132)
> Header checksum: 0x1d3d [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.66
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xa9a86d3f (not verified)
>
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-13 9:43 ` Michael Tuexen
0 siblings, 0 replies; 75+ messages in thread
From: Michael Tuexen @ 2017-01-13 9:43 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Your router does NOT change any field in the SCTP packet, but the
SCTP checksum was modified from
Checksum: 0xbaea49e5 (not verified)
to
Checksum: 0xa9a86d3f (not verified)
At least one of these is wrong. Read the tracefiles in wireshark and
enable checksum validation and wireshark will tell you which one is
correct. (That is why I asked for .pcap file instead of a .txt).
My guess is that the initial checksum is correct and your box middlebox
not only changes the destination address and ttl field and header
checksum in the IP-header (which is expected) but also incorrectly the
SCTP checksum. Since no field in the SCTP packet has changed, the checksum
must be the same.
Best regards
Michael
> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>
> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1483692769.662321000 seconds
> [Time delta from previous captured frame: 0.000179000 seconds]
> [Time delta from previous displayed frame: 0.000179000 seconds]
> [Time since reference or first frame: 0.000179000 seconds]
> Frame Number: 2
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
> 0100 .... = Version: 4
> .... 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
> 0000 00.. = Differentiated Services Codepoint: Default (0)
> .... ..10 = Explicit Congestion Notification: ECN-Capable
> Transport codepoint '10' (2)
> Total Length: 84
> Identification: 0x0000 (0)
> Flags: 0x02 (Don't Fragment)
> 0... .... = Reserved bit: Not set
> .1.. .... = Don't fragment: Set
> ..0. .... = More fragments: Not set
> Fragment offset: 0
> Time to live: 63
> Protocol: SCTP (132)
> Header checksum: 0x1d3d [validation disabled]
> [Good: False]
> [Bad: False]
> Source: 192.168.206.83
> Destination: 192.168.206.66
> [Source GeoIP: Unknown]
> [Destination GeoIP: Unknown]
> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
> Port: 3868 (3868)
> Source port: 50001
> Destination port: 3868
> Verification tag: 0x00000000
> [Assocation index: 0]
> Checksum: 0xa9a86d3f (not verified)
>
> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
> Chunk type: INIT (1)
> 0... .... = Bit: Stop processing of the packet
> .0.. .... = Bit: Do not report
> Chunk flags: 0x00
> Chunk length: 52
> Initiate tag: 0xe79f40cb
> Advertised receiver window credit (a_rwnd): 62464
> Number of outbound streams: 3000
> Number of inbound streams: 3000
> Initial TSN: 176990880
> IPv4 address parameter (Address: 192.168.206.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.206.83
> IPv4 address parameter (Address: 192.168.1.83)
> Parameter type: IPv4 address (0x0005)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> IP Version 4 address: 192.168.1.83
> Supported address types parameter (Supported types: IPv6, IPv4)
> Parameter type: Supported address types (0x000c)
> 0... .... .... .... = Bit: Stop processing of chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 8
> Supported address type: IPv6 address (6)
> Supported address type: IPv4 address (5)
> ECN parameter
> Parameter type: ECN (0x8000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .0.. .... .... .... = Bit: Do not report
> Parameter length: 4
> Forward TSN supported parameter
> Parameter type: Forward TSN supported (0xc000)
> 1... .... .... .... = Bit: Skip parameter and continue
> processing of the chunk
> .1.. .... .... .... = Bit: Do report
> Parameter length: 4
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-13 9:43 ` Michael Tuexen
@ 2017-01-13 13:19 ` Michael Tuexen
-1 siblings, 0 replies; 75+ messages in thread
From: Michael Tuexen @ 2017-01-13 13:19 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>
> Your router does NOT change any field in the SCTP packet, but the
> SCTP checksum was modified from
> Checksum: 0xbaea49e5 (not verified)
> to
> Checksum: 0xa9a86d3f (not verified)
> At least one of these is wrong. Read the tracefiles in wireshark and
> enable checksum validation and wireshark will tell you which one is
> correct. (That is why I asked for .pcap file instead of a .txt).
>
> My guess is that the initial checksum is correct and your box middlebox
> not only changes the destination address and ttl field and header
> checksum in the IP-header (which is expected) but also incorrectly the
> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
> must be the same.
At the server have a look at the SNMP counters:
cat /proc/net/sctp/snmp
You should find a line staring with
SctpChecksumErrors
If the number reported there is positive, the node received packets
with checksum errors.
Best regards
Michael
>
> Best regards
> Michael
>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>
>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>> Encapsulation type: Ethernet (1)
>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>> [Time shift for this packet: 0.000000000 seconds]
>> Epoch Time: 1483692769.662321000 seconds
>> [Time delta from previous captured frame: 0.000179000 seconds]
>> [Time delta from previous displayed frame: 0.000179000 seconds]
>> [Time since reference or first frame: 0.000179000 seconds]
>> Frame Number: 2
>> Frame Length: 98 bytes (784 bits)
>> Capture Length: 98 bytes (784 bits)
>> [Frame is marked: False]
>> [Frame is ignored: False]
>> [Protocols in frame: eth:ethertype:ip:sctp]
>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>> .... ..0. .... .... .... .... = LG bit: Globally unique
>> address (factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>> .... ..0. .... .... .... .... = LG bit: Globally unique
>> address (factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Type: IPv4 (0x0800)
>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>> 0100 .... = Version: 4
>> .... 0101 = Header Length: 20 bytes (5)
>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>> Transport codepoint '10' (2)
>> Total Length: 84
>> Identification: 0x0000 (0)
>> Flags: 0x02 (Don't Fragment)
>> 0... .... = Reserved bit: Not set
>> .1.. .... = Don't fragment: Set
>> ..0. .... = More fragments: Not set
>> Fragment offset: 0
>> Time to live: 63
>> Protocol: SCTP (132)
>> Header checksum: 0x1d3d [validation disabled]
>> [Good: False]
>> [Bad: False]
>> Source: 192.168.206.83
>> Destination: 192.168.206.66
>> [Source GeoIP: Unknown]
>> [Destination GeoIP: Unknown]
>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>> Port: 3868 (3868)
>> Source port: 50001
>> Destination port: 3868
>> Verification tag: 0x00000000
>> [Assocation index: 0]
>> Checksum: 0xa9a86d3f (not verified)
>>
>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>> Chunk type: INIT (1)
>> 0... .... = Bit: Stop processing of the packet
>> .0.. .... = Bit: Do not report
>> Chunk flags: 0x00
>> Chunk length: 52
>> Initiate tag: 0xe79f40cb
>> Advertised receiver window credit (a_rwnd): 62464
>> Number of outbound streams: 3000
>> Number of inbound streams: 3000
>> Initial TSN: 176990880
>> IPv4 address parameter (Address: 192.168.206.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.206.83
>> IPv4 address parameter (Address: 192.168.1.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.1.83
>> Supported address types parameter (Supported types: IPv6, IPv4)
>> Parameter type: Supported address types (0x000c)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> Supported address type: IPv6 address (6)
>> Supported address type: IPv4 address (5)
>> ECN parameter
>> Parameter type: ECN (0x8000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 4
>> Forward TSN supported parameter
>> Parameter type: Forward TSN supported (0xc000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .1.. .... .... .... = Bit: Do report
>> Parameter length: 4
>
> --
> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-13 13:19 ` Michael Tuexen
0 siblings, 0 replies; 75+ messages in thread
From: Michael Tuexen @ 2017-01-13 13:19 UTC (permalink / raw)
To: Sun Paul; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>
> Your router does NOT change any field in the SCTP packet, but the
> SCTP checksum was modified from
> Checksum: 0xbaea49e5 (not verified)
> to
> Checksum: 0xa9a86d3f (not verified)
> At least one of these is wrong. Read the tracefiles in wireshark and
> enable checksum validation and wireshark will tell you which one is
> correct. (That is why I asked for .pcap file instead of a .txt).
>
> My guess is that the initial checksum is correct and your box middlebox
> not only changes the destination address and ttl field and header
> checksum in the IP-header (which is expected) but also incorrectly the
> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
> must be the same.
At the server have a look at the SNMP counters:
cat /proc/net/sctp/snmp
You should find a line staring with
SctpChecksumErrors
If the number reported there is positive, the node received packets
with checksum errors.
Best regards
Michael
>
> Best regards
> Michael
>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>
>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>> Encapsulation type: Ethernet (1)
>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>> [Time shift for this packet: 0.000000000 seconds]
>> Epoch Time: 1483692769.662321000 seconds
>> [Time delta from previous captured frame: 0.000179000 seconds]
>> [Time delta from previous displayed frame: 0.000179000 seconds]
>> [Time since reference or first frame: 0.000179000 seconds]
>> Frame Number: 2
>> Frame Length: 98 bytes (784 bits)
>> Capture Length: 98 bytes (784 bits)
>> [Frame is marked: False]
>> [Frame is ignored: False]
>> [Protocols in frame: eth:ethertype:ip:sctp]
>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>> .... ..0. .... .... .... .... = LG bit: Globally unique
>> address (factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>> .... ..0. .... .... .... .... = LG bit: Globally unique
>> address (factory default)
>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>> Type: IPv4 (0x0800)
>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>> 0100 .... = Version: 4
>> .... 0101 = Header Length: 20 bytes (5)
>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>> Transport codepoint '10' (2)
>> Total Length: 84
>> Identification: 0x0000 (0)
>> Flags: 0x02 (Don't Fragment)
>> 0... .... = Reserved bit: Not set
>> .1.. .... = Don't fragment: Set
>> ..0. .... = More fragments: Not set
>> Fragment offset: 0
>> Time to live: 63
>> Protocol: SCTP (132)
>> Header checksum: 0x1d3d [validation disabled]
>> [Good: False]
>> [Bad: False]
>> Source: 192.168.206.83
>> Destination: 192.168.206.66
>> [Source GeoIP: Unknown]
>> [Destination GeoIP: Unknown]
>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>> Port: 3868 (3868)
>> Source port: 50001
>> Destination port: 3868
>> Verification tag: 0x00000000
>> [Assocation index: 0]
>> Checksum: 0xa9a86d3f (not verified)
>>
>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>> Chunk type: INIT (1)
>> 0... .... = Bit: Stop processing of the packet
>> .0.. .... = Bit: Do not report
>> Chunk flags: 0x00
>> Chunk length: 52
>> Initiate tag: 0xe79f40cb
>> Advertised receiver window credit (a_rwnd): 62464
>> Number of outbound streams: 3000
>> Number of inbound streams: 3000
>> Initial TSN: 176990880
>> IPv4 address parameter (Address: 192.168.206.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.206.83
>> IPv4 address parameter (Address: 192.168.1.83)
>> Parameter type: IPv4 address (0x0005)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> IP Version 4 address: 192.168.1.83
>> Supported address types parameter (Supported types: IPv6, IPv4)
>> Parameter type: Supported address types (0x000c)
>> 0... .... .... .... = Bit: Stop processing of chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 8
>> Supported address type: IPv6 address (6)
>> Supported address type: IPv4 address (5)
>> ECN parameter
>> Parameter type: ECN (0x8000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .0.. .... .... .... = Bit: Do not report
>> Parameter length: 4
>> Forward TSN supported parameter
>> Parameter type: Forward TSN supported (0xc000)
>> 1... .... .... .... = Bit: Skip parameter and continue
>> processing of the chunk
>> .1.. .... .... .... = Bit: Do report
>> Parameter length: 4
>
> --
> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-13 9:43 ` Michael Tuexen
@ 2017-01-16 18:47 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 75+ messages in thread
From: Marcelo Ricardo Leitner @ 2017-01-16 18:47 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Fri, Jan 13, 2017 at 10:43:39AM +0100, Michael Tuexen wrote:
> Your router does NOT change any field in the SCTP packet, but the
> SCTP checksum was modified from
> Checksum: 0xbaea49e5 (not verified)
> to
> Checksum: 0xa9a86d3f (not verified)
Sun, which operating system is your router running?
Marcelo
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-01-16 18:47 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 75+ messages in thread
From: Marcelo Ricardo Leitner @ 2017-01-16 18:47 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Fri, Jan 13, 2017 at 10:43:39AM +0100, Michael Tuexen wrote:
> Your router does NOT change any field in the SCTP packet, but the
> SCTP checksum was modified from
> Checksum: 0xbaea49e5 (not verified)
> to
> Checksum: 0xa9a86d3f (not verified)
Sun, which operating system is your router running?
Marcelo
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-13 13:19 ` Michael Tuexen
@ 2017-02-21 4:26 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-21 4:26 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Hi,
sorry to get back late, the platform is running on KVM. and this
problem is resolved by moving to VMware environment, however, a new
problem is coming out, we noticed that the HB REQ is being ABORT from
client.
03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
[HB REQ] (from server to sctp router)
03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
[HB REQ] (from sctp router to client)
03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
[ABORT] (from client to sctp router)
03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
For the above packet flow, 10.165.250.22 is the server and
192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
SCTP router change the src address before forward the HB REQ to the
client.
But somehow the client is ABORT the HB REQ, any idea? is it related to
the HEARTBEAT information? or the checksum again>?
On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>
>> Your router does NOT change any field in the SCTP packet, but the
>> SCTP checksum was modified from
>> Checksum: 0xbaea49e5 (not verified)
>> to
>> Checksum: 0xa9a86d3f (not verified)
>> At least one of these is wrong. Read the tracefiles in wireshark and
>> enable checksum validation and wireshark will tell you which one is
>> correct. (That is why I asked for .pcap file instead of a .txt).
>>
>> My guess is that the initial checksum is correct and your box middlebox
>> not only changes the destination address and ttl field and header
>> checksum in the IP-header (which is expected) but also incorrectly the
>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>> must be the same.
> At the server have a look at the SNMP counters:
> cat /proc/net/sctp/snmp
> You should find a line staring with
> SctpChecksumErrors
> If the number reported there is positive, the node received packets
> with checksum errors.
>
> Best regards
> Michael
>>
>> Best regards
>> Michael
>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>
>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>> Encapsulation type: Ethernet (1)
>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>> [Time shift for this packet: 0.000000000 seconds]
>>> Epoch Time: 1483692769.662321000 seconds
>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>> [Time since reference or first frame: 0.000179000 seconds]
>>> Frame Number: 2
>>> Frame Length: 98 bytes (784 bits)
>>> Capture Length: 98 bytes (784 bits)
>>> [Frame is marked: False]
>>> [Frame is ignored: False]
>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>> address (factory default)
>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>> address (factory default)
>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>> Type: IPv4 (0x0800)
>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>> 0100 .... = Version: 4
>>> .... 0101 = Header Length: 20 bytes (5)
>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>> Transport codepoint '10' (2)
>>> Total Length: 84
>>> Identification: 0x0000 (0)
>>> Flags: 0x02 (Don't Fragment)
>>> 0... .... = Reserved bit: Not set
>>> .1.. .... = Don't fragment: Set
>>> ..0. .... = More fragments: Not set
>>> Fragment offset: 0
>>> Time to live: 63
>>> Protocol: SCTP (132)
>>> Header checksum: 0x1d3d [validation disabled]
>>> [Good: False]
>>> [Bad: False]
>>> Source: 192.168.206.83
>>> Destination: 192.168.206.66
>>> [Source GeoIP: Unknown]
>>> [Destination GeoIP: Unknown]
>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>> Port: 3868 (3868)
>>> Source port: 50001
>>> Destination port: 3868
>>> Verification tag: 0x00000000
>>> [Assocation index: 0]
>>> Checksum: 0xa9a86d3f (not verified)
>>>
>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>> Chunk type: INIT (1)
>>> 0... .... = Bit: Stop processing of the packet
>>> .0.. .... = Bit: Do not report
>>> Chunk flags: 0x00
>>> Chunk length: 52
>>> Initiate tag: 0xe79f40cb
>>> Advertised receiver window credit (a_rwnd): 62464
>>> Number of outbound streams: 3000
>>> Number of inbound streams: 3000
>>> Initial TSN: 176990880
>>> IPv4 address parameter (Address: 192.168.206.83)
>>> Parameter type: IPv4 address (0x0005)
>>> 0... .... .... .... = Bit: Stop processing of chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 8
>>> IP Version 4 address: 192.168.206.83
>>> IPv4 address parameter (Address: 192.168.1.83)
>>> Parameter type: IPv4 address (0x0005)
>>> 0... .... .... .... = Bit: Stop processing of chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 8
>>> IP Version 4 address: 192.168.1.83
>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>> Parameter type: Supported address types (0x000c)
>>> 0... .... .... .... = Bit: Stop processing of chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 8
>>> Supported address type: IPv6 address (6)
>>> Supported address type: IPv4 address (5)
>>> ECN parameter
>>> Parameter type: ECN (0x8000)
>>> 1... .... .... .... = Bit: Skip parameter and continue
>>> processing of the chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 4
>>> Forward TSN supported parameter
>>> Parameter type: Forward TSN supported (0xc000)
>>> 1... .... .... .... = Bit: Skip parameter and continue
>>> processing of the chunk
>>> .1.. .... .... .... = Bit: Do report
>>> Parameter length: 4
>>
>> --
>> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-21 4:26 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-21 4:26 UTC (permalink / raw)
To: Michael Tuexen; +Cc: David Laight, Neil Horman, linux-sctp, linux-kernel
Hi,
sorry to get back late, the platform is running on KVM. and this
problem is resolved by moving to VMware environment, however, a new
problem is coming out, we noticed that the HB REQ is being ABORT from
client.
03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
[HB REQ] (from server to sctp router)
03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
[HB REQ] (from sctp router to client)
03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
[ABORT] (from client to sctp router)
03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
For the above packet flow, 10.165.250.22 is the server and
192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
SCTP router change the src address before forward the HB REQ to the
client.
But somehow the client is ABORT the HB REQ, any idea? is it related to
the HEARTBEAT information? or the checksum again>?
On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>
>> Your router does NOT change any field in the SCTP packet, but the
>> SCTP checksum was modified from
>> Checksum: 0xbaea49e5 (not verified)
>> to
>> Checksum: 0xa9a86d3f (not verified)
>> At least one of these is wrong. Read the tracefiles in wireshark and
>> enable checksum validation and wireshark will tell you which one is
>> correct. (That is why I asked for .pcap file instead of a .txt).
>>
>> My guess is that the initial checksum is correct and your box middlebox
>> not only changes the destination address and ttl field and header
>> checksum in the IP-header (which is expected) but also incorrectly the
>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>> must be the same.
> At the server have a look at the SNMP counters:
> cat /proc/net/sctp/snmp
> You should find a line staring with
> SctpChecksumErrors
> If the number reported there is positive, the node received packets
> with checksum errors.
>
> Best regards
> Michael
>>
>> Best regards
>> Michael
>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>
>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>> Encapsulation type: Ethernet (1)
>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>> [Time shift for this packet: 0.000000000 seconds]
>>> Epoch Time: 1483692769.662321000 seconds
>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>> [Time since reference or first frame: 0.000179000 seconds]
>>> Frame Number: 2
>>> Frame Length: 98 bytes (784 bits)
>>> Capture Length: 98 bytes (784 bits)
>>> [Frame is marked: False]
>>> [Frame is ignored: False]
>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>> address (factory default)
>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>> address (factory default)
>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>> Type: IPv4 (0x0800)
>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>> 0100 .... = Version: 4
>>> .... 0101 = Header Length: 20 bytes (5)
>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>> Transport codepoint '10' (2)
>>> Total Length: 84
>>> Identification: 0x0000 (0)
>>> Flags: 0x02 (Don't Fragment)
>>> 0... .... = Reserved bit: Not set
>>> .1.. .... = Don't fragment: Set
>>> ..0. .... = More fragments: Not set
>>> Fragment offset: 0
>>> Time to live: 63
>>> Protocol: SCTP (132)
>>> Header checksum: 0x1d3d [validation disabled]
>>> [Good: False]
>>> [Bad: False]
>>> Source: 192.168.206.83
>>> Destination: 192.168.206.66
>>> [Source GeoIP: Unknown]
>>> [Destination GeoIP: Unknown]
>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>> Port: 3868 (3868)
>>> Source port: 50001
>>> Destination port: 3868
>>> Verification tag: 0x00000000
>>> [Assocation index: 0]
>>> Checksum: 0xa9a86d3f (not verified)
>>>
>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>> Chunk type: INIT (1)
>>> 0... .... = Bit: Stop processing of the packet
>>> .0.. .... = Bit: Do not report
>>> Chunk flags: 0x00
>>> Chunk length: 52
>>> Initiate tag: 0xe79f40cb
>>> Advertised receiver window credit (a_rwnd): 62464
>>> Number of outbound streams: 3000
>>> Number of inbound streams: 3000
>>> Initial TSN: 176990880
>>> IPv4 address parameter (Address: 192.168.206.83)
>>> Parameter type: IPv4 address (0x0005)
>>> 0... .... .... .... = Bit: Stop processing of chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 8
>>> IP Version 4 address: 192.168.206.83
>>> IPv4 address parameter (Address: 192.168.1.83)
>>> Parameter type: IPv4 address (0x0005)
>>> 0... .... .... .... = Bit: Stop processing of chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 8
>>> IP Version 4 address: 192.168.1.83
>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>> Parameter type: Supported address types (0x000c)
>>> 0... .... .... .... = Bit: Stop processing of chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 8
>>> Supported address type: IPv6 address (6)
>>> Supported address type: IPv4 address (5)
>>> ECN parameter
>>> Parameter type: ECN (0x8000)
>>> 1... .... .... .... = Bit: Skip parameter and continue
>>> processing of the chunk
>>> .0.. .... .... .... = Bit: Do not report
>>> Parameter length: 4
>>> Forward TSN supported parameter
>>> Parameter type: Forward TSN supported (0xc000)
>>> 1... .... .... .... = Bit: Skip parameter and continue
>>> processing of the chunk
>>> .1.. .... .... .... = Bit: Do report
>>> Parameter length: 4
>>
>> --
>> 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
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-21 4:26 ` Sun Paul
@ 2017-02-21 15:53 ` Xin Long
-1 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-21 15:53 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi,
>
> sorry to get back late, the platform is running on KVM. and this
> problem is resolved by moving to VMware environment, however, a new
> problem is coming out, we noticed that the HB REQ is being ABORT from
> client.
>
>
> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
> [HB REQ] (from server to sctp router)
> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
> [HB REQ] (from sctp router to client)
> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
> [ABORT] (from client to sctp router)
>
> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>
> For the above packet flow, 10.165.250.22 is the server and
> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
> SCTP router change the src address before forward the HB REQ to the
> client.
>
> But somehow the client is ABORT the HB REQ, any idea? is it related to
> the HEARTBEAT information? or the checksum again>?
The incorrect checksum won't cause ABORT, but the abnormal HB REQ
could be, if HB information was modified when calculating the checksum
on router, the ABORT may be caused in client process.
is your SCTP router linux ? if yes, what's the kernel version ?
>
> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>
>>> Your router does NOT change any field in the SCTP packet, but the
>>> SCTP checksum was modified from
>>> Checksum: 0xbaea49e5 (not verified)
>>> to
>>> Checksum: 0xa9a86d3f (not verified)
>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>> enable checksum validation and wireshark will tell you which one is
>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>
>>> My guess is that the initial checksum is correct and your box middlebox
>>> not only changes the destination address and ttl field and header
>>> checksum in the IP-header (which is expected) but also incorrectly the
>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>> must be the same.
>> At the server have a look at the SNMP counters:
>> cat /proc/net/sctp/snmp
>> You should find a line staring with
>> SctpChecksumErrors
>> If the number reported there is positive, the node received packets
>> with checksum errors.
>>
>> Best regards
>> Michael
>>>
>>> Best regards
>>> Michael
>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>
>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>> Encapsulation type: Ethernet (1)
>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>> [Time shift for this packet: 0.000000000 seconds]
>>>> Epoch Time: 1483692769.662321000 seconds
>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>> Frame Number: 2
>>>> Frame Length: 98 bytes (784 bits)
>>>> Capture Length: 98 bytes (784 bits)
>>>> [Frame is marked: False]
>>>> [Frame is ignored: False]
>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>> address (factory default)
>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>> address (factory default)
>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>> Type: IPv4 (0x0800)
>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>> 0100 .... = Version: 4
>>>> .... 0101 = Header Length: 20 bytes (5)
>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>> Transport codepoint '10' (2)
>>>> Total Length: 84
>>>> Identification: 0x0000 (0)
>>>> Flags: 0x02 (Don't Fragment)
>>>> 0... .... = Reserved bit: Not set
>>>> .1.. .... = Don't fragment: Set
>>>> ..0. .... = More fragments: Not set
>>>> Fragment offset: 0
>>>> Time to live: 63
>>>> Protocol: SCTP (132)
>>>> Header checksum: 0x1d3d [validation disabled]
>>>> [Good: False]
>>>> [Bad: False]
>>>> Source: 192.168.206.83
>>>> Destination: 192.168.206.66
>>>> [Source GeoIP: Unknown]
>>>> [Destination GeoIP: Unknown]
>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>> Port: 3868 (3868)
>>>> Source port: 50001
>>>> Destination port: 3868
>>>> Verification tag: 0x00000000
>>>> [Assocation index: 0]
>>>> Checksum: 0xa9a86d3f (not verified)
>>>>
>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>> Chunk type: INIT (1)
>>>> 0... .... = Bit: Stop processing of the packet
>>>> .0.. .... = Bit: Do not report
>>>> Chunk flags: 0x00
>>>> Chunk length: 52
>>>> Initiate tag: 0xe79f40cb
>>>> Advertised receiver window credit (a_rwnd): 62464
>>>> Number of outbound streams: 3000
>>>> Number of inbound streams: 3000
>>>> Initial TSN: 176990880
>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>> Parameter type: IPv4 address (0x0005)
>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 8
>>>> IP Version 4 address: 192.168.206.83
>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>> Parameter type: IPv4 address (0x0005)
>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 8
>>>> IP Version 4 address: 192.168.1.83
>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>> Parameter type: Supported address types (0x000c)
>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 8
>>>> Supported address type: IPv6 address (6)
>>>> Supported address type: IPv4 address (5)
>>>> ECN parameter
>>>> Parameter type: ECN (0x8000)
>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>> processing of the chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 4
>>>> Forward TSN supported parameter
>>>> Parameter type: Forward TSN supported (0xc000)
>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>> processing of the chunk
>>>> .1.. .... .... .... = Bit: Do report
>>>> Parameter length: 4
>>>
>>> --
>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-21 15:53 ` Xin Long
0 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-21 15:53 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi,
>
> sorry to get back late, the platform is running on KVM. and this
> problem is resolved by moving to VMware environment, however, a new
> problem is coming out, we noticed that the HB REQ is being ABORT from
> client.
>
>
> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
> [HB REQ] (from server to sctp router)
> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
> [HB REQ] (from sctp router to client)
> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
> [ABORT] (from client to sctp router)
>
> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>
> For the above packet flow, 10.165.250.22 is the server and
> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
> SCTP router change the src address before forward the HB REQ to the
> client.
>
> But somehow the client is ABORT the HB REQ, any idea? is it related to
> the HEARTBEAT information? or the checksum again>?
The incorrect checksum won't cause ABORT, but the abnormal HB REQ
could be, if HB information was modified when calculating the checksum
on router, the ABORT may be caused in client process.
is your SCTP router linux ? if yes, what's the kernel version ?
>
> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>
>>> Your router does NOT change any field in the SCTP packet, but the
>>> SCTP checksum was modified from
>>> Checksum: 0xbaea49e5 (not verified)
>>> to
>>> Checksum: 0xa9a86d3f (not verified)
>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>> enable checksum validation and wireshark will tell you which one is
>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>
>>> My guess is that the initial checksum is correct and your box middlebox
>>> not only changes the destination address and ttl field and header
>>> checksum in the IP-header (which is expected) but also incorrectly the
>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>> must be the same.
>> At the server have a look at the SNMP counters:
>> cat /proc/net/sctp/snmp
>> You should find a line staring with
>> SctpChecksumErrors
>> If the number reported there is positive, the node received packets
>> with checksum errors.
>>
>> Best regards
>> Michael
>>>
>>> Best regards
>>> Michael
>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>
>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>> Encapsulation type: Ethernet (1)
>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>> [Time shift for this packet: 0.000000000 seconds]
>>>> Epoch Time: 1483692769.662321000 seconds
>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>> Frame Number: 2
>>>> Frame Length: 98 bytes (784 bits)
>>>> Capture Length: 98 bytes (784 bits)
>>>> [Frame is marked: False]
>>>> [Frame is ignored: False]
>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>> address (factory default)
>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>> address (factory default)
>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>> Type: IPv4 (0x0800)
>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>> 0100 .... = Version: 4
>>>> .... 0101 = Header Length: 20 bytes (5)
>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>> Transport codepoint '10' (2)
>>>> Total Length: 84
>>>> Identification: 0x0000 (0)
>>>> Flags: 0x02 (Don't Fragment)
>>>> 0... .... = Reserved bit: Not set
>>>> .1.. .... = Don't fragment: Set
>>>> ..0. .... = More fragments: Not set
>>>> Fragment offset: 0
>>>> Time to live: 63
>>>> Protocol: SCTP (132)
>>>> Header checksum: 0x1d3d [validation disabled]
>>>> [Good: False]
>>>> [Bad: False]
>>>> Source: 192.168.206.83
>>>> Destination: 192.168.206.66
>>>> [Source GeoIP: Unknown]
>>>> [Destination GeoIP: Unknown]
>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>> Port: 3868 (3868)
>>>> Source port: 50001
>>>> Destination port: 3868
>>>> Verification tag: 0x00000000
>>>> [Assocation index: 0]
>>>> Checksum: 0xa9a86d3f (not verified)
>>>>
>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>> Chunk type: INIT (1)
>>>> 0... .... = Bit: Stop processing of the packet
>>>> .0.. .... = Bit: Do not report
>>>> Chunk flags: 0x00
>>>> Chunk length: 52
>>>> Initiate tag: 0xe79f40cb
>>>> Advertised receiver window credit (a_rwnd): 62464
>>>> Number of outbound streams: 3000
>>>> Number of inbound streams: 3000
>>>> Initial TSN: 176990880
>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>> Parameter type: IPv4 address (0x0005)
>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 8
>>>> IP Version 4 address: 192.168.206.83
>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>> Parameter type: IPv4 address (0x0005)
>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 8
>>>> IP Version 4 address: 192.168.1.83
>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>> Parameter type: Supported address types (0x000c)
>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 8
>>>> Supported address type: IPv6 address (6)
>>>> Supported address type: IPv4 address (5)
>>>> ECN parameter
>>>> Parameter type: ECN (0x8000)
>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>> processing of the chunk
>>>> .0.. .... .... .... = Bit: Do not report
>>>> Parameter length: 4
>>>> Forward TSN supported parameter
>>>> Parameter type: Forward TSN supported (0xc000)
>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>> processing of the chunk
>>>> .1.. .... .... .... = Bit: Do report
>>>> Parameter length: 4
>>>
>>> --
>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-01-06 9:34 ` Sun Paul
` (2 preceding siblings ...)
(?)
@ 2017-02-21 18:51 ` Davide Caratti
-1 siblings, 0 replies; 75+ messages in thread
From: Davide Caratti @ 2017-02-21 18:51 UTC (permalink / raw)
To: linux-sctp
On Tue, 2017-02-21 at 12:26 +0800, Sun Paul wrote:
> Hi,
>
> sorry to get back late, the platform is running on KVM. and this
> problem is resolved by moving to VMware environment, however, a new
> problem is coming out, we noticed that the HB REQ is being ABORT from
> client.
hello Sun,
I'm working on some issues with SCTP checksums: sometimes the kernel does
not compute CRC32c on forwarded SCTP packets (see
http://www.spinics.net/lists/linux-sctp/msg05666.html); but apparently this
is a scenario where the opposite occurs (i.e. the kernel computes CRC32c
even if when it is not necessary _ see below):
> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
> >
> > >
> > > On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> > >
> > > Your router does NOT change any field in the SCTP packet, but the
> > > SCTP checksum was modified from
> > > Checksum: 0xbaea49e5 (not verified)
> > > to
> > > Checksum: 0xa9a86d3f (not verified)
> > > At least one of these is wrong.
what Michael says is correct: in case SCTP NAT did not translate port
numbers, the packet CRC32c should not be recomputed, because SCTP checksum
has no pseudo-header. The (RFC) patch below modifies netfilter SCTP NAT to
avoid useless calls to sctp_compute_csum() when source / destination port
is not changed (*).
------ 8< ------------
--- a/net/netfilter/nf_nat_proto_sctp.c
+++ b/net/netfilter/nf_nat_proto_sctp.c
@@ -33,6 +33,7 @@
enum nf_nat_manip_type maniptype)
{
sctp_sctphdr_t *hdr;
+ __be16 port_xlate = 0;
if (!skb_make_writable(skb, hdroff + sizeof(*hdr)))
return false;
@@ -41,14 +42,17 @@
if (maniptype = NF_NAT_MANIP_SRC) {
/* Get rid of src port */
+ port_xlate |= hdr->source ^ tuple->src.u.sctp.port;
hdr->source = tuple->src.u.sctp.port;
} else {
/* Get rid of dst port */
+ port_xlate |= hdr->dest ^ tuple->dst.u.sctp.port;
hdr->dest = tuple->dst.u.sctp.port;
}
if (skb->ip_summed != CHECKSUM_PARTIAL) {
- hdr->checksum = sctp_compute_cksum(skb, hdroff);
+ if (port_xlate)
+ hdr->checksum = sctp_compute_cksum(skb, hdroff);
skb->ip_summed = CHECKSUM_NONE;
}
------ >8 ------------
Please let me know if it can be useful in your setup.
Thank you in advance,
regards,
--
davide
Notes:
(*) how I tested this: on a two-namespace test setup, a
ncat server is running on namespace nat_test_b and listening for SCTP onÂ
eth1 (192.168.111.18:2000). On namespace nat_test_a, ncat client binds to
dummy0 (10.0.0.13) and connects to server through eth0 (192.168.111.17),
where a SNAT rule is configured; eth0 and eth1 are connected through a
switch. The following command is done on the client:
# perf probe -m nf_nat --add sctp_csum_update
# perf probe -m nf_nat --add sctp_csum_combine
# ip netns exec nat_test_a \
perf record -e '{probe:sctp_csum_combine,probe:sctp_csum_update}' -R -- \
ncat --sctp -c uname -s 10.0.0.13 -w1 192.168.111.18 2000
9 packets are received by the server:
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [INIT]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [INIT ACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [COOKIE ECHO]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [COOKIE ACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [DATA]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [SACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [SHUTDOWN]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [SHUTDOWN ACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [SHUTDOWN COMPLETE]
Before applying the patch:
# perf script | wc -l
9
After applying the patch:
# perf script | wc -l
0
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-21 15:53 ` Xin Long
@ 2017-02-22 1:12 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-22 1:12 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi
the router is actually is a linux running on RHEL6.8
(2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
forward.
On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi,
>>
>> sorry to get back late, the platform is running on KVM. and this
>> problem is resolved by moving to VMware environment, however, a new
>> problem is coming out, we noticed that the HB REQ is being ABORT from
>> client.
>>
>>
>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>> [HB REQ] (from server to sctp router)
>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>> [HB REQ] (from sctp router to client)
>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>> [ABORT] (from client to sctp router)
>>
>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>
>> For the above packet flow, 10.165.250.22 is the server and
>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>> SCTP router change the src address before forward the HB REQ to the
>> client.
>>
>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>> the HEARTBEAT information? or the checksum again>?
> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
> could be, if HB information was modified when calculating the checksum
> on router, the ABORT may be caused in client process.
>
> is your SCTP router linux ? if yes, what's the kernel version ?
>
>>
>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>
>>>> Your router does NOT change any field in the SCTP packet, but the
>>>> SCTP checksum was modified from
>>>> Checksum: 0xbaea49e5 (not verified)
>>>> to
>>>> Checksum: 0xa9a86d3f (not verified)
>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>> enable checksum validation and wireshark will tell you which one is
>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>
>>>> My guess is that the initial checksum is correct and your box middlebox
>>>> not only changes the destination address and ttl field and header
>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>> must be the same.
>>> At the server have a look at the SNMP counters:
>>> cat /proc/net/sctp/snmp
>>> You should find a line staring with
>>> SctpChecksumErrors
>>> If the number reported there is positive, the node received packets
>>> with checksum errors.
>>>
>>> Best regards
>>> Michael
>>>>
>>>> Best regards
>>>> Michael
>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>
>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>> Encapsulation type: Ethernet (1)
>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>> Frame Number: 2
>>>>> Frame Length: 98 bytes (784 bits)
>>>>> Capture Length: 98 bytes (784 bits)
>>>>> [Frame is marked: False]
>>>>> [Frame is ignored: False]
>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>> address (factory default)
>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>> address (factory default)
>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>> Type: IPv4 (0x0800)
>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>> 0100 .... = Version: 4
>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>> Transport codepoint '10' (2)
>>>>> Total Length: 84
>>>>> Identification: 0x0000 (0)
>>>>> Flags: 0x02 (Don't Fragment)
>>>>> 0... .... = Reserved bit: Not set
>>>>> .1.. .... = Don't fragment: Set
>>>>> ..0. .... = More fragments: Not set
>>>>> Fragment offset: 0
>>>>> Time to live: 63
>>>>> Protocol: SCTP (132)
>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>> [Good: False]
>>>>> [Bad: False]
>>>>> Source: 192.168.206.83
>>>>> Destination: 192.168.206.66
>>>>> [Source GeoIP: Unknown]
>>>>> [Destination GeoIP: Unknown]
>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>> Port: 3868 (3868)
>>>>> Source port: 50001
>>>>> Destination port: 3868
>>>>> Verification tag: 0x00000000
>>>>> [Assocation index: 0]
>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>
>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>> Chunk type: INIT (1)
>>>>> 0... .... = Bit: Stop processing of the packet
>>>>> .0.. .... = Bit: Do not report
>>>>> Chunk flags: 0x00
>>>>> Chunk length: 52
>>>>> Initiate tag: 0xe79f40cb
>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>> Number of outbound streams: 3000
>>>>> Number of inbound streams: 3000
>>>>> Initial TSN: 176990880
>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>> Parameter type: IPv4 address (0x0005)
>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 8
>>>>> IP Version 4 address: 192.168.206.83
>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>> Parameter type: IPv4 address (0x0005)
>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 8
>>>>> IP Version 4 address: 192.168.1.83
>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>> Parameter type: Supported address types (0x000c)
>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 8
>>>>> Supported address type: IPv6 address (6)
>>>>> Supported address type: IPv4 address (5)
>>>>> ECN parameter
>>>>> Parameter type: ECN (0x8000)
>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>> processing of the chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 4
>>>>> Forward TSN supported parameter
>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>> processing of the chunk
>>>>> .1.. .... .... .... = Bit: Do report
>>>>> Parameter length: 4
>>>>
>>>> --
>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-22 1:12 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-22 1:12 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi
the router is actually is a linux running on RHEL6.8
(2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
forward.
On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi,
>>
>> sorry to get back late, the platform is running on KVM. and this
>> problem is resolved by moving to VMware environment, however, a new
>> problem is coming out, we noticed that the HB REQ is being ABORT from
>> client.
>>
>>
>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>> [HB REQ] (from server to sctp router)
>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>> [HB REQ] (from sctp router to client)
>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>> [ABORT] (from client to sctp router)
>>
>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>
>> For the above packet flow, 10.165.250.22 is the server and
>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>> SCTP router change the src address before forward the HB REQ to the
>> client.
>>
>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>> the HEARTBEAT information? or the checksum again>?
> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
> could be, if HB information was modified when calculating the checksum
> on router, the ABORT may be caused in client process.
>
> is your SCTP router linux ? if yes, what's the kernel version ?
>
>>
>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>
>>>> Your router does NOT change any field in the SCTP packet, but the
>>>> SCTP checksum was modified from
>>>> Checksum: 0xbaea49e5 (not verified)
>>>> to
>>>> Checksum: 0xa9a86d3f (not verified)
>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>> enable checksum validation and wireshark will tell you which one is
>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>
>>>> My guess is that the initial checksum is correct and your box middlebox
>>>> not only changes the destination address and ttl field and header
>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>> must be the same.
>>> At the server have a look at the SNMP counters:
>>> cat /proc/net/sctp/snmp
>>> You should find a line staring with
>>> SctpChecksumErrors
>>> If the number reported there is positive, the node received packets
>>> with checksum errors.
>>>
>>> Best regards
>>> Michael
>>>>
>>>> Best regards
>>>> Michael
>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>
>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>> Encapsulation type: Ethernet (1)
>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>> Frame Number: 2
>>>>> Frame Length: 98 bytes (784 bits)
>>>>> Capture Length: 98 bytes (784 bits)
>>>>> [Frame is marked: False]
>>>>> [Frame is ignored: False]
>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>> address (factory default)
>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>> address (factory default)
>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>> Type: IPv4 (0x0800)
>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>> 0100 .... = Version: 4
>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>> Transport codepoint '10' (2)
>>>>> Total Length: 84
>>>>> Identification: 0x0000 (0)
>>>>> Flags: 0x02 (Don't Fragment)
>>>>> 0... .... = Reserved bit: Not set
>>>>> .1.. .... = Don't fragment: Set
>>>>> ..0. .... = More fragments: Not set
>>>>> Fragment offset: 0
>>>>> Time to live: 63
>>>>> Protocol: SCTP (132)
>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>> [Good: False]
>>>>> [Bad: False]
>>>>> Source: 192.168.206.83
>>>>> Destination: 192.168.206.66
>>>>> [Source GeoIP: Unknown]
>>>>> [Destination GeoIP: Unknown]
>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>> Port: 3868 (3868)
>>>>> Source port: 50001
>>>>> Destination port: 3868
>>>>> Verification tag: 0x00000000
>>>>> [Assocation index: 0]
>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>
>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>> Chunk type: INIT (1)
>>>>> 0... .... = Bit: Stop processing of the packet
>>>>> .0.. .... = Bit: Do not report
>>>>> Chunk flags: 0x00
>>>>> Chunk length: 52
>>>>> Initiate tag: 0xe79f40cb
>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>> Number of outbound streams: 3000
>>>>> Number of inbound streams: 3000
>>>>> Initial TSN: 176990880
>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>> Parameter type: IPv4 address (0x0005)
>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 8
>>>>> IP Version 4 address: 192.168.206.83
>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>> Parameter type: IPv4 address (0x0005)
>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 8
>>>>> IP Version 4 address: 192.168.1.83
>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>> Parameter type: Supported address types (0x000c)
>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 8
>>>>> Supported address type: IPv6 address (6)
>>>>> Supported address type: IPv4 address (5)
>>>>> ECN parameter
>>>>> Parameter type: ECN (0x8000)
>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>> processing of the chunk
>>>>> .0.. .... .... .... = Bit: Do not report
>>>>> Parameter length: 4
>>>>> Forward TSN supported parameter
>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>> processing of the chunk
>>>>> .1.. .... .... .... = Bit: Do report
>>>>> Parameter length: 4
>>>>
>>>> --
>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-22 1:12 ` Sun Paul
@ 2017-02-22 2:00 ` Xin Long
-1 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-22 2:00 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi
>
> the router is actually is a linux running on RHEL6.8
> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
> forward.
https://bugzilla.redhat.com/show_bug.cgi?id=1412038
sctp_manip_pkt->sctp_compute_cksum:
struct sctphdr *sh = sctp_hdr(sub);
But in rhel6, skb->transport_header is not yet set at that time.
This patch should be backported into rhel6.
commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Jul 15 20:03:19 2013 -0700
ipv4: set transport header earlier
>
> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi,
>>>
>>> sorry to get back late, the platform is running on KVM. and this
>>> problem is resolved by moving to VMware environment, however, a new
>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>> client.
>>>
>>>
>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>> [HB REQ] (from server to sctp router)
>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>> [HB REQ] (from sctp router to client)
>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>> [ABORT] (from client to sctp router)
>>>
>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>
>>> For the above packet flow, 10.165.250.22 is the server and
>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>> SCTP router change the src address before forward the HB REQ to the
>>> client.
>>>
>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>> the HEARTBEAT information? or the checksum again>?
>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>> could be, if HB information was modified when calculating the checksum
>> on router, the ABORT may be caused in client process.
>>
>> is your SCTP router linux ? if yes, what's the kernel version ?
>>
>>>
>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>
>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>> SCTP checksum was modified from
>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>> to
>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>> enable checksum validation and wireshark will tell you which one is
>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>
>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>> not only changes the destination address and ttl field and header
>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>> must be the same.
>>>> At the server have a look at the SNMP counters:
>>>> cat /proc/net/sctp/snmp
>>>> You should find a line staring with
>>>> SctpChecksumErrors
>>>> If the number reported there is positive, the node received packets
>>>> with checksum errors.
>>>>
>>>> Best regards
>>>> Michael
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>
>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>> Encapsulation type: Ethernet (1)
>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>> Frame Number: 2
>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>> [Frame is marked: False]
>>>>>> [Frame is ignored: False]
>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>> address (factory default)
>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>> address (factory default)
>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>> Type: IPv4 (0x0800)
>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>> 0100 .... = Version: 4
>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>> Transport codepoint '10' (2)
>>>>>> Total Length: 84
>>>>>> Identification: 0x0000 (0)
>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>> 0... .... = Reserved bit: Not set
>>>>>> .1.. .... = Don't fragment: Set
>>>>>> ..0. .... = More fragments: Not set
>>>>>> Fragment offset: 0
>>>>>> Time to live: 63
>>>>>> Protocol: SCTP (132)
>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>> [Good: False]
>>>>>> [Bad: False]
>>>>>> Source: 192.168.206.83
>>>>>> Destination: 192.168.206.66
>>>>>> [Source GeoIP: Unknown]
>>>>>> [Destination GeoIP: Unknown]
>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>> Port: 3868 (3868)
>>>>>> Source port: 50001
>>>>>> Destination port: 3868
>>>>>> Verification tag: 0x00000000
>>>>>> [Assocation index: 0]
>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>
>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>> Chunk type: INIT (1)
>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>> .0.. .... = Bit: Do not report
>>>>>> Chunk flags: 0x00
>>>>>> Chunk length: 52
>>>>>> Initiate tag: 0xe79f40cb
>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>> Number of outbound streams: 3000
>>>>>> Number of inbound streams: 3000
>>>>>> Initial TSN: 176990880
>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 8
>>>>>> IP Version 4 address: 192.168.206.83
>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 8
>>>>>> IP Version 4 address: 192.168.1.83
>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>> Parameter type: Supported address types (0x000c)
>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 8
>>>>>> Supported address type: IPv6 address (6)
>>>>>> Supported address type: IPv4 address (5)
>>>>>> ECN parameter
>>>>>> Parameter type: ECN (0x8000)
>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>> processing of the chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 4
>>>>>> Forward TSN supported parameter
>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>> processing of the chunk
>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>> Parameter length: 4
>>>>>
>>>>> --
>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-22 2:00 ` Xin Long
0 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-22 2:00 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi
>
> the router is actually is a linux running on RHEL6.8
> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
> forward.
https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
sctp_manip_pkt->sctp_compute_cksum:
struct sctphdr *sh = sctp_hdr(sub);
But in rhel6, skb->transport_header is not yet set at that time.
This patch should be backported into rhel6.
commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Jul 15 20:03:19 2013 -0700
ipv4: set transport header earlier
>
> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi,
>>>
>>> sorry to get back late, the platform is running on KVM. and this
>>> problem is resolved by moving to VMware environment, however, a new
>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>> client.
>>>
>>>
>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>> [HB REQ] (from server to sctp router)
>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>> [HB REQ] (from sctp router to client)
>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>> [ABORT] (from client to sctp router)
>>>
>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>
>>> For the above packet flow, 10.165.250.22 is the server and
>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>> SCTP router change the src address before forward the HB REQ to the
>>> client.
>>>
>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>> the HEARTBEAT information? or the checksum again>?
>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>> could be, if HB information was modified when calculating the checksum
>> on router, the ABORT may be caused in client process.
>>
>> is your SCTP router linux ? if yes, what's the kernel version ?
>>
>>>
>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>
>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>> SCTP checksum was modified from
>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>> to
>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>> enable checksum validation and wireshark will tell you which one is
>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>
>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>> not only changes the destination address and ttl field and header
>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>> must be the same.
>>>> At the server have a look at the SNMP counters:
>>>> cat /proc/net/sctp/snmp
>>>> You should find a line staring with
>>>> SctpChecksumErrors
>>>> If the number reported there is positive, the node received packets
>>>> with checksum errors.
>>>>
>>>> Best regards
>>>> Michael
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>
>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>> Encapsulation type: Ethernet (1)
>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>> Frame Number: 2
>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>> [Frame is marked: False]
>>>>>> [Frame is ignored: False]
>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>> address (factory default)
>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>> address (factory default)
>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>> Type: IPv4 (0x0800)
>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>> 0100 .... = Version: 4
>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>> Transport codepoint '10' (2)
>>>>>> Total Length: 84
>>>>>> Identification: 0x0000 (0)
>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>> 0... .... = Reserved bit: Not set
>>>>>> .1.. .... = Don't fragment: Set
>>>>>> ..0. .... = More fragments: Not set
>>>>>> Fragment offset: 0
>>>>>> Time to live: 63
>>>>>> Protocol: SCTP (132)
>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>> [Good: False]
>>>>>> [Bad: False]
>>>>>> Source: 192.168.206.83
>>>>>> Destination: 192.168.206.66
>>>>>> [Source GeoIP: Unknown]
>>>>>> [Destination GeoIP: Unknown]
>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>> Port: 3868 (3868)
>>>>>> Source port: 50001
>>>>>> Destination port: 3868
>>>>>> Verification tag: 0x00000000
>>>>>> [Assocation index: 0]
>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>
>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>> Chunk type: INIT (1)
>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>> .0.. .... = Bit: Do not report
>>>>>> Chunk flags: 0x00
>>>>>> Chunk length: 52
>>>>>> Initiate tag: 0xe79f40cb
>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>> Number of outbound streams: 3000
>>>>>> Number of inbound streams: 3000
>>>>>> Initial TSN: 176990880
>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 8
>>>>>> IP Version 4 address: 192.168.206.83
>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 8
>>>>>> IP Version 4 address: 192.168.1.83
>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>> Parameter type: Supported address types (0x000c)
>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 8
>>>>>> Supported address type: IPv6 address (6)
>>>>>> Supported address type: IPv4 address (5)
>>>>>> ECN parameter
>>>>>> Parameter type: ECN (0x8000)
>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>> processing of the chunk
>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>> Parameter length: 4
>>>>>> Forward TSN supported parameter
>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>> processing of the chunk
>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>> Parameter length: 4
>>>>>
>>>>> --
>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-22 2:00 ` Xin Long
@ 2017-02-22 2:29 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-22 2:29 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi Xin
do you mean we need to patch the kernel?
On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi
>>
>> the router is actually is a linux running on RHEL6.8
>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>> forward.
> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>
> sctp_manip_pkt->sctp_compute_cksum:
> struct sctphdr *sh = sctp_hdr(sub);
>
> But in rhel6, skb->transport_header is not yet set at that time.
> This patch should be backported into rhel6.
>
> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
> Author: Eric Dumazet <edumazet@google.com>
> Date: Mon Jul 15 20:03:19 2013 -0700
>
> ipv4: set transport header earlier
>
>
>>
>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> sorry to get back late, the platform is running on KVM. and this
>>>> problem is resolved by moving to VMware environment, however, a new
>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>> client.
>>>>
>>>>
>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>> [HB REQ] (from server to sctp router)
>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>> [HB REQ] (from sctp router to client)
>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>> [ABORT] (from client to sctp router)
>>>>
>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>
>>>> For the above packet flow, 10.165.250.22 is the server and
>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>> SCTP router change the src address before forward the HB REQ to the
>>>> client.
>>>>
>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>> the HEARTBEAT information? or the checksum again>?
>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>> could be, if HB information was modified when calculating the checksum
>>> on router, the ABORT may be caused in client process.
>>>
>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>
>>>>
>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>
>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>> SCTP checksum was modified from
>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>> to
>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>
>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>> not only changes the destination address and ttl field and header
>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>> must be the same.
>>>>> At the server have a look at the SNMP counters:
>>>>> cat /proc/net/sctp/snmp
>>>>> You should find a line staring with
>>>>> SctpChecksumErrors
>>>>> If the number reported there is positive, the node received packets
>>>>> with checksum errors.
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>
>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>> Frame Number: 2
>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>> [Frame is marked: False]
>>>>>>> [Frame is ignored: False]
>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>> address (factory default)
>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>> address (factory default)
>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>> Type: IPv4 (0x0800)
>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>> 0100 .... = Version: 4
>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>> Transport codepoint '10' (2)
>>>>>>> Total Length: 84
>>>>>>> Identification: 0x0000 (0)
>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>> ..0. .... = More fragments: Not set
>>>>>>> Fragment offset: 0
>>>>>>> Time to live: 63
>>>>>>> Protocol: SCTP (132)
>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>> [Good: False]
>>>>>>> [Bad: False]
>>>>>>> Source: 192.168.206.83
>>>>>>> Destination: 192.168.206.66
>>>>>>> [Source GeoIP: Unknown]
>>>>>>> [Destination GeoIP: Unknown]
>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>> Port: 3868 (3868)
>>>>>>> Source port: 50001
>>>>>>> Destination port: 3868
>>>>>>> Verification tag: 0x00000000
>>>>>>> [Assocation index: 0]
>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>
>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>> Chunk type: INIT (1)
>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>> .0.. .... = Bit: Do not report
>>>>>>> Chunk flags: 0x00
>>>>>>> Chunk length: 52
>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>> Number of outbound streams: 3000
>>>>>>> Number of inbound streams: 3000
>>>>>>> Initial TSN: 176990880
>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> Supported address type: IPv6 address (6)
>>>>>>> Supported address type: IPv4 address (5)
>>>>>>> ECN parameter
>>>>>>> Parameter type: ECN (0x8000)
>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>> processing of the chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 4
>>>>>>> Forward TSN supported parameter
>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>> processing of the chunk
>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>> Parameter length: 4
>>>>>>
>>>>>> --
>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-22 2:29 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-22 2:29 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi Xin
do you mean we need to patch the kernel?
On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi
>>
>> the router is actually is a linux running on RHEL6.8
>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>> forward.
> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>
> sctp_manip_pkt->sctp_compute_cksum:
> struct sctphdr *sh = sctp_hdr(sub);
>
> But in rhel6, skb->transport_header is not yet set at that time.
> This patch should be backported into rhel6.
>
> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
> Author: Eric Dumazet <edumazet@google.com>
> Date: Mon Jul 15 20:03:19 2013 -0700
>
> ipv4: set transport header earlier
>
>
>>
>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> sorry to get back late, the platform is running on KVM. and this
>>>> problem is resolved by moving to VMware environment, however, a new
>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>> client.
>>>>
>>>>
>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>> [HB REQ] (from server to sctp router)
>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>> [HB REQ] (from sctp router to client)
>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>> [ABORT] (from client to sctp router)
>>>>
>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>
>>>> For the above packet flow, 10.165.250.22 is the server and
>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>> SCTP router change the src address before forward the HB REQ to the
>>>> client.
>>>>
>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>> the HEARTBEAT information? or the checksum again>?
>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>> could be, if HB information was modified when calculating the checksum
>>> on router, the ABORT may be caused in client process.
>>>
>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>
>>>>
>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>
>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>> SCTP checksum was modified from
>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>> to
>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>
>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>> not only changes the destination address and ttl field and header
>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>> must be the same.
>>>>> At the server have a look at the SNMP counters:
>>>>> cat /proc/net/sctp/snmp
>>>>> You should find a line staring with
>>>>> SctpChecksumErrors
>>>>> If the number reported there is positive, the node received packets
>>>>> with checksum errors.
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>
>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>> Frame Number: 2
>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>> [Frame is marked: False]
>>>>>>> [Frame is ignored: False]
>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>> address (factory default)
>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>> address (factory default)
>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>> Type: IPv4 (0x0800)
>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>> 0100 .... = Version: 4
>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>> Transport codepoint '10' (2)
>>>>>>> Total Length: 84
>>>>>>> Identification: 0x0000 (0)
>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>> ..0. .... = More fragments: Not set
>>>>>>> Fragment offset: 0
>>>>>>> Time to live: 63
>>>>>>> Protocol: SCTP (132)
>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>> [Good: False]
>>>>>>> [Bad: False]
>>>>>>> Source: 192.168.206.83
>>>>>>> Destination: 192.168.206.66
>>>>>>> [Source GeoIP: Unknown]
>>>>>>> [Destination GeoIP: Unknown]
>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>> Port: 3868 (3868)
>>>>>>> Source port: 50001
>>>>>>> Destination port: 3868
>>>>>>> Verification tag: 0x00000000
>>>>>>> [Assocation index: 0]
>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>
>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>> Chunk type: INIT (1)
>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>> .0.. .... = Bit: Do not report
>>>>>>> Chunk flags: 0x00
>>>>>>> Chunk length: 52
>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>> Number of outbound streams: 3000
>>>>>>> Number of inbound streams: 3000
>>>>>>> Initial TSN: 176990880
>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> Supported address type: IPv6 address (6)
>>>>>>> Supported address type: IPv4 address (5)
>>>>>>> ECN parameter
>>>>>>> Parameter type: ECN (0x8000)
>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>> processing of the chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 4
>>>>>>> Forward TSN supported parameter
>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>> processing of the chunk
>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>> Parameter length: 4
>>>>>>
>>>>>> --
>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-22 2:29 ` Sun Paul
@ 2017-02-22 3:03 ` Xin Long
-1 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-22 3:03 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi Xin
>
> do you mean we need to patch the kernel?
Yups, pls comment on that bz if it's really needed for your env.
A z-stream kernel may be available for that issue soon.
Thanks.
>
>
>
> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi
>>>
>>> the router is actually is a linux running on RHEL6.8
>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>> forward.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>
>> sctp_manip_pkt->sctp_compute_cksum:
>> struct sctphdr *sh = sctp_hdr(sub);
>>
>> But in rhel6, skb->transport_header is not yet set at that time.
>> This patch should be backported into rhel6.
>>
>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>> Author: Eric Dumazet <edumazet@google.com>
>> Date: Mon Jul 15 20:03:19 2013 -0700
>>
>> ipv4: set transport header earlier
>>
>>
>>>
>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>> client.
>>>>>
>>>>>
>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>> [HB REQ] (from server to sctp router)
>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>> [HB REQ] (from sctp router to client)
>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>> [ABORT] (from client to sctp router)
>>>>>
>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>
>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>> client.
>>>>>
>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>> the HEARTBEAT information? or the checksum again>?
>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>> could be, if HB information was modified when calculating the checksum
>>>> on router, the ABORT may be caused in client process.
>>>>
>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>
>>>>>
>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>
>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>> SCTP checksum was modified from
>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>> to
>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>
>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>> not only changes the destination address and ttl field and header
>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>> must be the same.
>>>>>> At the server have a look at the SNMP counters:
>>>>>> cat /proc/net/sctp/snmp
>>>>>> You should find a line staring with
>>>>>> SctpChecksumErrors
>>>>>> If the number reported there is positive, the node received packets
>>>>>> with checksum errors.
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>>
>>>>>>> Best regards
>>>>>>> Michael
>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>> Frame Number: 2
>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>> [Frame is marked: False]
>>>>>>>> [Frame is ignored: False]
>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>> address (factory default)
>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>> address (factory default)
>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>> 0100 .... = Version: 4
>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>> Transport codepoint '10' (2)
>>>>>>>> Total Length: 84
>>>>>>>> Identification: 0x0000 (0)
>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>> Fragment offset: 0
>>>>>>>> Time to live: 63
>>>>>>>> Protocol: SCTP (132)
>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>> [Good: False]
>>>>>>>> [Bad: False]
>>>>>>>> Source: 192.168.206.83
>>>>>>>> Destination: 192.168.206.66
>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>> Port: 3868 (3868)
>>>>>>>> Source port: 50001
>>>>>>>> Destination port: 3868
>>>>>>>> Verification tag: 0x00000000
>>>>>>>> [Assocation index: 0]
>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>
>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>> Chunk type: INIT (1)
>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>> Chunk flags: 0x00
>>>>>>>> Chunk length: 52
>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>> Number of outbound streams: 3000
>>>>>>>> Number of inbound streams: 3000
>>>>>>>> Initial TSN: 176990880
>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 8
>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 8
>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 8
>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>> ECN parameter
>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>> processing of the chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 4
>>>>>>>> Forward TSN supported parameter
>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>> processing of the chunk
>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>> Parameter length: 4
>>>>>>>
>>>>>>> --
>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-22 3:03 ` Xin Long
0 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-22 3:03 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi Xin
>
> do you mean we need to patch the kernel?
Yups, pls comment on that bz if it's really needed for your env.
A z-stream kernel may be available for that issue soon.
Thanks.
>
>
>
> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi
>>>
>>> the router is actually is a linux running on RHEL6.8
>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>> forward.
>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>
>> sctp_manip_pkt->sctp_compute_cksum:
>> struct sctphdr *sh = sctp_hdr(sub);
>>
>> But in rhel6, skb->transport_header is not yet set at that time.
>> This patch should be backported into rhel6.
>>
>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>> Author: Eric Dumazet <edumazet@google.com>
>> Date: Mon Jul 15 20:03:19 2013 -0700
>>
>> ipv4: set transport header earlier
>>
>>
>>>
>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>> client.
>>>>>
>>>>>
>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>> [HB REQ] (from server to sctp router)
>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>> [HB REQ] (from sctp router to client)
>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>> [ABORT] (from client to sctp router)
>>>>>
>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>
>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>> client.
>>>>>
>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>> the HEARTBEAT information? or the checksum again>?
>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>> could be, if HB information was modified when calculating the checksum
>>>> on router, the ABORT may be caused in client process.
>>>>
>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>
>>>>>
>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>
>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>> SCTP checksum was modified from
>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>> to
>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>
>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>> not only changes the destination address and ttl field and header
>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>> must be the same.
>>>>>> At the server have a look at the SNMP counters:
>>>>>> cat /proc/net/sctp/snmp
>>>>>> You should find a line staring with
>>>>>> SctpChecksumErrors
>>>>>> If the number reported there is positive, the node received packets
>>>>>> with checksum errors.
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>>
>>>>>>> Best regards
>>>>>>> Michael
>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>> Frame Number: 2
>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>> [Frame is marked: False]
>>>>>>>> [Frame is ignored: False]
>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>> address (factory default)
>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>> address (factory default)
>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>> 0100 .... = Version: 4
>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>> Transport codepoint '10' (2)
>>>>>>>> Total Length: 84
>>>>>>>> Identification: 0x0000 (0)
>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>> Fragment offset: 0
>>>>>>>> Time to live: 63
>>>>>>>> Protocol: SCTP (132)
>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>> [Good: False]
>>>>>>>> [Bad: False]
>>>>>>>> Source: 192.168.206.83
>>>>>>>> Destination: 192.168.206.66
>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>> Port: 3868 (3868)
>>>>>>>> Source port: 50001
>>>>>>>> Destination port: 3868
>>>>>>>> Verification tag: 0x00000000
>>>>>>>> [Assocation index: 0]
>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>
>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>> Chunk type: INIT (1)
>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>> Chunk flags: 0x00
>>>>>>>> Chunk length: 52
>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>> Number of outbound streams: 3000
>>>>>>>> Number of inbound streams: 3000
>>>>>>>> Initial TSN: 176990880
>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 8
>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 8
>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 8
>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>> ECN parameter
>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>> processing of the chunk
>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>> Parameter length: 4
>>>>>>>> Forward TSN supported parameter
>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>> processing of the chunk
>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>> Parameter length: 4
>>>>>>>
>>>>>>> --
>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-22 3:03 ` Xin Long
@ 2017-02-23 5:30 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-23 5:30 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
does this fixed in RHEL7?
On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi Xin
>>
>> do you mean we need to patch the kernel?
> Yups, pls comment on that bz if it's really needed for your env.
> A z-stream kernel may be available for that issue soon.
>
> Thanks.
>
>>
>>
>>
>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> Hi
>>>>
>>>> the router is actually is a linux running on RHEL6.8
>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>> forward.
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>>
>>> sctp_manip_pkt->sctp_compute_cksum:
>>> struct sctphdr *sh = sctp_hdr(sub);
>>>
>>> But in rhel6, skb->transport_header is not yet set at that time.
>>> This patch should be backported into rhel6.
>>>
>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>> Author: Eric Dumazet <edumazet@google.com>
>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>
>>> ipv4: set transport header earlier
>>>
>>>
>>>>
>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>> client.
>>>>>>
>>>>>>
>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>> [HB REQ] (from server to sctp router)
>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>> [HB REQ] (from sctp router to client)
>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>> [ABORT] (from client to sctp router)
>>>>>>
>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>
>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>> client.
>>>>>>
>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>> could be, if HB information was modified when calculating the checksum
>>>>> on router, the ABORT may be caused in client process.
>>>>>
>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>
>>>>>>
>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>
>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>> SCTP checksum was modified from
>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>> to
>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>
>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>> must be the same.
>>>>>>> At the server have a look at the SNMP counters:
>>>>>>> cat /proc/net/sctp/snmp
>>>>>>> You should find a line staring with
>>>>>>> SctpChecksumErrors
>>>>>>> If the number reported there is positive, the node received packets
>>>>>>> with checksum errors.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Michael
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>> Frame Number: 2
>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>> [Frame is marked: False]
>>>>>>>>> [Frame is ignored: False]
>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>> address (factory default)
>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>> address (factory default)
>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>> Total Length: 84
>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>> Fragment offset: 0
>>>>>>>>> Time to live: 63
>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>> [Good: False]
>>>>>>>>> [Bad: False]
>>>>>>>>> Source: 192.168.206.83
>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>> Port: 3868 (3868)
>>>>>>>>> Source port: 50001
>>>>>>>>> Destination port: 3868
>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>> [Assocation index: 0]
>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>
>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>> Chunk flags: 0x00
>>>>>>>>> Chunk length: 52
>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>> Initial TSN: 176990880
>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 8
>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 8
>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 8
>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>> ECN parameter
>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>> processing of the chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 4
>>>>>>>>> Forward TSN supported parameter
>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>> processing of the chunk
>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>> Parameter length: 4
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-23 5:30 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-23 5:30 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
does this fixed in RHEL7?
On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi Xin
>>
>> do you mean we need to patch the kernel?
> Yups, pls comment on that bz if it's really needed for your env.
> A z-stream kernel may be available for that issue soon.
>
> Thanks.
>
>>
>>
>>
>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> Hi
>>>>
>>>> the router is actually is a linux running on RHEL6.8
>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>> forward.
>>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>>
>>> sctp_manip_pkt->sctp_compute_cksum:
>>> struct sctphdr *sh = sctp_hdr(sub);
>>>
>>> But in rhel6, skb->transport_header is not yet set at that time.
>>> This patch should be backported into rhel6.
>>>
>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>> Author: Eric Dumazet <edumazet@google.com>
>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>
>>> ipv4: set transport header earlier
>>>
>>>
>>>>
>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>> client.
>>>>>>
>>>>>>
>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>> [HB REQ] (from server to sctp router)
>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>> [HB REQ] (from sctp router to client)
>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>> [ABORT] (from client to sctp router)
>>>>>>
>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>
>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>> client.
>>>>>>
>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>> could be, if HB information was modified when calculating the checksum
>>>>> on router, the ABORT may be caused in client process.
>>>>>
>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>
>>>>>>
>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>
>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>> SCTP checksum was modified from
>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>> to
>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>
>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>> must be the same.
>>>>>>> At the server have a look at the SNMP counters:
>>>>>>> cat /proc/net/sctp/snmp
>>>>>>> You should find a line staring with
>>>>>>> SctpChecksumErrors
>>>>>>> If the number reported there is positive, the node received packets
>>>>>>> with checksum errors.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Michael
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>> Frame Number: 2
>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>> [Frame is marked: False]
>>>>>>>>> [Frame is ignored: False]
>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>> address (factory default)
>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>> address (factory default)
>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>> Total Length: 84
>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>> Fragment offset: 0
>>>>>>>>> Time to live: 63
>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>> [Good: False]
>>>>>>>>> [Bad: False]
>>>>>>>>> Source: 192.168.206.83
>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>> Port: 3868 (3868)
>>>>>>>>> Source port: 50001
>>>>>>>>> Destination port: 3868
>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>> [Assocation index: 0]
>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>
>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>> Chunk flags: 0x00
>>>>>>>>> Chunk length: 52
>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>> Initial TSN: 176990880
>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 8
>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 8
>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 8
>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>> ECN parameter
>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>> processing of the chunk
>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>> Parameter length: 4
>>>>>>>>> Forward TSN supported parameter
>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>> processing of the chunk
>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>> Parameter length: 4
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-23 5:30 ` Sun Paul
@ 2017-02-23 6:07 ` Xin Long
-1 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-23 6:07 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
> does this fixed in RHEL7?
yes, I think so.
>
> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi Xin
>>>
>>> do you mean we need to patch the kernel?
>> Yups, pls comment on that bz if it's really needed for your env.
>> A z-stream kernel may be available for that issue soon.
>>
>> Thanks.
>>
>>>
>>>
>>>
>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> Hi
>>>>>
>>>>> the router is actually is a linux running on RHEL6.8
>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>> forward.
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>>>
>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>
>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>> This patch should be backported into rhel6.
>>>>
>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>> Author: Eric Dumazet <edumazet@google.com>
>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>
>>>> ipv4: set transport header earlier
>>>>
>>>>
>>>>>
>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>> client.
>>>>>>>
>>>>>>>
>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>
>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>
>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>> client.
>>>>>>>
>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>> on router, the ABORT may be caused in client process.
>>>>>>
>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>
>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>> SCTP checksum was modified from
>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>> to
>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>
>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>> must be the same.
>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>> You should find a line staring with
>>>>>>>> SctpChecksumErrors
>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>> with checksum errors.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Michael
>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>> Frame Number: 2
>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>> address (factory default)
>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>> address (factory default)
>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>> Total Length: 84
>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>> Fragment offset: 0
>>>>>>>>>> Time to live: 63
>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>> [Good: False]
>>>>>>>>>> [Bad: False]
>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>> Source port: 50001
>>>>>>>>>> Destination port: 3868
>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>
>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>> Chunk length: 52
>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 8
>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 8
>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 8
>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>> ECN parameter
>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>> processing of the chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 4
>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>> processing of the chunk
>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>> Parameter length: 4
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-23 6:07 ` Xin Long
0 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-23 6:07 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
> does this fixed in RHEL7?
yes, I think so.
>
> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi Xin
>>>
>>> do you mean we need to patch the kernel?
>> Yups, pls comment on that bz if it's really needed for your env.
>> A z-stream kernel may be available for that issue soon.
>>
>> Thanks.
>>
>>>
>>>
>>>
>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> Hi
>>>>>
>>>>> the router is actually is a linux running on RHEL6.8
>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>> forward.
>>>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>>>
>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>
>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>> This patch should be backported into rhel6.
>>>>
>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>> Author: Eric Dumazet <edumazet@google.com>
>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>
>>>> ipv4: set transport header earlier
>>>>
>>>>
>>>>>
>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>> client.
>>>>>>>
>>>>>>>
>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>
>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>
>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>> client.
>>>>>>>
>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>> on router, the ABORT may be caused in client process.
>>>>>>
>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>
>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>> SCTP checksum was modified from
>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>> to
>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>
>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>> must be the same.
>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>> You should find a line staring with
>>>>>>>> SctpChecksumErrors
>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>> with checksum errors.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Michael
>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>> Frame Number: 2
>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>> address (factory default)
>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>> address (factory default)
>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>> Total Length: 84
>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>> Fragment offset: 0
>>>>>>>>>> Time to live: 63
>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>> [Good: False]
>>>>>>>>>> [Bad: False]
>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>> Source port: 50001
>>>>>>>>>> Destination port: 3868
>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>
>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>> Chunk length: 52
>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 8
>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 8
>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 8
>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>> ECN parameter
>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>> processing of the chunk
>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>> Parameter length: 4
>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>> processing of the chunk
>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>> Parameter length: 4
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-23 6:07 ` Xin Long
@ 2017-02-27 9:01 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-27 9:01 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi, can I confirm that the problem is on the Linux router itself or on
both server and client?
On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>> does this fixed in RHEL7?
> yes, I think so.
>
>>
>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> Hi Xin
>>>>
>>>> do you mean we need to patch the kernel?
>>> Yups, pls comment on that bz if it's really needed for your env.
>>> A z-stream kernel may be available for that issue soon.
>>>
>>> Thanks.
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>> Hi
>>>>>>
>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>> forward.
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>>>>
>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>
>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>> This patch should be backported into rhel6.
>>>>>
>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>
>>>>> ipv4: set transport header earlier
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>> client.
>>>>>>>>
>>>>>>>>
>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>
>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>
>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>> client.
>>>>>>>>
>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>
>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>
>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>> to
>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>
>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>> must be the same.
>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>> You should find a line staring with
>>>>>>>>> SctpChecksumErrors
>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>> with checksum errors.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Michael
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Michael
>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>> address (factory default)
>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>> address (factory default)
>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>> Total Length: 84
>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>> Time to live: 63
>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>> [Good: False]
>>>>>>>>>>> [Bad: False]
>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>> Source port: 50001
>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>
>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>> ECN parameter
>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>> processing of the chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>> processing of the chunk
>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-27 9:01 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-02-27 9:01 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi, can I confirm that the problem is on the Linux router itself or on
both server and client?
On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>> does this fixed in RHEL7?
> yes, I think so.
>
>>
>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> Hi Xin
>>>>
>>>> do you mean we need to patch the kernel?
>>> Yups, pls comment on that bz if it's really needed for your env.
>>> A z-stream kernel may be available for that issue soon.
>>>
>>> Thanks.
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>> Hi
>>>>>>
>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>> forward.
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>>>>
>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>
>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>> This patch should be backported into rhel6.
>>>>>
>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>
>>>>> ipv4: set transport header earlier
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>> client.
>>>>>>>>
>>>>>>>>
>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>
>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>
>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>> client.
>>>>>>>>
>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>
>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>
>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>> to
>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>
>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>> must be the same.
>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>> You should find a line staring with
>>>>>>>>> SctpChecksumErrors
>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>> with checksum errors.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Michael
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Michael
>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>> address (factory default)
>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>> address (factory default)
>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>> Total Length: 84
>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>> Time to live: 63
>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>> [Good: False]
>>>>>>>>>>> [Bad: False]
>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>> Source port: 50001
>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>
>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>> ECN parameter
>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>> processing of the chunk
>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>> processing of the chunk
>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-27 9:01 ` Sun Paul
@ 2017-02-27 15:06 ` Xin Long
-1 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-27 15:06 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi, can I confirm that the problem is on the Linux router itself or on
> both server and client?
>
try with a new kernel in router, like build and install a upstream
kernel on your route machine.
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
https://kernelnewbies.org/KernelBuild :
part "Setting up your kernel configuration" and
part "Building the kernel"
> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>> does this fixed in RHEL7?
>> yes, I think so.
>>
>>>
>>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> Hi Xin
>>>>>
>>>>> do you mean we need to patch the kernel?
>>>> Yups, pls comment on that bz if it's really needed for your env.
>>>> A z-stream kernel may be available for that issue soon.
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>>> forward.
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>>>>>
>>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>>
>>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>>> This patch should be backported into rhel6.
>>>>>>
>>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>>
>>>>>> ipv4: set transport header earlier
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>>
>>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>>
>>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>>
>>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>>> to
>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>>
>>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>>> must be the same.
>>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>>> You should find a line staring with
>>>>>>>>>> SctpChecksumErrors
>>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>>> with checksum errors.
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Michael
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>> Michael
>>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>>> Total Length: 84
>>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>>> Time to live: 63
>>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>>> [Good: False]
>>>>>>>>>>>> [Bad: False]
>>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>>> Source port: 50001
>>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>
>>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>>> ECN parameter
>>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-02-27 15:06 ` Xin Long
0 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-02-27 15:06 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi, can I confirm that the problem is on the Linux router itself or on
> both server and client?
>
try with a new kernel in router, like build and install a upstream
kernel on your route machine.
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
https://kernelnewbies.org/KernelBuild :
part "Setting up your kernel configuration" and
part "Building the kernel"
> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>> does this fixed in RHEL7?
>> yes, I think so.
>>
>>>
>>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> Hi Xin
>>>>>
>>>>> do you mean we need to patch the kernel?
>>>> Yups, pls comment on that bz if it's really needed for your env.
>>>> A z-stream kernel may be available for that issue soon.
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>>> forward.
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>>>>>
>>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>>
>>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>>> This patch should be backported into rhel6.
>>>>>>
>>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>>
>>>>>> ipv4: set transport header earlier
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>>
>>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>>
>>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>>
>>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>>> to
>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>>
>>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>>> must be the same.
>>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>>> You should find a line staring with
>>>>>>>>>> SctpChecksumErrors
>>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>>> with checksum errors.
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Michael
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>> Michael
>>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>>> Total Length: 84
>>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>>> Time to live: 63
>>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>>> [Good: False]
>>>>>>>>>>>> [Bad: False]
>>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>>> Source port: 50001
>>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>
>>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>>> ECN parameter
>>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-02-27 15:06 ` Xin Long
@ 2017-03-01 4:15 ` Sun Paul
-1 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-03-01 4:15 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi Xin
I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the
same issue still occur.
any idea?
On Mon, Feb 27, 2017 at 11:06 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi, can I confirm that the problem is on the Linux router itself or on
>> both server and client?
>>
> try with a new kernel in router, like build and install a upstream
> kernel on your route machine.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>
> https://kernelnewbies.org/KernelBuild :
> part "Setting up your kernel configuration" and
> part "Building the kernel"
>
>> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> does this fixed in RHEL7?
>>> yes, I think so.
>>>
>>>>
>>>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>> Hi Xin
>>>>>>
>>>>>> do you mean we need to patch the kernel?
>>>>> Yups, pls comment on that bz if it's really needed for your env.
>>>>> A z-stream kernel may be available for that issue soon.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>>>> forward.
>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>>>>>>
>>>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>>>
>>>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>>>> This patch should be backported into rhel6.
>>>>>>>
>>>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>>>
>>>>>>> ipv4: set transport header earlier
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>>>
>>>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>>>
>>>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>>>
>>>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>>>> to
>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>>>
>>>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>>>> must be the same.
>>>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>>>> You should find a line staring with
>>>>>>>>>>> SctpChecksumErrors
>>>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>>>> with checksum errors.
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>> Michael
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards
>>>>>>>>>>>> Michael
>>>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>>>> Total Length: 84
>>>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>>>> Time to live: 63
>>>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>>>> [Good: False]
>>>>>>>>>>>>> [Bad: False]
>>>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>>>> Source port: 50001
>>>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>>
>>>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>>>> ECN parameter
>>>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-03-01 4:15 ` Sun Paul
0 siblings, 0 replies; 75+ messages in thread
From: Sun Paul @ 2017-03-01 4:15 UTC (permalink / raw)
To: Xin Long
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
Hi Xin
I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the
same issue still occur.
any idea?
On Mon, Feb 27, 2017 at 11:06 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul <paulrbk@gmail.com> wrote:
>> Hi, can I confirm that the problem is on the Linux router itself or on
>> both server and client?
>>
> try with a new kernel in router, like build and install a upstream
> kernel on your route machine.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>
> https://kernelnewbies.org/KernelBuild :
> part "Setting up your kernel configuration" and
> part "Building the kernel"
>
>> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>> does this fixed in RHEL7?
>>> yes, I think so.
>>>
>>>>
>>>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>> Hi Xin
>>>>>>
>>>>>> do you mean we need to patch the kernel?
>>>>> Yups, pls comment on that bz if it's really needed for your env.
>>>>> A z-stream kernel may be available for that issue soon.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>>>> forward.
>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>>>>>>
>>>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>>>
>>>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>>>> This patch should be backported into rhel6.
>>>>>>>
>>>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>>>
>>>>>>> ipv4: set transport header earlier
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>>>
>>>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>>>
>>>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>>>> client.
>>>>>>>>>>
>>>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>>>
>>>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>>>> to
>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>>>
>>>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>>>> must be the same.
>>>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>>>> You should find a line staring with
>>>>>>>>>>> SctpChecksumErrors
>>>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>>>> with checksum errors.
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>> Michael
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards
>>>>>>>>>>>> Michael
>>>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>>>> Total Length: 84
>>>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>>>> Time to live: 63
>>>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>>>> [Good: False]
>>>>>>>>>>>>> [Bad: False]
>>>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>>>> Source port: 50001
>>>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>>
>>>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>>>> ECN parameter
>>>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
2017-03-01 4:15 ` Sun Paul
@ 2017-03-01 6:43 ` Xin Long
-1 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-03-01 6:43 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Wed, Mar 1, 2017 at 12:15 PM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi Xin
>
> I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the
> same issue still occur.
>
> any idea?
>
what I can only see is :
03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
this ABORT might be caused by no assoc.
can you show more details about your env ?
1. the iptables rule for nat in router (# iptables -L -t nat)
2. the asocs info in client (# cat /proc/net/sctp/assocs)
3. more packet you captured, like 4-shake and some packets
right before these 3 packets.
4. conntrack info in router (# cat /proc/net/nf_conntrack)
> On Mon, Feb 27, 2017 at 11:06 PM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi, can I confirm that the problem is on the Linux router itself or on
>>> both server and client?
>>>
>> try with a new kernel in router, like build and install a upstream
>> kernel on your route machine.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>>
>> https://kernelnewbies.org/KernelBuild :
>> part "Setting up your kernel configuration" and
>> part "Building the kernel"
>>
>>> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> does this fixed in RHEL7?
>>>> yes, I think so.
>>>>
>>>>>
>>>>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>> Hi Xin
>>>>>>>
>>>>>>> do you mean we need to patch the kernel?
>>>>>> Yups, pls comment on that bz if it's really needed for your env.
>>>>>> A z-stream kernel may be available for that issue soon.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>>>>> forward.
>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>>>>>>>
>>>>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>>>>
>>>>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>>>>> This patch should be backported into rhel6.
>>>>>>>>
>>>>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>>>>
>>>>>>>> ipv4: set transport header earlier
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>>>>
>>>>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>>>>
>>>>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>>>>
>>>>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>>>>> to
>>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>>>>
>>>>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>>>>> must be the same.
>>>>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>>>>> You should find a line staring with
>>>>>>>>>>>> SctpChecksumErrors
>>>>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>>>>> with checksum errors.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards
>>>>>>>>>>>> Michael
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>> Michael
>>>>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>>>>> Total Length: 84
>>>>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>>>>> Time to live: 63
>>>>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>>>>> [Good: False]
>>>>>>>>>>>>>> [Bad: False]
>>>>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>>>>> Source port: 50001
>>>>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>>>>> ECN parameter
>>>>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Problem on SCTP
@ 2017-03-01 6:43 ` Xin Long
0 siblings, 0 replies; 75+ messages in thread
From: Xin Long @ 2017-03-01 6:43 UTC (permalink / raw)
To: Sun Paul
Cc: Michael Tuexen, David Laight, Neil Horman, linux-sctp, linux-kernel
On Wed, Mar 1, 2017 at 12:15 PM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi Xin
>
> I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the
> same issue still occur.
>
> any idea?
>
what I can only see is :
03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
this ABORT might be caused by no assoc.
can you show more details about your env ?
1. the iptables rule for nat in router (# iptables -L -t nat)
2. the asocs info in client (# cat /proc/net/sctp/assocs)
3. more packet you captured, like 4-shake and some packets
right before these 3 packets.
4. conntrack info in router (# cat /proc/net/nf_conntrack)
> On Mon, Feb 27, 2017 at 11:06 PM, Xin Long <lucien.xin@gmail.com> wrote:
>> On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>> Hi, can I confirm that the problem is on the Linux router itself or on
>>> both server and client?
>>>
>> try with a new kernel in router, like build and install a upstream
>> kernel on your route machine.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>>
>> https://kernelnewbies.org/KernelBuild :
>> part "Setting up your kernel configuration" and
>> part "Building the kernel"
>>
>>> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>> does this fixed in RHEL7?
>>>> yes, I think so.
>>>>
>>>>>
>>>>> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>> Hi Xin
>>>>>>>
>>>>>>> do you mean we need to patch the kernel?
>>>>>> Yups, pls comment on that bz if it's really needed for your env.
>>>>>> A z-stream kernel may be available for that issue soon.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> the router is actually is a linux running on RHEL6.8
>>>>>>>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>>>>>>>> forward.
>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id\x1412038
>>>>>>>>
>>>>>>>> sctp_manip_pkt->sctp_compute_cksum:
>>>>>>>> struct sctphdr *sh = sctp_hdr(sub);
>>>>>>>>
>>>>>>>> But in rhel6, skb->transport_header is not yet set at that time.
>>>>>>>> This patch should be backported into rhel6.
>>>>>>>>
>>>>>>>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>>>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>>>> Date: Mon Jul 15 20:03:19 2013 -0700
>>>>>>>>
>>>>>>>> ipv4: set transport header earlier
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>>>>>>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> sorry to get back late, the platform is running on KVM. and this
>>>>>>>>>>> problem is resolved by moving to VMware environment, however, a new
>>>>>>>>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>>> [HB REQ] (from server to sctp router)
>>>>>>>>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>>>>>>>>> [HB REQ] (from sctp router to client)
>>>>>>>>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>>>>>>>>> [ABORT] (from client to sctp router)
>>>>>>>>>>>
>>>>>>>>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>>>>>>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>>>>>>>>
>>>>>>>>>>> For the above packet flow, 10.165.250.22 is the server and
>>>>>>>>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>>>>>>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>>>>>>>>> SCTP router change the src address before forward the HB REQ to the
>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>>>>>>>>> the HEARTBEAT information? or the checksum again>?
>>>>>>>>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>>>>>>>>> could be, if HB information was modified when calculating the checksum
>>>>>>>>>> on router, the ABORT may be caused in client process.
>>>>>>>>>>
>>>>>>>>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>>>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>>>>>>>>> SCTP checksum was modified from
>>>>>>>>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>>>>>>>>> to
>>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>>>>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>>>>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>>>>>>>>
>>>>>>>>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>>>>>>>>> not only changes the destination address and ttl field and header
>>>>>>>>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>>>>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>>>>>>>>> must be the same.
>>>>>>>>>>>> At the server have a look at the SNMP counters:
>>>>>>>>>>>> cat /proc/net/sctp/snmp
>>>>>>>>>>>> You should find a line staring with
>>>>>>>>>>>> SctpChecksumErrors
>>>>>>>>>>>> If the number reported there is positive, the node received packets
>>>>>>>>>>>> with checksum errors.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards
>>>>>>>>>>>> Michael
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>> Michael
>>>>>>>>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>>>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>>>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>>>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>>>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>>>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>>>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>>>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>>>>>>>>> Frame Number: 2
>>>>>>>>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>>>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>>>>>>>>> [Frame is marked: False]
>>>>>>>>>>>>>> [Frame is ignored: False]
>>>>>>>>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>>>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>>>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>>>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>>>>>>>>> address (factory default)
>>>>>>>>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>>>>>>>>> Type: IPv4 (0x0800)
>>>>>>>>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>>>>>>>>> 0100 .... = Version: 4
>>>>>>>>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>>>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>>>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>>>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>>>>>>>>> Transport codepoint '10' (2)
>>>>>>>>>>>>>> Total Length: 84
>>>>>>>>>>>>>> Identification: 0x0000 (0)
>>>>>>>>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>>>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>>>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>>>>>>>>> ..0. .... = More fragments: Not set
>>>>>>>>>>>>>> Fragment offset: 0
>>>>>>>>>>>>>> Time to live: 63
>>>>>>>>>>>>>> Protocol: SCTP (132)
>>>>>>>>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>>>>>>>>> [Good: False]
>>>>>>>>>>>>>> [Bad: False]
>>>>>>>>>>>>>> Source: 192.168.206.83
>>>>>>>>>>>>>> Destination: 192.168.206.66
>>>>>>>>>>>>>> [Source GeoIP: Unknown]
>>>>>>>>>>>>>> [Destination GeoIP: Unknown]
>>>>>>>>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>>>>>>>>> Port: 3868 (3868)
>>>>>>>>>>>>>> Source port: 50001
>>>>>>>>>>>>>> Destination port: 3868
>>>>>>>>>>>>>> Verification tag: 0x00000000
>>>>>>>>>>>>>> [Assocation index: 0]
>>>>>>>>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>>>>>>>>> Chunk type: INIT (1)
>>>>>>>>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>>>>>>>>> .0.. .... = Bit: Do not report
>>>>>>>>>>>>>> Chunk flags: 0x00
>>>>>>>>>>>>>> Chunk length: 52
>>>>>>>>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>>>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>>>>>>>>> Number of outbound streams: 3000
>>>>>>>>>>>>>> Number of inbound streams: 3000
>>>>>>>>>>>>>> Initial TSN: 176990880
>>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>>>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>>>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>>>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>>>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>>>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 8
>>>>>>>>>>>>>> Supported address type: IPv6 address (6)
>>>>>>>>>>>>>> Supported address type: IPv4 address (5)
>>>>>>>>>>>>>> ECN parameter
>>>>>>>>>>>>>> Parameter type: ECN (0x8000)
>>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>>> Forward TSN supported parameter
>>>>>>>>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>>>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>>>>>>>>> processing of the chunk
>>>>>>>>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>>>>>>>>> Parameter length: 4
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2017-03-01 7:45 UTC | newest]
Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-06 9:34 Problem on SCTP Sun Paul
2017-01-06 9:34 ` Sun Paul
2017-01-06 11:43 ` Marcelo Ricardo Leitner
2017-01-06 11:43 ` Marcelo Ricardo Leitner
2017-01-09 2:06 ` Sun Paul
2017-01-09 2:06 ` Sun Paul
2017-01-06 12:37 ` Neil Horman
2017-01-06 12:37 ` Neil Horman
2017-01-09 2:08 ` Sun Paul
2017-01-09 2:08 ` Sun Paul
2017-01-09 2:30 ` Sun Paul
2017-01-09 2:30 ` Sun Paul
2017-01-09 9:51 ` David Laight
2017-01-09 9:51 ` David Laight
2017-01-09 10:00 ` Sun Paul
2017-01-09 10:00 ` Sun Paul
2017-01-09 12:25 ` Neil Horman
2017-01-09 12:25 ` Neil Horman
2017-01-09 16:31 ` Sun Paul
2017-01-09 16:31 ` Sun Paul
2017-01-09 19:18 ` Neil Horman
2017-01-09 19:18 ` Neil Horman
2017-01-10 1:30 ` Sun Paul
2017-01-10 1:30 ` Sun Paul
2017-01-10 1:31 ` Sun Paul
2017-01-10 1:31 ` Sun Paul
2017-01-10 14:33 ` Neil Horman
2017-01-10 14:33 ` Neil Horman
2017-01-11 8:39 ` Sun Paul
2017-01-11 8:39 ` Sun Paul
2017-01-11 12:57 ` Neil Horman
2017-01-11 12:57 ` Neil Horman
2017-01-12 9:30 ` Sun Paul
2017-01-12 9:30 ` Sun Paul
2017-01-12 9:51 ` David Laight
2017-01-12 9:51 ` David Laight
2017-01-12 10:53 ` Michael Tuexen
2017-01-12 10:53 ` Michael Tuexen
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:29 ` Sun Paul
2017-01-13 3:29 ` Sun Paul
2017-01-13 9:43 ` Michael Tuexen
2017-01-13 9:43 ` Michael Tuexen
2017-01-13 13:19 ` Michael Tuexen
2017-01-13 13:19 ` Michael Tuexen
2017-02-21 4:26 ` Sun Paul
2017-02-21 4:26 ` Sun Paul
2017-02-21 15:53 ` Xin Long
2017-02-21 15:53 ` Xin Long
2017-02-22 1:12 ` Sun Paul
2017-02-22 1:12 ` Sun Paul
2017-02-22 2:00 ` Xin Long
2017-02-22 2:00 ` Xin Long
2017-02-22 2:29 ` Sun Paul
2017-02-22 2:29 ` Sun Paul
2017-02-22 3:03 ` Xin Long
2017-02-22 3:03 ` Xin Long
2017-02-23 5:30 ` Sun Paul
2017-02-23 5:30 ` Sun Paul
2017-02-23 6:07 ` Xin Long
2017-02-23 6:07 ` Xin Long
2017-02-27 9:01 ` Sun Paul
2017-02-27 9:01 ` Sun Paul
2017-02-27 15:06 ` Xin Long
2017-02-27 15:06 ` Xin Long
2017-03-01 4:15 ` Sun Paul
2017-03-01 4:15 ` Sun Paul
2017-03-01 6:43 ` Xin Long
2017-03-01 6:43 ` Xin Long
2017-01-16 18:47 ` Marcelo Ricardo Leitner
2017-01-16 18:47 ` Marcelo Ricardo Leitner
2017-02-21 18:51 ` Davide Caratti
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.