Ok, my hardware is a rpi3 running latest osmc. I have a laptop, three tablets and an android phone. All work perfectly happily together except the Samsung Galaxy Tab A. If I connect from the samsung to the rpi3 with ssh, or a file manager, or yatse remote then the rpi3 drops it’s wifi connection. No problem at all connecting with the other tablets/phone/laptop. It’s not an address clash, all except the pi are dhcp, and the pi has a fixed ip address outside the dhcp range.
I have a debug log, but can’t auto-upload it as the network is dead at that point. I saved it to SD card, but there doesn’t appear to be anything in the log relating to network at the time it dies. I could upload it separately if it would be useful.
There is no problem with the same setup on rpi2, only rpi3. I tried briefly running openelec on the pi3 and that seems to work. I’m guessing it’s an osmc wifi driver problem, or a pi3 firmware issue that openelec works around but osmc doesn’t? I don’t know how to pin it down further. I tried disabling the internal wifi and using an external tp-link dongle, and that works correctly with the samsung.
I see there are a couple of other threads about random wifi dropout, and another user asking for a script to reset the network but doesn’t say why. Maybe these are all related? At least in my case it’s not random, it’s readily reproducible.
Where do I go from here. Scrap the samsung tablet I guess 
If you have a log then yes please do paste it, you can do so with the paste-log command, it may show something useful.
Are you using the RPi3’s built-in WiFi? If so doesn’t seem to be terribly reliable. Could you try temporarily connecting it with a cable or a WiFi dongle and see if the issue still occurs?
Yes it’s the built in wifi. I tried an external tp-link dongle and that works correctly after disabling the inbuit wifi. I haven’t tried using an ethernet connection from rpi3 to the router. Log uploaded to http://paste.osmc.io/lonelicizo
Maybe IP address conflict?
No, as I said in the first post everything is dhcp except the pi which has a fixed ip outside the dhcp range.
The pi is on 192.168.0.2 router is 192.168.0.1
Tablets,phone,laptop are all in the range 192.168.0.100+
Nothing jumps out immediately in the log, except a number of mono errors.
There are a very large number of extra packages installed though, which makes me wonder if something else is interacting badly.
Do you have a spare SD card that you could set up with a vanilla OSMC install and test that with the Samsung tablet? At least that will confirm it is nothing else in your relatively complex setup and rule out or in a lot of troubleshooting.
I will try a vanilla install and report back. Nothing too unusual in my setup, nothing network driver related has been changed. I run a few other servers on the mediacenter, transmission, nzbget, sonarr, headphones, lazylibrarian and sonarr needs mono. The mono entries in the debug log are me updating mono to a later version. All the servers are running fine, the only thing misbehaving is the network dropping if my samsung tablet connects.
Another option would be to install packet capturing software and monitor what happens when you connect with the Samsung tablet. This would require a 3rd machine with a network card which supports promiscuous mode.
Even sudo tcpdump -i wlan0 on the Pi 3 might give us something useful. Could narrow down to port 22 but that might miss something.
Tried a vanilla osmc install, latest release. Still the same problem. All working normally, wifi drops when Samsung tablet is connected. Seems to be rpi3 firmware related, seems Samsung and broadcom wifi drivers don’t talk nicely. I found a thread on a raspberrypi group that seems to be describing the same problem https://github.com/raspberrypi/linux/issues/1342
From the vanilla install I did another debug log, which again shows nothing. Then I installed tcpdump via apt and ran sudo tcpdump -U -i wlan0 the output file is at tcpdump - Pastebin.com
Hopefully it will show the problem.
I couldn’t figure out how to get osmc to upload it, so it’s not in the osmc account.
In the dump file, 192.168.0.103 is the rpi3, 192.168.0.105 is the Samsung tablet. Yatse remote was the app I used to crash the wifi. Ask Yatse to scan for kodi devices on the network, then try to connect to kodi on the rpi3
Hi. I waded through the tcpdump file. TBH, it would have been a lot easier as a pcap file! 
There’s nothing I could see that looked obviously iffy, but there is this odd frame that appears near the end of the file at timestamp 13:13:07.778315 with an ethertype of 0x886c that is sending something from MAC address b8:27:eb:20:60:ee to, er, MAC address b8:27:eb:20:60:ee, ie to itself. Hmmm.
This post suggests that ethertype 0x886c is used by the firmware, presumably the wifi firmware, to notify the host driver of an “event”. It might be possible to decode the frame; I’ll see if I can find anything.
Edit: To summarise what I found:
-
At timestamp 13:13:07.778315 there is a frame with an ethertype of 0x886c and a length of 79 bytes.
-
Before this frame, we see traffic to and from IP address 192.168.0.105 but no traffic afterwards.
-
While the tcpdump file contains 70 frames with an ethertype of 0x886c, only one has a length of 79 bytes:
Count Length
4 144:
11 163:
16 174:
12 175:
13 304:
13 320:
1 79:
- It’s fairly circumstantial, but it looks like the firmware could have experienced an issue that caused the connection to be lost. OP mentions that OpenELEC firmware / driver does not exhibit this problem, so perhaps those better versed in these dark arts can explain the possibilities for trial-and-error substitution of OpenELEC firmware and/or driver in OSMC.
Wow, thanks for that. I’m guessing the ether type 0x886c is probably the disconnect event so the real problem is just before that?. Maybe the Samsung sends an invalid packet causing the disconnect, or overflows a buffer? For now I’m switching over to a tp-link dongle for wifi.
That seems to be likely, though in the sense of the disconnect being caused by an error condition occurring in the firmware, rather than being due to some controlled event.
Trying to figure out what caused the “event” is likely to be a fruitless task, since I’d guess the Broadcom firmware is supplied as a binary “blob” - and even if it isn’t, you’re going to have a hard time finding someone willing to debug it. (It’s way above my pay grade.)
Firmware and/or driver substitution is the only reasonable way forward, IMO, though we await the input of an OSMC guru who can explain what is and isn’t possible.
I’d missed this. Problems with internal wifi and an external dongle reduce the probability of it being an issue with the internal wifi firmware and/or driver. Is it 100% reproducible with the dongle?
Right now, it’s difficult to know where to focus attention, though I’d still recommend trying a bit of firmware / driver substitution from OpenELEC, if that gets the go-ahead from @sam_nazarko or one of the devs. If it doesn’t work, you should still be able to revert to the standard build.
My apologies, I will go back and edit that. I am currently running on the tp-link dongle and it’s run for 24hrs now without a problem. I’m guessing I hadn’t disabled the internal wifi correctly on the previous test. It’s certainly still crashing on a clean osmc install and no dongle. I will try openelec again later today just to confirm that is working as reported earlier.
Ok, further update. The problem is also present in raspbian early April release (latest version from download page) but disappears after a sudo apt get dist-upgrade. There have been some recent changes to wifi and a kernel upgrade in raspbian (last couple of weeks) so hopefully the fixes will appear in osmc in due course.
Thanks for the heads-up.
I don’t have a Pi 3 running Raspbian but do have a Pi 1. Out of curiosity, I looked at the directory /lib/firmware/brcm, which is where I’m guessing the wifi firmware lives. On the Pi 1 with Raspbian, an MD5 of the files gave this:
pi@raspberrypi:/lib/firmware/brcm $ md5sum *
b0736e3590b05d27284fbb8a3efd50e1 bcm43xx-0.fw
5e51778ee011badcb42f1e2cb4ab3956 bcm43xx_hdr-0.fw
2be9d4da43aba729bfa3417829e011df brcmfmac43143.bin
dc78f76883f5a0df9f13fad30d78442b brcmfmac43143-sdio.bin
3575f0473cd9082d5b03f0e2549a998f brcmfmac43241b0-sdio.bin
62dffd52291975a60b2c079f2b671c06 brcmfmac43241b4-sdio.bin
ff610cee869375a2d0c0be6b97b107fb brcmfmac4329-sdio.bin
4ec6341cbe351f13d787aaea99141bea brcmfmac4330-sdio.bin
0e5d2b9bfaaf3b6c43077405cfe92632 brcmfmac4334-sdio.bin
678ed027a1bac420318cd54daa1e1579 brcmfmac4335-sdio.bin
ce95e81aa95f9dc1a32fb8acf691dbd8 brcmfmac43362-sdio.bin
b24aad300e161782072b227abe9862f7 brcmfmac43430-sdio.bin
8c3cb6d8f0609b43f09d083b4006ec5a brcmfmac43430-sdio.txt
a3a73454d750f6b01170c7cbaa02c952 brcmfmac4354-sdio.bin`
And then on OSMC (Pi 3)
osmc@osmc:/lib/firmware/brcm$ md5sum *
b0736e3590b05d27284fbb8a3efd50e1 bcm43xx-0.fw
5e51778ee011badcb42f1e2cb4ab3956 bcm43xx_hdr-0.fw
2be9d4da43aba729bfa3417829e011df brcmfmac43143.bin
dc78f76883f5a0df9f13fad30d78442b brcmfmac43143-sdio.bin
3575f0473cd9082d5b03f0e2549a998f brcmfmac43241b0-sdio.bin
62dffd52291975a60b2c079f2b671c06 brcmfmac43241b4-sdio.bin
ff610cee869375a2d0c0be6b97b107fb brcmfmac4329-sdio.bin
**c6908817b83724800bb76b0114eec7a5 brcmfmac4330-sdio.bin**
0e5d2b9bfaaf3b6c43077405cfe92632 brcmfmac4334-sdio.bin
678ed027a1bac420318cd54daa1e1579 brcmfmac4335-sdio.bin
ce95e81aa95f9dc1a32fb8acf691dbd8 brcmfmac43362-sdio.bin
**4a410ab9a1eefe82e158d36df02b3589 brcmfmac43430-sdio.bin**
8c3cb6d8f0609b43f09d083b4006ec5a brcmfmac43430-sdio.txt
a3a73454d750f6b01170c7cbaa02c952 brcmfmac4354-sdio.bin
Two of the driver files differ (highlighted).
Please keep us posted.