TCP соединение установлено/остается открытым до сброса клиентом… но данные отправить не получается(?!)

TCP соединение установлено/остается открытым до сброса клиентом… но данные отправить не получается(?!), wifiman

wbenroy

Guest

15.02.2025 21:20:00

После успешного установления TCP-соединения между клиентом и HTTP-сервером, клиент отправляет "HTTP GET /", но сервер никогда не подтверждает получение данных (ACK). Позже сервер повторно передает предыдущий ACK, но номер подтверждения предназначен для TCP SYN-пакета клиента, а не для данных, отправленных для HTTP-запроса. Я не обнаружил никаких сообщений в логах, указывающих на сброс пакетов из-за какой-либо политики или по другой причине. Я проверил консоль UniFi, dmesg на устройствах UniFi (UCG и AP) и pfctl на клиенте (macOS host firewall). Логирование на сервере ограничено, так как это устройство IoT (микроконтроллер esp32).

Ошибка происходит, когда клиент и сервер находятся в разных Wi-Fi сетях. Ошибка не происходит (все работает, и клиент может получить HTTP-ответ) если клиент подключен к проводному порту, подключенному к UCG, или если клиент находится в той же Wi-Fi сети, что и сервер.

Сервер является устройством IoT. Это esp32, на котором работает компонент web server из esphome (esphome -dot- io/components/web_server.html). Я пробовал несколько клиентов, включая Macbook Pro, Windows 11, iOS-устройство и домашний ассистент, работающий на Raspberry Pi. Все клиенты ведут себя одинаково. Они могут посещать HTTP-сайт, если они находятся в той же Wi-Fi сети или подключены по проводному соединению к порту UCG.

Я отключил брандмауэр хоста на Mac (кажется, я это сделал), но это не помогло. Отмечу, что Mac работает нормально (независимо от брандмауэра хоста), если он не находится в другой Wi-Fi сети (т.е., если он находится в той же Wi-Fi сети или использует проводное Ethernet-соединение к порту UCG).

Сеть состоит из UniFi Cloud Gateway с AP U7 Pro, подключенным к порту 1, и AP U6 Pro, который работает в меше через AP U7 Pro к UCG. Сервер всегда связан с U6 Pro на частоте 2,4 ГГц. Есть 3 SSID с названиями blah, blah-iot и roblox5g, которые находятся в сетях Humans, Things и Guests соответственно.

Когда я начал расследовать эту проблему, SSID blah-iot (сеть Things) транслировался только на U6 Pro, и была включена опция Enhanced IoT Connectivity. Сейчас я отключил Enhanced IoT Connection на blah-iot, чтобы я мог включить 5-GHz диапазон, я (пытался) сохранить все остальные настройки такими же, какими они были при включенной Enhanced IoT Connection. Но, похоже, это не меняет поведение.

В чем может быть проблема? Можете ли вы предложить какие-нибудь другие советы по устранению неполадок?

Приложенный файл wtf.zip содержит:
curl-from-mac.txt - вывод запроса curl к серверу с клиента на Mac, который в конечном итоге заканчивается таймаутом.
tcpdump-on-mac.txt - вывод tcpdump во время запроса curl, запущенный на том же клиенте на Mac.
tcpdump-on-ucg.txt - вывод tcpdump во время запроса curl, запущенный на UniFi Cloud Gateway.
tcpdump-on-U6Pro.txt - вывод tcpdump во время запроса curl, запущенный на UniFi U6 Pro AP.

Удачи!

Обновление/дополнительные сведения:

Я не упомянул, что все порты UCG находятся в сети Humans. Как указано выше, сервер всегда находится в сети Things. Все работает, если клиент подключен к порту UCG/сети Humans. Поэтому, похоже, это не проблема связи между сетями.

Я также заставил клиента на Mac связаться как с AP U6 Pro (с которым связан сервер), так и с AP U7 Pro (и подтвердил BSSID с Mac). Независимо от AP, это не работает, если Mac находится в сети blah/Humans, но работает, если Mac находится в сети blah-iot/Things.

wbenroy Guest	#2 21.02.2025 23:32:00 Ранний доступ к прошивке для U7Pro, кажется, исправил проблему. https://dl.ui.com/unifi/firmware/U7PRO/8.0.9.16583/BZ.ipq53xx_8.0.9+16583.250208.0914.bin

wbenroy Guest	#3 21.02.2025 02:51:00 Это причина. Проблема исчезает, если этот AP выключен или подключен напрямую к UCG, а не через другую точку доступа в режиме Mesh. Я уже описал эту проблему в поддержку, и первым их предложением было внести это изменение. Так что, я думаю, что другие пользователи сталкивались с похожими проблемами. До этого я упростил ситуацию, чтобы исключить некоторые переменные. Я использовал два ноутбука, с HTTP-сервером на одном (python -m http.server 80) и клиентом на другом (curl -v <сервер>). Как и выше, если клиент находился на blah/Humans, а сервер на blah-iot/Things, TCP-сессия устанавливалась, но сервер не получал никаких данных, отправленных клиентом. Я мог поменять ноутбуками и воспроизвести проблему, чтобы убедиться, что дело не в одном из них. Ноутбуки также сделали возможным/легче контролировать, какой BSSID я использую, и делать tcpdump на обоих ноутбуках. Я также мог изменить направление. Другими словами, я мог установить соединение с клиента на blah-iot/Things к серверу на blah/Humans. Это работало, что странно, но к этому моменту это уже не удивляло. Ничего из этого на самом деле не помогло, кроме как подтвердить, что я не свихнулся. Проблема действительно возникала, была очень воспроизводима и локализована в сети, а не в конечных устройствах. Как уже упоминалось, проблему обнаружила поддержка и сразу же. Я до сих пор не уверен, можно ли заставить это работать с U6 Pro в режиме Mesh. Тикет в поддержку всё ещё открыт (так что сага продолжается, надеюсь (это не "Новая надежда", но... (кто-нибудь?))). В любом случае, я знаю, что 25 из вас смотрели на это и не спали по ночам, так что надеюсь, это принесёт вам некоторое облегчение.

Читают тему (гостей: 1)