OK, donc dans le cas du guest Windows, on voit bien des NS/NA pour une GUA, ce qu'on ne voit pas dans le cas de Linux.
On voit que les VM solicitent un routeur, recoivent un RA et configurent leurs adresses sur l'interface. Quand tu as fait tes captures, c'était juste après avoir activé la connexion réseau ? La VM démarre avec la connexion réseau désactivée dans ce cas ? Je demande pour savoir si on démarre avec un cache ND vide sur le routeur ou pas.
Je pars du principe que :
- ces captures ont été faites en wifi,
- tu n'as pas généré de traffic intentionnellement depuis les VM (comme faire un ping de la GUA du routeur) depuis le redémarrage de la VM,
- un hote sur le réseau (le routeur?) émet des NS pour la/les GUA/ULA configurées sur les VM.
J'ai bon ?
On ne voit aucun multicast ND de la part du routeur sur ces deux captures, mais on voit bien des échanges NS/NA unicast, ainsi que des router discovery (multicast) et unicast router advertisements. J'en déduis que :
- le patch a finalement été intégré à VirtualBox, car l'adresse MAC de la VM contenue dans les NA est bien remplacée par celle de ton interface Wifi (sinon, les échanges NS/NA unicast ne fonctionneraient pas). Tu devrais d'ailleurs pouvoir le vérifier en comparant les adresses MAC inclues dans les paquets NA émises par le guest de chaque côté du bridge VirtualBox (coté wifi et côté guest, donc) : elles devraient être différentes.
- les RS (router soliciation) émis par le guest en multicast arrivent bien à l'acces point (sinon, il n'y aurait pas de neighbor advertisements en retour),
- le guest ne recoit qu'une partie des paquets multicast recus par ton interface wifi.
Selon moi, ce qui sauve Windows, c'est qu'il émet des unsolicited neighbor advertisements juste après avoir configuré ses adresses (paquets #284 à 296 dans ta seconde capture).
Ces paquets sont émis en multicast et contiennent l'adresse MAC de la VM. Après leur réception par le point d'accès, ils contiennent l'adresse MAC de la carte wifi du host, et peuplent les caches ND de tous les hôtes qui les recoivent, dont le routeur.
Lorsque le routeur veut émettre un paquet vers la GUA du guest, il a déjà dans son cache ND une adresse MAC correspondant. Il peut donc envoyer le paquet en question sans avoir à faire une requête NS préalable, puis revalide périodiquement l'entrée de ce cache en faisant des requêtes NS unicast.
-> Il n'y a donc jamais de NS multicast émis par le routeur, et le traffic est acheminé correctement.
Dans ta capture Linux, ces unsolicited neighbor advertisements ne sont pas émis. Le routeur n'a donc pas d'entrée pour la GUA de la VM dans son cache ND, et doit donc émettre un NS multicast pour savoir à quelle adresse MAC le transmettre.
Ce paquet n'est jamais recu par ton guest, il n'y répond donc pas (logique). Le routeur timeout et jette le paquet original.
Maintenant, cherchons à résoudre le souci.
Normalement, VirtualBox devrait configurer ton interface wifi en "promiscuous", c'est à dire qu'elle désactive son filtre multicast et accepte toute trame multicast recue. Tu peux faire
$ ip link
et regarder les flags de ton interface (par exemple, chez moi, j'ai wlp2s0b1: <BROADCAST,MULTICAST,UP,LOWER_UP>).
Si le flag ALLMULTI n'est pas présent, ca n'a pas fonctionné. Tu peux faire
# ip link set $DEV allmulticast on
pour l'activer. Chez moi, ca donne wlp2s0b1: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP>.
Ensuite, refais une capture sur le guest. Est-ce que les NS multicast traversent le bridge VirtualBox cette fois ci ? Est-ce que ca résoud tes soucis de connectivité non sollicitée ?