On Sun, 11 Dec 2022 07:43:11 +0100, Marek <f...@f...com> wrote:
> Okazuje się, że winą za to zachowanie ponosi separacja sieci wifi.
> Gniazdka używają dedykowanej, odeseparowanej sieci wifi (inne ssid)
> od tej co używam na codzień w telefonie. Obie sieci używają tego
> samego netbloku, separacja jest na poziomie APów
> wysyłać polecenia i reagują. A aplikacja nie umie się z nimi
> skontaktować...

No dobra już zdiagnozowałem w czym problem z tą aplikacją i czemu
"wisi". Może kiedyś komuś się przyda w podobnej konfiguracji.
Jak wcześniej wspomniałem używam odseparowanego SSID, wykorzystując
funkcje "guest network" w kontrolerze APsów jakich używam (Omada
TP-Link). Oczywiście separację powinno się zrobić porządnie na
osobnym VLANie ale to wymaga rutera z multinat + drugi DHCP dla
VLANu... a że takowych nie mam to jak dotąd wykorzystywałem tą
separację na poziomie AP. Ona blokuje ruch na poziomie IP pomiędzy
klientami połączonymi z SSID z ustawiona flagą "guest network" a
innymi SSID. Ponieważ wszystkie urządzenia są na jednym netbloku to
ta separacja musi przepuszczać broadcasty np. żądania dhcp. No i
tutaj jest problem. Gniazdka periodycznie puszczają broadcasty do
255.255.255.255:6667 meldując swoje istnienie. Aplikacja Tuya Smart
mimo, że uruchomiona na innym SSID widzi te broadcasty, co powoduje,
że przy próbie wyboru gniazdka z menu próbuje połączenia TCP z
źródłem broadcastu no i tak sobie wisi czekając na połączenie bo AP
dropują negocjację tcp do sieci "guest".
Rozwiązaniem było dodanie reguły ACL na kontrolerze AP by dropować
ruch z "guest network" na port docelowy 6667. Po tym nagle aplikacja
się odblokowała i już łączy się poprawnie przez chmurę.

--
Marek