Hi Balena Team! I’m using a NUC7i7BNH , and after installing a Balena OS image onto the device, it never shows up in my dashboard. If I plug in a WiFi dongle supported by Raspberry Pi it catches the connection and provisions/shows up in the Cloud Dashboard, but until I do that it never shows up. Does the built-in WiFi not work?
P.S. if I try to leave the dongle in when I reboot, the connection will never establish unless I physically remove and plug the dongle back in a few minutes after boot
Hi Jarek, could you share the output of the dmesg command on your NUC? The interesting bits are the ones that may reveal the specific WiFi chipset and driver in the NUC, for example:
You may choose to share the whole output, as what’s missing may be as revealing as what’s included.
Also, what is your baIenaOS version? I am aware of the following issue affecting OS 2.27.0, which is missing the firmware for the Intel Dual Band Wireless-9560 (iwlwifi-9000-pu-b0-jf-b0-34.ucode)
However, if your NUC has a different WiFi chipset, then that issue may not apply.
[ 4.113668] bluetooth hci0: Direct firmware load for intel/ibt-17-2.sfi failed with error -2
[ 4.113669] Bluetooth: hci0: Failed to load Intel firmware file (-2)
[ 4.376385] [drm] failed to retrieve link info, disabling eDP
[ 4.395973] [drm] Initialized i915 1.6.0 20170818 for 0000:00:02.0 on minor 0
[ 4.396943] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 4.397167] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[ 4.397324] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
[ 4.398830] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-9000-pu-b0-jf-b0-34.ucode failed with error -2
[ 4.398844] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-9000-pu-b0-jf-b0-33.ucode failed with error -2
[ 4.398857] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-9000-pu-b0-jf-b0-32.ucode failed with error -2
[ 4.398870] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-9000-pu-b0-jf-b0-31.ucode failed with error -2
[ 4.398886] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-9000-pu-b0-jf-b0-30.ucode failed with error -2
[ 4.398888] iwlwifi 0000:00:14.3: no suitable firmware found!
[ 4.398890] iwlwifi 0000:00:14.3: minimum version required: iwlwifi-9000-pu-b0-jf-b0-30
[ 4.398891] iwlwifi 0000:00:14.3: maximum version supported: iwlwifi-9000-pu-b0-jf-b0-34
[ 4.398892] iwlwifi 0000:00:14.3: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
I’m running balenaOS 2.29.0+rev1, supervisor 9.0.1; I just provisioned these devices this morning. Is the firmware supposed to be included in 2.29rev1?
Jarek, 2.29 is also affected (missing the firmware) as far as I can gather. I understand that another issue is blocking our ability to ship the required firmware: lack of disk space in the relevant system partition:
We are working to solve the problem in two fronts:
Reviewing the set modules currently shipped with the NUC to delete anything we can in order to free up space for the WiFi firmware in currently released balenaOS versions.
Increasing the partition size in balenaOS 3.0.
Keep an eye on the two linked tickets (this post and my previous one) for updates.
As you may have to live with a WiFi dongle until the issue with the built-in WiFi is solved (and if an Ethernet cable is not an option), we can try debugging the issue with the dongle. If you look at the output of following commands in the Host OS, what can you see in relation to the dongle?
dmesg
journalctl -b
nmcli device
ifconfig
You may find it useful to attach a keyboard and monitor to the NUC to run these commands when the dongle is plugged, but network is down. If the device is in local mode, you can type CTRL-ALT-F2 to get a terminal – you can login as root without a password.
Thanks again for looking into this! After trying different combinations and patterns, I found an issue where if you define a SSID during balena image creation, using the balena-wifi-connect container with the default startup script doesn’t get past the iwgetid -r part if that binary doesn’t exist in your image, but also doesn’t connect to the WiFi as it tries to create a hotspot, but silently fails for some reason. Removing and reinserting the USB stick somehow bypasses this issue and the NUC connects to the pre-defined at flash time SSID.
Is it possible to send you those logs through a private message? They contain some sensitive information and I don’t know which is useful and which isnt…
Hi @jarek, the maintainer of WiFi Connect here. Please send me the logs indeed in a PM and I will check them. WEP is supported by WiFi Connect, however most probably the predefined connection is tuned for WPA2.
Also can you please try to connect to the wifi network with UDEV switched off in your Dockerfile: ENV UDEV=0. I have a suspicion that the udev service running in the container could be causing this.
We had to turn the WEP network off after another engineer broke into it just to prove how easy it is… actually planning to just mark it as “Unsupported” to our end-users since we don’t want to encourage others to use WEP
Hi @jarek, you can do the third step by opening a host OS terminal, then cd /etc/NetworkManager/system-connection, see what is the name of the connection profile with ls -l and then do a cat filename to see what the contents is. You may send it to me in a PM (you can exclude the password).
Also please try adding the ENV UDEV=0, I have a high suspicion it is what is causing the issue.
You are right about the WEP encryption. Also now even WPA1 is considered not very safe. As far as I remember iPhones warn about it. WPA2 is better.
I have plans to update the list with supported dongles, as that one is from a few years ago and hopefully I can reach this stage soon. There are multiple facets with wifi dongles: whether they are wifi-connect compatible (support for AP mode), how stable is their Linux driver/firmware, whether they support 5 GHz networks, form factor, etc.
Thanks again for looking into this, I’ll bring the device home with me this weekend and try out ENV UDEV=0 for WEP on a router that still has it manager isn’t keen on switching office wifi back to WEP again…
In a separate test, we were looking at improving WiFi performance after getting sub-par results with the dongle I linked previously, so we picked up a “better looking” device from the list of supported dongles, https://www.tp-link.com/us/products/details/cat-11_TL-WN722N.html , but after plugging this one in to the NUC the wifi hotspot doesn’t show up. The dongle blinked green one or two times after boot, but no AP appears on either my phone or laptop. Swapping out the dongle for the older one and restarting the NUC made the hotspot show up, but swapping them and rebooting again made the hotspot disappear. Can I send you some logs to troubleshoot please? This dongle looks much more ‘professional’ and we’d love to use its upgraded antenna until the NUC internal WiFi driver issue is fixed
Hi hedss! I’ve been eagerly following the github issue and it looks like this may be resolved in the next OS release. Our next batch will include this release; will followup when we get them running
Hi @jarek
Just wanted to check back with you on this.
Did you gave the newest balenaOS release for the NUC?
Do you still face this issue?
If yes, could you please provide us some logs to help us investigating further?
Hi Thodoris, thanks for following up. Yup, with 2.92rev+2 the internal wifi works perfectly, I was pleasantly surprised that https://github.com/balena-io/wifi-connect works out-of-the-box now as well