Subject: kern/32772: pppoe(4) should (optionally) wait before retrying
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: None <cube@cubidou.net>
List: netbsd-bugs
Date: 02/08/2006 08:25:00
>Number: 32772
>Category: kern
>Synopsis: pppoe(4) should (optionally) wait before retrying
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Feb 08 08:25:00 +0000 2006
>Originator: Quentin Garnier
>Release: NetBSD-current
>Organization:
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
>Environment:
Irrelevant
>Description:
Currently, pppoe(4) (and other users of sppp code) doesn't wait
before retrying when configured to retry after e.g. a failed
login. Some PPPoE servers are not really happy about it, and
take a lot of time to properly allow authentication when they
are hammered that way, whereas waiting for a few seconds is
enough to make them happy.
I think it would be good to have an option to make the sppp
code wait before retrying, for a configurable time. Marin
Husemann even suggested to have an incremental waiting time.
>How-To-Repeat:
Disconnect and reconnect too fast on some PPPoE servers. It
will fail all attempts for a long time before properly
recovering, while downing the interface and upping a while
later just works.
>Fix:
Not provided. From what I've started, it shouldn't be very
difficult, using a callout. However, one has to be very
careful about the state of the callout when the user changes
the state of the interface and so forth.
Note that I won't be around the relevant PPPoE line before
long, so I won't really be able to test anything (the line is
20,000 kms away from where I usually live).