Malformed passthru line gives opaque error message

Question

Malformed passthru line gives opaque error message

Closed this issue 8 months ago · 4 comments

Description

I had passthru=pci0:58:0:0 instead of passthru=58/0/0 and the error message was

2024-02-04T10:45:12-0700 WARN  The PPT device could not be destroyed

which is useless. There was no other messages, logs, the console was useless (no login: prompt). I only lucked into setting up PPT on a forum that caused me to read the surrounding comment a second time to see my mistake. While I should have read for comprehension the first time, I did not.

wifibox should check to make sure that the passthru argument matches ^[0-9]+/[0-9]+/[0-9]+ and issue a warning to /var/log/wifibox when it doesn't.

Host operating system

Output of `uname -a`.
FreeBSD downward-dog 15.0-CURRENT FreeBSD 15.0-CURRENT #16 firmware-1-n267653-724e901f0a68-dirty: Tue Jan 23 22:11:10 MST 2024     imp@downward-dog:/usr/home/imp/obj/usr/home/imp/git/freebsd/src/amd64.amd64/sys/GENERIC amd64

Wireless NIC

Relevant output of `pciconf -lv`.
n/a

Wifibox version

Output of `wifibox version`.  Note that only the latest version is supported.
wifibox version 0.12.0
Disk image checksum: f026fde7a684cfa54aee3aa32b55e9caf7e36c81550380dec219c2e6e074db2c

Disk image type and version

The kind of VM image in use, e.g. Wifibox/Alpine, and its version.
default

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.
see above for bad line in bhyve.conf.

Logs

Please copy and paste any relevant log output from the following sources:

- /var/log/wifibox.log (with DEBUG logging verbosity)
- /var/run/wifibox/appliance/log/dmesg
- /var/run/wifibox/appliance/log/messages

Just the one line posted above. Also, how do I turn it up to DEBUG? Adding 'see /usr/local/etc/wifibox.conf' would be useful. I'm not sure if this config error gives any additional info at debug because I didn't learn of it from the man page (where it should be) but in my annoyance of having to search it out and guess.

Additional context

Add any other context about the problem here that might help the investigation.

Have you tried to turn it on and off?

Yes, I have read all the manual pages first!

Answer 1 · 2024-02-07T08:06:10.000Z

Thanks for the report @bsdimp! I agree that is a valid miss on the side of Wifibox. I will add the fix and make it available for you for testing.

With regard to the comment at the "Logs" section, please note that Wifibox uses multiple configuration files instead of a single one. The "Configuration" section of the wifibox(8) manual page also suggests that: "check the sample configuration files provided in the /usr/local/etc/wifibox directory and follow the instructions to create a working configuration". There you can find core.conf where the logging verbosity could be configured. This is a design decision: I did not want to replicate the contents and comments for the configuration files in the manual page, instead I placed this reference. Anyhow, I can update the template to give the reporter more detailed instructions for increasing the log level if that helps.

Answer 2 · 2024-02-07T11:17:37.000Z

Please check the updated version of the net/wifibox-core port with the proposed fix in this tree: https://github.com/pgj/freebsd-wifibox-port/tree/73935895cee2546e0865616061bdf94cac71c327 . You are also invited to comment on #85 that contains the fix itself.

Answer 3 · 2024-02-07T18:55:13.000Z

"check the sample configuration files provided in the /usr/local/etc/wifibox directory and follow the instructions to create a working configuration"

This is exactly the not-helpful advice I was suggesting be improved. It's true, I'll grant that. However, it's not useful enough. There's no mention of this being a NAT setup in the rest of the doc. There's no mention that you need to ensure that the NAT translation doesn't conflict with the native addresses on the network. There's no mention that all network and wireless negotiation is handled by the Linux guest and none of it will be done by the host os. There's no mention that the host OS's network access is done solely through this NAT when using the wifibox interface.

Now maybe all of those would be overkill, but I was confused for a good half hour as to what to do. And I'm not exactly a novice, though my Linux networking fu might be weak. Some guidance on those points I think would result in a better experience or the users. If you'd like, I can suggest a sentence or three that would go a long way towards giving useful guidance through the issue without unduly belaboring it:

diff --git a/man/wifibox.8 b/man/wifibox.8
index 3ddf553..59d01f9 100644
--- a/man/wifibox.8
+++ b/man/wifibox.8
@@ -60,6 +60,17 @@ directory and follow the instructions to create a working configuration,
 otherwise
 .Nm
 will refuse to start.
+All network access, wireless configuration and network sign-in is
+handled by the linux guest.
+The files in
+.Pa %%PREFIX%%/etc/wifibox/appliance
+need to be configured so the linux guest acts as a NAT router so
+the host can access the network.
+The files in this directory are used instead of the host's files, so
+any pre-existing configuration may need to be copied from
+.Pa /etc
+to here, especially
+.Pa wpa_supplicant.conf .
 .Pp
 By default, PCI pass-through is disabled for AMD-based hardware, hence
 it must be explicitly enabled via the corresponding

might be a good start at giving the critical information. Though the bit about wpa_supplicant I'm unsure about.

Answer 4 · 2024-02-08T08:47:25.000Z

Sorry, I have not yet gotten to #83. My time is limited on this project as this is not my day job. But I am slowly making progress with these issues and I am glad to work with you to find a solution. Thanks for your feedback and suggestions!

That said, I would not go into the details of the manual page here. I would only like to give a reasoning for the structure of the documentation as my personal take on the subject.

First of all, this is an experimental project in a sense that I am challenging certain software development norms such as delegating the discussion of the examples to the actual configuration files. We could call this "executable documentation". I believe that it makes less sense to include snippets on the manual page (or anywhere else as text) that one would have to copy over anyway and it would have to be maintained separately.

On the other hand, Wifibox uses many different other software with their own configuration files and it is just simpler to keep them in a single directory and pass them around as needed. A single, unified "wifibox.conf" file would not be capable doing this and there would be a translation needed, which is inflexible.

Also, Wifibox has evolved over time in a way where it has become dependent on the configuration of the operating system that is run in the guest, its "firmware". It does not know anything about NAT or WPA Supplicant for example, its job only is to find the virtual machine image and launch it with bhyve, configure the PCI, file-system, and Unix Domain Socket pass-through, and supervise all that.

Actually, that is the guest who has all the software who need those configuration files which are then shared over 9P. Of course, currently there is only a single firmware available, Wifibox/Alpine, which uses the aforementioned settings. These are documented separately on the wifibox-alpine(5) manual page (with the generic symlink of wifibox-guest(5) pointing to that). But in theory, it is possible to create a firmware where bridging of the virtual Ethernet and the wireless interfaces is implemented and drop the need for both NATting and running WPA Supplicant on the guest. Some discussion around that topic has already happened in #52, #53, and I was able to do that in a very limited way (suboptimal performance and DHCP does not work). As a hobby OS researcher, I am keeping this option open for later experimentation. That is why the guest does not really have a firm and documented interface either.

Minor exceptions to these rules might be spotted on the main wifibox(8) manual page to aid getting up to speed with the use. The induction of new users follows a strategy. On installing the package/port, the user is notified to go to wifibox(8). This manual page has the pointers to the parts of the configuration and the description of the guest. I accept that these pointers may not be that clear, probably that what we will need to fix. Configuration files and the wifibox-guest then have all the details to finish the configuration.

Last, but not least, I admit that the GitHub "landing page", the README file of this repository may not be the best. This may come through that Wifibox does all these features but actually the description is meant to say that it only provides support for them. It is up to the guest whether it is implemented that way. Previously I was thinking about creating a whole GitHub organization with all these projects at a single place, but I felt it too great of a hassle. As consequence, this repository collects the issues for every component but they may apply to only a subset of them, as it is shown by the labels. I feel this is an acceptable compromise but potentially confusing, hopefully at the first sight only, though. Note that the FreeBSD ports have much better structure, fortunately.