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.
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>
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].
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.
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.
Previous code had an `if` to force sending a packet when retransmitting.
When the remote window is zero this would cause an infinite loop of
sending empty packets, because the "retransmit" flag would never get cleared.
Remove the force-retransmit, and add an explicit check on `seq_to_transmit` for
pending SYNs because SYN retransmission relied on it.
Found with cargo-fuzz.
This causes an infinite loop of zero-length packets: when we have data
to send, it sends MSS-length packets until filling the window, which
is an infinte amount of packets because mss is zero.
Found with cargo-fuzz.
529: Fix typos in tcp docs r=Dirbaio a=david-sawatzke
Too few round brackets
530: tcp: fix delayed ack causing ack not to be sent after 3 packets. r=Dirbaio a=Dirbaio
Co-authored-by: david-sawatzke <david-sawatzke@users.noreply.github.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>