Есть порт на коммутаторе, в который за минуту насыпается десяток гиг (mirroring-group monitor-port), и соединенный с ним сетевой интерфейс на сервере с t6/branch. Запускаю tshark примерно так: tshark -f "udp port 2944" -i интерфейс Но ничего не ловится. И даже если снять фильтр, то в отловленном никаких UDP-пакетов через требуемый порт не наблюдается. Аналогичным образом ведут себя все pcap-based-снифферы. Помогает замена ядра на std-def.
p6/2.6.32-el-smp-alt27 # ethtool -i eth0 driver: e1000e version: 1.2.20-k2 firmware-version: 1.3-0 bus-info: 0000:00:19.0 На дуплексном потоке в районе 50 мегабит udp ловится. На буднях попробую момент поймать, когда за 100 мегабит вылезет.
У меня: # ethtool -i none driver: tg3 version: 3.119 firmware-version: 5721-v3.65, ASFIPMI v6.24 bus-info: 0000:03:00.0 Но это уже не std-def Как доберусь, попробую на совсем другой сетевой карте проверить
> Но это уже не std-def ^^ на
> Как доберусь, попробую на совсем другой сетевой карте проверить проверил, на e1000e тоже не ловится
Собрал стендик. Получатель трафика на материнке Intel S3210SH, там две бортовых гигабитных сетевых карты. Ядро 2.6.32-ovz-el-alt34. Источник - Intel S3420GP, тоже бортовая сетевая, хотя наверное, источник не сильно важен. Трафик генерировался с помощью iperf. Поток 800 мегабит (пакеты, правда, большие - что-то не видно, как в iperf размером пакета управлять иначе, чем через размер буфера, а при буфере 64b скорость больше 30-и мегабит не получается). tcpdump что-то ловит, надо какие-то ещё различия искать. Intel Corporation 82541GI Gigabit Ethernet Controller driver: e1000 version: 7.3.21-k6-1-NAPI firmware-version: N/A 15:06:20.077836 IP 10.1.1.2.58829 > 10.1.1.1.5001: UDP, length 1470 15:06:20.077840 IP 10.1.1.2.58829 > 10.1.1.1.5001: UDP, length 1470 15:06:20.077842 IP 10.1.1.2.58829 > 10.1.1.1.5001: UDP, length 1470 ^C 40657 packets captured 153633 packets received by filter 112905 packets dropped by kernel Intel Corporation 82566DM-2 Gigabit Network Connection driver: e1000e version: 1.2.20-NAPI firmware-version: 1.3-0 15:15:18.424714 IP 10.1.1.2.43417 > 10.1.1.1.5001: UDP, length 1470 15:15:18.424718 IP 10.1.1.2.43417 > 10.1.1.1.5001: UDP, length 1470 15:15:18.424720 IP 10.1.1.2.43417 > 10.1.1.1.5001: UDP, length 1470 ^C 152005 packets captured 792383 packets received by filter 640378 packets dropped by kernel
отправил, перечитал и увидел, что тестировал ovz-el (копипаст, однако. :-) ). Переделал тесты с 2.6.32-el-smp-alt27, всё работает точно так же.
Блин. С самого начала подумал, но подумал, что мысль не очень правильная. > tshark -f "udp port 2944" -i интерфейс tshark -i интерфейс, очевидно, покажет весь udp-трафик. Думаю, что я воспроизвёл ситуацию. 803.1q используется ведь ? "tcpdump -ni eth2 udp" с ядром std-def игнорирует метку 803.1q (ядро декодирует автоматом, что ли ?) и показывает трафик, а с el-smp этот фильтр не работает - соответствия не находится. Однако, весь этот трафик становится видно, если смотреть так: "tcpdump -ni eth2 | grep UDP".
(In reply to comment #7) > 803.1q 802.1q, конечно.
(В ответ на комментарий №8) > (In reply to comment #7) > > 803.1q > > 802.1q, конечно. Гм. Интеловские карты же вроде бы на аппаратном уровне теги обрабатывают?
Вроде бы да. Но, возможно, включением/выключением этого драйвер занимается. И, может, как-то на это переключение в promiscuous mode ещё влияет, при чём в разных ядрах по-разному. Тут надо почитать/посмотреть, пока не знаю.
> "tcpdump -ni eth2 udp" с ядром std-def игнорирует метку 802.1q (ядро декодирует > автоматом, что ли ?) и показывает трафик, а с el-smp этот фильтр не работает - > соответствия не находится. Однако, весь этот трафик становится видно, если > смотреть так: "tcpdump -ni eth2 | grep UDP". С помощью grep 2944 я по-прежнему ничего не вижу, так что гипотеза, видимо, не подтверждается.
(In reply to comment #11) > С помощью grep 2944 я по-прежнему ничего не вижу, так что гипотеза, > видимо, не подтверждается. 2944, случайно, в /etc/services не доописан ? Всё же погрепать бы по "UDP" (можно grep -i на всякий случай) - в принципе посмотреть, UDP есть, или нет совсем.
> 2944, случайно, в /etc/services не доописан? Нет > Всё же погрепать бы по "UDP" > (можно grep -i на всякий случай) - в принципе посмотреть, UDP есть, или нет > совсем. Есть и довольно много. Если сохранить в файл, а потом рыться в нем с помощью wireshark, то ничего по порту 2944 опять же не видно
А что на nobody ? kernel-image-el-smp в Сизифе нет уже, можно и как wontfix.
