Периодические сообщения Destination unreachble

[san]

Во время проверки схемы, я обнаружил некоторую странность.
К порту LAN платы VE-02 подключен SIP телефон и зарегистрирован на ней, также на плате есть окончание FS01. Совершая звонок телефон->окончание, я увидел что периодически плата VE-02 говорит по ICMP Destination unreachble, хотя соединение всё ещё активно и причин закрывать порт нет. Думаю, что это неправильно. При звонке в обратном направлении таких периодических сообщений я не увидел.
test1 - Звонок окончание -> телефон
test2 - Звонок телефон -> окончание
192.168.20.100 - IP адрес телефона.
дампы приложу ниже

[san]

Дампы положил в xchange\alx\Test_and_bugs\VE-02\destination unreachable\

[alx]

Уточни, пожалуйста, в чем именно по-твоему заключается баг. Или, иными словами, что я как разработчик могу сделать в рамках данного тикета?

[alx]

И приложи, пожалуйста, логи платы VE-02 за период, в котором устанавливалось это соединение.

[alx]

Первые несколько сообщений Destination unreachble передаются от платы VE-02 к телефону в 14:58:20. Насколько я вижу, за долю секунды до этого телефон отвечает сообщением SIP "200 OK" на вызов. В данном случае в серии сообщений ICMP Destination unreachble нет ничего странного. Телефон отправляет сообщение "200 OK" и активирует передачу RTP потока в направлении платы, однако в плате в этот момент RTP поток не активирован, и она не ожидает получения этого потока, так как еще не получила сообщение с ответом на предложение SDP. На то, чтобы плата VE-02 получила сообщение SIP, обработала его и активировала прием RTP потока, требуется некоторое время. За это время серия первых пакетов RTP, отправленных телефоном, вместо MSP попадают в CSP, который в ответ генерирует сообщение ICMP Destination unreachble.

[alx]

Выше описывалось то, что я видел в файле test1.pcap. В test2.pcap ситуация полностью аналогична (время инцидента 14:59:34).

[san]

Я специально не записывал, кажется ничего в логах нет

Dec 10 07:48:30 comcerto daemon.warn sip_ua[479]: poller.cpp:1089: --> registrat                                                                              ions updated.
Dec 10 07:48:30 comcerto daemon.err sip_ua[479]: fs01.cpp:390: module 1 [FS01]:                                                                               DC-DC calibration started...
Dec 10 07:48:30 comcerto daemon.err sip_ua[479]: fs01.cpp:427: module 1 [FS01]:                                                                               SLIC calibration started...
Dec 10 07:48:31 comcerto daemon.err sip_ua[479]: poller.cpp:3114: wget exited wi                                                                              th return code 1
Dec 10 07:48:33 comcerto daemon.err sip_ua[479]: fs01.cpp:541: module 1 [FS01]:                                                                               SLIC calibration 2 started...
Dec 10 07:48:37 comcerto user.debug kernel: eth2: no IPv6 routers present
Dec 10 12:17:54 comcerto authpriv.info dropbear[502]: Child connection from 10.4                                                                              1.114.193:49647

Первые несколько сообщений Destination unreachble передаются от платы VE-02 к телефону в 14:58:20. Насколько я вижу, за долю секунды до этого телефон отвечает сообщением SIP "200 OK" на вызов. В данном случае в серии сообщений ICMP Destination unreachble нет ничего странного.

Это я понимаю, речь о ICMP Destination unreachble гораздо позже начала соединения., например в 14:58:47 в файле test1 (#2829)

[san]

Replying to alx:

Уточни, пожалуйста, в чем именно по-твоему заключается баг. Или, иными словами, что я как разработчик могу сделать в рамках данного тикета?

Я сделал вывод, что поведение платы некорректно. Нужно разобраться действительно ли так это, если да. то попытаться устранить баг.

[san]

Кажется я в описании тикета перепутал в каком файле эти самые сообщения присутствуют, насколько я вижу они в test1.

[alx]

Replying to san:

Я специально не записывал, кажется ничего в логах нет

Тогда, наверное, и не надо, вроде бы и из дампов все видно. Я про логи написал еще до того, как стал смотреть дампы.

Это я понимаю, речь о ICMP Destination unreachble гораздо позже начала соединения., например в 14:58:47 в файле test1 (#2829)

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

[alx]

Replying to alx:

Это я понимаю, речь о ICMP Destination unreachble гораздо позже начала соединения., например в 14:58:47 в файле test1 (#2829)

Попробую посмотреть, наверное, уже в понедельник.

Посмотрел.

Как видно из дампа, через пол-секунды после данного сообщения в адрес телефона пришло SIP сообщение BYE. На основании этого предполагаю, что имела место ситуация, подобная описанной ранее в comment:4, но с обратным порядком событий:

1. Канальное окончание платы VE-02 принимает решение отбиться от имеющегося соединения. Для этого оно деактивирует медиапоток и передает в сеть сообщение BYE.
2. Сообщение BYE "путешествует" от канального окончания платы VE-02 до телефона, по доорге обрабатываясь в промежуточных пунктах (прокси-серверах).
3. Сообщение BYE принимается телефоном и обрабатывается в нем.
4. Телефон деактивирует медиапоток (перестает отправлять RTP пакеты).

Так как пункты 2 и 3 описанного процесса не выполняются мгновенно, существует ненулевой отрезок времени, когда получатель (канальное окончание платы VE-02) уже отключил обработку RTP потока в MSP, а отпарвитель (телефон) его еще передает. Как результат, эти переданные телефоном RTP пакеты уже не обрабатываются MSP платы VE-02, а форвардятся в CSP, который и генерирует в ответ ICMP Destination unreachble. Бага в описанной ситуации нет.

[san]

Ок... ещё одна попытка 14:58:42(#2319 в файле test 1) :) ?

[alx]

Replying to san:

Ок... ещё одна попытка 14:58:42(#2319 в файле test 1) :) ?

Наугад называешь? :) Тут ты меня поймал - у меня нет объяснения этому сообщению. Ни до него, ни после него (на разумном временном отрезке) никаких сигнальных сообщений нет...

[san]

Интересно что эти сообщения которым нет объяснения повторяются каждую секунду, начиная с начала соединения и до конца.

[alx]

Replying to san:

Интересно что эти сообщения которым нет объяснения повторяются каждую секунду, начиная с начала соединения и до конца.

Хм... Так может быть телефон вообще шлет RTP на неправильный номер порта (который MSP не слушает)? Связь-то при этом вообще работает?

[alx]

Replying to alx:

Хм... Так может быть телефон вообще шлет RTP на неправильный номер порта (который MSP не слушает)? Связь-то при этом вообще работает?

Посмотрел SDP в INVITE и ответе "200 OK". Вроде бы все правильно - на стороне FS08 адрес 10.41.114.236 порт 10508, на стороне телефона адрес 192.168.20.100 порт 12242. И телефон шлет RTP с 192.168.20.100:12242 на 10.41.114.236:10508...

[san]

Связь работает, голос было слышно в обе стороны.

[san]

У меня воспроизводится, но не каждый раз и сообщение Destination unreachble теперь не каждую секунду разговора а раз в 5 секунд.
Не знаю с чем связаны отличия в воспроизведении бага: по сравнению с предыдущим экспериментом изменилась версия прошивки, модель Sip-телефона и Sip в телефоне работает через TCP, а не UDP.
VE-02 ревизии 31

[alx]

In 2033/sip_ua:

Шлюз больше не передает медиапотоки в eth2 с фиктивного адреса 169.254.5.5.
В iptables убрана трансляция из фиктивного адреса 169.254.5.5 в реальный.
Добавлен модуль mediaProxy, передающий входящие через eth2 медиапотоки
в MSP. Добавлено правило iptables, блокирующее исходящие в eth2 сообщения
ICMP port unreachable. Closes #381.