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.
562: fuzz: DHCP header parser r=Dirbaio a=alexandrasandulescu
Hi. This fuzz target tests the [DHCPRepr](https://docs.rs/smoltcp/0.7.5/smoltcp/wire/struct.DhcpRepr.html) `parse` and `emit` functions ([context](https://github.com/smoltcp-rs/smoltcp/issues/305#issuecomment-530327153)).
The fuzz target requires a small change in the `DHCPOption` parser because the option type `OPT_DOMAIN_NAME_SERVER ` requires the payload representing the DNS server list to have a length multiple of 4. Otherwise the `chunks` call places the remainder in the last chunk (length < 4). This panics when the last chunk is parsed into an `IPv4Address`. Do you have a better suggestion for handling this situation?
I ran the fuzzer for a couple of days but it didn't find any crash yet. To increase the chances, I used the oss-fuzz seed corpora of `dnsmasq` DHCP fuzzer and `systemd` DHCP server fuzzer.
Please share if you have suggestions on how to improve coverage.
Co-authored-by: Alexandra Sandulescu <aesa@google.com>
563: Print log to stdout in test r=Dirbaio a=deantvv
Use simple [trick](https://github.com/rust-lang/log/issues/106) to allow print log to stdout in test
Co-authored-by: Dean Li <deantvv@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
561: Add lint `#[must_use]` for ring buffer functions r=Dirbaio a=luojia65
This pull request adds `#[must_use]` flag on several ring buffer functions that have side-effects.
This lint is in stable Rust now: https://github.com/rust-lang/rust/issues/43302, these changes are noted according to code comment from `@whitequark:` f65bc8aa79.
Some test cases and functions are altered due to changes of `#[must_use]`.
Co-authored-by: luojia65 <me@luojia.cc>
556: ci: do not run tests on master push r=Dirbaio a=Dirbaio
bors already tests the *result* of merging PRs into master, and then
pushes the *exact same commit* to master on success, so it's guaranteed
to pass CI. No point in running everything again.
This'll make other CI runs faster, since we have so many jobs that we're
always running against the GHA limit of 10 concurrent jobs.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
This lint is in stable Rust now: https://github.com/rust-lang/rust/issues/43302.
These changes are noted according to code comment from @whitequark.
Some test cases and functions are altered due to changes of #[must_use].
560: IEEE802154: getters for security fields r=Dirbaio a=thibautvdv
This adds getters for the security fields of the IEEE802154 frame. Also added a test for it.
`src/wire/ieee802154.rs` also contained a function for calculating the CRC. However, this is not needed and thus I also remove it in this PR.
Co-authored-by: Thibaut Vandervelden <thvdveld@vub.be>
bors already tests the *result* of merging PRs into master, and then
pushes the *exact same commit* to master on success, so it's guaranteed
to pass CI. No point in running everything again.
This'll make other CI runs faster, since we have so many jobs that we're
always running against the GHA limit of 10 concurrent jobs.
469: Add IEEE 802.15.4/6LoWPAN support r=Dirbaio a=thibautvdv
This adds the IEEE 802.15.4 frame representation.
Still a work in progress and interested to know what you think about this.
I really would like to add 6LowPAN as well, however I'm not sure where to put this in smoltcp, since 6LowPAN is kind of weird.
Co-authored-by: Thibaut Vandervelden <thvdveld@vub.be>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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.
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.
552: tcp: Reply with RST to ACKs with invalid ackno in SYN_SENT. r=Dirbaio a=Dirbaio
Should fixaramperes/onetun#17.
`@aramperes` could you check if this fixes the issue? Thank you!
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Dario Nieuwenhuis
bors[bot]
Dean Li
Alexandra Sandulescu
luojia65
Thibaut Vandervelden
mkb2091