Because IEEE802.15.4 uses a lot of compression in its frame, fuzzing it
is maybe a good idea. Adding this fuzz target showed that some frame
methods were panicking. `check_len` now checks if accessors will panic
or not.
I ran the fuzzer for about 15 minutes and nothing showed up.
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.
This fixes DHCP on Linksys WRT1900AC. With 0x0001, it would not reply to
DISCOVERs at all, probably because seeing an unknown reserved flag being set.
With 0x8000, it works fine.
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.
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.
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: 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.