Volumio on rpi fails to detect SSID

Help and Support Help
1

so I installed the latest release 2.031 on my raspberry pi with internal wifi and followed the instructions to hook it up to my wifi modem.

As suggested I connect my laptop to the volumio Access Point, point the browser to the Volumio network settings and look for my network’s SSID. Curiously, it lists a number of SSID in the vicinity except my own network’s SSID. My SSID is visible to my other devices running linux, android and iOS10. My home wifi modem picks a channel automatically.

Now, when I change the modem’s wifi channel to 4 (random choice), my rpi running volumio discovers the SSID. Is this by any chance because volumio sets the rpi wifi mode by default to US mode and consequently fails to discover certain EU channels ?

Any thoughts on this issue would be appreciated.

2

Had the same problem with one of my first 2.00x installations, but I saw that Volumio hotspot used channel 4 and then I changed the router wifi channel ,but I didn’t noticed that as a problem/bug until you wrote about it (I was probably blaming a misconfigured router)

3

That’s very interesting, I’ll try to put my network on same channel that hotspot use…
That makes sense!

4

Changing the router channel from auto to 4 worked to solve this issue for me as well. Thanks for posting.

Verstuurd vanaf mijn GT-I9195 met Tapatalk

5

This could probably be very much linked to particular wifi HW used in your Volumio hardware (pi or other), and how Volumio initiate Hostspot functionality at boot.
Indeed various chipsets have various HW capabilities, particularly in terms of virtual interfaces (ability to handle both client and AP mode), and also some buggy drivers (like brcmfmac used in Pi3).

One capability parameter among others is an eventual limitation to use only one channel at a time.
It would be interesting to know which wifi adapter you are using (always a good measure when talking about wifi problems) and in particular dump result of the following command sudo iw phy phy0 info and closely look at #channels info within valid interface combinations section.
Wouldn’t be surprised it may be <=1 in such cases.

Currently we know Volumio launches hotspot at boot even if sometimes not needed: maybe it forces default channel #4 at that time (Volumio-specifi preference), and when mode switches to AP client, something might not be properly reset and client is stuck to #4…
Just a tentative explanation at this point.

6

Hi @macmpi

“iw phy phy0 info” don’t work !

I’m just using the integrated adapter in my Rpi3’s , have one Rpi2B+ with some kind of “TP-Link” adapter, but I have never never had any problems with that piece

7

try with sudo, sorry

8

Yeah of course !

volumio@sk3:~$ sudo iw phy phy0 info
Wiphy phy0
        max # scan SSIDs: 10
        max scan IEs length: 2048 bytes
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports roaming.
        Device supports T-DLS.
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP (00-0f-ac:4)
                * CMAC (00-0f-ac:6)
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * P2P-client
                 * P2P-GO
                 * P2P-device
        Band 1:
                Capabilities: 0x1020
                        HT20
                        Static SM Power Save
                        RX HT20 SGI
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 16 usec (0x07)
                HT TX/RX MCS rate indexes supported: 0-7
                Bitrates (non-HT):
                        * 1.0 Mbps
                        * 2.0 Mbps (short preamble supported)
                        * 5.5 Mbps (short preamble supported)
                        * 11.0 Mbps (short preamble supported)
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 2412 MHz [1] (20.0 dBm)
                        * 2417 MHz [2] (20.0 dBm)
                        * 2422 MHz [3] (20.0 dBm)
                        * 2427 MHz [4] (20.0 dBm)
                        * 2432 MHz [5] (20.0 dBm)
                        * 2437 MHz [6] (20.0 dBm)
                        * 2442 MHz [7] (20.0 dBm)
                        * 2447 MHz [8] (20.0 dBm)
                        * 2452 MHz [9] (20.0 dBm)
                        * 2457 MHz [10] (20.0 dBm)
                        * 2462 MHz [11] (20.0 dBm)
                        * 2467 MHz [12] (20.0 dBm)
                        * 2472 MHz [13] (20.0 dBm)
                        * 2484 MHz [14] (disabled)
        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * start_ap
                 * join_ibss
                 * set_pmksa
                 * del_pmksa
                 * flush_pmksa
                 * remain_on_channel
                 * frame
                 * set_channel
                 * tdls_oper
                 * start_sched_scan
                 * start_p2p_device
                 * crit_protocol_start
                 * crit_protocol_stop
                 * connect
                 * disconnect
        Supported TX frame types:
                 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        Supported RX frame types:
                 * managed: 0x40 0xd0
                 * P2P-client: 0x40 0xd0
                 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * P2P-device: 0x40 0xd0
        software interface modes (can always be added):
        valid interface combinations:
                 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
                   total <= 3, #channels <= 2
                 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
                   total <= 4, #channels <= 1
        Device supports scan flush.
volumio@sk3:~$
9

Ok, so the log was indeed for RPi3 built-in wifi, and that’s the one having issue.
Would be nice to have feedback from others, to see if it’s something that shows-up only with RPi3 built-in wifi or if it does show-up with other wifi HW.

10

Yes this one had the issues , during one of my first 2.00x installations I used hotspot to configure and I didn’t find my regular wifi until I changed the router wifi channel to 4, I haven’t had any problems with updates/reinstallations on any units after the change

feels like reasonable idea !

11

At this stage @SonosKiller, @sixdiamants and @hja seem to all be using RPi3-wifi: it’s likely to be RPi3-specific (bogusly-known driver maybe).
We’d need more feedback to check if problem is shared with some other wifi HW.

Anyhow, maybe as a workaround measure Volumio may need to shutdown/restart wifi HW (or unload/reload RPi3 wifi driver if issue is specific) at each change between client and Hotspot modes (along with optimizing Hostspot startup management, which seems to be in the work already).

Let’s see other reports if any.

12

Yeah a proper Shutdown solves many problems ! :slight_smile:

13

Was referring to wifi-only restart (or driver reload), not the whole Pi.
Have you tried?
I do not have a Pi3 handy, so can’t help much further in the resolution.

14

I can confirm that I indeed use the rpi3. The issue can be related to this pi version. However, I feel meanwhile that part of the issue might also be in the device it should connect with. I see a list of access points listed in Volumio that are broadcasting their SSID. There I see multiple access points of the neighbors but ours was not listed. Scanning the network with my phone did list our access point so it was broadcasting its SSID. One of the neighbors has the same access point (showing up in my phone scan) but also this was not listed in Volumio. The access point I use is a Ziggo Horizon Mediabox (see e.g. ziggo.nl/klantenservice/horizon/mediabox/). Their SSID is HZN followed by numbers which makes it possible to identify a similar device at the neighbors. Hope this helps to pinpoint where the root cause for the issue is.

15

All, do you still experience this issue on re-installed device with new 2.114 image?
With Hotspot set to OFF, can Pi3 connect to Home wifi, even if Home wifi is NOT on channel #4 ?

Thanks for any feedback

16

I have exactly the same problem on an RPI 3, using integrated Wifi.

The Wifi works- Volumio can throw up an AP which I can join. If I boot the Pi 3 with Rune Audio, it can see and join the SSID without problems. All other devices can join the SSID just fine, too.

I am using a fully up to date Volumio at the time of writing- freshly flashed as of last night (as the .14 update was broken, and couldn’t update cleanly to .18, it always updated, and then showed as still being .14 and needing an update after reboot). I don’t have the dev channel updates enabled. Let me know if there’s other info that you’d find helpful.

17

Thanks for the feedback.
if you are familiar with a bit of typing under ssh, can you try the following?

sudo mv /etc/modprobe.d/raspi-blacklist.conf /etc/modprobe.d/raspi-blacklist.old sudo cp /bin/wifistart.sh /bin/wifistart.old sudo nano /bin/wifistart.shand comment all the lines, except the last one: should be like this:[code]#!/bin/sh
#sudo /sbin/iw dev wlan0 set power_save off

#!/bin/sh
#sudo /sbin/modprobe brcmfmac
#sudo /sbin/modprobe brcmutil
sudo /sbin/iw dev wlan0 set power_save off[/code]then ctrl-o ctrl-x to save and quit.
Then restart Volumio.
Do you have same issue to connect to home AP that is not on channel #4 ?

18

I’ll try that tonight, if I get time!

I spent some time trying to make it join the SSID via manual config of the interfaces file and the like, to no avail, so goodness knows what state it’s in. I’ll just reflash that card from the current image, so it can start from a known state. I am suspecting that it’s a dodgy driver, though.

(Also, not sure that moving to ch4 will be an option, if that ends up being the suggestion. I live in a densely-populated area where we need to use as many channels as possible when on 2.4GHz…)

19

Ok, that made no difference at all. I can still see 15 other SSIDs, but not my own, usually on channel 13.

(As before, the SSID works fine on the same Pi 3’s onboard networking in Rune Audio, from my laptop under Linux, under MacOS, iOS, Android 4.xx-7.xx, Windows 7 etc. with an assortment of wireless interfaces- so I’m pretty confident that the router isn’t totally broken.)

I threw an AP up on channel 6 via my phone, it could see that, but apparently failed to connect to it, when I gave it the password, I got the notification in the web interface that wireless had been restarted but wireless suddenly showed as “off”.

However, the web interface was just a bit screwed up and not accurately reflecting the state of the networking settings, as ifconfig showing wlan0 to have an ip:

wlan0 Link encap:Ethernet HWaddr b8:27:eb:0a:2c:85 inet addr:192.168.43.38 Bcast:192.168.43.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:390 errors:0 dropped:382 overruns:0 frame:0 TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:140601 (137.3 KiB) TX bytes:7241 (7.0 KiB)

I unplugged eth0 and went to wlan0’s ip on my phone (as it’d be the only thing with a route to the interface) and got the familiar Volumio front end. I replugged eth0 and reloaded the page in my desktop browser (which will be going via eth0) and it showed the wireless as connected- but only the wireless. I shift-ctrl-r reloaded the page, and could see both eth0 and wlan0 in the web interface.

So it looks like there’s more than one issue at play- it can’t find my router on channel 13 to save its life (and that’s the quietest place for my router to be), and also the web interface doesn’t always correctly reflect the status of the networking, which can lead to drawing bad conclusions.

Incidentally, a pox on nano- you’d be amazed how many times I typed “:wq” before I remembered that I was using it :laughing:

20

ok…let’s try to keep thing focused and simple. (I’m blind here, as I do not have a Pi3 to test things).
Just want to make sure (as this is important): can you confirm Hotspot is turned OFF (and setting saved) on Volumio, Wireless set to ON, and that you only use onboard wifi (no add-on USB Wifi)?

The issue is well characterized: under some circumstances Pi3 can not connect to AP if AP is NOT on channel#4.
Yes it can see other SSID, but it will not connect to them. You would be able to connect IF your AP set on channel #4.
In earlier posts, I explained some Pi3 (and PiZero W) radio chipset (and possibly driver) limitations possibly at play here (but Volumio Hotspot management at startup may also add to the issues-mix).

Now, to help try to fix/circumvent the issue, please let your AP on other channel than #4, and have the Pi connected to ethernet.
Once booted with ethernet (and UI available), open a ssh session, and type: sudo iwconfig wlan0 txpower off then wait about 5sec and type sudo iwconfig wlan0 txpower on (or: sudo iwconfig wap0 txpower 31dBm if it fails) then go to Volumio UI network panel and switch wireless OFF/ON and save: you should see a widget saying wireless is restarted after a while.
Then do you manage to connect to your AP, after filling the login details and hitting connect?
(refresh the page, by going to another one and coming back to network UI and see if a valid IP is shown for wireless interface).