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>
549: wire: add From<Address> for ::std::net::IpAddr r=Dirbaio a=Dirbaio
Originally from #296
Co-authored-by: Marc-André Lureau <marcandre.lureau@redhat.com>
548: DHCP fixes r=Dirbaio a=Dirbaio
Several fixes, including one that fixes DHCP not working with some routers.
See individual commit messages for details.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Reasons:
1. We were already accidentally not setting the BROADCAST flag due to it being the wrong bit (see previous commit).
2. Major OSes don't set it.
3. rfc1542 section 3.1.1 states it's discouraged, and the issue it's supposed to workaround doesn't apply to smoltcp.
Unfortunately, some client implementations are
unable to receive such unicast IP datagrams until they know their own
IP address
(..)
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
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.
547: Basic rand infrastructure. r=Dirbaio a=Dirbaio
See [previous discussion](https://github.com/smoltcp-rs/smoltcp/pull/465#pullrequestreview-774487285). Opening a separate PR so it can be discussed separately.
- Add `smoltcp::rand`.
- 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.
- Make TCP initial sequence numbers actually random.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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.