- 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
- Correct from_system_time implementation
- Add missing functions and implementations to Instant type
- Add missing frnction to Duration type
Closes: #141
Approved by: whitequark
- Update documentation about current support in the wire module
- Ensure the possible panic is documented for Ipv6Option::data_mut
- Add a Repr structure for Ethernet II headers
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
- Improve TimeExceeded support
- Add support for message codes
- Add the TimeExceeded enum type
- Improve ParamProblem support
- Add support for message codes
- Add the ParamProblem enem type
Closes: #152
Approved by: whitequark
- 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
* The IPv6 address parser now handles IPv4 mapped IPv6 addresses which
take on the form ::ffff:x.x.x.x.
* Implement Display for IPv4 mapped IPv6 addresses
* Implement From<IPv4Address> for IPv6Address
Fixes#86
- There are several warnings that are thrown when running `cargo doc`. Fix
these warnings.
- Convert all module documentation to use /*! for consistency.
- 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.
This would result in results near usize::MAX, and is indicative of
a bug. A panic is always used instead of a debug_assert!() because
debug builds are easily slow enough so that the underlying bugs
are not tripped.
Related to #62.
- Add the ipv6 feature
- Ensure a travis build with the ipv6 feature enabled.
- Add the necessary infrastructure to wire for ipv6 support.
- Ipv6Address
- Ipv6Cidr
- Add Ipv6 Address and Cidr parsing to parsers
- Add basic tests.
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).
This paves way for adding more metadata apart from handles,
such as caches and so on.
This commit also removes SocketHandle::EMPTY in favor of
SocketHandle::default() since they are functionally identical.
- 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.
This is more likely to result in downstream confusion than not.
Let downstream code decide exactly what it wants to do with
an empty string; be conservative here.
- 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
This is basically a rename that now calls an apple an apple,
except user code can no longer change it. It's not obvious if
user code getting the socket handle from the socket is very useful,
but it's not harmful either, so why not.
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.
The previous implementation made no sense. It is obvious that
poll_at() should use the same mechanisms to decide whether dispatch()
should be called as dispatch() itself uses to decide whether to send
anything.
This fixes numerous busy looping issues that arise if the return
value of poll() is used for waiting.
1. Apart from non-empty transmit buffer, a state which transmits
a FIN flag should also be considerd. Otherwise, closing a socket
with an empty transmit buffer may retransmit the FIN flag forever.
2. Timeout poll requests should only be overridden by timer poll
requests when the latter is earlier.
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.
Some of them already use Result, but the ones that can return
an empty slice (or a slice shorter than requested) also must have
their return value (at least) checked.
After this change, if an 1s timeout is set on a socket that received
no packet for 2s, it will be instantly aborted, which seems
more reasonable. Also, this makes the `self.remote_last_ts.is_none()`
branch in TcpSocket::dispatch() actually behave as described.
set_len() with a positive length change is better represented
with enqueue(), and set_len() with a negative length change
is not really a valid operation on its own.
This also makes TcpSocket::{send,recv}_slice slightly more efficient
in case when the slice wraps around the corresponding buffer,
halving the necessary amount of calls.
This is prohibited by RFC 1122. Instead, aggregate them, and respond
once in the egress function.
However, still instantly send challenge ACKs to trigger fast
retransmit.
Commit 21282fdb was not completely sufficient because e.g. receiving
one octet and then blocking meant that an ACK with window length
of one is then sent, and this isn't motivating the other TCP stacks
all that much.
In any case, preemptively notifying the peer of window size increase
can only be beneficial, modulo network congestion.
Zero is a valid sequence number, treating it as an absence of value
isn't any good. This is unlikely to cause any real harm but it
just isn't good practice, nor does it make for understandable code.
These functions only skipped the header, but what they should have
done is cut the packet at its total length and skip the header.
Otherwise, if the buffer the IP packet is constructed from contains
padding, such as Ethernet packets, the payload would be too long.
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, if the amount of data in the buffer caused it
to be split among many outgoing packets, and retransmit timer
was active, the socket would behave very erratically and flood
the peer.
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.
We don't transmit anything in FIN-WAIT-2, so we don't need the timer
running, or we'll get spurious log messages about retransmissions.
This also makes logic cleaner, although with no functional change.
Dan Robertson
Astro
Dan Robertson
whitequark
Herman J. Radtke III
Philipp Oppermann
Andrew Cann
寧靜
Egor Karavaev
Alex Crawford
Josh Gangloff
Jeremy Soller
Kai Lüke
Steffen Butzer