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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> > >> > 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 >> > >> -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
