Добрый день. Ковыряя tc, столкнулся с рядом крайне неприятных особенностей:
Устаревшая документация (LARTC) - половина современных дисциплин вообще никак не описана, либо описана крайне скудно (да взять, хотя бы, HFSC);
Несоответствие документации (того же lartc) реальности. Из этого вытекает два вопроса:
Есть ли где-то актуальная документация на современные дисциплины обработки очереди?
Почему вот эта ерунда работает вот так:
tc filter add dev ppp0 parent 10: protocol ip pref 10 u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthdr+13 flowid 10:11
tc -s -d fi sh dev ppp0
filter parent 10: protocol ip pref 10 u32
filter parent 10: protocol ip pref 10 u32 fh 809: ht divisor 1
filter parent 10: protocol ip pref 10 u32 fh 809::800 order 2048 key ht 809 bkt 0 flowid 10:11 (rule hit 0 success 0)
match 00060000/00ff0000 at 8 (success 0 )
match 00100000/00ff0000 at nexthdr+12 (success 0 )
Т.е. задаю смещение в 13 байт в заголовке следующего уровня, а реально применяется смещение в 12.
А ведь это пример из документации, который нифига реально не работает.
Хотя в LARTC не указано, что смещение выравнивается по 32-м битам. Нашел это случайно(!) на хабре. Соответственно, как мне, поймать фильтром u32 TCP ACK пакет по такому правилу?
Либо приходится брать u16 и накладывать маску на 16 бит. Есть где-то документация по всем этим подводным камням, либо это надо находить в исходниках?
Собственно, второй вопрос более интересен - это в последних ядрах смещение стало выравниваться, или всегда так было? Откуда тогда в документации смещения (at nexthdr+13, например) не кратные 32-м битам?
|
Вариант для распечатки
