- boot PIN is not requested on root password init. it's redundant,
as it is actually set when you format the PDDB
- boot key was mistakenly a copy of the encrypted private key
for ed25519 key signing. "oops". didn't catch that bug until now...
i don't think it has a big impact on existing user base, because
the key is never exposed outside the rootkey server, and the
ed25519 key itself is encrypted with the root password and then
used as the boot key. But still -- that's just not what was intended.
- root password is requested twice to check the validity of the password
png filter specification calls for initial prior_line = [0u8]
see: https://www.w3.org/TR/PNG/#9Filters
but [0u8] results in distortion ???????
so use [125u8]
The checksum calc is inner-loop so removed for performance gain.
If a hacker can manipulate a byte then then they can manipulate a RGB
byte or a checksum byte - so the checksum doesn't really give any
protection from hacking afaik. I presume the checksum is in there to
detect corruption during storage or transmission - but if a couple of
bytes are corrupted you will not notice the change in the image - and
if a lot of bytes are corrupted then the distortion in the image will be
obvious. This is even more the case in Precursor, where we are shrinking
and dithering the image as a matter of course. So I don't really see the
point of the checkum
also print the sector data that errors out -- might be a bit
much at the moment but it's very helpful for immmediately
visualizing a loss-of-power event related write corruption
instead of sharing the wifi buffer loopback has its own buffer.
this eliminates a race condition that happens whenever an Rx
happens to happen on the wifi interface while there's loopback
traffic in progress.
also, i see a lot of opportunities to optimize the net stack now
that i have tweaked this path; it might be interesting to break
the receive interrupt out directly into the COM crate instead
of passing it through LLIO then NET then COM and having COM
drain the RX buffer immediately into a local "infinite" sized
queue.
The llio->net->com loop exists because the interrupt handler
for all the i/o is shared within one hardware block, but maybe
i can create an additional interrupt responder for the com
interface just to optimize things a bit in a future SOC update.
Alternatively, I could move all the interrupts into COM and not
have them resident in LLIO. This would optimize for COM latency
at the expence of I2C latency, but that's probably OK because
I2C is much less latency sensitive (i2c and com interrupt, as
mentioned above, share the same hardware block for external
pin-based interrupts).
- Peek now has a handler for reads that can't be met immediately
- add a count to the number of times a close socket has been polled,
if it exceeds a threshold close the socket anyways. This is a compromise
between trying to figure out how to implement a fully non-blocking TcpClose,
and having an interlocked one that cleans up state but ends up blocking
the case where you have, in the same thread, a sender and receiver
(which is ironically somehow legal and does not cause deadlock,
because the TcpClose in Unix is not blocking on internal state
being cleared up).
0 is a "valid" port and it means OS please give me a port.
This implements a method where a random port is chosen until
you find one that's not occupied.
If a Stream is opened and a process isn't constantly polling it,
it'll never close if the remote side goes away -- you'll just
end up hanging in a FIN-WAIT-2 condition.
Add some logic to detect this and close out streams automatically
where the remote has hung up.
I'm not actually sure this is what you're *supposed* to do, but,
lacking a formal specification, all I can do is try to get
this thing to pass the test bench. And pass it does.
TcpClose should not immediately remove the socket. It
has to wait until the FIN comes. Add a fin waiter state.
Also rewrite to use "retain". Woo. I'm starting to get
the hang of Rust closures. Only took a couple years.
RxWait gets stuck in CLOSE_WAIT state. It's a state where
you "could" transmit, but you can't receive anymore.
In this case respond with a 0-length receive? That seems
to be what leads to the right behavior. I would have thought
you'd want to respond with a timeout error but that doesn't
match what's in the test bench.
The response to get OpenSSH to work is non-compliant
(because it's trying to read a 2.1 command set out of a 2.0
device). This will lead to breakage in the 2.0 test bench,
but, it will allow the device to work with OpenSSH.
meh. specs, schmecs.
