Prior to this change, the neighbor cache would get limited even when the
device failed to process our arp packet, which could put the socket in
the waiting state in the next poll.
This change only limits the cache rate if the device successfully
consumed our packet.
Adds accessor functions to the device implementing the phy::Device trait
within an ethernet interface. The intent is to allow access to read-only
methods such as gathering of device statistics or other diagnostics
while the interface is running. The interface does not hold any internal
invariants on the device, so that a mutable accessor can be added as
well.
Closes: #289
Approved by: whitequark
A regression meant broadcast IPv4 packets were ignored. Restore
handling those packets and also reply to broadcast ICMPv4 echo requests.
Closes#287.
Closes: #288
Approved by: whitequark
Using Routes<'static> used to make these functions impossible because it created a reference that needed to be valid for the static lifetime
Closes: #243
Approved by: dlrobertson
- Add a function to EthernetInterface useful for determining if a
received packet with the source address being a solicited node
address is the solicited node address for an IPv6 address assigned
to the interface.
- Add SOLICITED_NODES_PREFIX to Ipv6Cidr
- Fix some nits
Closes: #175
Approved by: whitequark
Add basic ICMPv6 handling
- ICMPv6
- Handle ICMPv6 echo requests
- Send ICMPv6 error messages
- When know listening UDP socket is found in process_udp
- When the next header is not known
- Update icmpv6 test to be more useful
- ICMPv4
- Handle one more case where we are sending too much data
- Add `process_ipv6` to `EthernetInterface`
- Add basic test for `process_ipv6`
- Add `deny(unused)` if either proto-ipv4 or proto-ipv6 is enabled
- Add `cfg`s where needed to avoid compile time errors due to the above
- Add MIN_MTU constants to the IP version modules.
- Ensure that ICMPv4 error replies comply with the size requirements
specified in RFC 1812 § 4.3.2.3.
The previous model was flawed. Consider the following case:
* The main loop looks as follows (pseudocode):
loop {
let _ = (tcp:1234).read_all()
wait(iface.poll())
}
* The remote end is continuously transmitting data and at some
point fills the window of (tcp:1234), stopping the transmission
afterwards.
* The local end processes the packets and, as a part of egress
routine, emits an ACK. That also updates the window, and
the socket's poll_at() routine returns None, since there is
nothing to transmit or retransmit.
* The local end now waits indefinitely even though it can start
processing the data in the socket buffers right now.