Jump to content

Search the Community

Showing results for tags 'udp'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Keenetic Community
    • Keenetic Development
    • Keenetic Community Support
    • Keenetic OS Testing
    • Mobile App
  • Open Package Support
    • Opkg Help
    • Opkg Cookbook
    • Opkg Cookbook RUS

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Location


Web-site


Interests


Occupation


AOL Account


ICQ Account


WLM


YAHOO


Facebook Account


Twitter Account


Skype Account


Youtube Account


Google+ Account


Keenetic

Found 2 results

  1. Хочу предложить добавить отображение udp трафика в "Мониторе трафика хостов". У меня этот трафик генерирует IPTV-приставка от провайдера. Хотелось-бы видеть не только tcp, но и udp - трафик с выключателем, показывать его или нет в мониторе.
  2. stderr

    Имеем: Keenetic 2 с прошивкой 2.12.B.0.0-4, статический белый IP от провайдера и локальную сеть из нескольких машин за NAT’ом. Возникла необходимость использовать UDP между машиной в локальной сети (за NAT’ом кинетика) и хостами во внешней сети (также с «белыми» IP). В связи с этим на кинетике были соответствующим образом проброшены порты: После бинда UDP-сокета на порту 5440 (для примера) локальной машины начинаются странности: - Если инициатором передачи данных выступает хост из «внешней» сети, то NAT ведет себя ожидаемым образом: пакет приходит на порт 5440 «белого» адреса Кинетика и переадресуется на порт 5440 машины в локальной сети. После чего ответные пакеты от машины локальной сети с «серого» порта 5440 успешно переправляются Кинетиком с «белого» порта 5440 на порт машины в глобальной сети. Сценарий отработал успешно и ожидаемо. - Если инициатором передачи данных выступает хост из локальной сети, то порт отправителя преобразуется Кинетиком в нечто совершенно странное, что хорошо видно на стороне хоста в глобальной сети (например, он показывает в качестве порта отправителя принятого пакета 35004). Дальше – интереснее: А) Если хост в глобальной сети отправляет ответ на «внешний» порт 5440 Кинетика (который должен пробрасываться), то до машины в локальной сети доходят данные с еще одним значением порта отправителя (1028, хотя локальная машина ожидает 5440 – ведь она отправляла данные туда) Б) Если хост в глобальной сети в ответ отправляет данные на указанный в принятом пакете порт отправителя (35004 в примере), то они успешно доходят до локальной машины, и в порте отправителя, как это ни странно, показывается 5440. Но при отправлении данных на этот же порт с другого «белого» IP они до локальной машины просто не доходят. Возникает ощущение, что NAT на Кинетике пытается использовать TCP’шную логику «сессий» для работы с UDP: если для исходящей дейтаграммы уже существует «сессия» для «серой» комбинации IP:порт, то при трансляции используется соответствующий «внешний» порт, если нет – то «внешний» порт выбирается случайным образом, при этом совершенно не учитывается, есть ли порт в таблице «переадресации» или нет. P.S. Специально откатил прошивку Кинетика на последнюю «релизную» 2.06 и проверил поведение на ней – данного бага не наблюдается, проброшенный порт всегда остается неизменным, то есть хост во внешней сети видит портом отправителя «правильный» 5440.
×