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).