Lost Wifi connection on smart TV

phuthuytrangbg · November 28, 2022, 12:07pm

Hi all,

I am using router Totolink X5000R with openwrt 21.02
I have a problem when my TV (Samsung SmartTV) connect to wifi network from router. I turn off the TV for a few hours after using wifi network normarlly and then turn on again, then I get a message that can't connect to the internet on the TV (The TV still connect to the router). Other device still connect to internet as normal.
I cheked on my router via Luci web or logread, then still see the IP that be assigned to TV. But I can not ping to that IP from router

I did some tests:

Change to static IP for my TV, but it's not OK
Reconect to the wifi network, it's not OK
Only change the default gateway to other address, then change back to the old gateway, then it's OK and my TV have internet connection again.

Has anyone have this same problem with me? Please help me diagnose this problem?

Thanks in advance,

I add some configurations on the router:
cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option packet_steering '1'
	option ula_prefix 'fddb:e315:081f::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	option ipv6 '0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option igmp_snooping '1'
	option ipaddr '192.168.0.1'
	option defaultroute '0'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option peerdns '0'
	list dns '8.8.8.8'
	option ipv6 '0'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'

config device
	option name 'wlan0'
	option ipv6 '0'

config device
	option name 'wlan1'
	option ipv6 '0'

cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option band '2g'
	option htmode 'HE40'
	option channel 'auto'
	option country 'VN'
	option cell_density '1'
	option noscan '1'
	option log_level '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2'
	option key 'mywifi@2022'
	option ssid 'mywifi'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
	option channel 'auto'
	option band '5g'
	option htmode 'HE80'
	option country 'VN'
	option cell_density '1'
	option log_level '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2'
	option key 'mywifi@2022'
	option ssid 'mywifi'

Pico · November 28, 2022, 3:53pm

According to wiki, your router has a 7615DA/DN. I dont know, if your issue is related to recently discussed 7615N issues: [Solved] OpenWrt on MT7621/MT7615N devices with 5GHz problems

you can test, whether it also occurs with a proprietary vendor OS router.
some recently said, that problem is less likely to occure, if OpenWRT is used in access point only mode.
you can test, whether a freshly rebooted OpenWRT right before you turn on the TV has an effect.
You can try to test with fewer optional Wifi security options.
if you feel fine with testing it: recent snapshot was a while ago said to contain some fixes, see also the referenced link mentioned above (but I am not tracking it, so I do not know, whether and which probably relevant fixes are currently still part of the daily snapshot)
avoid hardware offloading, if experiencing any issues

I think I have not read about such type of temporary workaround on the mentioned 7615N thread before (but again, I am not sure, if your issue is related)

phuthuytrangbg · November 29, 2022, 3:22am

Thanks Pico for responding me.

I will do some tests as you said.

avoid hardware offloading, if experiencing any issues

I don't understand this point. I enabled both of software flow offloading and hardware flow offloading on my router. I don't know how it is affecting on this problem.
Can you explain to me about this?

Futher, I am using Totolink X5000R with wifi chipset MT7915, may be not related to the thread about MT7615N. I will read all this thread to get more information.

Thank you again,

Pico · November 29, 2022, 7:17am

some people claimed varying issues with offloading. Why not temporarily disable offloading for a test?

e.g.:

phuthuytrangbg · November 29, 2022, 9:45am

Thank @RachelGomez161999 for responding me.

I tried placing the router close to the TV. I think it's close enough and the problem still happens
If I unplug power cable and plug in again then TV will have internet connection again. I have not tried to reboot the router
3 & 4. I see the wifi signal strength on TV, it's OK and the distance is enough close and have no obstructions
My router is next to modem from ISP. Could this be the problem?
I will find out and try it
It's OK when using ethernet cable.

Thank you,

phuthuytrangbg · November 29, 2022, 10:06am

Hi @Pico,

I will check with disable offloading.
In the thread that you refer, I see that there is a thread that may be related: Option disassoc_low_ack '1'

You have tested this option before. Can you share the effect it had on the problem you had (I find quite similar to what I'm having)?

Thank you,

frank92735 · November 29, 2022, 10:14am

Just a thought....I wonder if setting the DHCP lease time to a lower value like say 1 hour (default 12 hours) would help refresh the TV's wifi connection?

40Mhz channels aren't recommended on 2.4Ghz. Also the wireless card on the TV might not like it. Try sticking with 20Mhz.

Don't leave it on auto channel. Select one.

Or you could add another OpenWRT router in client mode to feed the TV a LAN connection.

Check the main page in LuCI to see if the TV is getting a good signal: -35db (better) to -75db
(worse)
Make a dedicated wireless network for the TV in LuCI.

I don't see if you are using 5Ghz or 2.4Ghz wifi for the TV. I assumed 2.4Ghz. If the TV supports 5Ghz try that (assuming the 5Ghz issues don't affect the 7915 chipset).

What model# is the TV?

phuthuytrangbg · November 29, 2022, 11:58am

Thanks @frank92735

Just a thought....I wonder if setting the DHCP lease time to a lower value like say 1 hour (default 12 hours) would help refresh the TV's wifi connection?
-> I check logread from router and see the log disconected and connected again periodically.

Disconnect:

Tue Nov 29 13:50:39 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED d0:d0:03:24:e4:18
Tue Nov 29 13:50:39 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: disassociated due to inactivity
Tue Nov 29 13:50:39 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DISASSOCIATE.indication(d0:d0:03:24:e4:18, 4)
Tue Nov 29 13:50:39 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DELETEKEYS.request(d0:d0:03:24:e4:18)
Tue Nov 29 13:50:40 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Nov 29 13:50:40 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DEAUTHENTICATE.indication(d0:d0:03:24:e4:18, 2)
Tue Nov 29 13:50:40 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DELETEKEYS.request(d0:d0:03:24:e4:18)

Connect again:

Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: authentication OK (open system)
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-AUTHENTICATE.indication(d0:d0:03:24:e4:18, OPEN_SYSTEM)
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DELETEKEYS.request(d0:d0:03:24:e4:18)
Tue Nov 29 14:10:04 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: authenticated
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: association OK (aid 2)
Tue Nov 29 14:10:04 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: associated (aid 2)
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-ASSOCIATE.indication(d0:d0:03:24:e4:18)
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 MLME: MLME-DELETEKEYS.request(d0:d0:03:24:e4:18)
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.11: binding station to interface 'wlan0'
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: event 1 notification
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: start authentication
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.1X: unauthorizing port
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: sending 1/4 msg of 4-Way Handshake
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: received EAPOL-Key frame (2/4 Pairwise)
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: sending 3/4 msg of 4-Way Handshake
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: received EAPOL-Key frame (4/4 Pairwise)
Tue Nov 29 14:10:04 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED d0:d0:03:24:e4:18
Tue Nov 29 14:10:04 2022 daemon.debug hostapd: wlan0: STA d0:d0:03:24:e4:18 IEEE 802.1X: authorizing port
Tue Nov 29 14:10:04 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 RADIUS: starting accounting session 6F8852F53A1CD74D
Tue Nov 29 14:10:04 2022 daemon.info hostapd: wlan0: STA d0:d0:03:24:e4:18 WPA: pairwise key handshake completed (RSN)
Tue Nov 29 14:10:04 2022 daemon.info dnsmasq-dhcp[5784]: DHCPDISCOVER(br-lan) d0:d0:03:24:e4:18
Tue Nov 29 14:10:04 2022 daemon.info dnsmasq-dhcp[5784]: DHCPOFFER(br-lan) 192.168.0.175 d0:d0:03:24:e4:18
Tue Nov 29 14:10:04 2022 daemon.info dnsmasq-dhcp[5784]: DHCPREQUEST(br-lan) 192.168.0.175 d0:d0:03:24:e4:18
Tue Nov 29 14:10:04 2022 daemon.info dnsmasq-dhcp[5784]: DHCPACK(br-lan) 192.168.0.175 d0:d0:03:24:e4:18 TIZEN

Both logs are when TV is turn off by remote (may be sleep or idle mode)
I think there is always a process to refresh the TV's wifi connection.

Check the main page in LuCI to see if the TV is getting a good signal: -35db (better) to -75db
(worse) -> RSSI ~ -60db

Make a dedicated wireless network for the TV in LuCI -> Yes, I am using focus only on SSID for my TV on 2.4GHz.
My TV's model is Samsung Smart TV UA55RU7200KXXV

Thanks

frank92735 · November 29, 2022, 12:37pm

After changing the router to a 20Mhz fixed channel it might not be a bad idea to factory reset the TV (if it keeps disconnecting).

From the samsung website:

Reset the TV.

Navigate to Settings, then select General, and then select Reset. Enter your PIN (the default is 0000). After the reset, try connecting again.

If you do this check your TV manual to verify this is the correct way to get back in!

HTH

phuthuytrangbg · November 29, 2022, 12:44pm

Ok, I will try this.

Thank you

phuthuytrangbg · November 30, 2022, 9:35am

Hi @Pico

How is your opinion about this option "disassoc_low_ack" ?

Thank you

Pico · November 30, 2022, 7:38pm

That was a while ago for me. Have a single 2.4 IT device which after a week on OpenWRT the devices wifi got lost. The device had to be offboarded and reonboarded to fix the Wifi issue, but after a week issue came back.

The issues stopped appearing completely, when testwise using a proprietary apple airport express AP for about 2 months.

I then felt like joining the IoT device back to OpenWRT, and

checkmarked Disable Inactivity Polling
increased „Station inactivity limit“
unchecked Disassociate On Low Acknowledgement
With all 3, issue period now increased to 3-4 week periods

I then had moved on to yet a strategy: a power outlet timer that cut power to OpenWRT every 24h, to reboot OpenWRT (not the IoT device!), that reliably worked avoided the IoTs wifi issue permanently.

Very difficult to track issues on such rare occurences. I have some doubts about the IoT sleep mode theory, as to why would a device suddenly go to sleep after 3 weeks? It rather feels like some kind of counter or so on the Wifi AP side somehow overflowing into a value range that the IoT cannot process. But I am a layman argumenting here, not a coder.

Time fast forward: a few weeks ago, my environment has changed: i have removed the timer and now have a dedicated x86 router. The dir-1960 is now operating in access point mode. Furthermore I have a mobile app running that regularly polls data from the IoT, so it also likely goes less into the suspected sleep mode. The issue has not yet reappeared since then. Could be the dir-1960 no longer acting as router or the more frequent polling of the IoT.

As I currently do not have the problem appearing, its hard to test it.

You should definitely test variations of the 3 parameters and keep note, what happens. None of the 3 parametrs break anything and can be set back to default.
You could also try latest snapshot, if recovery on your device feels easy.

phuthuytrangbg · December 1, 2022, 4:26am

Thanks for your suggestion,

My problem is seem be same to you. I checked log on my router, then see that my TV periodically disconnect from the router (is running openwrt) when it is in sleep mode. Specifically, after turning off the TV about 5 minutes, TV is disconnected from the wifi network. And after 20 minutes, it will ask to connect again. This keeps repeating when my TV is in sleep mode. I suspect that when I turn on TV (while it is disconnected state), something happen. I also check other smart TVs, then see there are no devices behave like that when they are in sleep mode. Seem be openwrt is having problem with the devices have the such sleep mode. I will search more information about such sleep mode on devices.

I will also try your way, 3 options related to "inactivity" and restart the router after a period of time.

Thank you again.

frank92735 · December 7, 2022, 3:03pm

Glad you got it all working!

....or you can install watchcat.

DTIM problem? Try shortening or lengthening the DTIM and see if that works? (In other words I don't know the answer)

You could also try rolling back 19.07.10 and see if that fixes it.

Investigate if there are other wifi drivers you can use besides ath9k.

Maybe it's the TV's wifi is not handling sleep mode correctly. You could try manually updating the TV firmware. You could also try deleting third party apps that may be conflicting or crashing the TV wifi card.

phuthuytrangbg:

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
	option channel 'auto'
	option band '5g'
	option htmode 'HE80'

If radio 0 and 1 are in HE mode = 802.11ax and perhaps the TV doesn't like it? Try Running the 5Ghz in 802.11ac and the 2.4 in 20Mhz channel width.

Or you could get a dedicated router to handle 2.4 wifi AP for the TV if you don't want to disable 802.11ax on the totolinkX5000R.

danpawlik · May 30, 2023, 8:18pm

I also loose my mind with the Samsung Smart TV.
On old Samsung tv, there was a bug, that only WPA2 TKIP encryption was working well, other was failing.
On new tv, I tried same - create a dedicated network (MyNetwork_4A) for the tv, that does not have any configuration with 802.11r/k/v/w and use just TKIP and nothing. The option disassoc_low_ack set to 0 also does not work.
One day, I disabled other wireless networks and I just tried to enable WPS and it seems to work. Then I come back to many SSIDs and it stops working. After few restarts, it starts, but after few days stops.
I just share my config, but it might not be helpful.
Soon I will add some log messages.

Tl;dr I move to 2.4GHz with WPA2, where tv connects without any issue.

	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option channel '8'
	option band '2g'
	option htmode 'HT40'
	option txpower '18'
	option country 'PL'
	option cell_density '0'
	option noscan '1'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'MyNetwork_2G'
	option encryption 'psk2'
	option key 'mypassword1234'
	option ieee80211r '1'
	option nasid '4a-2'
	option mobility_domain 'abab'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option channel '104'
	option band '5g'
	option htmode 'VHT80'
	option country 'PL'
	option txpower '18'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'MyNetwork'
	option encryption 'psk2'
	option key 'mypassword1234'
	option ieee80211r '1'
	option nasid '4a-5'
	option mobility_domain 'abab'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'
	option ieee80211k '1'
	option ieee80211v '1'
	option bss_transition '1'
	option wnm_sleep_mode '1'
	option ieee80211w '1''

config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option ssid 'MyNetwork_4A'
	option encryption 'sae-mixed'
	option key 'mypassword1234'
	option network 'lan'

Edit: after checking also the Unifi settings (https://evanmccann.net/blog/2021/11/unifi-advanced-wi-fi-settings), I change the dtim_period to 3 and it starts working once again.
Just the tv SSID looks like:

config wifi-iface 'wifinet3'
        option device 'radio1'
        option mode 'ap'
        option ssid 'MyNetwork_4A'
        option encryption 'sae-mixed'
        option key 'mypassword1234'
        option network 'lan'
        option dtim_period '3'

danpawlik · July 14, 2023, 7:24am

Hi,
Issue is not in the wireless configuration, but... in irqbalance. I did not dig yet, what would be proper configuration, but so far, I know that Xiaomi 4A Gigabit version with irqbalance and Samsung TV (QE55Q67B) is no a good buddies.
So if someone have issue with smart TV and router/dumb ap, I recommend to try to disable irqbalance (if its installed).

EDIT:
Problem is definitely in MT7621. No meter which encryption lib is used: wpad-{openssl,wolfss,mbedtls} nothing is working. Workaround is to set force encryption algorithm to TKIP (not CCMP or TKIP+CCMP).

Edit:
After a while, it seems that the problem is...in option country "PL". I changed the country to US + added option noscan '1' and it works well. Finally I don't have any issue with MT7621 and Samsung TV.