при этом оно будет аналогично правилу:

iptables ... -m ttl --ttl-lt 4

Так как переменная Start не может быть меньше 0, то получить вышеописанным образом доступ к первым трём байтам не получится. Для доступа к ним используется более сложная конструкция со сдвигом. Подробнее об этом можно прочитать в [7]. Так как маркируемые биты находятся во втором байте заголовка (2-3=-1), то простым образом обратиться к ним не получится. Конструкция Start&Mask позволяет считать первые 4 байта сразу без сдвига с помощью «0&0xFFFFFFFF», конструкция, считывающая второй по счёту (первый по нумерации, начиная с нуля) байт выглядит так «0&0x00FF0000». Фактически это то, что нам нужно. Уже сейчас можно написать аналог применяемого нами ранее правила:

iptables -A FORWARD -d 192.168.0.5 -m dscp --dscp 0x18

который будет выглядеть так:

iptables -A FORWARD -m u32 --u32 "0&0x00FF0000=0x00600000" -d 192.168.0.5

Это правило полностью аналогично, то есть оно содержит все те недостатки, что были обсуждены ранее. Однако теперь их можно исправить, используя для сравнения не все биты, а только те, которые нас интересуют 0110000 (0x60).

iptables -A FORWARD -m u32 --u32 "0&0x00600000=0x00600000" -d 192.168.0.5

Такая конструкция полностью делает всё от неё ожидаемое, хотя и не очень удобна в том плане, что сравниваемое значение приходится окружать большим количеством нулей. Куда разумнее оба сравниваемых значения сдвинуть на 2 байта (16 бит) вправо, тогда лишних нулей можно будет избежать, при этом правило для iptables более элегантно можно будет записать так:

iptables -A FORWARD -m u32 --u32 "0&0x00600000>>16=0x60" -d 192.168.0.5

Логично догадаться, что если у вас маркируются другие биты, то поменять значения в правиле не очень сложно.

Замечание 1. Вадимом Беркгаутом было обнаружено, что маршрутизаторы Cisco (в частности 7206) помечают не все пакеты в поле DSCP. Почему-то не помечаются пакеты с установленными флагами SYN или FIN и иногда некоторые пакеты, идущие перед последним. Также не всегда помечаются и ICMP-пакеты. Если на счёт SYN- и FIN-пакетов есть некоторые соображения, то по поводу случайной не маркировки некоторых ICMP-пакетов сделать выводы сложно. В частности, есть предположение, что существуют те или иные RFC, которые рекомендуют так поступать. Например, RFC 2873 (TCP Processing of the IPv4 Precedence Field), указывающий, что во время установки соединения поле precedence должно игнорироваться обеими сторонами. Это значит, что Cisco может думать так: «а зачем маркировать пакеты, если поле всё равно игнорируется». Возможно, что это особенности конкретного экземпляра, если кто-то из читателей знает, почему так происходит и как ведут себя другие маршрутизаторы, буду рад услышать ваше мнение.