26626 2011-11-25 13:49:34 +0400 Потеря пакетов в pcap-приложениях 2014-02-15 21:54:41 +0400 1 1 4 Development Sisyphus kernel-image-el-smp unstable all Linux CLOSED WONTFIX P3 normal --- 1 enp nobody aspsk asy boris boyarsh dubrsl glebfm ldv mike mithraen rider sbolshakov shrek sin stalker vitty vsu zerg qa-sisyphus oldest_to_newest 127188 0 enp 2011-11-25 13:49:34 +0400 Есть порт на коммутаторе, в который за минуту насыпается десяток гиг (mirroring-group monitor-port), и соединенный с ним сетевой интерфейс на сервере с t6/branch. Запускаю tshark примерно так: tshark -f "udp port 2944" -i интерфейс Но ничего не ловится. И даже если снять фильтр, то в отловленном никаких UDP-пакетов через требуемый порт не наблюдается. Аналогичным образом ведут себя все pcap-based-снифферы. Помогает замена ядра на std-def. 127207 1 asy 2011-11-26 14:49:00 +0400 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 мегабит вылезет. 127209 2 enp 2011-11-26 15:07:26 +0400 У меня: # ethtool -i none driver: tg3 version: 3.119 firmware-version: 5721-v3.65, ASFIPMI v6.24 bus-info: 0000:03:00.0 Но это уже не std-def Как доберусь, попробую на совсем другой сетевой карте проверить 127210 3 enp 2011-11-26 15:10:58 +0400 > Но это уже не std-def ^^ на 127215 4 enp 2011-11-28 10:27:01 +0400 > Как доберусь, попробую на совсем другой сетевой карте проверить проверил, на e1000e тоже не ловится 127291 5 asy 2011-11-30 11:52:06 +0400 Собрал стендик. Получатель трафика на материнке 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 127292 6 asy 2011-11-30 12:05:08 +0400 отправил, перечитал и увидел, что тестировал ovz-el (копипаст, однако. :-) ). Переделал тесты с 2.6.32-el-smp-alt27, всё работает точно так же. 127295 7 asy 2011-11-30 13:12:00 +0400 Блин. С самого начала подумал, но подумал, что мысль не очень правильная. > 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". 127296 8 asy 2011-11-30 13:13:41 +0400 (In reply to comment #7) > 803.1q 802.1q, конечно. 127297 9 stalker 2011-11-30 13:35:44 +0400 (В ответ на комментарий №8) > (In reply to comment #7) > > 803.1q > > 802.1q, конечно. Гм. Интеловские карты же вроде бы на аппаратном уровне теги обрабатывают? 127298 10 asy 2011-11-30 13:52:17 +0400 Вроде бы да. Но, возможно, включением/выключением этого драйвер занимается. И, может, как-то на это переключение в promiscuous mode ещё влияет, при чём в разных ядрах по-разному. Тут надо почитать/посмотреть, пока не знаю. 127386 11 enp 2011-12-05 09:28:08 +0400 > "tcpdump -ni eth2 udp" с ядром std-def игнорирует метку 802.1q (ядро декодирует > автоматом, что ли ?) и показывает трафик, а с el-smp этот фильтр не работает - > соответствия не находится. Однако, весь этот трафик становится видно, если > смотреть так: "tcpdump -ni eth2 | grep UDP". С помощью grep 2944 я по-прежнему ничего не вижу, так что гипотеза, видимо, не подтверждается. 127388 12 asy 2011-12-05 10:00:30 +0400 (In reply to comment #11) > С помощью grep 2944 я по-прежнему ничего не вижу, так что гипотеза, > видимо, не подтверждается. 2944, случайно, в /etc/services не доописан ? Всё же погрепать бы по "UDP" (можно grep -i на всякий случай) - в принципе посмотреть, UDP есть, или нет совсем. 127389 13 enp 2011-12-05 13:21:00 +0400 > 2944, случайно, в /etc/services не доописан? Нет > Всё же погрепать бы по "UDP" > (можно grep -i на всякий случай) - в принципе посмотреть, UDP есть, или нет > совсем. Есть и довольно много. Если сохранить в файл, а потом рыться в нем с помощью wireshark, то ничего по порту 2944 опять же не видно 145273 14 asy 2014-02-15 21:54:18 +0400 А что на nobody ? kernel-image-el-smp в Сизифе нет уже, можно и как wontfix.