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.
The actual header length may be larger than the bpf_hdr struct due to aligning:
37ecb4d066/sys/net/bpf.c (L1649)8f02f2a044/bsd/net/bpf.c (L3580)
Tests are only valid for 32 and 64 bit architectures. I did not bother
guarding them with additional cfg flags.
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.
This was flagged by `cargo clippy`:
warning: field assignment outside of initializer for an instance
created with Default::default()
This changes the visibility of the dummy field to be public, but only to
the crate.
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
This was flagged by `cargo clippy`:
warning: called `map(f)` on an `Option` value where `f` is a closure
that returns the unit type `()`
I decided to disable this because it was suggesting changes like the
following and I prefer the original:
@@ -1 +1 @@
-self.waker.take().map(|w| w.wake());
+if let Some(w) = self.waker.take() { w.wake() }
These were flagged by `cargo clippy`:
warning: the operation is ineffective. Consider reducing it to `number`
warning: this function has too many arguments (8/7)
warning: you should consider adding a `Default` implementation for
`phy::loopback::Loopback`
I like the code better as it is.
These were flagged by `cargo clippy`:
warning: the loop variable is used to index
I've verified that this doesn't increase the size of consuming binaries.
Pretty impressive. I tested this with a project that uses the following
features: ethernet, proto-dhcpv4, socket-tcp.
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: explicit lifetimes given in parameter types where they
could be elided (or replaced with `'_` if needed by type
declaration)
These were flagged by `cargo clippy`:
warning: this seems like a manual implementation of the
non-exhaustive pattern
The non_exhaustive attribute isn't available until we increase the
minimum Rust version to 1.40, so we should just silence these warnings
in the meantime.
These were flagged by `cargo clippy`:
warning: you don't need to add `&` to all patterns
This should have happened in ac830e8b, but I guess I missed it.
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.
This commit fixes a small bug, where the TcpSocket computed the maximum
size per payload in a tx_buffer without taking into account the MTU
defined by the underlying network device.
Prior to this change, the neighbor cache would get limited even when the
device failed to process our arp packet, which could put the socket in
the waiting state in the next poll.
This change only limits the cache rate if the device successfully
consumed our packet.
Previously, the window update was sent anytime it changed. This is
not desirable for 2 reasons:
- It would send window updates in TimeWait or Closed states, which is incorrect.
- It would send window updates in states where we've already received the
remote side's FIN, such as CloseWait. This is not necessarily incorrect, but
is useless, since the remote side is not going to send us more data, therefore
it's not interested in our window size anymore.
This allows applications to distinguish whether the remote end has
gracefully closed the connection with a FIN (in which case it has
received all the data intact), or the connection has failed due to e.g. a
RST or a timeout (in which case the received data may be truncated).
Previously, `ack_reply()` was sending the ack number present in `remote_last_ack`,
which is only updated by `dispatch`. This means the ack replies could contain
a wrong, old ack number.
Most of the time this simply caused wasting an extra roundtrip until the socket state
settles down, but in extreme cases it could lead to an infinite loop of packets, such
as in https://github.com/smoltcp-rs/smoltcp/issues/338Fixes#338