loopback packets are intercepted on the way to the COM and
re-injected directly into the Rx queue, along with a message
sent back to the main loop to pump the Rx buffer to extract the
loopback packet.
the CM can't always detect if the EC changes state; this is
especially true after an update or a forced reset where
the state caches are not reliably updated. If no packets are
seen for a while, poll the actual state and force a sync-up.
Also try to make sure that the interrupts are enabled correctly.
Due to overly liberal use of `.take()`, file handles were getting closed
when doing ordinary operations. This stops that.
Signed-off-by: Sean Cross <sean@xobs.io>
This now adds a `timeout` parameter to the connect() API call.
Additionally, connections will not be returned until they are determined
to be open, or until an error occurs (such as a timeout).
Signed-off-by: Sean Cross <sean@xobs.io>
It's crappy because it uses a busy wait loop to poll the udp
rx socket in order to accurately emulate the Xous async callback
feature (which is _not_ emulated for Tcp, for example).
It's more accurate because this emulation happens. But it's a lot
more complicated to implement it because zero-cost async UDP callbacks
aren't really a host-native feature (but they are a Xous-native feature!),
and I didn't want to .. pull in tokio or mio code surface into
the Xous hosted mode, seemed a bit like crushing a fly by dropping
a house on it. Maybe that's a fine solution in Oz, but Xous doesn't live in Oz.
Total bodge -- we lop off the TCP stack at the Xous API level, and
substitute it with a native host TCP stack.
Caveat hacker: this means that a lot of OS-specific net properties
will carry through to the hosted mode emulation. This is adequate
for "smoke testing" a build but do not be shocked, *shocked* if
there are more bugs to be found because of some weird host integration
issue.
It's not a good time to bug the EC to do network stuff when it's updating
itself.
...might even want to send the network into a disconnected state,
but, let's start with just turning off the connection manager
for now.
Good enough so that if you type `net server` and you hit the IP
address of the device, it'll respond with something like
Hello from Precursor!
I have been up for 86087 ms.
There's still all kinds of bugs, I'm sure. But ... I'm also not
sure /why/ you would want a web server on Precursor. This is more
just to make sure that the TCP stack isn't totally broken.
The "web server" as it may be is quite broken and doesn't parse
any headers and probably sends a bogus amount of data because
I can't figure out if the content length includes some new lines
or not. But really, this just isn't in scope. Works with Chrome,
Firefox shows the status page and then says "connection reset" and hides
all the information. Whatever, browser compatibility is well beyond
my pay grade!
- 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.
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.
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.
