Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1552636 > unrolled thread
| Started by | Sun Paul <paulrbk@gmail.com> |
|---|---|
| First post | 2017-01-06 10:40 +0100 |
| Last post | 2017-01-16 19:50 +0100 |
| Articles | 20 on this page of 25 — 5 participants |
Back to article view | Back to linux.kernel
Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-06 10:40 +0100
Re: Problem on SCTP Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> - 2017-01-06 12:50 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-09 03:10 +0100
Re: Problem on SCTP Neil Horman <nhorman@tuxdriver.com> - 2017-01-06 13:50 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-09 03:10 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-09 03:40 +0100
RE: Problem on SCTP David Laight <David.Laight@ACULAB.COM> - 2017-01-09 11:00 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-09 11:10 +0100
Re: Problem on SCTP Neil Horman <nhorman@tuxdriver.com> - 2017-01-09 13:30 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-09 17:40 +0100
Re: Problem on SCTP Neil Horman <nhorman@tuxdriver.com> - 2017-01-09 20:20 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-10 02:40 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-10 02:40 +0100
Re: Problem on SCTP Neil Horman <nhorman@tuxdriver.com> - 2017-01-10 15:40 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-11 09:40 +0100
Re: Problem on SCTP Neil Horman <nhorman@tuxdriver.com> - 2017-01-11 14:00 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-12 10:40 +0100
RE: Problem on SCTP David Laight <David.Laight@ACULAB.COM> - 2017-01-12 11:00 +0100
Re: Problem on SCTP Michael Tuexen <Michael.Tuexen@lurchi.franken.de> - 2017-01-12 12:20 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-13 04:30 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-13 04:30 +0100
Re: Problem on SCTP Sun Paul <paulrbk@gmail.com> - 2017-01-13 04:40 +0100
Re: Problem on SCTP Michael Tuexen <Michael.Tuexen@lurchi.franken.de> - 2017-01-13 10:50 +0100
Re: Problem on SCTP Michael Tuexen <Michael.Tuexen@lurchi.franken.de> - 2017-01-13 14:20 +0100
Re: Problem on SCTP Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> - 2017-01-16 19:50 +0100
Page 1 of 2 [1] 2 Next page →
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-06 10:40 +0100 |
| Subject | Problem on SCTP |
| Message-ID | <sWza9-8fH-7@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> |
|---|---|
| Date | 2017-01-06 12:50 +0100 |
| Message-ID | <sWBbY-1l7-35@gated-at.bofh.it> |
| In reply to | #1552636 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-09 03:10 +0100 |
| Message-ID | <sXxzj-6jh-9@gated-at.bofh.it> |
| In reply to | #1552716 |
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 >>
[toc] | [prev] | [next] | [standalone]
| From | Neil Horman <nhorman@tuxdriver.com> |
|---|---|
| Date | 2017-01-06 13:50 +0100 |
| Message-ID | <sWC81-20x-19@gated-at.bofh.it> |
| In reply to | #1552636 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-09 03:10 +0100 |
| Message-ID | <sXxzj-6jh-7@gated-at.bofh.it> |
| In reply to | #1552757 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-09 03:40 +0100 |
| Message-ID | <sXy2m-6t3-19@gated-at.bofh.it> |
| In reply to | #1554011 |
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 >>
[toc] | [prev] | [next] | [standalone]
| From | David Laight <David.Laight@ACULAB.COM> |
|---|---|
| Date | 2017-01-09 11:00 +0100 |
| Message-ID | <sXEUf-2wC-27@gated-at.bofh.it> |
| In reply to | #1554011 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-09 11:10 +0100 |
| Message-ID | <sXF3Q-2PI-27@gated-at.bofh.it> |
| In reply to | #1554185 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | Neil Horman <nhorman@tuxdriver.com> |
|---|---|
| Date | 2017-01-09 13:30 +0100 |
| Message-ID | <sXHfk-48s-21@gated-at.bofh.it> |
| In reply to | #1554193 |
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 > > >
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-09 17:40 +0100 |
| Message-ID | <sXL9h-6vS-43@gated-at.bofh.it> |
| In reply to | #1554272 |
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 >> > >>
[toc] | [prev] | [next] | [standalone]
| From | Neil Horman <nhorman@tuxdriver.com> |
|---|---|
| Date | 2017-01-09 20:20 +0100 |
| Message-ID | <sXNE6-89F-9@gated-at.bofh.it> |
| In reply to | #1554475 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-10 02:40 +0100 |
| Message-ID | <sXTzQ-39s-15@gated-at.bofh.it> |
| In reply to | #1554622 |
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
>>>
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-10 02:40 +0100 |
| Message-ID | <sXTzQ-39s-17@gated-at.bofh.it> |
| In reply to | #1554622 |
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
>>
[toc] | [prev] | [next] | [standalone]
| From | Neil Horman <nhorman@tuxdriver.com> |
|---|---|
| Date | 2017-01-10 15:40 +0100 |
| Message-ID | <sY5KG-2vR-41@gated-at.bofh.it> |
| In reply to | #1554865 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-11 09:40 +0100 |
| Message-ID | <sYmBP-4Dt-1@gated-at.bofh.it> |
| In reply to | #1555470 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | Neil Horman <nhorman@tuxdriver.com> |
|---|---|
| Date | 2017-01-11 14:00 +0100 |
| Message-ID | <sYqFr-72T-19@gated-at.bofh.it> |
| In reply to | #1556278 |
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 > > >
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-12 10:40 +0100 |
| Message-ID | <sYK1r-2hi-7@gated-at.bofh.it> |
| In reply to | #1556466 |
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 >> > >>
[toc] | [prev] | [next] | [standalone]
| From | David Laight <David.Laight@ACULAB.COM> |
|---|---|
| Date | 2017-01-12 11:00 +0100 |
| Message-ID | <sYKkN-2oa-5@gated-at.bofh.it> |
| In reply to | #1557242 |
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
[toc] | [prev] | [next] | [standalone]
| From | Michael Tuexen <Michael.Tuexen@lurchi.franken.de> |
|---|---|
| Date | 2017-01-12 12:20 +0100 |
| Message-ID | <sYLAd-3jp-1@gated-at.bofh.it> |
| In reply to | #1557258 |
> 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"ú!
[toc] | [prev] | [next] | [standalone]
| From | Sun Paul <paulrbk@gmail.com> |
|---|---|
| Date | 2017-01-13 04:30 +0100 |
| Message-ID | <sZ0IV-49E-3@gated-at.bofh.it> |
| In reply to | #1557368 |
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" ú!
>>
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web