Добрый день. Ковыряя 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-м битам?
>[оверквотинг удален]
> А ведь это пример из документации, который нифига реально не работает.
> Хотя в LARTC не указано, что смещение выравнивается по 32-м битам. Нашел
> это случайно(!) на хабре. Соответственно, как мне, поймать фильтром u32 TCP
> ACK пакет по такому правилу?
> Либо приходится брать u16 и накладывать маску на 16 бит. Есть где-то
> документация по всем этим подводным камням, либо это надо находить в
> исходниках?
> Собственно, второй вопрос более интересен - это в последних ядрах смещение стало
> выравниваться, или всегда так было? Откуда тогда в документации смещения (at
> nexthdr+13, например) не кратные 32-м битам?согласен с тем что документация устарела, нет ни только информации по дисциплинам но также по фильтрам и экшенам, единственyое могу сказать, что сорсы открыты, и из них достаточно легко почерпнуть (последнее не отyjсится к дисциплинfм)
>[оверквотинг удален]
>> Либо приходится брать u16 и накладывать маску на 16 бит. Есть где-то
>> документация по всем этим подводным камням, либо это надо находить в
>> исходниках?
>> Собственно, второй вопрос более интересен - это в последних ядрах смещение стало
>> выравниваться, или всегда так было? Откуда тогда в документации смещения (at
>> nexthdr+13, например) не кратные 32-м битам?
> согласен с тем что документация устарела, нет ни только информации по дисциплинам
> но также по фильтрам и экшенам, единственyое могу сказать, что сорсы
> открыты, и из них достаточно легко почерпнуть (последнее не отyjсится к
> дисциплинfм)А что по смещениям, почему такая ерунда у меня получается? Т.е. реально фильтры уже работают совсем иначе, по сравнению с lartc? Ядро выравнивает все фильтры по границе 32-бита, и фильтры писать так как-то крайне неудобно...