The intent was to run custom code after the user is done modifying the socket,
for example to update a (not yet existing) port->socket map in SocketSet. However
this wouldn't work, since the SocketRef would have to borrow the SocketSet at
the same time as the Socket to be able to notify the SocketSet.
I believe such indexing can be achieved by setting a "dirty" bit *before* giving
the socket to the user, then on poll() reindexing all dirty sockets. This could
even be faster: if user gets a socket multiple times between polls, it'd be reindexed
only once.
Also check for the correct destination PAN id when receiving a frame (as
discussed). Linux does this as well.
However, hardware implementations also can drop those packets.
We assume the FCS is checked by lower layers or by hardware.
- Makes it consistent with Ethernet mediums, where we don't handle the FCS either.
- Linux ieee802154 raw sockets send/receive packets without the FCS.
- Mirrors what Linux does, so will hopefully reduce problems in broken networks.
- it can actually increase performance: for small ARP caches, it'll reduce the
amount of entries that we're not going to use, increasing the chances of the
ones that we actually use to stay in the cache.
Fixes#537
On paper this looks great, and in a sane network it should work.
However the world out there is full of horribly broken, screwed up
networks, which *of course* ruin this.
I've seen a customer's network where the router is IP 192.168.1.1,
MAC addr xx:03. However, every 1 minute the router broadcasts some
"mikrotik discovery" UDP garbage with source IP 192.168.1.1, source MAC
addr xx:02 (one less!). This accidentally poisons smoltcp's ARP cache,
which then sends all traffic for the default gateway to xx:02, which
unsurprisingly blackholes it.
And, of course, the broadcast is every 1min and the ARP cache lifetime
is 1min. This means the cache is almsot all the time poisoned, and the
smoltcp device barely works. Fantastic.
Screw you mikrotik.
This makes UdpRepr work like IpRepr, where it only emits the header, and the user
must emit the payload.
This makes it easier to emit UDP packets with payloads that come from protocol-specific
reprs, like DHCP and in the future DNS.
DeviceCapabilities contains the `medium` field, so tests had to give it a value
even if it was unused. This is impossible to do with no `medium-*` enabled, because
it makes `Medium` uninhabited (empty enum).
- Add `medium` in `DeviceCapabilities`.
- Rename EthernetInterface to Interface.
- Add support to Interface for both Ethernet and IP mediums. The medium to use is detected from `device.capabilities().medium`.
- Ethernet-only features are gated behind the "ethernet" feature, as before.
- IP features are always enabled for now.
Dario Nieuwenhuis
Dean Li
Thibaut Vandervelden
qiujiangkun
Ryan Summers