freebsd. icmp не видит _большие_ пакеты, которые видит tcpdump.
MTU на l2tp канале меньше 1500 байт.
http://www.netup.ru/phpbb/viewtopic.php?t=1199
Возможно, еще в mpd есть опция - запрещающая фрагментацию только ICMP пакетов
http://www.netup.ru/phpbb/viewtopic.php?t=1199
Возможно, еще в mpd есть опция - запрещающая фрагментацию только ICMP пакетов
с mtu игрался по-всякому. и в конфиге и через ifconfig
Я хочу обратить внимание на то, что ситуация симметричная. оба хоста отвечают на большие пинги большими пакетами, но они не могут распознать ответ.
пинг в одну сторону(одно и тоже на обоих интерфейсах)
пинг в другую (одно и тоже на обоих интерфейсах)
Вот. после того, как я оставил на ночь этот пинг, теперь mpd5 stop не хочет выполняться.
прибить его можно как-то без перезагрузки всего компа?
все нетграф-ноды удалил руками. Процесс всё равно висит.
kill -9 5549
не прибивает. Такое бывает?
Я хочу обратить внимание на то, что ситуация симметричная. оба хоста отвечают на большие пинги большими пакетами, но они не могут распознать ответ.
пинг в одну сторону(одно и тоже на обоих интерфейсах)
15:33:21.653772 IP 192.168.101.2 > 192.168.101.1: ICMP echo request, id 15318, seq 55512, length 1376
15:33:21.653782 IP 192.168.101.2 > 192.168.101.1: icmp
15:33:21.657296 IP 192.168.101.1 > 192.168.101.2: ICMP echo reply, id 9069, seq 55512, length 1376
15:33:21.657313 IP 192.168.101.1 > 192.168.101.2: icmp
пинг в другую (одно и тоже на обоих интерфейсах)
15:34:28.673704 IP 192.168.101.1 > 192.168.101.2: ICMP echo request, id 54730, seq 2, length 1376
15:34:28.673710 IP 192.168.101.1 > 192.168.101.2: icmp
15:34:28.673717 IP 192.168.101.2 > 192.168.101.1: ICMP echo reply, id 54730, seq 2, length 1376
15:34:28.673723 IP 192.168.101.2 > 192.168.101.1: icmp
Вот. после того, как я оставил на ночь этот пинг, теперь mpd5 stop не хочет выполняться.
52 london ...etc/mpd5(0/1)# ngctl list
There are 15 total nodes:
Name: <unnamed> Type: ksocket ID: 000001d2 Num hooks: 1
Name: <unnamed> Type: l2tp ID: 000001d0 Num hooks: 2
Name: <unnamed> Type: socket ID: 000001cf Num hooks: 1
Name: em0 Type: ether ID: 00000001 Num hooks: 0
Name: em1 Type: ether ID: 00000002 Num hooks: 0
Name: mpd5549-cso Type: socket ID: 000001ac Num hooks: 0
Name: mpd5549-eso Type: socket ID: 000001ad Num hooks: 0
Name: mpd5549-lso Type: socket ID: 000001ab Num hooks: 1
Name: ngctl88212 Type: socket ID: 000001dc Num hooks: 0
Name: vboxnetflt_em1 Type: vboxnetflt ID: 00000046 Num hooks: 0
Name: vboxnet0 Type: ether ID: 00000004 Num hooks: 2
Name: mpd5549-toklon Type: ppp ID: 000001af Num hooks: 1
Name: vboxnetflt_vboxnet0 Type: vboxnetflt ID: 00000047 Num hooks: 2
Name: ipfw0 Type: ether ID: 00000003 Num hooks: 0
Name: mpd5549-stats Type: socket ID: 000001b7 Num hooks: 0
прибить его можно как-то без перезагрузки всего компа?
все нетграф-ноды удалил руками. Процесс всё равно висит.
kill -9 5549
не прибивает. Такое бывает?
# ps wwaux |grep 5549что-то как-то всё поменялось, а я и не заметил.
root 5549 0.0 0.0 31476 5544 ? DNs 11:11PM 0:01.07 /usr/local/sbin/mpd5 -p /var/run/mpd5.pid -b
mpd5 повис намертво.
kill -9 его не берёт даже после удаления всех его ng-нод.
Более того. Запускаю другой mpd5.(даже без поднятия соединения, потому что bind:address already in use) - он тоже не прибивается по kill -9
Ребут делать не хочу. Уж больно интересно, что произошло. Раньше бывало, что mpd вис, но после kill-9 он убивался, хотя и оставлял после себя ng-ноды, которые руками приходилось удалять.
kill -9 его не берёт даже после удаления всех его ng-нод.
Более того. Запускаю другой mpd5.(даже без поднятия соединения, потому что bind:address already in use) - он тоже не прибивается по kill -9
Ребут делать не хочу. Уж больно интересно, что произошло. Раньше бывало, что mpd вис, но после kill-9 он убивался, хотя и оставлял после себя ng-ноды, которые руками приходилось удалять.
А в каком состоянии процесс mpd? На каком wchan висит?
Эх. чуть-чуть не дотерпел и ребутнулся 
.
А в каком он состоянии может быть, что по -9 не убивается?
.А в каком он состоянии может быть, что по -9 не убивается?
MTU на l2tp канале меньше 1500 байт.
Так это я знаю.
на другом интерфейсе ng0 (до пройдера) тоже mtu < 1500 и всё проходит, хотя выглядит вот так:
#ping -s 1500 1.1.1.1
18:28:31.390825 IP 2.2.2.2 > 1.1.1.1: ICMP echo request, id 14344, seq 3, length 1440
18:28:31.390834 IP 2.2.2.2> 1.1.1.1: icmp
18:28:31.393850 IP 1.1.1.1 > 2.2.2.2: ICMP echo reply, id 14344, seq 3, length 40
18:28:31.394045 IP 1.1.1.1 > 2.2.2.2: icmp
18:28:31.394054 IP 1.1.1.1 > 2.2.2.2: icmp
хотя это провайдер кромсает пакеты. с 1.1.1.1 они уходят в другом формате.
Я опасаюсь, что он был в состоянии ngsock.
если ещё раз повиснет, гляну.
а ноды могут нормально остановлены(ngctl shutdown если он был в этом состоянии?
а ноды могут нормально остановлены(ngctl shutdown если он был в этом состоянии?
Попробуй убивать сигналом -15, а не -9.
Да, ноды от процессов не зависят.
так я сначала /usr/local/etc/rc.d/mpd5 stop сделал.
а потом и kill `cat /var/run/mpd5.pid`, который 15 и посылает.
а потом уже -9
а потом и kill `cat /var/run/mpd5.pid`, который 15 и посылает.
а потом уже -9
вот такое у меня было года 4 назад.
http://www.mail-archive.com/freebsd-freebsd.org/msg97...
но сейчас ребутнулся штатно.
а что это за wchan такой?
http://www.mail-archive.com/freebsd-freebsd.org/msg97...
но сейчас ребутнулся штатно.
а что это за wchan такой?
Когда из юзерленда выполняется send в нетграфовый контрольный сокет, и сообщение не может быть доставлено синхронно, например потому, что та нода, которой адерсовано сообщение, сейчас залочена, то тред засыпает на ngsock. Когда сообщение достигает адресата, и адресат отрабатывает сообщение, то он прописывает return value в нужное место и пробуждает тред, пославший сообщение.
Похоже существует баг, когда сообщение теряется, например по причине того, что адресат исчез, и никто не пробуждает спящий тред.
Похоже существует баг, когда сообщение теряется, например по причине того, что адресат исчез, и никто не пробуждает спящий тред.
а почему он по -9 не убивается-то? чтобы избежать ситуации, что отослалось пол-сообщения?
и самое интересное, как его разбудить из этого состояния?
и самое интересное, как его разбудить из этого состояния?
Никак не разбудить, он засыпает так, что сигналы не доставляются. Это сделано специально, потому что согласно API, NgSendMsg отрабатывает синхронно и непрерываем. Кстати API нетграфа для userland не менялся со времён FreeBSD 4.0, очень не хотелось бы создавать прецедент.
Конечно, логично было бы если бы для -9 в ядре существовало исключение.
Вообще здорово бы получить воспроизводимый скрипт, который создаёт зависший на ngsock процесс.
Конечно, логично было бы если бы для -9 в ядре существовало исключение.
Вообще здорово бы получить воспроизводимый скрипт, который создаёт зависший на ngsock процесс.
Оставить комментарий
Phoenix
Есть 2 сервера. между ними ppp соединение. Пробовал vtund, udp на mpd5. сейчас вот l2tp на mpd5.Иногда(от чего зависит, до сих пор не пойму) появляется такое поведение.
в это время на tcpdump показывает такое.
Т.е. пакетики возвратились, но приложение их не получило.
ещё из странностей.
1.1.1.1 - внешний адрес сервера1.
2.2.2.2 - внешний адрес сервера2.
10.208.44.0 -внутренний адрес сервера2.
Почему tcpdump показывает, что сообщение уходит с адреса 10.208.44 - неясно.
UPD почему они доходят - ясно. в mpd стоит опция set iface enable nat.
но почему уходят с адреса 10.208.44.0 всё равно непонятно
ng0 - это pptp соединение до 85.21.0.94 (гейт провайдера)
ng1 - это l2tp между 1.1.1.1 и 2.2.2.2
А приходят сообщения на другой конец так как нужно(с правильным адресом отправителя).
пробовал отключать nat на ng0 от mpd5 - всё равно пакеты отправляются правильно. Видимо, tcpdump почему-то не то показывает, что нужно.
на 2.2.2.2
FreeBSD server2 8.1-STABLE
на 1.1.1.1
FreeBSD server2 8.1-RELEASE
куда рыть-то? как может ping не работать, если tcpdump показывает пришедший ему ответ?
а вот маленькие пакеты нормально проходят