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 o
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,
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-st
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 ip
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, th
um
>> must be the same.
> At the server have a look at the SNMP counters:
> cat /proc/net/sctp/snmp
> You should find a line staring with
> SctpChecksumErrors
> If the number reported there is positive, the node received packets
> with checksum errors.
>
> Best re
0)
1... = Bit: Skip parameter and continue
processing of the chunk
.1.. = Bit: Do report
Parameter length: 4
On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul wrote:
> Hi All
>
> below is the packet trace in text format.
>
>
>
wn]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)
On Fri, Jan 13, 2017 at 11:27
e:
>> 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 -&g
On Wed, Jan 11, 2017 at 8:57 PM, Neil Horman 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 LKSC
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 wr
er length: 4
On Tue, Jan 10, 2017 at 9:30 AM, Sun Paul wrote:
> Packet received (From client)
> ==
>
> No. Time SourceSPort
> Destination Protocol DPort Length Info
>
= Bit: Do report
Parameter length: 4
On Tue, Jan 10, 2017 at 3:18 AM, Neil Horman 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
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 S
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
>
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:
>
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 wrote:
> On Fri, Jan 06, 2017 at 05:34:47PM +0800, Sun Paul wrote:
>> Hi
>>
>> I am setti
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 c
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.
howe
Hi
we are using redhat 2.6.32-642.4.2.el6.x86_64
On Wed, Sep 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner
wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote:
>> Hi
>>
>> we have an SCTP application running in JAVA. and we found that there
&
Hi
we have an SCTP application running in JAVA. and we found that there
is a problem when we as a client trying to connect to a remote IP
address.
If the remote IP address is not accessible, our application will keep
retrying to connect using a self-defined local port address, says
51001,
We fou
When an ABORT is sent to side-A, side-A INIT a new connection again.
On Mon, Jan 26, 2015 at 7:46 PM, Marcelo Ricardo Leitner
wrote:
> Hi,
>
> On 25-01-2015 23:27, Sun Paul wrote:
>>
>> Hi
>>
>> sorry for the late reply. I am a bit confused. when side-A sends a
Hi
sorry for the late reply. I am a bit confused. when side-A sends a
request to side-B, and side-B return the response, but side-A keep
re-transmit the same request to side-B, why side-B needed to send a
ABORT to side-A?
If it is used in order to reestablish the connection, shoudn't it
should be
Hi
I would like to check the behave in LKSCTP.
we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
We noticed that when remote peer have retry to send the same request
for 4 times, the LKSCTP will initiate an ABORT chunk
So, can I get confirmation that whether we can enhance to support the
scenarios or any resolution on providing the correct routing?
On Tue, Nov 26, 2013 at 9:03 AM, Sun Paul wrote:
> Hi
>
> we have a problem on using LKSCTP to form a 4 ways multi-homing network.
>
> Configuration
returns HB_ACK to IP-B. In the meantime, the HB
communication between IP-B and IP-Y follows the normal flow.
Can I confirm, is it really valid?
On Tue, Dec 3, 2013 at 11:22 PM, Vlad Yasevich wrote:
> On 12/03/2013 08:11 AM, Sun Paul wrote:
>> But how about the HB and HB_ACK? Still vali
route get 11.1.1.1
RTNETLINK answers: Network is unreachable
On Tue, Dec 3, 2013 at 10:02 AM, Vlad Yasevich wrote:
> On 12/02/2013 08:31 PM, Sun Paul wrote:
>> Thanks Vlad
>>
>> I checked on the route, and it looks correct.
>>
>> [root@localhost ~]# ip route get 11
so in this case, says
(NODE-A) IP-B send INIT to IP-X (NODE-B), and then IP-Y (NODE-B)
returns INIT_ACK to IP-B (NODE-A)
this is also treated as a valid, am I correct?
On Tue, Dec 3, 2013 at 10:03 AM, Vlad Yasevich wrote:
> On 12/02/2013 08:39 PM, Sun Paul wrote:
>> Another question
Another question
if a wrong source IP is used, does the association still classified as normal?
On Tue, Dec 3, 2013 at 9:31 AM, Sun Paul wrote:
> Thanks Vlad
>
> I checked on the route, and it looks correct.
>
> [root@localhost ~]# ip route get 11.1.1.1 from 110.1.1.1
> 11.1.
t 9:38 AM, Vlad Yasevich wrote:
>>> On 11/27/2013 11:03 PM, Sun Paul wrote:
>>>> How LKSCTP select which source address to use for the INIT_ACK or
>>>> HB_ACK? below is the testing result where a router is located in the
>>>> middle.
>>>>
>
default
How LKSCTP select source address to reply? If we know how it works,
then we may know what is going wrong.
On Wed, Nov 27, 2013 at 8:45 PM, Neil Horman wrote:
> On Wed, Nov 27, 2013 at 07:10:49AM +0800, Sun Paul wrote:
>> Hi Vlad
>>
>> Thank for your reply. If it is base
test. However, the LKSCTP library know to use the interface eth1 to
respond to the SCTP request.
- PS
On Wed, Nov 27, 2013 at 7:09 AM, Sun Paul wrote:
> Hi Vlad
>
> Thank for your reply. If it is based on the destination IP to find the
> best route, why the problem didn't happen o
Hi
we have a problem on using LKSCTP to form a 4 ways multi-homing network.
Configuration
- Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
IP-B (eth2)
- Node-B has 2 IP addresses in different subnets, known as IP-X (eth1),
IP-Y (eth2)
the four way paths are shown below.
1.
33 matches
Mail list logo
