Максимальный размер MTU на виртуальных WiFi-интерфейсах

Итак, иногда проекты требуют чуть больше времени и их приходится откладывать, но у меня тут проблема: я пытаюсь отправить GET-запрос с сервера управления на устройства умного дома (точнее на термостаты), и получаю в ответ «Ошибка 400 – плохой запрос».  

Shelly – TRV_Poll_Status – ошибка опроса статуса:  
Crestron.SimplSharp.Net.Http.HttpException: HTTP/1.0 400 Bad Request  
Server: lwIP/2.1.2 (http://savannah.nongnu.org/projects/lwip)  
Content-Type: text/html  
в Crestron.SimplSharp.Net.Http.HttpClient.Dispatch(HttpClientRequest aRequest)  
в Shelly_Integration.Shelly.TRV_Poll_Status(String Device_IP, String Username, String Password)  
в UserModule_SHELLY_TRV_V3.UserModuleClass_SHELLY_TRV_V3.POLL_OnPush_1(Object EventInfo)  
в Amib.Threading.Internal.WorkItem.n()  
в Amib.Threading.Internal.WorkItem.Execute()  
в Amib.Threading.SmartThreadPool.f(WorkItem A_0)  
в Amib.Threading.SmartThreadPool.r()  

Общался с производителем, возможно, причина в какой-то «фрагментации», из-за которой служба lwIP не справляется, намекая на некую «сетевую» проблему. Вот почему я здесь. Я могу нормально подключиться ко всем термостатам через браузер, но не через систему управления. Если TRV сам отправляет URL, система управления его принимает и обрабатывает без проблем.  

Теперь я ищу способ это улучшить.  

Вот моя топология сети:  
 

CRS3112-4C-8XGM-RM работает как основной коммутатор, центральный роутер и Capsman-менеджер с такой конфигурацией: swicht-keller-2024-01-16.rsc (5.52 KB)  

CRS328-24P-4-S+ — по сути, это коммутаторы доступа, вот пример конфигурации одного из них: capsmanrouter-2024-01-16.rsc (15.6 KB)  

Кроме того, помимо конфигурации, которую они получают от Capsman, я немного подправил настройки hap AC: ap-keller-2024-01-16.rsc (7.56 KB)  

Система управления подключена к основному коммутатору, а TRV-термостаты разбросаны по всему зданию и подключены к WiFi-сети «Shelly».  

То есть путь всегда такой: Core → Access Switch → Access Point.  
(Точки доступа на CRS112 стоят снаружи, так что TRV туда подключаться не должны).  

Есть идеи, какие гайки подкрутить?

Итак, я сделал небольшой анализ трафика (wire-sharking), вот что получилось: Измерения проводились на зеркальном порту контроллера и моего ноутбука, подключённых к одному и тому же коммутатору. Мой ноутбук с адресом 192.168.110.33 отправляет Status-запрос размером 451 байт, который это устройство TRV принимает с удовольствием. Pro3 же отправляет такой же GET-запрос, но всего на 60 байт, и TRV почему-то его не любит. Думаю, это исключает какие-либо сетевые проблемы, или я ошибаюсь?

А, теперь понятнее, почему 400 связано с этим... хотя 8 фрагментов кажется странным. Я не могу точно вспомнить детали правил MTU для V6 capsman, так что не уверен на 100%... Но ты пробовал просто поменять MTU на wlan1 и wlan2 на 1500 (вместо 1600) и оставить L2MTU на 1600 (или больше)? Ещё не понимаю, почему ты не используешь MTU 1500 на Ethernet-портах... Но с тем, как работает мостовой интерфейс, он будет использовать минимальный MTU среди портов. Так что если поменять MTU на wlan1, “фактический MTU” моста станет 1500, и Ethernet с MTU 2000 особо не повлияет. Наверное, кто-то более знакомый может знать, ограничиваются ли туннели capsman MTU или L2MTU, учитывая, что заголовки DTLS что-то добавляют. Честно говоря, я только локальный форвардинг с CAPSMAN использовал.