Conversation
|
I added another small change during the install to replace some daemons that aren't used for rayhunter. They phone home to verizon, and by replacing them with just shell scripts that sleep that's avoided. Plus it gets us more memory. |
|
Now that I have the moxee I'm checking if it can support this too. |
BeigeBox
force-pushed
the
feature/client-wifi
branch
from
b7dc96b to
96ab600
Compare
|
We should figure out a way to hide the web ui config stuff if we didn't build with the wifi feature, right now as far as I can tell it would show up on all devices, no? Also It caused an error when I tried to set wifi stuff without compiling WPA supplicant first. |
I recall that I was hiding the wifi stuff for devices without support for wifi yet (except the 'device security' section always shows as that's relevant whether you're on wifi or not). I have a script for compiling the WPA supplicant, maybe I forgot to include it. I'll turn that script into actual instructions. |
|
To clarify what I meant was I think that wifi should be a separate crate outside of rayhunter. Rust could use a good wifi crate, the only other one was last updated 2 years ago. But more importantly I think that rayhunter should not be this tightly coupled with the wifi handling. Right now this PR is probably too long to properly review, making wifi a separate external crate would probably help with that (or using an existing wifi crate.) I also think that integrating the wifi with the installer is adding a lot of complexity for very little gain, I would suggest removing that for now and if you have a strong case for why it needs to be in there make that as a separate pull request later. |
|
oopsbagel
left a comment
oopsbagel
left a comment
There was a problem hiding this comment.
Lots to address here, I'd like to see a lot of these changes cleaned up and decoupled from this PR.
The review process has left me wondering to what degree we need to integrate any of the wifi client support with the rayhunter daemon? We're already installing wpa_supplicant, right? What we integrate with rayhunter is at this point mostly plumbing the configuration through to wpa_supplicant and configuring iptables? (I'm not mentioning the ota blocking feature because that needs to move to a separate PR.)
Ideally, we can completely decouple any code changes from rayhunter and provide them separately as a downloadable extra in the FAQ. (e.g., "here's how to setup wpa_supplicant, with links to a prebuilt and vetted binary!", the same way we provide documentation on how to disable wifi.) I'm willing to accept that the solution isn't quite that clean cut, but what besides configuration control do we gain by integrating wifi client mode into the rayhunter binary?
Critically, the stability issues need to be addressed before we can considering including this.
Thanks for your comments, I've looked over them and I'll address them one at a time in their respective locations. By integrating wifi client mode into the rayhunter installer and daemon we are getting two things in my view. The first being the groundwork for future work that needs a network or internet connection without paying for sim service. The second is user experience. The less roadbumps we have to getting something like this up and running, the greater the number of rayhunters will actually be deployed. If someone has to connect to the AP wifi every time they want more info than the minimal info a colored bar gives them that's going to be an impediment to the using it. Compare that to it being on their home network (or their phones hotspot) where they can just pull it up at any time. I guess it comes down to what the goal with rayhunter is. Are we aiming to get as many of these out there so that we can truly understand the landscape of SCC deployment, or is it going to be a passion project that requires a lot of technical knowhow. This intent to make the project more accessable bleeds into some of the other work I'm doing which is a GUI for the TFT screen on the Orbic and Moxee. |
|
I've got some code changes to finish testing then push, as well as comments from @oopsbagel to finish replying to but my lunch hour is up so I'll try and get to that tonight. |
|
I agree that it'd be ideal for client mode to be part of the official rayhunter software. Being able to set up real time alerts without having to pay for a separate cell plan for my rayhunter would be a huge improvement, and having these things integrated into the official installer is a huge help. I'm moderately familiar with setting up wireless related embedded systems, and have built a pwnagotchi, and I still dread trying to use third party modules for them. |
ch604
left a comment
ch604
left a comment
There was a problem hiding this comment.
The api doc builder won't like the external struct which has no utoipa decorators, so a change will likely be required upstream if we want to add api docs here successfully.
|
ffr happy to make that upstream pr :) |
That would be appreciated, thanks |
untitaker
left a comment
untitaker
left a comment
There was a problem hiding this comment.
I'll let @oopsbagel have the final word over things, but I think in general this looks as good as it can get, thanks for the work so far! I am saddened that we have to replicate an entire WiFi GUI for client mode to work, and I'm also not convinced that the separate init script is needed.
I had command lines in the installer, although I was asked to take it out. |
…OTA, revert unrelated changes - Replace Docker-based wpa_supplicant build with shell script (scripts/build-wpa-supplicant.sh) - Add iw cross-compilation and deployment to Orbic installer - Skip wifi tool install if binary already exists on device - Remove OTA daemon blocker (extracted for separate PR) - Revert unrelated UZ801 and T-Mobile installer changes - Remove connection.rs test scaffolding - Rewrite S01iptables init script to read config.toml directly - Pin url crate to 2.5.4 to fix MSRV
The ${VAR//pattern/replacement} syntax is a bash extension that
doesn't work in dash (Ubuntu's /bin/sh).
Passing PKG_CONFIG_LIBDIR as a make variable doesn't export it to $(shell pkg-config ...) calls. Set it as an environment variable so pkg-config finds the cross-compiled libnl.
Add decorators Co-authored-by: Andrej Walilko <walilkoa@gmail.com>
add utopia doc support Co-authored-by: Andrej Walilko <walilkoa@gmail.com>
add utopia doc support Co-authored-by: Andrej Walilko <walilkoa@gmail.com>
BeigeBox
force-pushed
the
feature/client-wifi
branch
2 times, most recently
from
c50da42 to
479742e
Compare
BeigeBox
force-pushed
the
feature/client-wifi
branch
from
479742e to
4be0214
Compare
|
I'll have to add SAE support in the future. SAE support requires rebuilding wpa_supplicant with a real crypto backend (wolfSSL is the lightest option) since the internal crypto lacks the bignum and elliptic curve primitives that Dragonfly key exchange needs. This just means only WPA3 ONLY APs handshake wouldn't work. This isn't too practical of a concern though as almost all APs will allow WPA2/3. |
|
Coming back to address the remaining open items. I replied to each of the inline comments individually, but the short version is: OTA removed, Docker replaced with shell script, UZ801 reverted, url pinned to 2.5.4, disk space check removed. All in 84062f1. That leaves the two big questions from your review. On stability: the wifi-station crate has a watchdog now that polls wlan1 every 30 seconds. It checks both interface existence and TX/RX packet counters. If traffic stalls for 3 consecutive polls it escalates through reassociate, wpa_supplicant restart, and full interface cycle. If the kernel module crashes entirely it reloads wlan.ko, restarts hostapd, and recreates the STA interface. There's exponential backoff on module reload failures and it gives up after 5 attempts. First crash saves a diagnostic snapshot to /data/rayhunter/crash-logs/ with dmesg, modules, ip addr, ps, and sysfs stats (keeps the last 10). There's also a kernel wakelock so the system doesn't sleep and drop wifi on battery. I've been running this on my Orbic for several weeks with no manual intervention needed. The watchdog has caught and recovered from a couple of wlan.ko crashes on its own. On whether this needs to be in the daemon vs standalone: there are a few things we'd lose with standalone docs + binary.
A standalone approach would work for people comfortable with shell access but it would lose status visibility, network discovery, and multi-device support out of the box. I think the integrated path makes sense if we want to lower the bar for getting rayhunters deployed. |
fix ntfy port_or_known_default, comment out ntfy_url in config template, update wifi-station with resolv.conf bind mount fallback, udhcpc_bin config, and module path fix for UZ801
both devices have wifi hardware and backend support. wingtech verified on hardware (QCA6174 via PCIe). uz801 excluded for now due to driver scan limitations with hostapd active.
cooperq
left a comment
cooperq
left a comment
There was a problem hiding this comment.
okay so, outstanding issues:
- Orbic-usb doesn't install the wifi files (are there other installers that we need to add support for?)
- install-dev doesn't install wifi files even in wifi install mode
- docs and web UI don't agree about the default DNS servers
- wifi client mode can't start if a client is connected to the device
If 1, 2, and 3 are fixed I think I'm ready to merge this, testing seems to work well and I think the code is in a good place now.
…, bump wifi-station rev
…ocument firewall fail-open, clarify UZ801 wifi status
6 participants
This has been tested on the Orbic. I have a Moxxe but I haven't tested it on that yet. One concern is that the wpa_supplicant is 1MB at present, which isn't good for the moxxe until we move it's logging to /cache. We may want to limit this to only Orbic until other devices are confirmed to work with this.
Posting this so folks can start to take a look at it and give me feedback. I've got a small shell script also that I threw together to tell me about the capabilities of other devices which I don't own. Reach out to me on mattermost if you have a device other than the Orbic or Moxxe and I'll send that to you. Then we can get a better idea of which devices can support client mode.
Pull Request Checklist
cargo fmt.