[Cerowrt-devel] Correctly calculating overheads on unknown connections
adf.lists at gmail.com
Wed Sep 24 18:48:48 EDT 2014
Sebastian Moeller wrote:
>> Maybe you mean overhead calculated by a script?
> Well in cerowrt’s SQM-scripts we expose the stab options so users can
> take link layer and overhead into account. If you naively determine
> the overhead, either with the help of the scrips I posted earlier or
> by looking it up on a table (if the encapsulation options are known)
> you will end up not handling the kernel’s auto-added overhead well.
> Currently SQM scripts does not expose PPP devices only ge00
> (ethernet) so -14 seems currently the best recommendation in
> combination with “please test”.
Oh, OK - I know nothing about wrt.
> What I am curious after your message
> is what happens if the kernel terminates a pppoe connection but is
> connected to a “modem” via ethernet, what does the kernel do. And
> thanks to your pointers I know have an idea of how to test that ;)
Well I can't say I know - testing is always best.
I think we are "seeing" skbs just as they enter an interface - so what
form they take depends on the particular interface they have just been
It's possible to have multiple pppoes/vlans on an eth and use the eth
normally at the same time. What you see I suppose depends on where you
are "attached". I guess shaping a pppoe on the eth rather than on the
actual ppp is doable with a bit of filtering - in which case you may
need to allow for the +14 macs/ethertype and that 8 ppp are already in
the payload - a totally untested theory :-)
>> On ppp skb->len = ip len
>> On eth skb->len = ip len + 14
>> On vlan skb->len = ip len + 18
> So this is the information I actually wanted to find and then somehow
> thought qdisc_pkt_len_init() was the place. Do you by chance have any
> pointer where this assignment is handled?
No, sorry I don't know the code.
More information about the Cerowrt-devel