much better, but still eventually the stack can fall over eventually.
also, the stack doesn't behave well when you try to initiate new
commands in the middle of a flood, because the back-pressure mechanisms
are primarily in-stack at the moment.
I think i have an idea on how to fix that but this will have to be later.
- moved most ping state into the Net crate proper, since the smoltcp
implementation assumes a tightly bound set of objects and lifetimes
in its icmp abstraction
- created various convenience abstractions for handling single and
multiple pings, blocking and non-blocking.
- refactored the "net" command to use the new form
Initial testing indicates there are still some bugs (seems to be
with the way we are handling timestamping and doing pong retirement)
but at least we're not getting tons of async callback errors like
we were before, and we're not shuttling obscene amounts of state
using Arc-Mutex between the input and output of the ping operations.
Probably about time to push some of this net stuff into main, even
though it's got a ways to go. This adds UDP/ICMP/DNS to the net stack,
but the ping probably needs to be refactored a bit to be *much simpler*
and more reliable, and there's some corner cases to chase.
Now that I understand how smoltcp does ping better I have regrets.
The demo example in smoltcp uses a funky macro that was a bit
misleading. I have gotten rid of that but I probably would have made
different decisions in implementing this had I understood the API better.
Anyways. It works, but has some trouble handling the cases of timeouts
sometimes.
not fully working yet, but the architecture is there and it builds.
smoltcp's ping implementation (or at least its demo code) was not
very amenable to splitting into modules, had to recode most of it.
the ipv6 is still a hack.
yes, i know there is some fancy way to code this with iterators.
i don't like that way. this ways is easier for me to understand
and verify. It works now.
Sometimes, Rust sucks a bit. It's ok, you can cry.
Multicast/Broadcast is not supported by smoltcp it seems, so those
calls are just unimplemented. But we are able to clone UdpSocket,
for the sick puppies who like to do that sort of thing.
this at least removes a panic that crashes processes. it does
mean that some log messages can get silently lost, but this is
better than crashing if the arguments to the logger can't be
parsed for some reason?
