[Cake] Cake on openwrt - falling behind

[Toke Høiland-Jørgensen]

Pete Heist <pete at heistp.net> writes:

>> On Jul 2, 2018, at 7:04 PM, Pete Heist <pete at heistp.net> wrote:
>> 
>> 
>> 
>>> On Jul 2, 2018, at 6:14 PM, Toke Høiland-Jørgensen <toke at toke.dk <mailto:toke at toke.dk>> wrote:
>>> 
>>> Aha! I think I figured out what is going on:
>>> 
>>> The gen_stats facility will add an nlattr header at the beginning of the
>>> qdisc stats, which is the toplevel TLV that contains all stats (and that
>>> we put our stats inside). It stores a reference to this header, and when
>>> all the per-qdisc callbacks have finished adding their stats, it goes
>>> back and fixes up the length of the containing header.
>>> 
>>> The problem is that on architectures that need padding, the padding TLV
>>> is added *first*, which means that the nlattr pointer that is stored
>>> before the callbacks are performed points to the padding TLV and not the
>>> stats TLV. And so, when the header is fixed up, the result (from the
>>> parser's perspective) is just a very big padding TLV.
>>> 
>>> The options TLV is before the stats TLV, so the bug only occurs if the
>>> options happen to have a length that means the stats will need padding.
>>> Which is why messing with the number of options "fixes" the bug.
>>> 
>>> Could you try applying the patch below (to the kernel) and see if that
>>> resolves the issue, please?
>> 
>> Awesome Toke! It looks like from Kevin’s email that it works for him,
>> but it didn’t work for me the first time around. This may have to do
>> with how I added the patch as I’m still not that familiar with
>> OpenWRT’s build system (first kernel patch I tried). I wasn’t sure if
>> it should go into generic or platform, for one, so I tried generic…is
>> that right?
>
> Ok, I got it to work after re-flashing with tftp. :) It looks like the
> OM2P is not always successfully performing sysupgrades, perhaps due to
> its limited memory (64M), but I’m not sure.

Great, thanks for testing, both of you!

> I still have my debugging in place and do still have one question. The
> pointer in TCA_STATS2 is now valid, but there is still a pointer value
> in TCA_PAD, which is pointing to a place 32 bits before TCA_STATS2. Is
> that expected?

Yes, that is expected. The PAD is there to align the subsequent STATS
TLV, so it is being parsed but is unused.

This is the offending spot from Kevin's pcap files:

Working: The header starts at byte 0x17c with a TLV of type 7 (TCA_STATS2)
of length 0x268. No padding TLV needed, so stats work:

00000170: 0000 0000 0008 000a 0000 0000 0268 0007  .............h..
00000180: 0234 0004 0008 0002 0025 f4cc 0008 0003  .4.......%......

Broken: The header starts at byte 0x180 with a PAD TLV (type 9) followed
by the TCA_STATS2 TLV. Both start out with 4-byte lengths (just the
header), but because the PAD TLV is the one being extended, that gets a
new length of 0x29c, which means it now contains the TCA_STATS2 TLV as
the first nested TLV. What should have happened was that the TCA_PAD TLV
should have stayed at 4 bytes, thus aligning the payload of the
TCA_STATS2 TLV at 0x188 bytes, and the TCA_STATS2 TLV should have been
length 0x298. Which is what happens after the patch, and why TCA_PAD is
still set by the parser.

00000180: 029c 0009 0004 0007 0260 0004 000c 0002  .........`......


-Toke