remove a test that has been obsoleted by the authentication failure
counter - enter slow retry mode always, not only if we already transfered
data successfully (the test was designed to disable retries when the
initial authentication setting was not correct, the auth failure counter
does this job better).
we don't know anything about with a PADT packet.
Use with care, this is pretty dangerous and will kill all userland PPPoE
implementations. Therefore it is not enabled by default nor added as
a commented out option to GENERIC kernels.
But it is highly usefull if you have a fixed IP, an ISP that does not use
LCP echo requests for link monitoring and you want to recover quickly after
a crash or otherwise ungracefull disconnect.
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.
values).
Implement a secondary connection-reestablishement mode, which is only
entered after (1) we have successfully transfered payload data over this
connection and (2) if initial retries did not reestablish a session.
In this mode we retry (infrequently) forever, until adminstrator stops
us (by "ifconfig ppppoe0 down"). XXX - need to display this mode in
pppoectl.
It is now possible to pull the DSL modems plug for say 15 minutes, plug
it back in again and just wait. The connection will be reestablished within
three minutes.
from sppp_attach.
When destroying the interface, call sppp_detach for proper cleanup.
This avoids a crash from the slow timeout handler for no longer existing
interfaces (spotted by Rémi Zara).
follows BSD/OS practice and ucd-snmp code (FreeBSD does it for specific
interfaces only).
was: if_lastchange get updated on every packet transmission/receipt.
now: if_lastchange get updated when IFF_UP is changed.
based on the existing net/if_spppsubr.c stuff.
While there are completely userland (bpf based) implementations available,
those have a vastly larger per packet overhead thus causing major CPU
overhead and higher latency. On an i386 base router, running a 486DX at 50MHz
my line (768kBit/s downstream) was limited to something (varying) between 10
and 20 kByte/s effective download rate. With this implementation I get full
bandwidth (~85kByte/s).
This is client side only. Arguably the right way to add full PPPoE support
(including server side) would be a variation of the ppp line discipline and
appropriate modifications to pppd. I promise every help I can give to anyone
doing that - but I needed this realy fast. Besids, on low memory NAT boxes
with typically a single PPPoE connection, this implementation is more
lightweight than a pppd based one, which nicely fits my needs.
