Недавно обратился клиент с проблемой на 802.11 сети: с мобильных телефонов часто не удавалось подключиться к SSID, зависало на фазе аутентификации. Со стационарных устройств таких проблем замечено не было - но именно с мобильных, как сообщал заказчик. Мы попросили сообщить происходит ли это во время удаления пользователя от точки доступа или нет, но клиент не смог сообщить, он сам не знал где физически располагаются точки доступа.

Точки доступа Huawei управлялись с контроллера AC6605. Мы запросили диагностическую информацию и логи с контроллера, и заметили, что проблема происходит, когда RSSI принимаемого сигнала от мобильного устройства доходил до примерно -72 dbm. При этом в логах генерировалась масса сообщений об отсутствии ответа от мобильного телефона, из-за чего точка AP пересылала EAPoL запрос снова и снова:

Лог пересылки EAPoL сообщения из-за отсутствия ответа на предыдущий запрос
Лог пересылки EAPoL сообщения из-за отсутствия ответа на предыдущий запрос

EAPoL - это формат инкапсуляции пакетов, определенный протоколом 802.1X. EAPoL в основном используется для передачи пакетов EAP по локальной сети между клиентом и сервером аутентификации. Иными словами, EAP (Extensible Authentication Protocol) - это сообщение, которое содержит данные для аутентификации. Оно инкапсулируется в формат, который называется EAPoL, чтобы быть переданным по сети между всеми участниками процесса аутентификации.

Множественный повтор отправки EAPoL сообщения из-за отсутствия ответа на предыдущий запрос
Множественный повтор отправки EAPoL сообщения из-за отсутствия ответа на предыдущий запрос

Поскольку уровень сигнала RSSI находился на пределе, мы предположили, что установка меньшего MTU (по умолчанию 1500 байт) сделает пакеты более устойчивыми, так как с увеличением размера пакета вероятность потери этого пакета увеличивается при низком уровне сигнала. А отключение тайм-аута сеанса заставит точку доступа ждать пакетов от мобильного устройства дольше.

В результате это, действительно, сделало обмен пакетами на этапе аутентификации более надежным:

[AC6605] radius-server template XXXXXX

[AC6605-radius-XXXXXX] radius-server attribute translate

[AC6605-radius-XXXXXX] radius-attribute disable session-timeout receive

[AC6605-radius-XXXXXX] radius-attribute set framed-mtu 1000

---

Почему и как MTU (и MSS) влияют на скорость передачи данных подробнее: "Большой разбор TCP: почему ping есть, но соединения нет!"

Комментарии (4)


  1. vadimr
    07.09.2022 10:04
    +4

    Хорошая техническая статья по делу, таких уже почти не осталось на хабре.


    1. BigBeerman
      07.09.2022 13:31
      +6

      в формате твита :) В журнале Радио раньше часто можно было такие встретить, мол, если телевизор вдруг стал показывать сине-зеленым, замените резистор R56 на номинал 2.2 килоома, ну и путь, как автор статьи к этому пришел


  1. alexyr
    07.09.2022 14:18
    +2

    На openwrt 2.4G клиенты иногда не могут нормально подключиться. В логе видно попытку, но не получают IP. Может такое быть по похожим причинам? На 5G такого не происходит


  1. Txanxs
    07.09.2022 20:38
    +4

    Согласно документации на хуавей -

    "When the Access-Challenge packet sent by the RADIUS server contains EAP information longer than 1200 bytes, the terminal may fail to receive the EAP Request/Challenge packet. In this case, you can run this command to set attribute-name to Framed-Mtu and reduce the value of the Frame-Mtu attribute in the authentication request packet sent by the device to the RADIUS server. The default value of the Frame-Mtu attribute is 1500. You can change it to 1000."

    Т.е. вряд ли проблема в слабом сигнале Wi-Fi.