Дано: есть некая довольно старая железяка, работающая домашним роутером у одного человека. В этой железяке торчат три сетевухи, все они работают через драйвер r8169:

00:0a.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)

Есть дебиан, с ядрами 2.6.26-486, 2.6.26-2-openvz-486 и 2.6.32-5-486 (из unstable). На всех этих ядрах воспроизводится один и тот же баг, проявляющийся в следующем:

• После некоторого аптайма, при попытке поднять опущенный интерфейс, вылезает пасквиль

  RTNETLINK answers: Cannot allocate memory

  и нифига не поднимается. Если вместо ip li se dev ethX up использовать сыплющий песком ifconfig, песня меняется незначительно:

  SIOCSIFFLAGS: Cannot allocate memory

• Аналогичный эффект проявляется сразу после загрузки, если при загрузке была автоматически запущена fsck для ext3 на /. Сеть в этом случае не поднимается вообще, ни один интерфейс.

При этом свободной памяти более чем достаточно:

             total       used       free     shared    buffers     cached
Mem:           249        237         12          0         69        136
-/+ buffers/cache:         30        218
Swap:          972          0        972

Особо дотошные люди могут изучить ругательства dmesg по этому поводу.

По результатам гугления сложилось впечатление, что это застарелый и никого не беспокоящий баг ядра. Уж кто-кто, а r8169 всегда изобиловал багами. Впрочем, в RHEL, ради разнообразия, их иногда фиксят, чего не скажешь о мейнстриме. Хотя наиболее эффективным решением в сложившейся ситуации мне представляется закатывание туда опенка, в котором к ядреным багам относятся без особого почтения. Однако меня еще не покинула надежда, что проблему можно решить шаманством с sysctl et cetera. Идеи?

Не столь давно решил переползти с ISC dhclient на dhcpcd (собственно, недавний эпик фейл был последней каплей).

Конфигурация сети у меня такая

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
METRIC=10
USERCTL=yes
RESOLV_MODS=yes
LINK_DETECTION_DELAY=6
DHCP_CLIENT=dhcpcd
PEERDNS=no
PEERYP=yes
PEERNTPD=no

До определенного момента все работало нормально. Вот вывод /etc/dhcpc/dhcpcd-eth0.info в штатном режиме:

IPADDR=xx.xx.xx.xx
NETMASK=255.255.255.0
NETWORK=xx.xx.xx.0
BROADCAST=xx.xx.xx.255
GATEWAY=xx.xx.xx.1
DOMAIN='aaa.aa'
DNS=yy.yy.yy.yy,zz.zz.zz.zz
DHCPSID=10.100.32.3
DHCPGIADDR=10.132.0.1
DHCPSIADDR=10.100.32.3
DHCPCHADDR=bb:bb:bb:bb:bb:bb
DHCPSHADDR=00:01:5C:31:4C:C0
DHCPSNAME=''
LEASETIME=86400
RENEWALTIME=86100
REBINDTIME=86100
INTERFACE='eth0'
CLASSID='Linux 2.6.aaa'
CLIENTID=bb:bb:bb:bb:bb:bb

Но! При перезагрузке кабельного модема (arris touchstone) модем на короткое время выдает внутренний айпишник без гейта (пока он к серваку прова не подконнектился). Выглядит это так:

IPADDR=192.168.100.2
NETMASK=255.255.255.0
NETWORK=192.168.100.0
BROADCAST=192.168.100.255
DNS=192.168.100.1
DHCPSID=192.168.100.1
DHCPGIADDR=0.0.0.0
DHCPSIADDR=0.0.0.0
DHCPCHADDR=bb:bb:bb:bb:bb:bb
DHCPSHADDR=00:15:CE:30:D3:2D
DHCPSNAME=''
LEASETIME=20
RENEWALTIME=10
REBINDTIME=17
INTERFACE='eth0'
CLASSID='Linux 2.6.aaa'
CLIENTID=bb:bb:bb:bb:bb:bb

dhclient такую ситуацию отрабатывает нормально.

Итого: для dhcpcd собственный кеш важнее данных от DHCP-сервера? Т.е. он глючное УГ? Или я в чем-то неправ?

Необходимо создать лекговесный сниффер, способный анализировать заголовки сетевого (IPv6) и канального (TCP, UDP) уровня. (Содержимое канального уровня и дальше вглубь интереса не представляет.)

В случае с IPv4 задача уже решена, однако сейчас моих знаний об IPv6 недостаточно, чтобы портировать это решение под данный протокол.

Собственно о чем прошу:
1. Реализуема ли эта задача средствами сырых сокетов, или нужно использовать pcap? Просто в процессе гугления наткнулся на информацию, что для IPv6 нельзя получить заголовки пакетов из сырых сокетов. Так ли это?
2. Дайте плз ссылки на вменяемые примеры парсинга указанных заголовков из сырых сокетов - если это возможно, если нет - аналогичная просьба про pcap. Отсылки к RFC и ip6.h будут рассматриваться как неинформативные, ибо теория без практики мертва :)

Как сказано вот в этом интересном документе (http://www.vniiftri.ru/rus/news/91.html), с весны прошлого года Всероссийский Научно-Исследовательский Институт Физико-Технических и Радиотехнических Измерений предоставляет широким массам услуги NTP-серверов, действующих "на базе Государственного эталона времени и частоты".

Серваки я эти юзал с марта этого года. Выгодно выделялись на фоне ужжасных, периодически исчезающих чудовищ с Черноголовки и Пущина. Правда, врали на 5 миллисекунд, но врали стабильно. В начале июня, кстати, врать перестали.

Вот на днях заметил, что все три их сервера stratum 1 работать перестали. Пинговаться - пингуются, и время на них нормальное, в пределах погрешности, а стратум почему-то 16. Естественно, ни один нормальный сервер синхронизироваться по ним не будет.

Вспомогательный же сервер стратума 2 почему-то работает в штатном режиме.

Посему вопрос: кто-нибудь знает что с ними произошло?

Дернула меня нелегкая водрузить Xen на десктопную машину.

После окончания загрузки на dom0 упала сеть. Причем с момента подъема eth0 до запуска xend сеть была, а потом упала. Вскрытие показало, что xend меняет MAC-адрес eth0 на fe:ff:ff:ff:ff:ff.

Далее в дело пошел гугл. Оказалось, что это врожденный косяк реалтековских встроенных сетевух (RTL8111/8168B PCI Express Gigabit Ethernet controller).

Было предложение включить какую-то опцию сетевухи в биосе (что-там про ROM). Она оказалась уже включена. Пробовал выключать, снова включать - не помогает.

Еще было предложение вместо дефолтного в центосе r8169 накатить из elrepo r8168. Накатил, прописал алиасом для eth0 в modprobe.conf - не помогло. Т.е. сеть работает, но только после ручного прописывания настоящего мака.

В конечном счете остановился на компромиссе - в конфиге ксена вместо (network-script network-bridge) выставил (network-script network-route) и vif-script аналогично, а также покапал начальству на мозги на предмет закупки новой сетевухи.

Собсно целей у данного поста две:
1. Сообщить широким массам, что встроенные реалтековские сетевухи - у..бищное г..но.
2. Спросить - может (вдруг) все-таки кто-то знает, как это можно вылечить?

Суть задачи стара как мир: нужно ограничивать/приоретизировать трафик на основании протоколов прикладного уровня.

Насколько я понял из документации по tc, фильтрация по handle <метка> fw хватает отдельные пакеты, а не соединения. Также, как показала практика, l7-filter тоже маркирует только отдельные пакеты. Например, для http он метит только начало ответа сервера (там где заголовки, которые матчатся по регэкспам).

Получается такая картина: для всех пакетов с маркировкой нужно делать CONNMARK --save-mark, а для всех пакетов без маркировки пакета, но с маркировкой соединения - CONNMARK --restore-mark.

Вроде логично. Но гугл выдает кучу манов, в которых таких вещей и близко нет. Вот мне и стало интересно: то ли я чего-то не понял, то ли столько "гениальных" копипаст^Wавторов поразвелось.