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.
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.
- Mirrors what Linux does, so will hopefully reduce problems in broken networks.
- it can actually increase performance: for small ARP caches, it'll reduce the
amount of entries that we're not going to use, increasing the chances of the
ones that we actually use to stay in the cache.
Fixes#537
On paper this looks great, and in a sane network it should work.
However the world out there is full of horribly broken, screwed up
networks, which *of course* ruin this.
I've seen a customer's network where the router is IP 192.168.1.1,
MAC addr xx:03. However, every 1 minute the router broadcasts some
"mikrotik discovery" UDP garbage with source IP 192.168.1.1, source MAC
addr xx:02 (one less!). This accidentally poisons smoltcp's ARP cache,
which then sends all traffic for the default gateway to xx:02, which
unsurprisingly blackholes it.
And, of course, the broadcast is every 1min and the ARP cache lifetime
is 1min. This means the cache is almsot all the time poisoned, and the
smoltcp device barely works. Fantastic.
Screw you mikrotik.
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>
Marc-André Lureau
Dario Nieuwenhuis
bors[bot]
qiujiangkun
Thibaut Vandervelden
david-sawatzke
bdbai
Anton Romanov
