- 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.
Adds `is_subnet_broadcast` to the ethernet interface which checks for
subnet broadcasts, which are discussed on page 8 in
https://tools.ietf.org/html/rfc917. The subnet broadcast addresses are
derived from the interfaces ipv4 addresses.
This de-duplicates and (hopefully) simplifies a few if-else blocks. The
others were given an exception because I thought they were more readable
as is. I've verified that these changes don't result in larger binaries.
These were flagged by `cargo clippy`:
warning: using `clone` on a `Copy` type
warning: passing a unit value to a function
warning: redundant closure found
warning: called `iter().cloned().collect()` on a slice to create a
`Vec`. Calling `to_vec()` is both faster and more readable
These were flagged by `cargo clippy`:
warning: redundant field names in struct initialization
There are plenty more redundant field names, but I only changed the ones
where the initialization was a single line of code. I still prefer the
redundant style for multi-line initializations (and I'm under the
impression that others agree), so I've also disabled the warning.
These were flagged by `cargo clippy`:
warning: called `is_some()` after searching an `Iterator` with find.
This is more succinctly expressed by calling `any()`.
warning: this `.into_iter()` call is equivalent to `.iter_mut()` and
will not consume the `BTreeMap`
warning: called `skip_while(p).next()` on an `Iterator`
The skip_while conversion is a little tricky. Clippy notes that:
warning: called `skip_while(p).next()` on an `Iterator`
help: this is more succinctly expressed by calling `.find(!p)` instead
So the condition of the skip_while is inverted and then simplified using
De Morgan's laws.
These were flagged by `cargo clippy`:
warning: you seem to be trying to use match for destructuring a
single pattern. Consider using `if let`
This also silences a few cases where the match couldn't be replaced with
an if because of the following error:
error: attributes are not yet allowed on `if` expressions
Once we increase the minimum Rust version to 1.43, these can be updated
as well.
Functions that only deal with IP packets take/return IpPacket's. IpPacket's
are wrapped into EthernetPacket's as late as possible.
This will later allow generalizing Interface to handle both Ethernet
and pure-IP mediums.