Dear Stefano, Thanks for your timely review. I agree with almost everything of it. Just a small clarification on this one: Stefano Brivio wrote:
@@ -1503,11 +1510,12 @@ void tap_backend_init(struct ctx *c) case MODE_PASST: tap_sock_unix_init(c);
- /* In passt mode, we don't know the guest's MAC address until it - * sends us packets. Use the broadcast address so that our - * first packets will reach it. + /* In passt mode, we don't know the guest's MAC address until + * it sends us packets (e.g. responds to our initial ARP or
I don't think the response is an example, so I wouldn't use "e.g." here, rather "i.e." / "that is", if that's the expected behaviour.
The reason for using "e.g." is the following: There is still the "usual" case where the passt client (QEMU) was freshly started together with passt. In that case, it *will not* respond to neither our ARP nor NDP request, simply because it won't recognize the IPv4/6 addresses, because it doesn't yet have any. In that situation, we'll learn about the guest's MAC address only after it sends a DCHP request, or NDP, or similar to us, on its own initiative - not as a response to anything we might have sent. So I'd propose to either keep the "e.g." wording, or to extend the comment by enumerating all possible cases. (Regarding the latter, I don't feel confident enough to be able to really enumerate them all. In addition to DCHP, NDP NS and DHCPv6, a sufficient strange client network stack might even broadcast nonsense packets to us, which we might not process further, but still learn the guest's MAC address from.) Best regards, Volker -- .---<<<((()))>>>---. | [[||]] | '---<<<((()))>>>---'