Lost Wifi connection on smart TV

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'

According to wiki, your router has a 7615DA/DN. I dont know, if your issue is related to recently discussed 7615N issues: 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)

2 Likes

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,

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

e.g.:

2 Likes

Thank @RachelGomez161999 for responding me.

  1. I tried placing the router close to the TV. I think it's close enough and the problem still happens
  2. 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
  3. My router is next to modem from ISP. Could this be the problem?
  4. I will find out and try it
  5. It's OK when using ethernet cable.

Thank you,

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,

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?

1 Like

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

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

1 Like

Ok, I will try this.

Thank you

Hi @Pico

How is your opinion about this option "disassoc_low_ack" ?

Thank you

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.

2 Likes

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.

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.

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.