| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Jan 2017 09:33:52 -0500
From: Neil Horman <nhorman@...driver.com>
To: Sun Paul <paulrbk@...il.com>
Cc: David Laight <David.Laight@...lab.com>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Problem on SCTP
On 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@...driver.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@...driver.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@...lab.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@...r.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@...r.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
Powered by blists - more mailing lists