Re: Strange problem with SCTP+IPv6

> On 26. Jun 2020, at 18:13, David Laight wrote: > > From: Xin Long >> Sent: 23 June 2020 11:14 It looks like a bug to me. Testing with this test app here, I can see the INIT_ACK being sent with a bunch of ipv4 addresses in it and that's unexpected for a v6only socket. As is, it's

RE: Strange problem with SCTP+IPv6

From: Xin Long > Sent: 23 June 2020 11:14 > > > It looks like a bug to me. Testing with this test app here, I can see > > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and > > > that's unexpected for a v6only socket. As is, it's the server saying > > > "I'm available at these

Re: Strange problem with SCTP+IPv6

inyard wrote: >>>>>>>>>> >>>>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard >>>>>>>>>>> wrote:

Re: Strange problem with SCTP+IPv6

22 June 2020 19:33 > >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote: > >>>>>>>> > >>>>>>>> On Mon, Jun 22,

Re: Strange problem with SCTP+IPv6

at 08:01:24PM +0200, Michael Tuexen wrote: > > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote: > > > > > >>> > > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > > >>

Re: Strange problem with SCTP+IPv6

t;>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote: >>>>>>>> >>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey M

Re: Strange problem with SCTP+IPv6

> >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> I've stu

Re: Strange problem with SCTP+IPv6

9:33 >>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: >>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote: >>>>>> >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>>>> On

Re: Strange problem with SCTP+IPv6

; > > > On 22. Jun 2020, at 18:57, Corey Minyard wrote: > > > > > > > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard > > > > >> wrote

Re: Strange problem with SCTP+IPv6

t;> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: >>>>>> >>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>>> sctp liste

Re: Strange problem with SCTP+IPv6

; > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > > > >>> > > > >>> I've stumbled upon a strange problem with SCTP and IPv6.

Re: Strange problem with SCTP+IPv6

rd wrote: > > > > >>> > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard > > > > >>>> wrote: > > > > >>

Re: Strange problem with SCTP+IPv6

g wrote: > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard > > > >>>> wrote: > > > >>>>> > > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I > > > >>

Re: Strange problem with SCTP+IPv6

0, Michael Tuexen wrote: > > >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote: > > >>> > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > > >>

RE: Strange problem with SCTP+IPv6

t;> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > > >>> > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > >

Re: Strange problem with SCTP+IPv6

t;>> > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > >>>>> > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an > >&g

Re: Strange problem with SCTP+IPv6

>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: >>>>> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, >>>>>

Re: Strange problem with SCTP+IPv6

On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote: > > On 22. Jun 2020, at 18:57, Corey Minyard wrote: > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > >>> >

Re: Strange problem with SCTP+IPv6

> On 22. Jun 2020, at 18:57, Corey Minyard wrote: > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: >>> >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >&g

Re: Strange problem with SCTP+IPv6

On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote: > On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > > > > I've stumbled upon a strange problem with SCTP and IPv6. If I create an > > sctp listening socket on :: and set the IPV6_V6ONLY socket option o

Re: Strange problem with SCTP+IPv6

> On 22. Jun 2020, at 14:01, Xin Long wrote: > > On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: >> >> I've stumbled upon a strange problem with SCTP and IPv6. If I create an >> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,

Re: Strange problem with SCTP+IPv6

On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote: > > I've stumbled upon a strange problem with SCTP and IPv6. If I create an > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, > then I make a connection to it using ::1, the connection will drop after &

Strange problem with SCTP+IPv6

I've stumbled upon a strange problem with SCTP and IPv6. If I create an sctp listening socket on :: and set the IPV6_V6ONLY socket option on it, then I make a connection to it using ::1, the connection will drop after 2.5 seconds with an ECONNRESET error. It only happens on SCTP, it doesn't have

Re: Problem on SCTP

On Wed, Mar 1, 2017 at 12:15 PM, Sun Paul wrote: > Hi Xin > > I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the > same issue still occur. > > any idea? > what I can only see is : 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]

Re: Problem on SCTP

On Wed, Mar 1, 2017 at 12:15 PM, Sun Paul wrote: > Hi Xin > > I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the > same issue still occur. > > any idea? > what I can only see is : 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ] 03:32:37.928717 IP

Re: Problem on SCTP

Hi Xin I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the same issue still occur. any idea? On Mon, Feb 27, 2017 at 11:06 PM, Xin Long wrote: > On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul wrote: >> Hi, can I confirm that the problem is on

Re: Problem on SCTP

Hi Xin I have used 3.10.0-514.6.2.el7.x86_64 on Centos7 and tessted. the same issue still occur. any idea? On Mon, Feb 27, 2017 at 11:06 PM, Xin Long wrote: > On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul wrote: >> Hi, can I confirm that the problem is on the Linux router itself or on >> both

Re: Problem on SCTP

On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul wrote: > Hi, can I confirm that the problem is on the Linux router itself or on > both server and client? > try with a new kernel in router, like build and install a upstream kernel on your route machine.

Re: Problem on SCTP

On Mon, Feb 27, 2017 at 5:01 PM, Sun Paul wrote: > Hi, can I confirm that the problem is on the Linux router itself or on > both server and client? > try with a new kernel in router, like build and install a upstream kernel on your route machine.

Re: Problem on SCTP

Hi, can I confirm that the problem is on the Linux router itself or on both server and client? On Thu, Feb 23, 2017 at 2:07 PM, Xin Long wrote: > On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote: >> does this fixed in RHEL7? > yes, I think so. > >> >> On

Re: Problem on SCTP

Hi, can I confirm that the problem is on the Linux router itself or on both server and client? On Thu, Feb 23, 2017 at 2:07 PM, Xin Long wrote: > On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote: >> does this fixed in RHEL7? > yes, I think so. > >> >> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long

Re: Problem on SCTP

On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote: > does this fixed in RHEL7? yes, I think so. > > On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote: >> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: >>> Hi Xin >>> >>> do you mean we

Re: Problem on SCTP

On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote: > does this fixed in RHEL7? yes, I think so. > > On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote: >> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: >>> Hi Xin >>> >>> do you mean we need to patch the kernel? >> Yups, pls comment on that bz

Re: Problem on SCTP

does this fixed in RHEL7? On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote: > On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: >> Hi Xin >> >> do you mean we need to patch the kernel? > Yups, pls comment on that bz if it's really needed for your env. >

Re: Problem on SCTP

does this fixed in RHEL7? On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote: > On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: >> Hi Xin >> >> do you mean we need to patch the kernel? > Yups, pls comment on that bz if it's really needed for your env. > A z-stream kernel may be available for

Re: Problem on SCTP

On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: > Hi Xin > > do you mean we need to patch the kernel? Yups, pls comment on that bz if it's really needed for your env. A z-stream kernel may be available for that issue soon. Thanks. > > > > On Wed, Feb 22, 2017 at 10:00 AM,

Re: Problem on SCTP

On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: > Hi Xin > > do you mean we need to patch the kernel? Yups, pls comment on that bz if it's really needed for your env. A z-stream kernel may be available for that issue soon. Thanks. > > > > On Wed, Feb 22, 2017 at 10:00 AM, Xin Long wrote: >>

Re: Problem on SCTP

Hi Xin do you mean we need to patch the kernel? On Wed, Feb 22, 2017 at 10:00 AM, Xin Long wrote: > On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul wrote: >> Hi >> >> the router is actually is a linux running on RHEL6.8 >> (2.6.32-642.4.2.el6.x86_64). it

Re: Problem on SCTP

Hi Xin do you mean we need to patch the kernel? On Wed, Feb 22, 2017 at 10:00 AM, Xin Long wrote: > On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul wrote: >> Hi >> >> the router is actually is a linux running on RHEL6.8 >> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT >>

Re: Problem on SCTP

On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul wrote: > Hi > > the router is actually is a linux running on RHEL6.8 > (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT > forward. https://bugzilla.redhat.com/show_bug.cgi?id=1412038

Re: Problem on SCTP

On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul wrote: > Hi > > the router is actually is a linux running on RHEL6.8 > (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT > forward. https://bugzilla.redhat.com/show_bug.cgi?id=1412038 sctp_manip_pkt->sctp_compute_cksum: struct

Re: Problem on SCTP

Hi the router is actually is a linux running on RHEL6.8 (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT forward. On Tue, Feb 21, 2017 at 11:53 PM, Xin Long wrote: > On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul wrote: >> Hi, >> >> sorry

Re: Problem on SCTP

Hi the router is actually is a linux running on RHEL6.8 (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT forward. On Tue, Feb 21, 2017 at 11:53 PM, Xin Long wrote: > On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul wrote: >> Hi, >> >> sorry to get back late, the platform is running

Re: Problem on SCTP

On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul wrote: > Hi, > > sorry to get back late, the platform is running on KVM. and this > problem is resolved by moving to VMware environment, however, a new > problem is coming out, we noticed that the HB REQ is being ABORT from > client.

Re: Problem on SCTP

On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul wrote: > Hi, > > sorry to get back late, the platform is running on KVM. and this > problem is resolved by moving to VMware environment, however, a new > problem is coming out, we noticed that the HB REQ is being ABORT from > client. > > >

Re: Problem on SCTP

Hi, sorry to get back late, the platform is running on KVM. and this problem is resolved by moving to VMware environment, however, a new problem is coming out, we noticed that the HB REQ is being ABORT from client. 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]

Re: Problem on SCTP

Hi, sorry to get back late, the platform is running on KVM. and this problem is resolved by moving to VMware environment, however, a new problem is coming out, we noticed that the HB REQ is being ABORT from client. 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]

Re: Problem on SCTP

On Fri, Jan 13, 2017 at 10:43:39AM +0100, Michael Tuexen wrote: > Your router does NOT change any field in the SCTP packet, but the > SCTP checksum was modified from >Checksum: 0xbaea49e5 (not verified) > to >Checksum: 0xa9a86d3f (not verified) Sun, which operating system is your router

Re: Problem on SCTP

On Fri, Jan 13, 2017 at 10:43:39AM +0100, Michael Tuexen wrote: > Your router does NOT change any field in the SCTP packet, but the > SCTP checksum was modified from >Checksum: 0xbaea49e5 (not verified) > to >Checksum: 0xa9a86d3f (not verified) Sun, which operating system is your router

Re: Problem on SCTP

> On 13 Jan 2017, at 10:43, Michael Tuexen > wrote: > > Your router does NOT change any field in the SCTP packet, but the > SCTP checksum was modified from > Checksum: 0xbaea49e5 (not verified) > to > Checksum: 0xa9a86d3f (not verified) > At least one of

Re: Problem on SCTP

> On 13 Jan 2017, at 10:43, Michael Tuexen > wrote: > > Your router does NOT change any field in the SCTP packet, but the > SCTP checksum was modified from > Checksum: 0xbaea49e5 (not verified) > to > Checksum: 0xa9a86d3f (not verified) > At least one of these is wrong. Read the tracefiles

Re: Problem on SCTP

Your router does NOT change any field in the SCTP packet, but the SCTP checksum was modified from Checksum: 0xbaea49e5 (not verified) to Checksum: 0xa9a86d3f (not verified) At least one of these is wrong. Read the tracefiles in wireshark and enable checksum validation and wireshark will

Re: Problem on SCTP

Your router does NOT change any field in the SCTP packet, but the SCTP checksum was modified from Checksum: 0xbaea49e5 (not verified) to Checksum: 0xa9a86d3f (not verified) At least one of these is wrong. Read the tracefiles in wireshark and enable checksum validation and wireshark will

Re: Problem on SCTP

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 SourceSPort Destination Protocol DPort Length

Re: Problem on SCTP

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 SourceSPort Destination Protocol DPort Length

Re: Problem on SCTP

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 SourceSPort Destination Protocol DPort Length

Re: Problem on SCTP

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 SourceSPort Destination Protocol DPort Length

Re: Problem on SCTP

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

Re: Problem on SCTP

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

Re: Problem on SCTP

> On 12 Jan 2017, at 10:51, David Laight wrote: > > From: Sun Paul [mailto:paul...@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

Re: Problem on SCTP

> On 12 Jan 2017, at 10:51, David Laight wrote: > > From: Sun Paul [mailto:paul...@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

RE: Problem on SCTP

From: Sun Paul [mailto:paul...@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 ->

RE: Problem on SCTP

From: Sun Paul [mailto:paul...@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 ->

Re: Problem on SCTP

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,

Re: Problem on SCTP

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,

Re: Problem on SCTP

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. > Yessoo, unlike what you said before, there

Re: Problem on SCTP

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. > Yessoo, unlike what you said before, there

Re: Problem on SCTP

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 wrote: > On Tue, Jan 10, 2017 at 09:30:39AM

Re: Problem on SCTP

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 wrote: > On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote:

Re: Problem on SCTP

On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote: > Packet received (From client) > == > > No. Time SourceSPort > Destination Protocol DPort Length Info > DSCP > 1

Re: Problem on SCTP

On Tue, Jan 10, 2017 at 09:30:39AM +0800, Sun Paul wrote: > Packet received (From client) > == > > No. Time SourceSPort > Destination Protocol DPort Length Info > DSCP > 1

Re: Problem on SCTP

Packet to SERVER No. Time SourceSPort Destination Protocol DPort Length Info DSCP 2 2017-01-06 08:52:49.662321192.168.206.8350001 192.168.206.66SCTP 3868

Re: Problem on SCTP

Packet to SERVER No. Time SourceSPort Destination Protocol DPort Length Info DSCP 2 2017-01-06 08:52:49.662321192.168.206.8350001 192.168.206.66SCTP 3868

Re: Problem on SCTP

Packet received (From client) == No. Time SourceSPort Destination Protocol DPort Length Info DSCP 1 2017-01-06 08:52:49.662142192.168.206.8350001 192.168.206.65

Re: Problem on SCTP

Packet received (From client) == No. Time SourceSPort Destination Protocol DPort Length Info DSCP 1 2017-01-06 08:52:49.662142192.168.206.8350001 192.168.206.65

Re: Problem on SCTP

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 wrote: > > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote: > >> Hi > >>

Re: Problem on SCTP

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 wrote: > > On Mon, Jan 09, 2017 at 06:00:36PM +0800, Sun Paul wrote: > >> Hi > >> > >> the linux router

Re: Problem on SCTP

what kind of information do you need? the whole INIT packet? On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman 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. >> >

Re: Problem on SCTP

what kind of information do you need? the whole INIT packet? On Mon, Jan 9, 2017 at 8:25 PM, Neil Horman 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

Re: Problem on SCTP

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

Re: Problem on SCTP

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 wrote: >

Re: Problem on SCTP

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 wrote: > From: Sun Paul >> Sent: 09 January 2017 02:08 > >> >> I am setting up a lab where the SCTP traffics from client is passing >> >>

Re: Problem on SCTP

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 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

RE: Problem on SCTP

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

RE: Problem on SCTP

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

Re: Problem on SCTP

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 <p

Re: Problem on SCTP

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 wrote: >

Re: Problem on SCTP

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

Re: Problem on SCTP

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

Re: Problem on SCTP

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 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

Re: Problem on SCTP

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 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

Re: Problem on SCTP

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

Re: Problem on SCTP

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

Re: Problem on SCTP

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 >

Re: Problem on SCTP

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 >

Problem on SCTP

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.

Problem on SCTP

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.