Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 6 Feb 2018 15:18:20 +0000 (UTC)
From:   Denis Du <dudenis2000@yahoo.ca>
To:     Krzysztof Halasa <khc@pm.waw.pl>
Cc:     David Miller <davem@davemloft.net>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Message-ID: <431228126.4042690.1517930300853@mail.yahoo.com>
In-Reply-To: <m3r2qavz73.fsf@pm.waw.pl>
References: <751079597.1884905.1516121905374.ref@mail.yahoo.com> <751079597.1884905.1516121905374@mail.yahoo.com> <20180122.152513.1108868799788445512.davem@davemloft.net> <998451043.3408644.1516727290310@mail.yahoo.com> <m3r2qavz73.fsf@pm.waw.pl>
Subject: Re: [PATCH] Carrier detect ok, don't turn off negotiation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 2072
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Hi, David:

How=C2=A0 do you think my patch?

As you see, Krzysztof=C2=A0 think my patch is ok to be accepted.

But if you have a better idea to fix it,I am glad to see it. Anyway, this i=
ssue have to be fixed.


Denis DU


On Sunday, January 28, 2018, 9:34:15 AM EST, Krzysztof Halasa <khc@pm.waw.p=
l> wrote:=20


Denis Du <dudenis2000@yahoo.ca> writes:


>>From the above code, I can get that only Carrier have some change, it
> will restart the protocol by hdlc_proto_start(dev);and thus the timer,
> the previous timer expired due to protocol fail.
>
> If carrier keep no change by if (hdlc->carrier =3D=3D on)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0goto carrier_exit; /* no =
change in DCD line level */It will do
> nothing, not start any new protocol and thus the timer.


Sorry about being late, just returned home and am trying to get all the
backlogs under control.

I remember the PPP standard is a bit cloudy about the possible issue,
but the latter indeed exists (the PPP state machine was written directly
to STD-51). There is related (more visible in practice, though we aren't
affected) issue of "active" vs "passive" mode (hdlc_ppp.c is "active",
and two "passives" wouldn't negotiate at all).

Anyway the problem is real (though not very visible in practice,
especially on relatively modern links rather than 300 or 1200 bps dialup
connections) and should be fixed. Looking at the patch, my first
impression is it makes the code differ from STD-51 a little bit.
On the other hand, perhaps applying it as is and forgetting about the
issue is the way to go.

Ideally, I think the negotiation failure should end up (optionally, in
addition to the current behavior) in some configurable sleep, then
the negotiation should restart. If it's worth the effort at this point,
I don't know.

Perhaps I could look at this later, but no promises (this requires
pulling on and setting up some legacy hardware).

Anyway, since the patch is safe and can solve an existing problem:

Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
--=20
Krzysztof Halasa