mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Denis Du <dudenis2000@yahoo.ca>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Carrier detect ok, don't turn off negotiation
Date: Sun, 28 Jan 2018 15:24:16 +0100	[thread overview]
Message-ID: <m3r2qavz73.fsf@pm.waw.pl> (raw)
In-Reply-To: <998451043.3408644.1516727290310@mail.yahoo.com> (Denis Du's message of "Tue, 23 Jan 2018 17:08:10 +0000 (UTC)")

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 == on)
>         goto 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>
-- 
Krzysztof Halasa

  reply	other threads:[~2018-01-28 14:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <751079597.1884905.1516121905374.ref@mail.yahoo.com>
2018-01-16 16:58 ` Denis Du
2018-01-22 20:25   ` David Miller
2018-01-22 22:17     ` Denis Du
2018-01-23 17:08     ` Denis Du
2018-01-28 14:24       ` Krzysztof Halasa [this message]
2018-02-06 15:18         ` Denis Du
     [not found]         ` <438911112.3985245.1517930128335@mail.yahoo.com>
2018-02-06 15:29           ` David Miller
2018-02-06 16:50             ` Denis Du
2018-02-21  3:35               ` Denis Du
2018-02-22 19:04                 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3r2qavz73.fsf@pm.waw.pl \
    --to=khc@pm.waw.pl \
    --cc=davem@davemloft.net \
    --cc=dudenis2000@yahoo.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®