> 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
> On 24. Jun 2020, at 09:25, Xin Long wrote:
>
> On Wed, Jun 24, 2020 at 5:48 AM Michael Tuexen
> wrote:
>>
>>> On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner
>>> wrote:
>>>
>>> On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael
> On 23. Jun 2020, at 23:31, Marcelo Ricardo Leitner
> wrote:
>
> On Tue, Jun 23, 2020 at 11:24:59PM +0200, Michael Tuexen wrote:
>>> On 23. Jun 2020, at 23:21, Marcelo Ricardo Leitner
>>> wrote:
>>>
>>> On Tue, Jun 23, 2020 at 11:17:56AM -0500
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
> On 23. Jun 2020, at 15:17, David Laight wrote:
>
> From: Marcelo Ricardo Leitner
>> Sent: 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:
>>>>
>>&g
> On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> wrote:
>
> 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 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
>>> sctp listening socket on :: and set the I
> 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,
>> then I make a connection to it
> 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
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 tell
> 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 the
> On 23 Jan 2015, at 18:10, Daniel Borkmann wrote:
>
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
I would like to check the behave in LKSCTP.
we are running DIAMETER message ove
> On 23 Jan 2015, at 19:30, Vlad Yasevich wrote:
>
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
>> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
On 01/23/2015 11:25 AM, Sun Paul wrote:
...
> I would like to check the behave in L
On Dec 5, 2013, at 10:35 AM, David Laight wrote:
the configured addresses could be:
System A) 10.0.0.1 on Lan X, 10.10.0.1 on Lan Y
System B) 10.0.0.2 on Lan X, 10.10.0.2 on Lan Y
System C) 10.0.0.3 on Lan X, 10.10.0.2 on Lan Z
Same problem will occur.
> ...
>> With
On Dec 4, 2013, at 7:23 PM, Vlad Yasevich wrote:
> On 12/04/2013 11:25 AM, Michael Tuexen wrote:
>> On Dec 4, 2013, at 5:12 PM, Vlad Yasevich wrote:
>>
>>> On 12/04/2013 11:01 AM, Michael Tuexen wrote:
>>>> On Dec 4, 2013, at 4:41 PM, Vlad Yasevich wrote
On Dec 4, 2013, at 5:48 PM, David Laight wrote:
>> The point is that address scoping should be used. When sending an
>> INIT from 10.10.10.1 to 10.10.10.4 you should not list 192.168.1.1,
>> since you are transmitting an address to a node which might or might
>> not "be in the same scope".
>
> Y
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich wrote:
> On 12/04/2013 09:50 AM, David Laight wrote:
In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In
the meantime, IP-B sends HB to IP-Y and IPY r
On Dec 4, 2013, at 5:12 PM, Vlad Yasevich wrote:
> On 12/04/2013 11:01 AM, Michael Tuexen wrote:
>> On Dec 4, 2013, at 4:41 PM, Vlad Yasevich wrote:
>>
>>> On 12/04/2013 09:50 AM, David Laight wrote:
>>>>>> In normal operation, IP-A sends INIT to IP-X
18 matches
Mail list logo
