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.
This fixes several space-related issues at once.
We have observed the following phenomenon on TP-Link, Orbic and Moxee:
- Filling /data bricks the device (broken wifi, broken rndis, broken
display)
- Filling /cache does not (it only bricks rayhunter if it's installed
there, and it might break firmware updates)
Therefore it would make sense to store the entire rayhunter installation
in /cache.
This is a great idea for TP-Link and Moxee, because /cache is
significantly larger than /data. However, on Orbic, /data is
significantly larger than /cache!
This PR refactors orbic-network and tplink to use a shared codepath for
setting up the data directory. A symlink is created at /data/rayhunter,
and what it points to is device-specific:
- Orbic will have its data at `/data/rayhunter-data`
- There is a new alias `installer moxee` that overrides this to
`/cache/rayhunter-data`
- TP-Link will have its data at /cache/rayhunter-data when there's no SD
card, and /media/whatever when there is one.
In all cases, existing data is migrated to the new location. The user
can switch back and forth between two values of --data-dir and the data
will be moved over every time.
This PR has one huge wart, and that is that the USB installer for Orbic
remains untouched. The annoying reason for this is that the
DeviceConnection trait is insufficient to reflect all the different
kinds of shells you can have over USB: adb with fakeroot, and serial
with real root. I think it's not possible to create the right
directories with 'rootshell -c'.
I'm thinking of spawning a telnet server over serial, so that we can
just do telnet again, but this is for another time.
On tplink and orbic, do not overwrite config files by default. There is
a new flag `installer orbic --reset-config` that one can use to restore
the old behavior. This fixes#778, a long-standing issue existent since
0.3.0.
The businesslogic for config file overrides is shared to some degree.
The Install trait from pinephone.rs has been moved out and renamed to
DeviceConnection for that purpose, so that `install_config` can be
shared across installers, which in turn can delegate to the trait for
running commands and copying files. This also works towards #542.
However, the pinephone and other installers have not been adapted to
support --reset-config out of fear of regressions. A future refactor by
somebody with ability to test on pinephone should probably also consider
using the same DeviceConnection impl as orbic, if possible.
We sometimes, but rarely, get bug reports where the sdcard fails
mounting. Write a dedicated log file for the mounting action to /tmp,
separately from the rayhunter logfile that is on the sdcard itself. That
log file is probably going to be small so it can fit in /tmp.
On firmware M7350(EU)_V9_9.0.2 Build 241021 (but not sooner), entryId=2
was being sent before entryId=1. entryId=2 is invalid if entryId=1 does
not exist yet. The reason it works is due to both requests firing
simultaneously, so sometimes entryId=1 is indeed being registered first.
We may also be hitting random race conditions on the backend, not 100%
sure. Try to alleviate them by sleeping 1 second between started
requests and waiting until the DOM is ready.
Also, on sluggish devices, it can happen that nc is not ready within
100ms. Fixing that with exponential backoff.
There is a shell injection vulnerability after all, so we can just
launch a remote shell, tplink-style. Except there's no telnetd on this
device so we need to use netcat.
This was found in the goahead binary on the device using Ghidra. The
decompiled code for this endpoint looks like this:
```c
void FUN_0003c614(int param_1)
{
int iVar1;
undefined4 uVar2;
int local_160;
undefined1 auStack_15c [64];
char acStack_11c [256];
int local_1c;
local_1c = __stack_chk_guard;
if (param_1 == 0) {
error("input parameter is NULL!");
uVar2 = 0x66;
goto LAB_0003c808;
}
iVar1 = websGetJsonItemValue(param_1,"password",10,auStack_15c,0x40);
if (iVar1 != 0) {
iVar1 = get_log_level_something();
if (1 < iVar1) {
some_logging_func(2,"modifying root password(%s)...",auStack_15c);
}
iVar1 = sprintf(acStack_11c,"echo root:\"%s\"|chpasswd",auStack_15c);
acStack_11c[iVar1] = '\0';
system(acStack_11c);
}
```
Usage is `./installer orbic-network`, as an alternative to `./installer
orbic`. It should work on Windows without any kind of drivers.
This installer also works on the Moxee device.
Because we toggle some ioctl settings based on this field, change the
name to better capture that we're selecting which device we want to load
settings for, not just the display module to load. This creates room for
future per-device settings without needing more config file fields.
Add support for the Wingtech CT2MHS01 hotspot, a Qualcomm mdm9650-based
device with a screen available for US$15-35. This device is often used
as a base platform for while labeled versions like the T-Mobile TMOHS1.
AT&T branded versions of the hotspot seem to be the most abundant.
The device has a framebuffer-driven screen at /dev/fb0 that behaves
similarly to the Orbic RC400L, although the userspace program
`displaygui` refreshes the screen significantly more often than on the
Orbic. This causes the green line on the screen to subtly flicker and
only be displayed during some frames. Subsequent work to fully control
the display without removing the OEM interface is desired.
* Fix autostart by adding another port trigger for rayhunter-daemon
* Use Orbic's IOCTL params as fallback
* Fix sdcard path and make it configurable
* Update docs to indicate support
* Add uninstalling instructions for TP-Link
KAI Maintainer