Opened 3 years ago

Closed 3 years ago

#381 closed баг (fixed)

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

Reported by: san Owned by: alx
Priority: фигня Milestone: 1 очередь
Component: VE-02 Keywords:
Cc:

Description

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

Attachments (1)

1.png (62.2 KB ) - added by san 3 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 by san, 3 years ago

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

comment:2 by alx, 3 years ago

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

comment:3 by alx, 3 years ago

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

comment:4 by alx, 3 years ago

Первые несколько сообщений 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.

comment:5 by alx, 3 years ago

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

Last edited 3 years ago by alx (previous) (diff)

comment:6 by san, 3 years ago

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

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)

in reply to:  2 comment:7 by san, 3 years ago

Replying to alx:

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

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

comment:8 by san, 3 years ago

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

in reply to:  6 ; comment:9 by alx, 3 years ago

Replying to san:

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

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

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

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

Last edited 3 years ago by alx (previous) (diff)

in reply to:  9 comment:10 by alx, 3 years ago

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 поток, а отпарвитель (телефон) его еще передает. Как результат, эти переданные телефоном RTP пакеты уже не обрабатываются MSP платы VE-02 (так как она уже не работает с этим потоком), а форвардятся в CSP, который и генерирует в ответ ICMP Destination unreachble.

Version 0, edited 3 years ago by alx (next)

comment:11 by san, 3 years ago

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

in reply to:  11 comment:12 by alx, 3 years ago

Replying to san:

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

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

Last edited 3 years ago by alx (previous) (diff)

comment:13 by san, 3 years ago

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

by san, 3 years ago

Attachment: 1.png added

in reply to:  13 ; comment:14 by alx, 3 years ago

Replying to san:

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

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

in reply to:  14 comment:15 by alx, 3 years ago

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...

comment:16 by san, 3 years ago

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

comment:17 by alx, 3 years ago

Resolution: не воспроизводится
Status: newclosed

comment:18 by san, 3 years ago

Priority: низкийфигня
Resolution: не воспроизводится
Status: closedreopened

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

comment:19 by alx, 3 years ago

Resolution: fixed
Status: reopenedclosed

In 2033/sip_ua:

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

Note: See TracTickets for help on using tickets.