#334 closed улучшение (fixed)
Плохой выбор bind-адреса в режиме "Авто"
| Reported by: | alx | Owned by: | dimag |
|---|---|---|---|
| Priority: | trivial | Milestone: | 2 очередь |
| Component: | ПО MC04-Dispatcher. Пульт диспетчера/техника | Keywords: | network |
| Cc: | san |
Description (last modified by )
Сейчас при установке "настройки bind-адреса" в значение "Auto" программа bind'ит UDP транспорт на адрес 0.0.0.0. Это один из самых неудачных вариантов, какие только можно придумать.
Предлагаю выбирать в качестве bind-адреса адрес интерфейса, в который указывает маршрут к выбранному серверу.
Change History (40)
follow-up: 4 comment:1 by , 8 years ago
follow-ups: 6 16 comment:3 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Priority: | major → trivial |
| Status: | new → assigned |
| Type: | баг → улучшение |
Сейчас у меня на ноутбуке два сетевых интерфейса: "Wi-fi" и медный "Eth".
Дефолтный маршрут в вай-фай.
В настройке Авто "программа работает" при подключении к серверу через любой из интерфейсов.
А если программа будет bind-иться на адрес интерфейса из дефолтного маршрута(вай фай), будет ли она работать если к серверу подключена через "Eth"?
Программа выберет адрес "вай-фай", а сервер не сможет отправить пакеты на адрес вай-фай, он про него ничего не знает, он видит только "Eth" и роутинга в сеть "Wi-fi" у него нет.
Вобщем я немного запутан, и пока не уверен что стоить менять bind-адрес по умолчанию.
(тикет пока заберу себе)
comment:4 by , 8 years ago
Replying to san:
А чем конкретно неудачен этот вариант?
В этом варианте невозможно предугадать, какой будет адрес отправителя у отправляемого пакета. Легко можно получить ситуацию, когда на запрос, направленный на один адрес, программа ответит с другого адреса. В результате такой пакет может быть отброшен либо самим получателем, либо даже где-то по дороге, если попадется какой-нибудь statefull firewall, отслеживающий соответствие запросов и ответов.
comment:5 by , 8 years ago
comment:6 by , 8 years ago
Replying to san:
А если программа будет bind-иться на адрес интерфейса из дефолтного маршрута(вай фай), будет ли она работать если к серверу подключена через "Eth"?
Программа выберет адрес "вай-фай", а сервер не сможет отправить пакеты на адрес вай-фай, он про него ничего не знает, он видит только "Eth" и роутинга в сеть "Wi-fi" у него нет.
Вот для таких случаев у нас предусмотрено ручное указание адреса в конфигурации.
follow-up: 9 comment:7 by , 8 years ago
Какие преимущества даёт вариант "Авто" с выбором адреса из дефолтного маршрута, если мы всё-равно не знаем "куда подключен сервер" ?
Кому и в каких случаях пригодится этот вариант?
comment:8 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
r361
Задал bind-адрес 192.168.0.81, совпадающий с IP моего подключения - выдалось следующее сообщение, то есть SIP клиент стла привязан к адресу 192.168.0.81
11:13:42.063 pjsua_core.c SIP UDP socket reachable at 192.168.0.81:6000
11:13:42.063 udp030BBB20 SIP UDP transport started, published address is 192.168.0.81:6000
Для авто применяется адрес используемый SIP-клиентом по умолчанию.
comment:9 by , 8 years ago
Replying to san:
Какие преимущества даёт вариант "Авто" с выбором адреса из дефолтного маршрута,
Преимущество по сравнению с чем? Если с вариантом "ручной", то преимущество в отсутствии необходимости выяснения, какой адрес у компьютера, и ввода этого адреса в настройках.
если мы всё-равно не знаем "куда подключен сервер" ?
? А зачем нам это знать?
Кому и в каких случаях пригодится этот вариант?
Наверное тому, кто не находится в ситуации, подобной описанной тобой в comment:3.
follow-ups: 12 27 comment:10 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
У меня в r361 программа по-прежнему привязывается к адресу 0.0.0.0.
comment:11 by , 8 years ago
Дима, будь внимательней.
- В этом тикете речь о том "Какой bind-адрес устанавливать врежиме авто"
- к тому-же, тикет я забрал себе, для обдумывания
А про неработающую настройку bind-адреса которую ты, кажется, починил - тикет #332
follow-up: 14 comment:12 by , 8 years ago
comment:14 by , 8 years ago
Replying to dimag:
Как вы это узнаёте?
root@voip:~# netstat -ulnp |grep MC04Disp udp 0 0 0.0.0.0:5061 0.0.0.0:* 12432/MC04Dispatche
В каком режиме "Авто" или "Ручная" с прописанным bind-адресом?
Если я жалуюсь на поведение программы в режиме "Авто", то и проверяю ее работу в режиме "Авто".
comment:16 by , 8 years ago
Поэтому и предлагаю тебе быть внимательней
Owner changed from dimag to san
(тикет пока заберу себе)
к тому-же, тикет я забрал себе, для обдумывания
comment:17 by , 8 years ago
У меня появилась: поскольку на момент привязки сокета уже известен адрес сервера, с которым мы будет работать, при выборе адреса привязки вместо дефолтного маршрута будет лучше брать маршрут к серверу.
comment:18 by , 8 years ago
| Description: | modified (diff) |
|---|
comment:21 by , 8 years ago
то есть, если адрес сервера 192.168.0.73, то при работе в режиме "авто" надо использовать адрес сервера 192.168.0.73?
follow-up: 23 comment:22 by , 8 years ago
Дима, я не понял твоего вопроса
Как я понимаю:
- Мы знаем адрес сервера
- Среди маршрутов мы должны найти маршрут к серверу
- Взять IP адрес интерфейса из этого маршрута и использовать его в качестве нашего bind-адреса
Алексей, поправь, если ошибаюсь
comment:23 by , 8 years ago
Replying to san:
Алексей, поправь, если ошибаюсь
Могу только уточнить, что здесь под сервером имеется в виду внешний SIP-сервер, с которым мы собираемся работать (прокси или непосредственно FreeSwitch).
А вопрос Димы я тоже не понял.
follow-up: 25 comment:24 by , 8 years ago
Как насчёт того, что в режиме "авто" оставить маршрут по умолчанию испльзуемый PJSIP?
comment:25 by , 8 years ago
Replying to dimag:
Попробую угадать, ты подразумеваешь: Как насчёт оставить в режиме "авто" bind-адрес 0.0.0.0 ?
comment:26 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
r361
Хорошо, пусть будет адрес 0.0.0.0
comment:27 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:28 by , 8 years ago
Дима разговаривает сам с собой и договорившись с собой закрывает тикет.
Дима:
- прочитай текст тикета
- прочитай comment:22
- Если что-то не понятно - спроси
comment:30 by , 8 years ago
В качестве примера того, как выбирается адрес, можно посмотреть, как в библиотеле libeXosip2 реализована функция eXosip_guess_localip().
comment:31 by , 8 years ago
comment:32 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
r413
Получаю bind-адрес по умолчанию, как в eXoSIP.
comment:33 by , 8 years ago
Правильно ли я понял, что сейчас bind-адрес выбирается исходя из маршрута на адрес "217.12.3.11" (строка 583 файла PJSIPSUA.cpp) и, таким образом, алгоритм не соответствует предложенному в описании тикета?
follow-up: 36 comment:34 by , 8 years ago
Нет, в качестве маршрута должен возвратиться маршрут на адрес 192.168.0.63(адрес сервера).
Если параметр host функции _eXosip_guess_ip_for_via равен NULL или не удалось получить маршрут к адресу заданному в host - 192.168.0.63, то пытаемся найти маршрут к 217.12.3.11.
Алгоритм соотвествует предложенному в описание, взят из исходного кода eXoSIP.
comment:35 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Зачем нам искать маршрут к 217.12.3.11 ?
Это таким образом ищется маршрут в интернет?
Зачем нам в интернет?
Дима объяснил существующий алгоритм так:
- Ищем маршрут на сервер
- Если не нашли ищем маршрут в 217.12.3.11
- если и его не нашли, то ищем маршрут в 127.0.0.1
- если его нет то биндимся в 0.0.0.0
Предлагаю убрать шаг 2 из существующего алгоритма. Алексей, что скажешь?
comment:36 by , 8 years ago
Replying to dimag:
Нет, в качестве маршрута должен возвратиться маршрут на адрес 192.168.0.63(адрес сервера).
OK, спасибо за разъяснение. Не увидел сразу этого в коде.
Replying to san:
Зачем нам искать маршрут к 217.12.3.11 ? Это таким образом ищется маршрут в интернет? Зачем нам в интернет?
Вероятно, предполагается, что если взять наугад произвольный интернет-адрес, вероятность, что он подпадает под какой-то специальный (non-default) маршрут в таблице маршрутизации, стремится к нулю. Таким образом, можно быть (почти) уверенным, что данный маршрут - дефолтный.
Обрати внимание, что программа использует этот адрес только в том случае, если не смогла разресолвить адрес сервера (FS или прокси). Таким образом, это всего лишь fallback. Какой именно это будет fallback, не очень интересно, так как если адрес сервера не ресолвится, программа все равно работать не сможет.
Предлагаю убрать шаг 2 из существующего алгоритма.
Во-первых, описание Димы существующего алгоритма не соответствует действительности. Смотри PJSIPSUA.cpp в районе строки 582. Я вижу там следующее:
- Ресолвим адрес сервера в IP.
- Если IP получить не удалось (имя не ресолвится), используем адрес 217.12.3.11.
- Ищем маршрут на полученный IP адрес.
Никакого "если ...не удалось получить маршрут к адресу заданному в host, то пытаемся найти маршрут к 217.12.3.11" в коде нет.
Во-вторых, "если и его не нашли, то ищем маршрут в 127.0.0.1" ни в комментарии Димы, ни в коде нет. И вообще искать маршрут на адрес 127.0.0.1 - глупо, он заведомо указывает в loopback-интерфейс.
Таким образом, единственное, в чем я здесь могу согласиться - это с тем, что если не удалось получить маршрут, то использовать адрес 0.0.0.0 (и выдать предупреждение хотя бы в лог!) вместо 127.0.0.1, так как с последним заведомо ничего работать не будет...
Кстати, тут в коде, похоже, баг - не освобождается результат ресолвинга. Создал тикет #406.
follow-up: 38 comment:37 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
r418
Теперь ищется маршрут только к серверу, если не найден, то используется адрес используемый PJSIP по умолчанию.
comment:38 by , 8 years ago
Replying to dimag:
если не найден, то используется адрес используемый PJSIP по умолчанию.
И какой это адрес?
comment:39 by , 8 years ago
Видимо я слишком доверчивый... код не смотрел, записал алгоритм со слов Димы.
Да, 127.0.0.1 - глупо, в самом деле
Replying to alx:
А чем конкретно неудачен этот вариант?