This continues work started in #579, with the goal of "remove unspecified variants from wire".
"unspecified" variants are bad, they've been a source of bugs in the past. The issue with them is that
depending on the context it may or may not make sense for the value to be unspecified.
It's better to not have them, and then use Option only where the value can really be unspecified.
This removes lots of `Address::Unspecified => unreachable!()` and similar match arms, which shows the
unreachable variant was actively unwanted in many places.
This fixes the "unspecified src addr" panic:
- Picking src addr is now the resposibility of the sockets, not the interface. All sockets now emit IpReprs with properly assigned src addr.
- Removed the `assert!(!ip_repr.src_addr().is_unspecified());`. This assert is WRONG even if
now sockets pick the source address, because there ARE cases where we indeed want to send a
packet with zero src addr, for example in DHCP.
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.
Using a raw socket on `monitor0` causes weird results: packets we receive
include FCS, packets we send are parsed as if they didn't have FCS, except
by wireshark which always expects a FCS??
Turns out the sane way is to use raw sockets on normal `wpanX` interfaces,
in which case all packets we send/receive are without FCS.
On `std` targets, `OsRng` is used by default. The user can supply a custom impl
by enabling the `rand-custom-impl` Cargo feature and using the `rand_custom_impl!()` macro.
Specifying a custom impl is mandatory when `std` is not enabled.
- 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.
These were flagged by `cargo clippy`:
warning: you seem to be trying to use match for destructuring a
single pattern. Consider using `if let`
warning: called `.nth(0)` on a `std::iter::Iterator`, when `.next()`
is equivalent
warning: using `write!()` with a format string that ends in a single
newline
warning: useless conversion to the same type:
`smoltcp::wire::Ipv4Address`
warning: called `map(f)` on an `Option` value where `f` is a closure
that returns the unit type `()`
warning: returning the result of a `let` binding from a block
warning: use of `unwrap_or` followed by a function call
This doesn't affect downstream code because log 0.3.9 is a facade
crate implemented in terms of log 0.4, and so log 0.3 and log 0.4
APIs can be used together.
This allows us to use:
(1.26)
- impl Trait
- autoderef in pattern matching
- fixed slice patterns
- inclusive ranges
(1.27)
- dyn Trait
- #[must_use] on functions
To prepare for edition change, dyn is added where applicable. Other
edition changes would require bumping the requirement even higher,
and so they are not applied for now.
