IPv6.connect: only return once any IP address is configured#432
Conversation
This reflects the behaviour of DHCP in the IPv4 stack: we have to temporarily start the Netif.listen function to potentially receive neighbour advertisements (and router advertisements etc.), and once an IP address moves into the PREFERRED state, we signal completion to our caller. This avoids busy-waiting polling loops in the tests (and all other user code that first needs to ensure to be able to send out data). It is not yet clear to me whether this is a sensible and useful solution (esp. in a dual stack with IPv4 configured by DHCP setup) for the long term, but in the medium term it is good enough: a IPv6 stack is only useful for transport layers (UDP, TCP) if we can send and receive datagrams over it.
|
now, we should add a test case where a neighbour advertisement is sent as a reply to the ND, and also check this error condition (it should not busy loop (or |
MagnusS
left a comment
MagnusS
left a comment
There was a problem hiding this comment.
Looks like a reasonable solution to me, at least for now -- it avoids the caller having to add workarounds to wait for the IP after a call to connect and makes the ipv6 stack behave more as ipv4
- RFC 4861 (4.3) requires ND to _not_ contain the link-level address if source=unspecified - RFC 4861 (4.4) requires NA to not have flag S set if multicast or unsolicited unicast advertisements Ipv6.connect: install a timeout (3 seconds) -- if no IP address is configured after this timeout, fail (Lwt.fail)
|
@MagnusS I got DAD to work with a FreeBSD host system on the other side (see the last commit for the changes). If this is fine with you, I'd proceed to merge this |
|
likely there are more error conditions: what if only some IP addresses could be configured, but not all (i.e. only link-local but no global ones)? what if only globals could be configured, but no link local? |
…ut of bound access
|
Changes LGTM and CI is green so merging. |
CHANGES: * Assorted IPv6 improvements (mirage/mirage-tcpip#428 mirage/mirage-tcpip#431 mirage/mirage-tcpip#432 @MagnusS @hannesm) - set length in packets to be sent - preserve updated ctx from Ndv6.handle - fix ICMP checksum computation - implement Mirage_stack.V6 signature - add connect, mtu, iperf tests - fix DAD protocol implementation (and test it) - avoid out of bounds accesses of IPv6 packets (check length before accessing) * Fix 32 bit issues (@MagnusS) * Implement stack-direct and tcp disconnect: tear down existing connections (mirage/mirage-tcpip#429 @hannesm) * Treat broadcast address of network as broadcast as well (mirage/mirage-tcpip#430 @hannesm, reported in mirage/mirage-tcpip#427)
2 participants
This reflects the behaviour of DHCP in the IPv4 stack: we have to temporarily
start the Netif.listen function to potentially receive neighbour
advertisements (and router advertisements etc.), and once an IP address moves
into the PREFERRED state, we signal completion to our caller.
This avoids busy-waiting polling loops in the tests (and all other user code
that first needs to ensure to be able to send out data).
It is not yet clear to me whether this is a sensible and useful solution (esp.
in a dual stack with IPv4 configured by DHCP setup) for the long term, but in
the medium term it is good enough: a IPv6 stack is only useful for transport
layers (UDP, TCP) if we can send and receive datagrams over it.