Losing WIFI Signal after a while

Well was itchy to see if this solves my problem instead of doing to tomorrow or so. And to be honest without reliable connectivity the Vero is usless anyway at the moment.

Did the following:

sudo apt-get install --reinstall wpasupplicant=2:2.4-1+deb9u3

Reboot, Vero joined 5GHz Wifi. Logged in, journalctl -f and 30 mins later Wifi connection was gone.

Issue wasn’t even logged, so something probably crashed, power cycled the box. Didn’t talk to any other AP in the mesh, so that can be ruled out as well.

Rolling back one more version, which is identical to what has been on the system before I updated:

wget https://snapshot.debian.org/archive/debian/20180824T204416Z/pool/main/w/wpa/wpasupplicant_2.4-1%2Bdeb9u2_armhf.deb
sudo dpkg -i wpasupplicant_2.4-1+deb9u2_armhf.deb

That brings up a question? Is there a more proper way to do it, if a version is not avaialble via apt-get? I mean simple overwriting is ok here, but still.

Rinse, wash, repeat… Didn’t even join 5GHz initially sigh, rebooted once more. On 5GHz now. Time to wait, oh was lucky happened very quickly this time:

May 28 23:18:09 Vero kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_DISASSOC_IND

This is the line in the logs where it begins, wpasupplicant errors are logged usually later. This time erorr 34, which is again total bullshit (excessive number of frames). Basically wpasupplicant just logs various disassociation errors that are typical poor signals, but the signal is strong. So this is just a symptom. The root cause must be something else.

And went from 5GHz to the 2.4GHz this time (still wrong and never happened before), instead of losing network connection completly. So just a variation.

Anyway, means we can rule wpasupplicant out here.

So back to the current version:

sudo apt-get dist-upgrade

Any other suggestion? Driver changed maybe? Something else related that could be involved? As said, absolutely nothing beside the Vero Update changed and the problems begin within an hour of the reboot after updating.

Willing to try out more before re-install the box completly with the December image, which is the last known good for me at this moment.

Do you have background scanning disabled?

Nothing running in the background. The box itself is just idle as you can see from the logs. Nothing at all happening on the Wifi (well beside me being logged in with SSH). Same setup as for years on Kodi. No changes made recently to anything beside the update. Last network change was about a year ago when the ISP offered a better new router with a speed upgrade - no issues like this ever before. Neither in my nor my mother’s setup.

Well, guess I’ll do a fallback to December build and see what is happening. If the issue is then not reproducible it’s something that changed on the OSMC or Debian side. Guess is the best way to find out. Cannot rule out of course that something else broken and the timing is just coincidental. As said, no configuration changes at all.

Background scanning is a software setting for the WLAN driver

Ah, I thought you meant the Kodi Library. Well the Wifi settings were never touched manually. Just entered password over the OSMC Add On once when setting up the unit, and never looked back.

Anything I should check in regards to the configuration that might have been updated? When it comes to Linux and WLAN i am a total noob. So please point my in the right direction what to check.

It wouldn’t have changed but this is how you disable it.
Add BackgroundScanning = false to the general section of /etc/connman.conf

Thanks, will give that a try. But first I rollback to the December built to make sure nothing else is involved. If that runs stable, I’ll upgrade again, verify that the problem still exists and then add the line to connman.conf and see if it makes a difference.

Will report back once I am done with some more testing…

Rollback to December: Works flawless as before :heart_eyes:
Update to May: …and the problem is back :rage:
Adjusting conman.conf: That seems very promising :+1:

I think you nailed it.

Looks like whatever changed wherever in the update has now serious issues with the background scanning in a WLAN mesh environment (more and more common these days) like mine and it goes haywire resulting in dropping Wifi connection completely or up even crashing/freezing the driver (had sometimes log logs at all, and I had to actually reboot).

Hope that’s it… fingers crossed. Let’s see how it behaves over a day or two before I mark the connman.conf adjustments as the solution.

Update:

Looked good initially, but well didn’t work out. Just lasted a bit longer this time. Yeah, it has some randomness to it…

Then:

May 29 17:07:57 vero wpa_supplicant[484]: wlan0: CTRL-EVENT-DISCONNECTED bssid=44:4e:6d:7b:9d:38 reason=6
May 29 17:07:57 vero kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_DEAUTH_IND
May 29 17:07:57 vero kernel: link down if wlan0 may call cfg80211_disconnected. event : 6, reason=6 from 44:4e:6d:7b:9d:38
May 29 17:07:57 vero kernel: wl_iw_event: Link Down with BSSID=44:4E:6D:7B:9D:38
May 29 17:07:57 vero kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK
May 29 17:07:57 vero kernel: cfg80211: Calling CRDA for country: DE

wpasupplicant error message is another random one… The Kernel error actually happens before the wpasupplicant message, just not always logged in that order.

Wifi was dead, couldn’t rejoin the network or any other network. Disabling/enabling the adapter helped. So it’s not a problem of my network. That can be ruled out 100% by now or else Demcember built would show the same problem.

I spare you the logs, same deal as before. Error from CFG80211, Wifi is gone, sometimes errors are not even logged ,meaning something crashed or else it could log, and most of the time I have to reboot the unit fully, though few times disabling/enabling the adpater is enough.

Whatever changed somewhere in OSMC or Debian is broken for my setup…

Will revert to December again - probably for good - unless someone else has an idea. Never had any Wifi trouble until this update.

We can up the debug level on wpa_supplicant and perhaps something will stand out, though it could, for example, be something occurring in the kernel that this method won’t catch.

You’ll need to edit file /lib/systemd/system/wpa_supplicant.service (using sudo) and change the line

ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant

to

ExecStart=/sbin/wpa_supplicant -d -u -s -O /run/wpa_supplicant

ie you’re adding a -d debug option. Then perform a cold boot and wait until the WiFi connection drops.

Finally, via eth0 run sudo journalctl -t wpa_supplicant | paste-log and let us know the URL.

(Don’t forget to change it back afterwards!)

1 Like

It’s for sure occuring in the kernel. The connection “dies”, hence you get a disassociation error , and depending what was going on wpasupplicant throws out an error based on that. Makes no real sense for me to waste time here on debug logging wpasupplicant it is not the culprit (I already did a fall back to the previous version I had to rule it out) and already the error messages are random. Nothing more to see here.

I went back now on the December built, absolutely rock solid. No problems so far at all, as it always has been. No disconnection, no random switches to 2.4GHz, no errors at all.

If I look at the packages that apt tries to update, only the kernel stands out. And well, can’t do try and error here, and not gonna dig into building a custom kernel for the Vero4K by digging through what might have changed upstream.

Might re-visit when there is some larger update of the base system in the future. For now I am good on 17.6 with the December built again… Though I would have liked Kodi 18 as well as some other fixes…

Edit: upgraded all debian packages - still stable Wifi connection

osmc@vero:~$ sudo apt list --upgradable
Listing… Done
armv7-eventlircd-osmc/unknown 1.3.9 armhf [upgradable from: 1.3.3]
armv7-libbluray-osmc/unknown 1.2.0-2 armhf [upgradable from: 1.1.0-1]
armv7-libsqlite-osmc/unknown 3.28.0-1 armhf [upgradable from: 3.21.0-2]
base-files-osmc/unknown,unknown 2.7.8 all [upgradable from: 2.7.4]
mediacenter-addon-osmc/unknown,unknown 3.0.672 all [upgradable from: 3.0.666]
mediacenter-skin-osmc/unknown,unknown 18.0.0-8 all [upgradable from: 17.0.5-12]
vero3-libcec-osmc/unknown 4.0.4-1 armhf [upgradable from: 4.0.2-6]
vero3-mediacenter-osmc/unknown 18.2.0-13 armhf [upgradable from: 17.6.0-61]
vero364-kernel-osmc/unknown 3.9.136 arm64 [upgradable from: 3.9.127]

Naturally I am not gonna touch these and will put them on hold. Given what is is left it’s coming from the kernel package. And I have zero clue about that and what is specific here. Kernels are out of my comfort zone to deal with to create a custom one.

Fair enough. Since this isn’t a widely reported issue, I guess it could be related to your mesh WiFi system. Out of interest, what’s the make / model?

Yeah, probably something Mesh related that the updated Kernel doesn’t really like/doesn’t handle properly. For sure some defect upstream somewhere between December and May. Happens, too bad we cannot isolate it easily.

Might go away with some future updates - at least I hope it will.

The mesh in question consists of the following elements at my mother’s house:

  • 1 x AVM Fritz Box 7590 (1st floor)
  • 2 x AVM Fritz WLAN Repeater 1750 (basement and 2nd floor)

Nothing really fancy here, all on latest firmware, no changes in the past 6 months (I think before that there was a firmware upgrade on the router in January).

Last WiFi changes in kernel was July 2017.

What do we have so far: December has no issues for me, May is unstable for me. I upgraded all Debian packages to latest version, still stable. So leaves only the OSMC packages What stands out? The kernel, unless some other OSMC package for Vero have some influence here. I don’t know, I did not create them. If you categorically exclude the kernel, then the problem comes from another package.

Choose your poison:

sudo apt list --upgradable
Listing… Done
armv7-eventlircd-osmc/unknown 1.3.9 armhf [upgradable from: 1.3.3]
armv7-libbluray-osmc/unknown 1.2.0-2 armhf [upgradable from: 1.1.0-1]
armv7-libsqlite-osmc/unknown 3.28.0-1 armhf [upgradable from: 3.21.0-2]
base-files-osmc/unknown,unknown 2.7.8 all [upgradable from: 2.7.4]
mediacenter-addon-osmc/unknown,unknown 3.0.672 all [upgradable from: 3.0.666]
mediacenter-skin-osmc/unknown,unknown 18.0.0-8 all [upgradable from: 17.0.5-12]
vero3-libcec-osmc/unknown 4.0.4-1 armhf [upgradable from: 4.0.2-6]
vero3-mediacenter-osmc/unknown 18.2.0-13 armhf [upgradable from: 17.6.0-61]
vero364-kernel-osmc/unknown 3.9.136 arm64 [upgradable from: 3.9.127]

Doesn’t need to be Wifi code per se, but can be anything causing the wifi part to go haywire for me.

Something is causing this for me and it is in one of the above packages as these are the only remaining difference between working and not working.

As said, I’ll try with future versions again…

You could try updating everything but the kernel.

Well, I stopped there because I was not sure if the kernel has anything the other packages rely on to function properly.

But if you say, it is safe to upgrade anything except the kernel I’ll do so. Don’t want to reset the unit again and reconfigure. Or the other way around, just upgrade the kernel.

Should be fine.

Will do that tomorrow and report back…

I’m sure we’ll get to the bottom of it.