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.
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: 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.
Converting from `::std::net::*` types to the ip related library structs
previously required both ip-version features to be enabled. This
introduced dedicated converters from the ip-version specific standard
address and endpoint representations (`IpV4Addr`, `IpV6Addr`,
`SocketAddrV4`, and `SocketAddrV6`) that are enabled without requiring
the other ip-version feature to be selected.
Closes: #286
Approved by: whitequark
- Add `process_ipv6` to `EthernetInterface`
- Add basic test for `process_ipv6`
- Add `deny(unused)` if either proto-ipv4 or proto-ipv6 is enabled
- Add `cfg`s where needed to avoid compile time errors due to the above
- Add the ipv6 feature
- Ensure a travis build with the ipv6 feature enabled.
- Add the necessary infrastructure to wire for ipv6 support.
- Ipv6Address
- Ipv6Cidr
- Add Ipv6 Address and Cidr parsing to parsers
- Add basic tests.
- Add the ttl member to the IpRepr
- Add the ttl member along with setters and getters to the tcp and udp
socket types
- Add unit tests for the new set_ttl parameter
- Update usage of IpRepr to include the ttl value
The use of this type has several drawbacks:
* It does not allow distinguishing between different error
conditions. In fact, we wrongly conflated some of them
before this commit.
* It does not allow propagation via ? and requires manual use
of map_err, which is especially tiresome for downstream code.
* It prevents us from expanding the set of error conditions
even if right now we have only one.
* It prevents us from blanket using Result<T> everywhere
(a nitpick at most).
Instead, use Result<T, Error> everywhere, and differentiate error
conditions where applicable.