2020-12-09 09:58:46

by Martin Schiller

[permalink] [raw]
Subject: Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On 2020-12-09 09:16, Xie He wrote:
> 1. When the x25 module gets loaded, layer 2 may already be running and
> connected. In this case, although we are in X25_LINK_STATE_0, we still
> need to handle the Restart Request received, rather than ignore it.

Hmm... I've never loaded the X.25 module after the interface is UP, but
in this case we really have to fix it.

>
> 2. When we are in X25_LINK_STATE_2, we have already sent a Restart
> Request
> and is waiting for the Restart Confirmation with t20timer. t20timer
> will
> restart itself repeatedly forever so it will always be there, as long
> as we
> are in State 2. So we don't need to check x25_t20timer_pending again.

Yeah, you're right, we can actually leave that out.

Acked-by: Martin Schiller <[email protected]>


2020-12-09 10:37:23

by Martin Schiller

[permalink] [raw]
Subject: Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On 2020-12-09 10:52, Martin Schiller wrote:
> On 2020-12-09 09:16, Xie He wrote:
>> 1. When the x25 module gets loaded, layer 2 may already be running and
>> connected. In this case, although we are in X25_LINK_STATE_0, we still
>> need to handle the Restart Request received, rather than ignore it.
>
> Hmm... I've never loaded the X.25 module after the interface is UP, but
> in this case we really have to fix it.
>

This seems to be a regression caused by moving the Layer2 link handling
into the lapb driver, which wasn't intended in my original patchset.

I also have another patch on my todo list which aims orphan packet
handling in the x25_receive_data() function. Maybe it is better to catch
the whole thing there.

>>
>> 2. When we are in X25_LINK_STATE_2, we have already sent a Restart
>> Request
>> and is waiting for the Restart Confirmation with t20timer. t20timer
>> will
>> restart itself repeatedly forever so it will always be there, as long
>> as we
>> are in State 2. So we don't need to check x25_t20timer_pending again.
>
> Yeah, you're right, we can actually leave that out.
>
> Acked-by: Martin Schiller <[email protected]>

2020-12-09 23:51:32

by Xie He

[permalink] [raw]
Subject: Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On Wed, Dec 9, 2020 at 2:31 AM Martin Schiller <[email protected]> wrote:
>
> >> 1. When the x25 module gets loaded, layer 2 may already be running and
> >> connected. In this case, although we are in X25_LINK_STATE_0, we still
> >> need to handle the Restart Request received, rather than ignore it.
> >
> > Hmm... I've never loaded the X.25 module after the interface is UP, but
> > in this case we really have to fix it.
> >
>
> This seems to be a regression caused by moving the Layer2 link handling
> into the lapb driver, which wasn't intended in my original patchset.
>
> I also have another patch on my todo list which aims orphan packet
> handling in the x25_receive_data() function. Maybe it is better to catch
> the whole thing there.

OK..

Currently it's not clear to me what your future patches would be.
Maybe we can first have this patch applied? Because based on the
current code I think this patch is necessary. When you are ready to
submit your patches, you can replace my code and we can discuss
further.

2020-12-10 07:32:23

by Martin Schiller

[permalink] [raw]
Subject: Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On 2020-12-09 21:16, Xie He wrote:
> On Wed, Dec 9, 2020 at 2:31 AM Martin Schiller <[email protected]> wrote:
>>
>> >> 1. When the x25 module gets loaded, layer 2 may already be running and
>> >> connected. In this case, although we are in X25_LINK_STATE_0, we still
>> >> need to handle the Restart Request received, rather than ignore it.
>> >
>> > Hmm... I've never loaded the X.25 module after the interface is UP, but
>> > in this case we really have to fix it.
>> >
>>
>> This seems to be a regression caused by moving the Layer2 link
>> handling
>> into the lapb driver, which wasn't intended in my original patchset.
>>
>> I also have another patch on my todo list which aims orphan packet
>> handling in the x25_receive_data() function. Maybe it is better to
>> catch
>> the whole thing there.
>
> OK..
>
> Currently it's not clear to me what your future patches would be.
> Maybe we can first have this patch applied? Because based on the
> current code I think this patch is necessary. When you are ready to
> submit your patches, you can replace my code and we can discuss
> further.

Yes, that's also the reason why I already acked this patch. We can
solve this later a little bit cleaner if necessary.

My patch that takes care of the orphaned packets in x25_receive_data()
has again a dependency on other patches, especially the patch to
configure the neighbor parameters (DCE/DTE, number of channels etc.),
which I already sent before but still have to revise.

Unfortunately I have only limited time for this topic, so I am not as
fast as some people would wish. Sorry for that.

Martin

2020-12-10 09:45:13

by Xie He

[permalink] [raw]
Subject: Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On Wed, Dec 9, 2020 at 10:35 PM Martin Schiller <[email protected]> wrote:
>
> Yes, that's also the reason why I already acked this patch. We can
> solve this later a little bit cleaner if necessary.
>
> My patch that takes care of the orphaned packets in x25_receive_data()
> has again a dependency on other patches, especially the patch to
> configure the neighbor parameters (DCE/DTE, number of channels etc.),
> which I already sent before but still have to revise.
>
> Unfortunately I have only limited time for this topic, so I am not as
> fast as some people would wish. Sorry for that.

OK. Thanks! I appreciate your work! Code needs to have specialist
developers like you to keep it alive and evolving.

I understand you have limited time. Please take your time. Thanks!