[technique] Probleme IPv6 avec lien Nanobeam19 AC

[Laurent GUERBY]

Bonjour,

Hiers samedi 20150307 nous avions prevu de remplacer
le lien observatoire <=> Matthieu par des nanobeam 19 AC.

Nous avons du revenir en arriere sur l'ancien lien car IPv6 tel que
configuré sur le reseau tetaneutral.net ne marchait
plus pour la quasi totalité des abonnés derriere le
nouveau lien, meme apres upgrade au dernier firmware
disponible XC v7.1.1-BETA2 (dont les release
notes mentionnent un fix IPv6).

J'ai pu reproduire au moins un probleme chez moi
et j'ai ouvert un ticket (ci-apres) chez ubnt.

Merci a Carlos et Matthieu pour leur aide.

Sincèrement,

Laurent

<<
I managed to reproduce one issue at least:
 
Laptop eth0 "c1" <=> NB19AC STA <=radio=> NB19AC AP <=> Laptop eth0 "c2"
 
eth0 on both laptop c1 and c2 are unconfigured, so there's just the ipv6
link local on them (running debian jessie if that matters).
 
To reproduce :
 
0/ power off everything
1/ Power on both laptops until you get a shell prompt
2/ On c1 prepare the command : ping6 -nc 1 fe80::xxx%eth0 where
fe80::xxx is the link local of laptop c2 eth0
3/ Power on both NB19AC and wait until all the link led are lighted (I
use channel 5180 width 20 to avoid DFS wait)
4/ Wait a few seconds and effectively launch the ping6 command from 2/
=> it will fail
 
If you look at tcdpump eth0 on c1 you'll see three neighbor solicitation
who has fe80::xxx going out but not arriving on c2 by looking at tcpdump
on c2.
 
After a while if you redo the command ping6 it will ... work, tcpdump
will show the solicitation going through and being answered.
 
This shows that the bridge is learning at last after a few unrelated
packets but by default it is not in a pass through mode for neighbor
solicitation and this is a bug.

We have no issue with IPv6 with previous ubnt hardware in bridge mode.

Let us know if you manage to reproduce the issue. We're willing
to test new firmware if available.
>>