Hi, this error seems to originate from the xradio_wlan driver that the Orange pP Zero uses for its WiFi chipset. I will ask our devices team whether the driver could be eventually upgraded if there is a newer version of it.
Thanks,
Zahari
Hi. Are you able to build the code on your side in order to try an updated kernel? We have a work in progress PR for this https://github.com/balena-os/balena-allwinner/pull/125
If you cannot build it, then youâd need to wait for a little while until we merge it and the new OS version will be available in the dashboard
Sorry, havenât got the opportunity to build at the moment, but will try to get to it and if itâs merged before then will report back here after trying it out.
Great, please let us know once you have a chance to build that and your results.
I have started using BalenaOS 2.60.1+rev1 from the staging page today. So far so good, but is early.
Is this image tested on a device before it goes to production? I am wondering how much detail to provide here on testing the image out. If helpful I could provide all the journalctl logs for a load of a new image if there isnât Orange Pi hardware there to test on.
No issues but the logs to contain a few warnings that may or may not be of significance (to device debugging in general, not just my issue noted above):
Nov 07 00:42:39 balena systemd-udevd[3212]: Could not generate persistent MAC address for veth5c7ad23: No such file or directory
Nov 07 00:42:16 balena sshd[3047]: error: Could not load host key: /etc/ssh/hostkeys/ssh_host_dsa_key
Nov 03 17:06:00 localhost kernel: /cpus/cpu@3 missing clock-frequency property
Nov 03 17:06:00 localhost kernel: sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
Nov 03 17:06:00 localhost kernel: dwmac-sun8i 1c30000.ethernet: IRQ eth_wake_irq not found
Nov 03 17:06:00 localhost kernel: dwmac-sun8i 1c30000.ethernet: IRQ eth_lpi not found
Nov 03 17:06:02 localhost systemd-udevd[768]: Specified group 'render' unknown
Nov 03 17:06:02 localhost systemd-udevd[768]: Specified group 'kvm' unknown
Nov 03 17:06:02 localhost systemd-udevd[775]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0 ' failed with exit code 1.
Nov 03 17:06:02 localhost systemd-udevd[776]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0p4 mmcblk0' failed with exit code 1.
Nov 03 17:06:03 localhost systemd-udevd[775]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0p1 mmcblk0' failed with exit code 1.
Nov 03 17:06:03 localhost systemd-udevd[777]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0p6 mmcblk0' failed with exit code 1.
Nov 03 17:06:03 localhost systemd-udevd[770]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0p5 mmcblk0' failed with exit code 1.
Nov 03 17:06:03 localhost systemd-udevd[773]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0p3 mmcblk0' failed with exit code 1.
Nov 03 17:06:03 localhost systemd-vconsole-setup[852]: KD_FONT_OP_GET failed while trying to get the font metadata: Function not implemented
Nov 03 17:06:03 localhost systemd-vconsole-setup[852]: Fonts will not be copied to remaining consoles
Nov 03 17:06:03 localhost systemd-udevd[772]: Process '/lib/udev/resin_update_state_probe /dev/mmcblk0p2 mmcblk0' failed with exit code 1.
Jan 01 00:01:51 balena resin-supervisor[1155]: (node:1) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.allo>
Jan 01 00:01:51 balena 4be05c8dc7d2[981]: (node:1) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), >
Jan 01 00:01:52 balena 4be05c8dc7d2[981]: [debug] Handling of local mode switch is completedAnd still getting the CTRL errors on this version:
Nov 07 01:59:45 balena NetworkManager[953]: <info> [1604714385.2208] device (wlan0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Nov 07 01:59:45 balena avahi-daemon[989]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::30a4:8468:3897:7c5e.
Nov 07 01:59:45 balena avahi-daemon[989]: New relevant interface wlan0.IPv6 for mDNS.
Nov 07 01:59:45 balena avahi-daemon[989]: Registering new address record for fe80::30a4:8468:3897:7c5e on wlan0.*.
Nov 07 01:59:45 balena avahi-daemon[989]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.42.1.
Nov 07 01:59:45 balena avahi-daemon[989]: New relevant interface wlan0.IPv4 for mDNS.
Nov 07 01:59:45 balena avahi-daemon[989]: Registering new address record for 192.168.42.1 on wlan0.IPv4.
Nov 07 01:59:45 balena NetworkManager[953]: <info> [1604714385.2397] device (wlan0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Nov 07 01:59:45 balena NetworkManager[953]: <info> [1604714385.2610] device (wlan0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Nov 07 01:59:45 balena NetworkManager[953]: <info> [1604714385.2631] device (wlan0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Nov 07 01:59:45 balena NetworkManager[953]: <info> [1604714385.2753] device (wlan0): Activation: successful, device activated.
Nov 07 01:59:45 balena nm-dispatcher[5268]: resin-ntp-config: Found config.json in /mnt/boot/config.json .
Nov 07 01:59:45 balena nm-dispatcher[5268]: 200 OK
Nov 07 01:59:46 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:47 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:47 balena 1f6b11060b11[981]: [60B blob data]
Nov 07 01:59:48 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:49 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:50 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:51 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:52 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Nov 07 01:59:53 balena wpa_supplicant[1003]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-95 retry=1Hi there, just out of interest, is wlan0 status up or down when you are seeing these entries in the logs? If the wireless interface is down, this appears to be by design.
ip link or nmcli ... commands should give the status of the wireless interface.
Here is the output of ip link while the errors are repeating, and while wifi-connect is up:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 02:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 12:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
5: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
link/ether a2:1a:3b:93:f2:ac brd ff:ff:ff:ff:ff:ff
6: br-59c18c8fafef: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 02:42:7c:77:09:9e brd ff:ff:ff:ff:ff:ff
7: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:21:41:88:59 brd ff:ff:ff:ff:ff:ff
8: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:5b:34:54:2f brd ff:ff:ff:ff:ff:ff
10: vethad359ce@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-59c18c8fafef
link/ether 32:b9:82:ab:55:e9 brd ff:ff:ff:ff:ff:ff
And nmcli:
eth0: connected to Wired connection 1
"eth0"
ethernet (dwmac-sun8i), 02:42:70:5B:85:FF, hw, mtu 1500
ip4 default
inet4 192.168.1.74/24
route4 0.0.0.0/0
route4 192.168.1.0/24
inet6 fe80::b23e:dc44:bf68:6366/64
route6 fe80::/64
route6 ff00::/8
wlan0: connected to Balena
"wlan0"
wifi (xradio_wlan), 12:42:70:5B:85:FF, hw, mtu 1500
inet4 192.168.42.1/24
route4 192.168.42.0/24
inet6 fe80::9ea3:e132:d7ac:7192/64
route6 fe80::/64
route6 ff00::/8
supervisor0: connected to supervisor0
"supervisor0"
bridge, 02:42:5B:34:54:2F, sw, mtu 1500
inet4 10.114.104.1/25
route4 10.114.104.0/25
balena0: unmanaged
"balena0"
bridge, 02:42:21:41:88:59, sw, mtu 1500
br-59c18c8fafef: unmanaged
"br-59c18c8fafef"
bridge, 02:42:7C:77:09:9E, sw, mtu 1500
resin-dns: unmanaged
"resin-dns"
bridge, A2:1A:3B:93:F2:AC, sw, mtu 1500
vethad359ce: unmanaged
sit0: unmanaged
"sit0"
iptunnel (sit), sw, mtu 1480
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.1.254
domains: Home
interface: eth0
"vethad359ce"
ethernet (veth), 32:B9:82:AB:55:E9, sw, mtu 1500
â
Here is the output when wifi-connect is down, error messages still repeating:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 02:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 12:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
5: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
link/ether a2:1a:3b:93:f2:ac brd ff:ff:ff:ff:ff:ff
6: br-59c18c8fafef: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 02:42:7c:77:09:9e brd ff:ff:ff:ff:ff:ff
7: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:21:41:88:59 brd ff:ff:ff:ff:ff:ff
8: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:5b:34:54:2f brd ff:ff:ff:ff:ff:ff
10: vethad359ce@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-59c18c8fafef
link/ether 32:b9:82:ab:55:e9 brd ff:ff:ff:ff:ff:ff
And here it is after a reboot, wifi-connect up (it comes up automatically) and without error messages (still havenât been able to identify the error message trigger:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 02:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 12:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
5: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
link/ether ee:f4:4f:e9:8c:6e brd ff:ff:ff:ff:ff:ff
6: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:8a:25:67:0f brd ff:ff:ff:ff:ff:ff
7: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:69:de:88:80 brd ff:ff:ff:ff:ff:ff
8: br-59c18c8fafef: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 02:42:77:01:88:b6 brd ff:ff:ff:ff:ff:ff
10: vethed80ee4@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-59c18c8fafef
link/ether d2:b0:9b:cd:f4:c0 brd ff:ff:ff:ff:ff:ffThink the post you found may be point us in the right direction though. Here is the last output after starting wifi-connect from within a container, which caused the connection to drop and meant having to power cycle the device:
WiFi device: wlan0
Access points: ["TELUS6473", "kastlerock", "Saija", "panama", "TELUS0027"]
Starting access point...
Access point 'WiFi Connect' created
Starting HTTP server on 192.168.42.1:9292
**Error: Cannot start HTTP server on '192.168.42.1:9292': address not available**
#
dnsmasq: unknown interface wlan0
Will keep trying things out. Iâm starting to wonder if wifi-connect is not always cleaning up on exit.
Perhaps a little closer to the issue. If wifi-connect starts but hits an error, such as âaddress in useâ, it doesnât shut down the processes it started. From the logs below you will see wifi-connect exits but WLAN0 stays up and the dnsmasq process stays running.
I am using wifi-connect 4.4.4. I am starting from a shell script as per the wifi-connect repo, but it isnât run from the Dockerfile as the core process, but started and stopped from within a running container.
./wifi-connect -o 80
WiFi device: wlan0
Access points: ["TELUS6473", "Shukin01", "sirsuede", "TELUS1576", "TELUS3334", "TELUS4340"]
Starting access point...
Access point 'WiFi Connect' created
Starting HTTP server on 192.168.42.1:80
Error: Cannot start HTTP server on '192.168.42.1:80': address in use
# ps a
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/bash start.sh
15 pts/0 S+ 0:00 sleep infinity
16 pts/1 Ss 0:00 sh
68 pts/2 Ss+ 0:00 sh
362 pts/1 S 0:00 dnsmasq --address=/#/192.168.42.1 --dhcp-range=192.168.42.2,192.168.42.254 --dhcp-option=option:router,192.168.4
366 pts/1 R+ 0:00 ps a
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 02:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 12:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
5: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether d2:f4:78:0a:64:e4 brd ff:ff:ff:ff:ff:ff
6: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:8b:56:1f:54 brd ff:ff:ff:ff:ff:ff
7: br-59c18c8fafef: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:e8:37:b0:05 brd ff:ff:ff:ff:ff:ff
8: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:a1:d8:ee:c7 brd ff:ff:ff:ff:ff:ff
10: veth2875242@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-59c18c8fafef state UP mode DEFAULT group default
link/ether fe:89:74:b2:67:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
# ./wifi-connect -o 80
WiFi device: wlan0
Access points: ["TELUS6473", "Shukin01", "sirsuede", "TELUS1576", "TELUS3334", "TELUS4340"]
Starting access point...
Access point 'WiFi Connect' created
Starting HTTP server on 192.168.42.1:80
Error: Cannot start HTTP server on '192.168.42.1:80': address in use
# ps a
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/bash start.sh
15 pts/0 S+ 0:00 sleep infinity
16 pts/1 Ss 0:00 sh
68 pts/2 Ss+ 0:00 sh
362 pts/1 S 0:00 dnsmasq --address=/#/192.168.42.1 --dhcp-range=192.168.42.2,192.168.42.254 --dhcp-option=option:router,192.168.4
366 pts/1 R+ 0:00 ps a
If I stop the container, and then check the WLAN0 link from the root of the device, it still shows as UP:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 02:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
link/ether 12:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
5: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
link/ether d2:f4:78:0a:64:e4 brd ff:ff:ff:ff:ff:ff
6: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:8b:56:1f:54 brd ff:ff:ff:ff:ff:ff
7: br-59c18c8fafef: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 02:42:e8:37:b0:05 brd ff:ff:ff:ff:ff:ff
8: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:a1:d8:ee:c7 brd ff:ff:ff:ff:ff:ff
10: veth2875242@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-59c18c8fafef
link/ether fe:89:74:b2:67:c3 brd ff:ff:ff:ff:ff:ff
*I am connected to the device via the ethernet port.
Hi,
Thanks for sharing the info about wifi-connect. Iâd be curious to see results with an additional wifi interface (say, via USB) to see if the issue is reflected there as well. Any chance you could try that?
John
I donât have a USB wifi dongle to test on, sorry.
Although I imagine itâs not related to the dnsmasq not shutting down on a wifi-connect error. I canât be sure that it not shutting down is the root of this error, but pretty good chance as when wifi-connect goes up and down cleanly I can see WLAN going up and down with it in ip link.
Hi, regarding the dnsmasq not being properly closed sometimes, we fixed that in the latest WiFi Connect release: https://github.com/balena-io/wifi-connect/blob/master/CHANGELOG.md#v444---2020-10-29. Please check with v4.4.4.
I understand that
Sorry, sent the message too early.
I understand that using the upgraded kernel from the upcoming release is an improvement over the previous behavior. Sorry to ask but the thread has become long and hard to follow - is there anything else that is not working well now except dnsmasq not exiting?
Thanks,
Zahari
Indeed, the thread has become very long. The focus now is on the wifi-connect shutdown, which I think is related to the main issue first reported.
Here is the current wifi-connect behaviour:
# ./wifi-connect --version
wifi-connect 4.4.4
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.4 4308 2124 pts/0 Ss+ 15:52 0:00 /bin/bash start.sh
root 14 0.0 0.0 3168 336 pts/0 S+ 15:52 0:00 sleep infinity
root 39 0.3 0.0 1472 388 pts/1 Ss 16:27 0:00 sh
root 50 2.0 0.3 6032 2016 pts/1 R+ 16:29 0:00 ps aux
# ./wifi-connect -o 8383
WiFi device: wlan0
Access points: ["TELUS6473"]
Starting access point...
Access point 'WiFi Connect' created
Starting HTTP server on 192.168.42.1:8383
^C
Received SIGINT
Exiting...
Stopping access point 'WiFi Connect'...
Access point 'WiFi Connect' stopped
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.4 4308 2124 pts/0 Ss+ 15:52 0:00 /bin/bash start.sh
root 14 0.0 0.0 3168 336 pts/0 S+ 15:52 0:00 sleep infinity
root 39 0.2 0.0 1472 388 pts/1 Ss 16:27 0:00 sh
root 89 0.0 0.4 6032 2056 pts/1 R+ 16:29 0:00 ps aux
A clean shutdown, great.
# ./wifi-connect -o 80
WiFi device: wlan0
Access points: ["TELUS6473", "WhoWhatWhereWhenWiFi"]
Starting access point...
Access point 'WiFi Connect' created
Starting HTTP server on 192.168.42.1:80
Error: Cannot start HTTP server on '192.168.42.1:80': address in use
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.4 4308 2124 pts/0 Ss+ 15:52 0:00 /bin/bash start.sh
root 14 0.0 0.0 3168 336 pts/0 S+ 15:52 0:00 sleep infinity
root 39 0.2 0.1 1472 980 pts/1 Ss 16:27 0:00 sh
nobody 93 10.0 0.5 7072 2656 pts/1 S 16:30 0:00 dnsmasq --address=/#/192.168.42.1 --dhcp-range=192.168.42.2,192.168.42.25
root 95 0.0 0.4 6032 2084 pts/1 R+ 16:30 0:00 ps aux
On an error, wifi-connect exits but leaves dnsmasq hanging.
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 02:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 12:42:70:5b:85:ff brd ff:ff:ff:ff:ff:ff
5: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 3a:c8:4d:b6:85:c3 brd ff:ff:ff:ff:ff:ff
6: br-59c18c8fafef: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:44:b4:ab:a1 brd ff:ff:ff:ff:ff:ff
7: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:be:ce:0a:29 brd ff:ff:ff:ff:ff:ff
8: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:45:20:23:c8 brd ff:ff:ff:ff:ff:ff
12: vethe56fcd8@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-59c18c8fafef state UP mode DEFAULT group default
link/ether 22:ce:5a:9a:cc:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 1
It has also left WLAN0 up.
# ./wifi-connect -o 8484
Deleting already created by WiFi Connect access point connection profile: "WiFi Connect"
WiFi device: wlan0
Access points: ["TELUS6473", "WhoWhatWhereWhenWiFi"]
Starting access point...
Access point 'WiFi Connect' created
Starting HTTP server on 192.168.42.1:8484
dnsmasq: failed to create listening socket for 192.168.42.1: Address already in use
The retry now errors as it has left the socket open.
FYI, the Orange Pi Zero LTS is rumoured to have overcome some of the wifi interference issues: https://lemariva.com/blog/2019/10/orange-pi-zero-lts-upgraded-alternative-old-raspberry-pis. Plus some firmware updates as you note.
I have not independently confirmed this. Also donât want to get this comment confused with the issues above, merely raising the distinction between the models and suggesting anyone buying the zero to ensure they opt for the LTS.
There is also a new Orange Pi Zero 2 with a different WiFi chip altogether. Perhaps if there could be a balena os for this we could all start to say goodbye to the XR819 altogether. http://www.orangepi.org/Orange%20Pi%20Zero2/
Hi, I created the following issue for tracking the non-clean exit on the address in use error: https://github.com/balena-io/wifi-connect/issues/364
Thanks,
Zahari
1 Like
Will see if I can wrap up some of the above in to something constructive for others.
Initial issue: [CTRL-EVENT-SCAN-FAILED ret=-95 retry=1](/t/wifi-connect-wpa-supplicant-848-wlan0-ctrl-event-scan-failed-ret-95-retry-1/197064)
As best as I can tell, this was caused by the WLAN0 remaining up after wifi-connect exits without shutting down dnsmasq or closing WLAN0, and then starting wifi-connect again. This scenario happened
1.) when wifi-connect failed to launch due to an occupied port, it would not close down what it had opened before exiting (logged under https://github.com/balena-io/wifi-connect/issues/364).
2.) While I was developing in a container, I was running wifi-connect on the device without it executing at container launch via CMD, and then when I did a balena push of new code, Balena supervisor was killing the container rather than sending SIGTERM or equivalent, subsequently replicating the equivalent of an âuncleanâ wifi-connect exit. This shouldnât be an issue in production if containers are setup properly, so no action needed, but noted here as another cause.
A link shared above seems to highlight a similar issue of wifi turning off and on inappropriately for reference: https://bbs.archlinux.org/viewtopic.php?pid=1850642#p1850642
Orange Pi Zero with XR819 wifi chip on OS 2.60.1+rev1 Dev Staging
I wasnât having any major issues on the old version, so not the best to be testing this. The initial issue logged as best as I can tell isnât related to the firmware per se. I have encountered a disconnect and crash since using .60 though so perhaps not 100% resolved. It should be noted that this is after a lot of wifi-connect going up and down, not that it justifies the error, but that the circumstances were more brutal than I expect in production. All the wifi-connect exits were clean though so wasnât expecting a crash:
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2276] device (wlan0): Activation: starting connection 'LB' (f069adac-0195-45cf-93d7-07ceb75db0ff)
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2433] audit: op="connection-add-activate" uuid="f069adac-0195-45cf-93d7-07ceb75db0ff" name="LB" pid=4115 uid=0 result="success"
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2462] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2546] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2590] device (wlan0): Activation: (wifi) connection 'LB' requires no security. No secrets needed.
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2600] Config: added 'ssid' value 'LB'
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2601] Config: added 'mode' value '2'
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2602] Config: added 'frequency' value '2412'
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2603] Config: added 'freq_list' value '2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484'
Jan 01 04:22:25 lb NetworkManager[836]: <info> [15745.2604] Config: added 'key_mgmt' value 'NONE'
Jan 01 04:22:25 lb wpa_supplicant[870]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
Jan 01 04:22:25 lb kernel: ieee80211 phy0: changing interface type; new type=3(2), p2p=0(0)
Jan 01 04:22:25 lb kernel: ieee80211 phy0: !!! vif_id=0
Jan 01 04:22:25 lb kernel: ieee80211 phy0: Interface ID:0 of type:3 added
Jan 01 04:22:28 lb kernel: xradio_wlan mmc1:0001:1: ***CMD timeout!>>> 0x0006 (16), buf_use=1, bh_state=0
Jan 01 04:22:28 lb kernel: ------------[ cut here ]------------
Jan 01 04:22:28 lb kernel: WARNING: CPU: 2 PID: 870 at /usr/src/debug/xradio/0.1-r0/git/sta.c:1913 xradio_vif_setup+0x4d8/0x4dc [xradio_wlan]
Jan 01 04:22:28 lb kernel: Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6table_filter xt_state ipt_REJECT nf_reject_ipv4 xt_MASQUERADE nf_conntrack_netlink nfnetlink br_netfilter xt_owner xradio_wlan(O) mac80211 cfg80211 libarc4
Jan 01 04:22:28 lb kernel: CPU: 2 PID: 870 Comm: wpa_supplicant Tainted: G O 5.4.18 #1
Jan 01 04:22:28 lb kernel: Hardware name: Allwinner sun8i Family
Jan 01 04:22:28 lb kernel: [<c010f098>] (unwind_backtrace) from [<c010b63c>] (show_stack+0x10/0x14)
Jan 01 04:22:28 lb kernel: [<c010b63c>] (show_stack) from [<c07b9c1c>] (dump_stack+0x94/0xa8)
Jan 01 04:22:28 lb kernel: [<c07b9c1c>] (dump_stack) from [<c01282cc>] (__warn+0xbc/0xd8)
Jan 01 04:22:28 lb kernel: [<c01282cc>] (__warn) from [<c012834c>] (warn_slowpath_fmt+0x64/0xc4)
Certainly going to be an improvement though having the firmware, and havenât noticed any new issues as a result of the update (on other areas, the new version such as the supervisor is a big improvement in responsiveness and doesnât timeout as much as before when pushing locally).
I have read the issues with XR819 are fairly widely held beyond Balena. A new Orange Pi Zero 2 has been launched retailing at about the same price as the Orange Pi Zero. It has a different wifi-chip and holds potential to overcome some of the larger wifi-issues (although its new and will need its own testing). I will open a new post asking if we can have a Balena OS for this device.