Commit Graph

4 Commits

Author SHA1 Message Date
martin
74f0920eda Take into account the two byte PPP protocol discrimator following the PPPoE
header when calculating the MTU. Ooops...

Thanks to Mario Kemper for noting this.
2001-06-24 20:35:50 +00:00
martin
91a63a0595 Protect interface queue manipulations by splnet(). Splsoftnet() is not
enough.
2001-06-18 12:32:47 +00:00
itojun
4d51fe368b change the meaning of ifnet.if_lastchange to meet RFC1573 ifLastChange.
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.
2001-06-14 05:44:23 +00:00
martin
b5b75a7d19 Add an in-kernel PPPoE (ppp over ethernet, RFC 2516) implementation,
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.
2001-04-29 09:50:36 +00:00