client mode added#888
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. |
…, bump wifi-station rev
…ocument firewall fail-open, clarify UZ801 wifi status
Co-authored-by: Cooper Quintin <cooperq@users.noreply.github.com>
| // `command -v` is a POSIX shell builtin, so it works on minimal busybox firmware | ||
| // even when /usr/bin/which is absent. | ||
| conn.run_command(&format!( | ||
| "command -v {name} >/dev/null 2>&1 && echo FOUND || echo MISSING" |
There was a problem hiding this comment.
The way run_command works over adb the && clause here will be checked against '/bin/rootshell -c $command` which always returns true, therefore this will always echo FOUND even if the binaries aren't there. This is probably better solved in the run_command function in orbic.rs but since this is the only place its an issue its good enough for now.
Co-authored-by: Cooper Quintin <cooperq@users.noreply.github.com>
cooperq
dismissed stale reviews from untitaker, ch604, and oopsbagel
stale review
|
😁 |
PR #888 introduced more files that the installer needs to bundle. Those files in particular are annoying to deal with because now every developer needs a working C crosscompiler to get the installer working. This prompted me to do some other refactoring. Refactor install-dev to not build the wifi tools if there is no crosscompiler, and refactor the installer so that these files are loaded at runtime when built in debug mode. The build script only ever warns if files are missing, and depending on debug/release mode, the get_file!() macro either panics at runtime or fails compiling. Now the installer can be built again without any files, clippy can be run directly without any envvars, and the installer runs atleast for devices that don't need those files. The orbic installer will panic at runtime if the wifi tools haven't been built. Building the installer in release mode still requires all files. Another nicety of loading these files on runtime is that the installer does not need to be recompiled when the daemon has been rebuilt. This should make things like make.sh really obsolete, which bypass the installer for speed.
PR #888 introduced more files that the installer needs to bundle. Those files in particular are annoying to deal with because now every developer needs a working C crosscompiler to get the installer working. This prompted me to do some other refactoring. Refactor install-dev to not build the wifi tools if there is no crosscompiler, and refactor the installer so that these files are loaded at runtime when built in debug mode. The build script only ever warns if files are missing, and depending on debug/release mode, the get_file!() macro either panics at runtime or fails compiling. Now the installer can be built again without any files, clippy can be run directly without any envvars, and the installer runs atleast for devices that don't need those files. The orbic installer will panic at runtime if the wifi tools haven't been built. Building the installer in release mode still requires all files. Another nicety of loading these files on runtime is that the installer does not need to be recompiled when the daemon has been rebuilt. This should make things like make.sh really obsolete, which bypass the installer for speed.
7 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.