Closed bsdimp closed 7 months ago
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.
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.
"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.
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.
Description
I had
passthru=pci0:58:0:0
instead ofpassthru=58/0/0
and the error message waswhich 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
Wireless NIC
Wifibox version
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
Logs
Additional context
Add any other context about the problem here that might help the investigation.
Have you tried to turn it on and off?