a configurable maximum (default: 5).
Some ISPs shut down accounts (at least temporarily) after to many bad
retries. This hit me recently due to a stupid pilot error and the fast
retry rate.
containing the userland visible thinks (i.e. ioctl definitions).
Remove all (both) old ioctls, as they had a brain dead API and made keeping
binary compatibility more or less impossible.
Replace by several new ioctls. While there, remove any arbitrary limits
(resulting from the old, broken ioctls) and allow any length of names
and passwords.
Collect both local and remote address and set them to the interface in
one step (the peer adress was not set at all before).
This causes the peer address now to show up on the interface and all
messages to the routing socket to be send with correct data. The latter
has been the last missing piece to complete PPPoE support.
In this mode, the PPP packets start with the protocol identifier and don't
have any explicit framing (which may be added by the lower level driver).
Make input/output statistics a little bit more correct by adding a hardware
driver adjustable framing length for each packet (instead of the constant
value "3" used before).
While there, bump authentication name length from 32 to 48 (I have a
connection where I need more than 32). XXX - this should not be artificialy
limited at all.
the interface tries to negotiate ifid with the other end by using IPv6CP.
other changes:
- do not share ppp sequence number across protocols.
- if LCP proto-rej is received, drop the protocol mentioned by the message.
this is to be friendly with non-IPv6 peer (if the peer complains due to
lack of IPv6CP, drop IPv6CP). this basically implements "RXJ+" state
transition in the RFC.
- cleanup debugging message. always print blank just before message.
CAVEAT:
- if the peer uses the same MAC address as our side (pretty unlikely)
the code may go into req-rej loop.
- even though we negotiate ifid, we don't configure destination address
onto the interface. it is not really necessary to do so (IMHO).
- I've tested this code on a NetBSD 1.4.2 node, which was with fair amount
of modifications. not sure if the committed code does it right... (please
test and send reports)
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
wiz