wifibox console: no output; wpa_supplicant repeatedly exits/cannot find interfaces
sk-spr opened this issue · comments
Description
A clear and concise description of what the problem is. What is expected from the application?
wifibox console produces no output other than the usual
Connecting, type "~." to leave the session...
Connected
~
[EOT]
Finished.
there is no login prompt.
In addition, dmesg shows repeated exits of wpa_supplicant, this may or may not be related.
Host operating system
Output of uname -a.
FreeBSD freebsdbook 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Wireless NIC
Relevant output of pciconf -lv.
none0@pci0:2:0:0: class=0x028000 rev=0x00 hdr=0x00 vendor=0x14c3 device=0x7961 subvendor=0x1a3b subdevice=0x4680
vendor = 'MEDIATEK Corp.'
device = 'MT7921 802.11ax PCI Express Wireless Network Adapter'
class = network
Wifibox version
Output of wifibox version. Note that only the latest version is supported.
wifibox version 0.13.0
Disk image checksum: 94904a08ee902c4a55dd345f8fffa2a96191cc8ad49f24031fe6eaf4acda5d05
Disk image type and version
The kind of VM image in use, e.g. Wifibox/Alpine, and its version.
wifibox-alpine-20240506
Changes to the default configuration files
Include relevant sections from all the configuration files that contain local changes and may help to reproduce the problem.
bhyve.conf:
console=yes
passthru=2/0/0
wpa_supplicant.conf:
network={
ssid="<correct ssid>"
psk="<correct key>"
key_mgmt=WPA-PSK
}
Logs
Please copy and paste any relevant log output from the following sources:
- /var/log/wifibox.log (with DEBUG logging verbosity)
2024-05-11T14:42:10+0200 DEBUG Program started as /usr/local/sbin/wifibox, with arguments: start
2024-05-11T14:42:10+0200 INFO Begin: wifibox start
2024-05-11T14:42:10+0200 DEBUG start=GN
2024-05-11T14:42:10+0200 INFO Creating bridge interface: wifibox0
2024-05-11T14:42:10+0200 DEBUG [ifconfig] wifibox0
2024-05-11T14:42:10+0200 INFO Linking tap interface to wifibox0: tap0
2024-05-11T14:42:10+0200 INFO vmm.ko is expected at path: /boot/kernel/vmm.ko
2024-05-11T14:42:10+0200 INFO vmm.ko is found at path: /boot/kernel/vmm.ko
2024-05-11T14:42:10+0200 DEBUG assert loaded: kmod=vmm, kmod_file=/boot/kernel/vmm.ko
2024-05-11T14:42:10+0200 DEBUG assert hardware support present: iommu=1, amdvi=1
2024-05-11T14:42:10+0200 DEBUG Backends reported by bhyve:
2024-05-11T14:42:10+0200 DEBUG [bhyve] ahci
2024-05-11T14:42:10+0200 DEBUG [bhyve] ahci-hd
2024-05-11T14:42:10+0200 DEBUG [bhyve] ahci-cd
2024-05-11T14:42:10+0200 DEBUG [bhyve] e1000
2024-05-11T14:42:10+0200 DEBUG [bhyve] dummy
2024-05-11T14:42:10+0200 DEBUG [bhyve] fbuf
2024-05-11T14:42:10+0200 DEBUG [bhyve] hda
2024-05-11T14:42:10+0200 DEBUG [bhyve] amd_hostbridge
2024-05-11T14:42:10+0200 DEBUG [bhyve] hostbridge
2024-05-11T14:42:10+0200 DEBUG [bhyve] lpc
2024-05-11T14:42:10+0200 DEBUG [bhyve] nvme
2024-05-11T14:42:10+0200 DEBUG [bhyve] passthru
2024-05-11T14:42:10+0200 DEBUG [bhyve] uart
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-9p
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-blk
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-console
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-input
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-net
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-rnd
2024-05-11T14:42:10+0200 DEBUG [bhyve] virtio-scsi
2024-05-11T14:42:10+0200 DEBUG [bhyve] xhci
2024-05-11T14:42:10+0200 INFO Bringing up null-modem devices for console connection
2024-05-11T14:42:10+0200 DEBUG assert loaded: kmod=nmdm, kmod_file=nmdm
2024-05-11T14:42:10+0200 INFO Null-modem devices are available
2024-05-11T14:42:10+0200 INFO Waiting for bhyve to start up
2024-05-11T14:42:10+0200 DEBUG Program started as /usr/local/sbin/wifibox, with arguments: _manage_vm
2024-05-11T14:42:10+0200 DEBUG assert daemonized: parent=daemon
2024-05-11T14:42:10+0200 INFO VM manager launched
2024-05-11T14:42:10+0200 INFO Gathering necessary configuration files for launching the guest
2024-05-11T14:42:10+0200 INFO Pulling bhyve options from configuration file
2024-05-11T14:42:10+0200 DEBUG cpus=1
2024-05-11T14:42:10+0200 DEBUG memory=128M
2024-05-11T14:42:10+0200 DEBUG passthru=[2/0/0]
2024-05-11T14:42:10+0200 DEBUG console=yes
2024-05-11T14:42:10+0200 DEBUG priority=50
2024-05-11T14:42:10+0200 DEBUG bhyve max cpus=16
2024-05-11T14:42:10+0200 INFO Guest console is configured to use
2024-05-11T14:42:10+0200 INFO Passthru devices configured: [2/0/0]
2024-05-11T14:42:10+0200 INFO PPT driver is configured for pci2:0:0 device
2024-05-11T14:42:10+0200 INFO tap interface is configured: tap0
2024-05-11T14:42:10+0200 INFO Launching guest wifibox from /usr/local/share/wifibox with grub-bhyve
2024-05-11T14:42:10+0200 INFO Application config is found at /usr/local/etc/wifibox/wpa_supplicant
2024-05-11T14:42:10+0200 INFO Application config will be mounted writeable
2024-05-11T14:42:10+0200 DEBUG Devices: virtio-blk,/usr/local/share/wifibox/disk.img virtio-9p,config=/usr/local/etc/wifibox/appliance,ro virtio-9p,var=/var/run/wifibox/appliance virtio-9p,app_config=/usr/local/etc/wifibox/wpa_supplicant
2024-05-11T14:42:10+0200 DEBUG Arguments: -S -M 128M -r host -c /dev/nmdm-wifibox.1A -d /usr/local/share/wifibox wifibox
2024-05-11T14:42:10+0200 INFO Launching guest wifibox from /usr/local/share/wifibox with bhyve
2024-05-11T14:42:10+0200 DEBUG Nice priority: 0
2024-05-11T14:42:10+0200 DEBUG Arguments: -c 1 -m 128M -AHP -u -S -l com1,/dev/nmdm-wifibox.1A -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/usr/local/share/wifibox/disk.img -s 4:1,virtio-9p,config=/usr/local/etc/wifibox/appliance,ro -s 4:2,virtio-9p,var=/var/run/wifibox/appliance -s 4:3,virtio-9p,app_config=/usr/local/etc/wifibox/wpa_supplicant -s 5:0,e1000,tap0 -s 6:0,passthru,2/0/0 wifibox
2024-05-11T14:42:11+0200 DEBUG [bhyve] rdmsr to register 0xc00000e9 on vcpu 0
2024-05-11T14:42:11+0200 INFO Guest wifibox has started up
2024-05-11T14:42:11+0200 INFO Guest is managed by PID 4107
2024-05-11T14:42:11+0200 INFO Bringing up Unix Domain Socket pass-through
2024-05-11T14:42:11+0200 INFO Found guest IP address: 10.0.0.1
2024-05-11T14:42:11+0200 INFO Configured sockets: [path=/var/run/wpa_supplicant/wlan0,user=root,group=0,mode=770,port=1200
path=/var/run/wpa_supplicant/p2p-dev-wlan0,user=root,group=0,mode=770,port=1201]
2024-05-11T14:42:11+0200 INFO Hooking up 10.0.0.1:1200 as /var/run/wpa_supplicant/wlan0 (root:0@770)
2024-05-11T14:42:11+0200 INFO Hooking up 10.0.0.1:1201 as /var/run/wpa_supplicant/p2p-dev-wlan0 (root:0@770)
2024-05-11T14:42:11+0200 INFO End: wifibox start
- /var/run/wifibox/appliance/log/dmesg
[ 0.227788] loop: module loaded
[ 0.228039] virtio_blk virtio0: 1/0/0 default/read/poll queues
[ 0.228811] virtio_blk virtio0: [vda] 242688 512-byte logical blocks (124 MB/119 MiB)
[ 0.229546] e1000: Intel(R) PRO/1000 Network Driver
[ 0.229906] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 0.535915] e1000 0000:00:05.0 eth0: (PCI:33MHz:32-bit) 00:a0:98:8a:05:71
[ 0.536368] e1000 0000:00:05.0 eth0: Intel(R) PRO/1000 Network Connection
[ 0.536653] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[ 0.537480] i8042: Warning: Keylock active
[ 0.538245] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.538585] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.539497] rtc_cmos 00:07: registered as rtc0
[ 0.539860] rtc_cmos 00:07: alarms up to one day, y3k, 114 bytes nvram
[ 0.540375] Initializing XFRM netlink socket
[ 0.540698] NET: Registered PF_PACKET protocol family
[ 0.541049] 9pnet: Installing 9P2000 support
[ 0.542078] IPI shorthand broadcast: enabled
[ 0.544917] registered taskstats version 1
[ 0.545203] Loading compiled-in X.509 certificates
[ 0.545930] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 0.546783] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 0.547272] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 0.547799] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 0.548380] cfg80211: failed to load regulatory.db
[ 0.549172] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
[ 0.549683] devtmpfs: mounted
[ 0.549935] Freeing unused kernel image (initmem) memory: 944K
[ 0.552673] Write protecting the kernel read-only data: 10240k
[ 0.553255] Freeing unused kernel image (rodata/data gap) memory: 348K
[ 0.553816] Run /sbin/init as init process
[ 0.554011] with arguments:
[ 0.554012] /sbin/init
[ 0.554012] with environment:
[ 0.554012] HOME=/
[ 0.554012] TERM=linux
[ 0.554013] BOOT_IMAGE=(host)/usr/local/share/wifibox/vmlinuz
[ 0.554013] modules=squashfs
[ 0.758706] mt7921e 0000:00:06.0: ASIC revision: 79610010
[ 0.845632] mt7921e 0000:00:06.0: HW/SW Version: 0x8a108a10, Build Time: 20240219110958a
[ 0.845632]
[ 0.855491] mt7921e 0000:00:06.0: WM Firmware Version: ____010000, Build Time: 20240219111038
[ 0.887872] NET: Registered PF_INET6 protocol family
[ 0.887975] Segment Routing with IPv6
[ 0.887977] In-situ OAM (IOAM) with IPv6
- /var/run/wifibox/appliance/log/messages
May 11 12:42:11 wifibox syslog.info syslogd started: BusyBox v1.36.1
May 11 12:42:11 wifibox daemon.err /etc/init.d/wpa_supplicant[969]: Could not find a wireless interface
May 11 12:42:11 wifibox daemon.info supervise-daemon[972]: Supervisor command line: supervise-daemon wpa_supplicant --start --respawn-delay 2 --respawn-max 5 --respawn-period 1800 /sbin/wpa_supplicant -- -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:11 wifibox daemon.info supervise-daemon[974]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:11 wifibox daemon.warn supervise-daemon[973]: /sbin/wpa_supplicant, pid 974, exited with return code 255
May 11 12:42:11 wifibox daemon.info dhcpcd[1074]: dhcpcd-10.0.6 starting
May 11 12:42:11 wifibox daemon.err dhcpcd[1077]: wlan0: interface not found
May 11 12:42:11 wifibox daemon.info dhcpcd[1077]: dhcpcd exited
May 11 12:42:11 wifibox daemon.err dhcpcd[1098]: dhcpcd is not running
May 11 12:42:11 wifibox daemon.info radvd[1135]: version 2.19 started
May 11 12:42:11 wifibox daemon.info supervise-daemon[1161]: Supervisor command line: supervise-daemon uds_passthru --start --respawn-delay 2 --respawn-max 5 --respawn-period 1800 /sbin/uds_passthru --
May 11 12:42:11 wifibox daemon.info supervise-daemon[1163]: Child command line: /sbin/uds_passthru
May 11 12:42:11 wifibox daemon.info : starting pid 1168, tty '': '/sbin/openrc default'
May 11 12:42:11 wifibox daemon.debug uds_passthru[1163]: Configuration: network=10.0.0.1:255.255.255.0, sockets=[path=/var/run/wpa_supplicant/wlan0,user=root,group=0,mode=770,port=1200 path=/var/run/wpa_supplicant/p2p-dev-wlan0,user=root,group=0,mode=770,port=1201]
May 11 12:42:11 wifibox daemon.warn uds_passthru[1163]: /var/run/wpa_supplicant/wlan0 is not available, skipping.
May 11 12:42:11 wifibox daemon.warn uds_passthru[1163]: /var/run/wpa_supplicant/p2p-dev-wlan0 is not available, skipping.
May 11 12:42:11 wifibox daemon.info uds_passthru[1163]: Waiting for PID 1173 to stop.
May 11 12:42:11 wifibox cron.info crond[1220]: crond (busybox 1.36.1) started, log level 8
May 11 12:42:11 wifibox daemon.info udhcpd[1274]: started, v1.36.1
May 11 12:42:11 wifibox daemon.info : starting pid 1281, tty '/dev/ttyS0': '/sbin/getty -L ttyS0 115200 vt100'
May 11 12:42:13 wifibox daemon.info supervise-daemon[1289]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:13 wifibox daemon.warn supervise-daemon[973]: /sbin/wpa_supplicant, pid 1289, exited with return code 255
May 11 12:42:15 wifibox daemon.info supervise-daemon[1291]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:15 wifibox daemon.warn supervise-daemon[973]: /sbin/wpa_supplicant, pid 1291, exited with return code 255
May 11 12:42:17 wifibox daemon.info supervise-daemon[1293]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:17 wifibox daemon.warn supervise-daemon[973]: /sbin/wpa_supplicant, pid 1293, exited with return code 255
May 11 12:42:19 wifibox daemon.info supervise-daemon[1294]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:19 wifibox daemon.warn supervise-daemon[973]: /sbin/wpa_supplicant, pid 1294, exited with return code 255
May 11 12:42:21 wifibox daemon.info supervise-daemon[1296]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
May 11 12:42:21 wifibox daemon.warn supervise-daemon[973]: /sbin/wpa_supplicant, pid 1296, exited with return code 255
May 11 12:42:21 wifibox daemon.warn supervise-daemon[973]: respawned "/sbin/wpa_supplicant" too many times, exiting
May 11 12:43:40 wifibox daemon.info udhcpd[1274]: sending ACK to 10.0.0.2
May 11 12:45:00 wifibox cron.info crond[1220]: USER root pid 1304 cmd run-parts /etc/periodic/15min
Additional context
Add any other context about the problem here that might help the investigation.
I've tried both wifibox-alpine and wifibox-mediatek guests, and both behave this way.
Have you tried to turn it on and off?
- Yes, I have read all the manual pages first!
The difference between the wifibox-alpine and wifibox-alpine-mediatek guests is not that big: the latter image is slimmer because it contains the firmware files for the Mediatek cards only. That is basically a flavor of the former.
There must be some problem with starting up the mt7921e driver because the wlan0 device could not be created on the guest. A reason for the guest being unresponsive when attached by wifibox console might be that it freezes on boot. However, according to the logs, the guest can somehow boot up. Another possible reason might be that the nmdm driver does not properly and the communication itself becomes stuck.
It might be curious to try the following. In one of the terminals, start the wifibox console command and leave it running. Then, in a different terminal, use the following command to restart the guest:
# wifibox restart guestYou should see the boot messages of Linux kernel on the terminal where the console is running.
Also, cannot you see any odd message in the logs of the host?
The difference between the
wifibox-alpineandwifibox-alpine-mediatekguests is not that big: the latter image is slimmer because it contains the firmware files for the Mediatek cards only. That is basically a flavor of the former.
Thank you, this was not entirely clear to me but now I know :)
It might be curious to try the following. In one of the terminals, start the
wifibox consolecommand and leave it running. Then, in a different terminal, use the following command to restart the guest:# wifibox restart guestYou should see the boot messages of Linux kernel on the terminal where the console is running.
Indeed I can, and it even lets me log in apparently. Relevant information from the boot messages might include the following:
* Could not find a wireless interface
* /var/run/wpa_supplicant: creating directory
* Starting WPA Supplicant ... [ ok ]
* Starting networking ... * lo ... [ ok ]
* eth0 ... [ ok ]
* wlan0 ...ip: SIOCGIFFLAGS: No such device
dhcpcd-10.0.6 starting
DUID 00:01:00:01:2d:d2:8e:06:00:a0:98:8a:05:71
wlan0: interface not found
dhcpcd exited
Running lspci -k on the guest appears to show that the NIC is passed through and picked up by mt7921e:
wifibox:~# lspci -k
00:1f.0 Class 0601: 8086:7000
00:04.2 Class 0100: 1af4:1009 virtio-pci
00:04.0 Class 0100: 1af4:1001 virtio-pci
00:00.0 Class 0600: 1275:1275
00:04.3 Class 0100: 1af4:1009 virtio-pci
00:06.0 Class 0280: 14c3:7961 mt7921e
00:04.1 Class 0100: 1af4:1009 virtio-pci
00:05.0 Class 0200: 8086:100f e1000
however, the interfacewlan0 is not up as already indicated by the boot log, confirmed by ifconfig:
wifibox:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 90:E8:68:43:F1:69
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Also, cannot you see any odd message in the logs of the host?
Yes, thisdmesgline seems odd, since the output frompciconf -lvindicates the card is at pci0:2:0:0, though I might be off here:
pci2: <network> at device 0.0 (no driver attached)
This mirrors another odd warning when restarting wifibox:
Restarting wifibox....WARNING: PPT device pci2:0:0 could not be destroyed.
.....OK
Here again, shouldn't the device be pci0:2:0:0? The manpages indicate that my passthru notation (see above) is correct for this device...
Thanks for the inputs. If you can see the card in the lspci -k output with the driver attached on the guest, it means that you did everything right on your side.
The no driver attached message in the host's dmesg is completely normal. However, the could not be destroyed message in the Wifibox log is a bit worrisome. It is worth to know that the relationship of bhyve with Mediatek cards can be flaky, see #73 for the details.
I am a bit confused about the ifconfig output on the guest. So you say that there is the wlan0 device but it is not in the "up" state? You can try to initiate the reconfiguration of the network interface on wifibox console with the following command:
wifibox# service networking restartIt would be interesting to see what wpa_supplicant actually complains about. You can get more logs from it by stopping the related the service on the guest:
wifibox# service wpa_supplicant stopand then start WPA Supplicant in the foreground (to watch the logs):
wifibox# wpa_supplicant -iwlan0 -dd -c/etc/wpa_supplicant/wpa_supplicant.confThis might also be caused by some regression in the Linux kernel. If you switch to the net/wifibox-alpine port, you can optionally select Linux 6.8 (as "edge") in the options for building the guest image and test with that if the driver (and the related networking stack) of that version works better for you.
Besides all these, you can experiment with pre-configuring the ppt (PCI pass-through) driver for the device and boot the host that way. This requires the loader.conf to have the following line:
pptdevs="2/0/0"
I have some interesting news based on your comment: When manually restarting networking inside the guest (after getting into the console by means of wifibox console and wifibox restart guest) using service networking restart after restarting wpa_supplicant (whose logs show nothing abnormal), wlan0 no longer times out waiting for a carrier (see below)!
Originally, this was the (relevant section of the) log from service networking restart:
* Starting networking ...
* lo ...
[ ok ]
* eth0 ...
[ ok ]
* wlan0 ...
dhcpcd-10.0.6 starting
wlan0: waiting for carrier
timed out
dhcpcd exited
ifup: failed to change interface wlan0 state to 'up'
however, after running service wpa_supplicant restart, and then service networking restart:
wifibox:~# service wpa_supplicant restart
* Starting WPA Supplicant ...
[ ok ]
wifibox:~# service networking restart
* Starting networking ...
* lo ...
[ ok ]
* eth0 ...
[ ok ]
* wlan0 ...
dhcpcd-10.0.6 starting
DUID 00:01:00:01:2d:d3:a4:e4:90:e8:68:43:f1:69
wlan0: connected to Access Point: TP-Link_22F4
wlan0: IAID 68:43:f1:69
wlan0: adding address fe80::92e8:68ff:fe43:f169
wlan0: rebinding lease of 10.0.0.16
wlan0: soliciting an IPv6 router
wlan0: Router Advertisement from fe80::1
wlan0: requesting DHCPv6 information
wlan0: REPLY6 received from fe80::1
wlan0: refresh in 86400 seconds
wlan0: probing address 10.0.0.16/24
wlan0: leased 10.0.0.16 for 86400 seconds
wlan0: adding route to 10.0.0.0/24
wlan0: adding default route via 10.0.0.138
A quick check on the host confirms that the network is fully online:
freebsdbook% ping google.com
PING google.com (142.250.180.206): 56 data bytes
64 bytes from 142.250.180.206: icmp_seq=0 ttl=114 time=43.840 ms
64 bytes from 142.250.180.206: icmp_seq=1 ttl=114 time=54.271 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 43.840/49.055/54.271/5.215 ms
freebsdbox% ifconfig
[...]
wifibox0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=0
ether 58:9c:fc:10:eb:66
inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 3 priority 128 path cost 2000000
groups: bridge
nd6 options=9<PERFORMNUD,IFDISABLED>
tap0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 58:9c:fc:10:13:38
groups: tap
media: Ethernet 1000baseT <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Opened by PID 4127
Very interesting! I would be curious if this behaviour affects other configurations as well; if it does, perhaps a change in the guest's service init order might work, though I'd have to try this (and am not very familiar with openrc configuration, unfortunately...)
There is a slight chance the issue shows up for others as well. However, I am not sure if the problem is with the init order of the guest. The wpa_supplicant service declares that it has to be started before networking (i.e. provider of net).
What I can currently image is that during the boot process, WPA Supplicant fails to find the wlan0 device, it cannot start up, and therefore the networking service fails to work as well. But if wpa_supplicant is restarted at some later point, everything starts to work. Maybe the mt7921e driver takes a long time to initialize? What are the timestamps and messages for that in the dmesg output? Could you please add the output of the following command:
wifibox# dmesg | fgrep mt7921eBy the way, I noticed in the logs that your wireless network uses the 10.0.0.0/24, which is the same as what Wifibox uses by default to communicate with the host. This all appears to be working, but maybe it is worth to tell Wifibox to use a different subnet (e.g. 10.0.1.0/24 to avoid any potential problems caused by this overlap.
Greetings,
I can verify the same behavior here with the same Mediatek card, wifibox 0.13.0.
Enabling the console and launching manually (with some delay, I guess) wpa_supplicant, then dhcpcd (interestingly, neither udhcpc nor udhcpc6 work, though BusyBox dhcpcd seems to invoke udhcpc), works around the behavior. Maybe a delayed retry (as in pgj/freebsd-wifibox-port@954eff3) would address the problem?
Alternatively, is there a mechanism through which one can specify a set of commands to be launched on the guest start (and possibly even on suspend/resume)? Since the guest image is read-only, I can’t modify the guest’s rc.conf or .bashrc or anything.
The two ways I could see this implemented would be either as a squashfs overlay (think Puppy Linux or any LiveUSB with additional persistent storage), or more simply a script passed through a bhyve arg or variable (like with some Docker images), much like the passthru option setting. But I may be reinventing the wheel here...
Hi @vvillenave, thanks for the confirmation. The delayed retry (of WPA Supplicant) is already part of the development version of the port (as you pointed out above) so you or @sk-spr can try that.
There is no explicit support for specifying commands on start/stop/suspend/resume for the guest. First of all, the guest does not deal with suspend/resume, that is always translated to start/stop (host suspend: guest stop or no-op, host resume: guest start or restart).
Second, even though the guest image is read-only, you can modify how it is constructed in the net/wifibox-alpine port. For example, the pre-build target in the port's Makefile can be used to add extra files for the guest's root file system (which is sourced from _GUESTDIR during the build process). But, since the whole construction is based on the use of Alpine Linux packages for modularity, it is often better to create your own package with the planned modifications and add the package to the list of packages to use (_PACKAGES variable). Even further, the boot/shutdown process could be influenced by creating OpenRC scripts and hooking them up (e.g. _BOOT_SERVICES variable). An example of that is the Wifibox-custom uds_passthru package.
But in cases of problems like this one, it is better to find a general solution. That is, have it reported here and create a solution together that works for everybody. For example, the delayed retry I implemented for WPA Supplicant was designed in a way to possibly cover other scenarios, and with some luck, it can even provide a solution for this issue as well.