In the past, QmdlReader was written to share a trait with DiagDevice, so
it had to pretend to be reading MessagesContainers. This needlessly
complicated both its code as well as that of consumers'. Instead,
QmdlReader now returns a stream of diag Messages.
QmdlReader also automatically detects if it's reading a compressed QMDL
stream or not.
Additionally, QmdlReader no longer can be bounded by a filesize limit,
and instead relies on HDLC message framing to detect file truncation.
This works for both compressed and uncompressed QMDL files.
This is perhaps a bit silly, but the current output of a compressed
QmdlReader is always decompressed, so when we export a ZIP, we're
basically un-gzipping the QMDL before zipping it.
However, this approach makes for simpler code and results in a uniform
set of files for the user, which I think is worth the slight amount of
wasted processing.
This reworks the QmdlWriter to output gzipped QMDL files by default,
and allows QmdlReader to operate on either compressed or uncompressed
QMDLs.
QmdlReader has been significantly rewritten to expose a single AsyncRead
interface to both compressed and uncompressed QMDL sources.
There are no important changes in the new tower version. The only reason
i'm bumping it is because it exposes our mis-configuration of tokio: We
depend on API surface enabled by `io-std`, but don't enable that
feature. Tower 0.5.2 pulls in that feature though, and our code works
anyway. Tower 0.5.3 no longer requires this feature and our code stops
compiling.
It's pretty annoying to have to scroll past all the old recordings to
be able to set the config. Since logs we already have figured out how to
create modals, so let's reuse that code.
Every once in a while, I get the error posted in #901:
Caused by:
0: Failed to send login request
1: error sending request
2: client error (SendRequest)
3: connection closed before message completed
(either this or "failed to start telnet" -- in either case there's a
request happening before it, and it's always "connection closed before
message completed")
Disabling connection pooling seems to reduce the amount of flakiness.
Here is what I used to test this fix:
while echo | cargo run -p installer util orbic-shell --admin-password 96df5476 ; do true; done
Usually it would stop <100 iterations, now it can do 800+ iterations.
This commit introduces checkboxes where users can certify that either
they did not use generative AI to create their pull request, or that
they did but they understand the code and wrote all comments and
descriptions themselves, per our recently publicised open source policy.
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.
telnet_send_command_with_output returns output with the original command
contained. This leads to higher-level bugs. Fix#894
Also, change telnet_send_command_with_output to not return any "exit
code" related output. This is now only part of telnet_send_command,
which means this output does not leak into users of the DeviceConnection
trait.
Will Greenberg