The rate of emission of neighbor discovery packets is already
limited at the level of the entire neighbor cache, but poll()
would uselessly spin until the answer arrives (if ever).
- Do not send ICMPv4 responses for packets with a broadcast destination
address.
- Do not send DstUnreachable with ProtoUnreachable on receipt of a
packet with an unknown protocol with a non-unicast destination
address.
- Do not send DstUnreachable with PortUnreachable on receipt of a
UDP packet when no sockets are listening on the destination port
and the destination address is a non-unicast address.
- Send the correct amount of the original datagram when sending Destination
Unreachable error responses.
- Do not assume that a ip datagram has a payload when sending a proto
unreachable ICMPv4 error response.
- Add tests to iface tests.
- Ensure ICMP error responses are correctly formed when the
datagram has no payload.
- Ensure ICMP error responses are correctly handled for UDP packets
when no socket is listening on the destination port.
- Ensure the correct amount of the original payload is returned in
Destination Unreachable responses.
- Add tests for the following
- ICMP error responses are not sent in response to broadcast requests
- ARP requests are responded to and inserted into the cache
- ARP requests for someone else are not responded to, but the sender
is still inserted in the cache
- Add the ttl member to the IpRepr
- Add the ttl member along with setters and getters to the tcp and udp
socket types
- Add unit tests for the new set_ttl parameter
- Update usage of IpRepr to include the ttl value
To be precise, I'm talking about IPX, AppleTalk and DECnet here,
not things like PPPoE, ATAoE, FCoE, or PTP, which make sense
to implement on top of EthernetInterface but do not work on
the same level on top of it as IP.
This reverts commit 51b2f18d1165bf7257de8894df101299cc93b094.
There's no throughput difference so far as I could measure, but
this greatly increases worst-case latency. At some later point
we could perhaps pass a deadline to the poll function, but for now
reverting this is simple enough.
Typically, the poll function is used as a part of a larger RTOS.
If we only dispatch one packet per socket per poll() call,
then we have to wait for a complete scheduler roundtrip,
which is potentially a lot of time, and as a result we are
not filling the peer's window efficiently.
We still print them into our debug log though, because it has more
context; the caller may opt to ignore any poll errors and only
use the smoltcp debug log as a, well, debugging aid, or it could
print user-visible warnings to alert the user to unusual network
conditions.
Before this commit, anything that touched RawSocket or TapInterface
worked partly by accident and partly because of a horrible crutch
that resulted in massive latencies as well as inevitable packet loss
every time an ARP request had to be issued. Also, there was no way
to use poll() other than by continuously calling it in a busy loop.
After this commit, poll() indicates when the earliest timer expires,
and so the caller can sleep until that moment (or until packets
arrive).
Note that there is a subtle problem remaining: every time poll()
is called, every socket with a pending outbound packet whose
IP address doesn't correspond to a MAC address will send a new
ARP request, resulting in potentially a whole lot of such requests.
ARP rate limiting is a separate topic though.