Neighbor advertisement komt niet aan op client

[Qlii256]

Ik heb een server die gebruikt wordt voor virtualisatie hosting. De server, verder benoemd als host, maakt gebruikt van QEMU-KVM virtualisatie om verschillende virtuele machines, verder benoemd als guests, te draaien. Ik heb nu een probleem waarbij ik lokaal niet naar de host of de guests kan verbinden (pingen faalt) via hun IPv6-adres. Dit probleem is enkel bij LAN devices (de guests als de host zijn nog bereikbaar van buiten mijn LAN) en doet zich enkel voor bij Wi-Fi devices tot nu toe.

Ik heb al een en ander uit gezocht, zo blijkt er een bug te zitten in de bridge-utils die gebruikt wordt op verschillende linux-distributies. De host maakt gebruik van Ubuntu 16.04.1 en is voorzien van een bridge op de main interface om elke guest van internet te voorzien. De interface die de bridge gebruikt zit rechtstreeks aangesloten op mijn LAN router. De host en de guests maken gebruik van een static IPv6 adres en zijn publiek (buiten LAN) en door al mijn LAN apparaten te pingen. De fix zou zijn om multicast (igmp_snooping) uit te zetten op de desbetreffende interface. Maar dit helpt niet en het probleem blijft zich voort doen.

Ik heb wat nader onderzoek gedaan, en wat blijkt is het volgende. Ik heb even een test scenario gemaakt. Hierin heb ik een Macbook Pro die gebruikt maakt van het LAN Wi-Fi netwerk via een AP. De AP, een Asus AC-66U in AP-modus, die met een ethernet-kabel verbonden is met mijn router. Dan de host, aangesloten via ethernet-kabel aan de router en maakt gebruikt van een static IPv6 adres.

De host pingen vanaf mijn Macbook Pro werkt zonder enige problemen. Echter, na enige tijd stopt dit plots met werken en merk ik op dat de neighbor discovery (incomplete) aangeeft als ik volgend commando uitvoer: ndp -an. Dit betekend dus dat de neighbor discovery faalt, wat dan ook veroorzaakt dat mijn Macbook Pro de host niet meer kan bereiken. Ik heb op alle drie mijn apparaten tcpdump -n icmp6 uitgevoerd, wat mij meer informatie geeft van wat elk apparaat doet en ziet. Hier merk ik op dat mijn Macbook Pro wel degelijk een neighbor solicitation uitvoert naar mijn host. Deze solicitation is ook te zien op de AP en op de host zelf. De host stuurt hierbij een neighbor advertisement terug, maar deze is niet meer te zien op de AP of de Macbook Pro.

Het is duidelijk dat er ergens iets mis gaat bij het terug sturen van zijn advertisement. Wat vreemd is, is dat dit pas gebeurd na enige tijd dat de server online is. Dit probleem lijkt zich tot nog toe niet voor te doen bij andere IPv6 LAN apparaten, die blijven gewoon pingable. Nog een vreemd iets, is dat als ik de host ping op zijn IPv4 adres, de neighbor advertisement plots terug aan komt op de Macbook Pro, en dan lijkt alles weer even te werken.

Ik ben ten einde raad, heb al tal van fora mijn probleem gepost, maar niemand kan mij helpen of weet genoeg over IPv6 in samenwerking met een bridge. Indien meer informatie nodig/gewenst dan laat je het maar weten.

[Brahiewahiewa]

Is het niet zo dat neighbour discovery uit gaat zo gauw je statische IP-adressen gebruikt?
Zie je hetzelfde als je rad gebruikt?

[Qlii256]

Volgens mij niet, waarom zou het dan eerst wel werken?

[Qlii256]

Niemand een idee? Ik zoek hier al lange tijd hoe ik dit probleem kan verhelpen. Het lijkt dus zo dat enkel Wi-Fi apparaten (dus bv. mijn Macbook Pro die verbonden is over Wi-Fi met het lokale netwerk) plots (het werkt eerst wel even) geen verbinding meet tot stand kunnen brengen met mijn IPv6 host inclusief de guests. Elke server staat wel los op zich, hiermee bedoel ik, als ik de host niet meer kan pingen over IPv6, en ik ping hem over IPv4, dan werkt IPv6 ping plots weer even (wat ook heel vreemd is...), maar dan werken de guests nog altijd niet. Als ik dan 1 guest ping over zijn IPv4 adres, dan kan ik die bepaalde guest ook weer voor een tijdje pingen op zijn IPv6 adres.

Ik snap er echt niets meer van, maar het lijkt toch iets met de host bridge instellingen. Aangezien ik wel perfect andere LAN apparaten kan pingen op hun IPv6 adres zonder problemen. Enkel die server geeft problemen, maar ik weet niet waarom.

[CyBeR]

Heb je netwerkapparatuur die IGMP snooping ondersteunt? Zo ja, zet dat eens uit?

[Qlii256]

Ik heb snooping uit op de bridges van de host alsook op de Wi-Fi AP. Waar zou ik dat nog kunnen uit zetten?

[ Voor 5% gewijzigd door Qlii256 op 26-11-2016 19:54 ]

[CyBeR]

Switch?

[Qlii256]

Ik heb geen switch tussen de AP en de host. De host zit op de switch van de AP (router die in AP modus staat). Maar ik denk niet dat er een optie is om IGMP snooping uit te zetten op de switch van doe router.

Kan je me ook verduidelijken waarom IGMP snooping voor problemen kan zorgen?

[CyBeR]

IGMP snooping is er om een andere feature te enablen: multicast filtering. Het idee is namelijk dat, aangezien multicast op ethernet hetzelfde behandeld wordt als broadcast, het een goed idee is on dat te beperken. IGMP geeft je die optie omdat je weet welke hosts een multicast stream opgevraagd hebben.

De reden dat het problemen geeft met IPv6, is dat ND ook met multicast werkt (itt IPv4 ARP) en dat sommige implementaties van IGMP snooping daar geen rekening mee houden.

De symptomen die jij ziet komen exact overeen met dit probleem.

[Qlii256]

Bedankt voor de verduidelijking! Dus er is ergens iets wat aan IGMP snooping doet die ervoor zorgt dan IPv6 breekt. Aangezien het enkel op Wi-Fi connected apparaten gebeurt lijkt het dus dat het aan de AP's ligt. Ook even vermelden dat ik 2 AP's in huis heb, en beide zijn een AC-66U router van Asus die in AP modus staan. Het probleem doet zich voor op beide AP's, wat opmerkelijk is dat ze ook exact hetzelfde model zijn. Maar IGMP snooping staat gewoon uit op de Wi-Fi interface op de router (op de 2.4 GHz en de 5 GHz band).

Ik weet dus niet waar het nog aan kan liggen. Het lijkt erop dat het verkeer tot aan de server komt (dus neighbor solicitation), en daarna er niets meer terugkomt op de router, terwijl de server wel degelijk een response stuurt. Hier nog even een schets van hoe de set-up in elkaar zit:


MODEM
.....l_PFSENSE ROUTER
..........l_ AC66U (AP MODE)
...............l_ AC66u (AP MODE)
....................l_MACBOOKPRO (wi-fi)
...............l_HOST
....................l_BRIDGE DEVICE
.........................l_GUEST1
.........................l_GUEST2
.........................l_GUEST3

Je merkt vast op de de 2de AC66u aan de 1ste AC66u zit. Dit is omdat AP1 aan de router hangt, en dien als switch (de router is een PFSENSE machina met 1 enkele ethernet-poort. De server zit ook met kabel op die AP1. Macbook Pro is dan draadloos verbonden met een van de twee AP's, en kan geen ND doen met de host. Andere IPv6 apparaten blijven wel werken, hierdoor lijkt het dus een probleem met de host zelf en de AP's. Want als het 100 % een switch/AP zou zijn, waarom dan niet met bv. mijn Windows pc? Die kan ik gewoon blijven pingen vanaf de Macbook Pro.

[ Voor 9% gewijzigd door Qlii256 op 27-11-2016 08:21 ]

[Qlii256]

Neg even wat geprobeerd. Ik heb de guests uit alsook de bridge. Ik maak nu gebruik van de host met gewoon een static IPv6 configuratie op de host. Maar ook hier werkt ND niet. Daarna heb ik getest met autoconfig (SLAAC) op de host, om te kijken of het probleem aan static IPv6 ligt, maar ook hier problemen. Via bekabelde verbindingen kan ik wel gewoon pingen op die host. Wel vreemd dat het enkel met die host (server) lijkt te zijn, ik kan dus gewoon wel mijn desktop pc pingen over z'n IPv6 adres.

Iemand nog ideeën wat het probleem kan zijn?

[Brahiewahiewa]

tijd voor wireshark

[Qlii256]

Brahiewahiewa schreef op zondag 27 november 2016 @ 22:43:
tijd voor wireshark

Draai ik deze dan op de Macbook Pro, de server of beide?

[Brahiewahiewa]

op beide; je wilt weten of de pakketjes verstuurd worden en of ze ontvangen worden

[Qlii256]

Brahiewahiewa schreef op zondag 27 november 2016 @ 22:47:
op beide; je wilt weten of de pakketjes verstuurd worden en of ze ontvangen worden

Wireshark installeren op MacOS lukte niet, krijg telkens een fout dat de installatie mislukt is zonder verdere uitleg waarom. Ik draai de laatste versie van MacOS, dus geen idee of dat werkt... .

[Qlii256]

Wireshark op Macbook Pro werkt inmiddels, ik had last van deze bug: https://ask.wireshark.org...tallation-issue-in-sierra.

Ik merk wel op dat er geen linux variant is van Wireshark, dus ik kan deze niet draaien op de server. Ik kan nu wel kijken wat er exact gebeurt, maar veel meer informatie dan tcpdump icmp6 krijg ik hier ook niet mee. Ik merk dus op dat de Macbook Pro een Neighbor Solicitation stuurt naar de desbetreffende server via z'n multicast adres (ff02::1....). Hiervan komt dan een Neighbor Advertisement terug, van het echte IPv6 adres van die server (dus niet het multicast adres, geen idee of dit normaal is? Hierna zie ik een echo ping request, en meteen daarna een echo ping reply.

Maar na enige tijd werkt dit niet meer (dus de neighbor vervalt (expired) en moet dus vernieuwd worden), de neighbor solicitation wordt verstuurd, maar ik krijg nooit een advertisement terug. Terwijl de server wel degelijk een advertisement blijkt te sturen (kan ik zien via tcpdump icmp6). Dus het zou mogelijk de AP zijn die hier wat verkeer begint te filteren. Maar waarom, heb hier totaal geen idee van. Super vreemd dat het ook enkel met die server lijkt te zijn, mijn Windows pc kan ik blijven pingen zonder enige problemen vanaf een wireless toestel.

[CyBeR]

Qlii256 schreef op zaterdag 3 december 2016 @ 17:08:
Ik merk wel op dat er geen linux variant is van Wireshark

Ten eerste: dat is er natuurlijk wel. Ten tweede: wireshark is gewoon een uitgebreidere versie van tcpdump.

[Qlii256]

CyBeR schreef op zaterdag 3 december 2016 @ 17:27:
[...]


Ten eerste: dat is er natuurlijk wel. Ten tweede: wireshark is gewoon een uitgebreidere versie van tcpdump.

Ahzo, op hun officiële website kon ik niet meteen een linux variant vinden. Maar wat zou ik dan meer moeten zien dan met tcpdump? Ik merk gewoon op dat er dus wel een advertisement gestuurd wordt op de server, maar niet aan komt op de Macbook Pro. Dus hiermee weet ik niets meer, dit wist ik al. Ik zou exact moeten weten waar het probleem zit. Ik zou even kunnen inloggen op de router (in AP modus) via ssh en kijken wat ik daar zie in tcpdump. Maar ik had dit al eens geprobeerd en op de router kwam toen ook niets aan. Geen idee of dit normaal is? Of het is de server die iets niet goed doen ofzo...

[CyBeR]

Wireshark zit in zo ongeveer elke distributie package manager. Maar om te zien of bepaald verkeer aan komt is tcpdump voldoende: 'tcpdump -nvvi eth0 ip6'

[Qlii256]

Dat is zo ongeveer het commando wat ik uitvoer op mijn server. Ik heb nu net weer het probleem, en ik zie dit op de server: [IPv6 server] > [IPv6 Macbook Pro] [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is [IPv6 server, Flags [solicited, override]
destination link-address option (2), lenght 8 (1): 00:1d:60:ac:54:04
0x0000; 001d 60ac 5404

Dus, er wordt gewoon een advertisement gestuurd, maar Wireshark toont niets van advertisements aan op de Macbook Pro. Het probleem moet wel ergens bij de AP liggen, want het is enkel met wireless devices...

UPDATE:

Even een update! Ik merk op dat de router (AP) wel degelijk de neighbor solicitation die van de Macbook Pro komt ziet in de tcpdump! Dit betekend dus dat het vrijwel zeker is (?) dat de server hier in fout is, aangezien hij een advertisement terug stuurt maar deze zelfs op de AP niet aan komt, wat wel vreemd is. Ook vreemd dat het eerst wel een tijdje lijkt te werken, iemand nog een idee wat dit kan zijn? Dus de server lijkt problemen te hebben met het versturen van de neighbor advertisement naar wireless clients.

UPDATE2:

Ik zit net nog te denken, kan het niet zo zijn dat de neighbor advertisement niet gestuurd kan worden omdat de server de Macbook Pro niet kan pingen? Want dit kan 'ie dus ook niet. Ik merk op dat de server dus ook een neighbor solicitation stuurt naar de Macbook Pro via z'n link-local adres, maar op de Macbook Pro komen deze ook niet toe, en ook niet op de router, daar zie ik zelfs de solicitation niet. Dus volgens mij zit het zo:

De Macbook Pro stuurt neighbor solicitation naar server, server respond met een neighbor advertisement. Hij moet zelf nog een neighbor opzetten met die Macbook Pro, dus stuurt eerst een neighbor solicitation naar de Macbook Pro, die blijkbaar niet aan komt. Hierdoor kan hij geen verbinding tot stand brengen met de Macbook Pro, wat dus tot gevolg geeft dat de Macbook nooit de advertisement terug krijgt... Maar waarom is mij nog steeds een vraag.

[ Voor 59% gewijzigd door Qlii256 op 03-12-2016 19:25 ]

[Qlii256]

Ik ga op doe server eens een live ubuntu USB draaien en kijken of deze ook het probleem geeft. Iemand anders nog ideeën die ik kan proberen?

[Qlii256]

De live usb van Ubuntu 16.04.1 Desktop gaf geen problemen. Ik kon die gewoon blijven pingen vanaf eender welk Wi-Fi connected device. Ik herstart de server opnieuw, maar ditmaal terug van de disk (dus niet via de live usb) en opnieuw na enige tijd niet pingen is de ND stuk.

Ik snap het echt niet. Hoe kan het zijn dat de server enkel Wi-Fi devices uitsluit (dus niet kan verbinden), maar de live usb het wel nog deed? Ik heb ook reeds een upgrade gedaan van Ubuntu 16.04 LTS naar 16.10, maar dat mag ook niet baten.

Ik ben zo wat ten einde raad. Een compleet nieuwe installatie doen zie ik niet meteen zitten, want ik ben niet 100 % zeker dat dit het probleem zal oplossen (ja, de live usb deed het wel, maar ik moet dit toch nog eens beter gaan testen, verder was het netwerk daar via de Network-Manager in Unity ingesteld en niet via de interfaces file (/etc/network/interfaces)) en er staat ook een hoop data die ik dan weer moet zien te behouden (maar dit moet overigens niet zo lastig zijn, aangezien het OS op een aparte disk staat los van de data, die in een ZFS pool zit. Deze kan ik dus bij een reinstall netjes terug importen lijkt me).

Iemand nog ideeën wat hier fout kan gaan? Ik zie dus wel duidelijk dat de server gewoon een response stuurt op de Neighbor Solicitation, maar waarom komt die nergens aan? Het lijkt wel alsof iets het tegen houd. Een wired device werkt wel gewoon zonder problemen. Dan is er ook nog een feit dat als ik de server ping op zijn lokaal IPv4 adres het plots weer even werkt.

[Out.of.Control]

Ik heb een tijdje geleden een enigszins vergelijkbaar probleem gehad. IPv6 werkte bedraad prima, maar via wifi niet of niet helemaal lekker. De details weet ik niet meer, maar één van de oorzaken weet ik nog wel.
De router advertisements worden als multicast verstuurd en het acces point dat ik destijds gebruikt (een TP-link TL-WA801ND) filterde een deel van het multi-cast verkeer (of alle?) eruit. Ik kon zien dat als de router een RA verstuurde, dat deze wel aankwam op een computer die bedraad was aangesloten, maar niet op een laptop via wifi.

Nadat ik deze vervangen had door een access point met IPv6 ondersteuning werkte het prima. Mijn vermoeden is dat veel sommige access points (zeker als ze alleen IPv4 ondersteunen) alle mulitcast verkeer blokkeren, waardoor IPv6 niet goed werkt.

Misschien kun je ergens een access point lenen dat wel goed werkt met IPv6 om te kijken of het probleem bij jou oplost. Ik heb goede ervaringen met een Linksys LAPN600 en Zyxel NWA-1123AC.

[ Voor 0% gewijzigd door Out.of.Control op 18-12-2016 22:39 . Reden: typo ]

[Qlii256]

Bedankt mauricej voor je tip! Maar beide AP's zijn IPv6 compatibel en hebben IGMP Snooping uitgeschakeld op Wi-Fi. Ik maak gebruik van twee Asus AC-66U routers.

[Qlii256]

Ik ben nu bezig met testen met een compleet nieuwe cleane installatie van Ubuntu 16.10. Ik heb nu enkel de netwerkinstellingen aangepast zodat die overeen komen met wat ik voordien had (maar geen bridge en dus ook (nog) geen guests op dit moment). Als het probleem hiermee opgelost is zou ik zeer blij zijn, maar ik vrees er voor...

EDIT: En ja hoor, zelfs met nieuwe install werkt het plots niet meer. Ik denk dat ik het OS wel kan uitsluiten als probleemmaker?

[ Voor 16% gewijzigd door Qlii256 op 21-12-2016 20:36 ]

[duronbug]

Misschien IGMP snooping in bridge uitschakelen op de ASUS AP's:

/sys/class/net/br0/bridge/multicast_snooping op 0

[gekkie]

Als je de linux bridging code wilt uitsluiten misschien eens in plaats daar van openvswitch proberen ?

[duronbug]

Het moet iets van een multcast/broadcast blokkade zijn

[Qlii256]

De bridge igmp snooping uitschakelen op de AP's had ik al eens geprobeerd maar dat lukte niet. Verder zou het vreemd zijn mocht de firmware hier dus niet goed werken. Waarom zou deze het plots gaan blokkeren? Ik kan het zo meteen wel even proberen nog, bedankt voor de tip!

OpenvSwitch zou ik eens moeten naar kijken, bedoel je dan installeren als OS op de server i.p.v. Ubuntu?

EDIT: Ook nog ever vermelden dat het niet meer kunnen pingen van net op de nieuwe Ubuntu installatie een foutje was van mij. Blijkbaar was gans die server vast gelopen omdat de videokaart het plots niet meer lijkt te doen (niet zo erg, ik gebruikte eigenlijk toch de onboard, maar had voor een andere test even een kaart erin ). Dom van me dat ik ook niet eens het IPv4 adres geprobeerd heb, maar het keyboard deed niets meer en beeld stond gewoon stil (dus ook niet de blinking cursor). Dus lijkt me dat dit even hier aan lag. Ik ben nu opnieuw aan het testen en laat weten of ik opnieuw dit probleem krijg.

[ Voor 44% gewijzigd door Qlii256 op 21-12-2016 20:53 ]

[Qlii256]

duronbug schreef op woensdag 21 december 2016 @ 20:40:
Misschien IGMP snooping in bridge uitschakelen op de ASUS AP's:

/sys/class/net/br0/bridge/multicast_snooping op 0

Ik geraak enkel tot /sys/class/net/br0/bridge/, maar de multicast_snooping optie is nergens te vinden...

Ik heb nu ook het probleem met de nieuwe installatie van Ubuntu. Ik zie dat de server gewoon een reply stuurt naar de Macbook Pro, maar ik ontvang niets. Ik kan dus ook vanop de server de Macbook niet meer pingen, en dit is namelijk het probleem. Op de AP zelf zie ik de solicitation die de Macbook stuurt, maar de advertisement staat hier nergens. Ik neem dus aan dat de server het gewoon niet verstuurd, maar waarom is mij een raadsel...

Verder kan ik nu ook gewoon met een andere laptop (Windows 10) over Wi-Fi de server pingen, terwijl het op de Macbook Pro niet meer lukt. Even kijken of het op deze laptop dan ook plots stopt met werken. Het lijkt toch echt een probleem op de server, waar hij de andere devices niet meer kan bereiken. Maar waarom enkel Wi-Fi connected devices blijft me een raadsel.

[ Voor 59% gewijzigd door Qlii256 op 21-12-2016 21:56 ]

[gekkie]

Qlii256 schreef op woensdag 21 december 2016 @ 20:51:
OpenvSwitch zou ik eens moeten naar kijken, bedoel je dan installeren als OS op de server i.p.v. Ubuntu?

Nee, openvswitch is een package (+ kernel modules) zou dus gewoon in je huidige Ubuntu setup kunnen werken.

[Qlii256]

gekkie schreef op woensdag 21 december 2016 @ 21:56:
[...]

Nee, openvswitch is een package (+ kernel modules) zou dus gewoon in je huidige Ubuntu setup kunnen werken.

Ok bedankt!

Ik merk net wat op. De Windows laptop kan ook plots niet meer pingen naar de server, maar wat mij opvalt is dat als ik de eerste keer de ping probeer die faalt, dat de server zelf een solicitation stuurt naar de laptop, maar via het link-local adres van de laptop. Dit blijkt niet te werken? Ik denk dat het hier dus fout gaat. Om een of andere reden wil de server een solicitation sturen naar het link-local adres van de laptop, maar dit werkt niet en komt nooit aan. Verder heb ik wel vaak multicast regels op de PFSENSE firewall die geblokkeerd zijn. Het is dan voornamelijk [ff02::c]:1900 UDP, maar dit is volgens mij UPNP (wat ook niet echt lijkt te werken op veel computers). Ik denk dat sommige applicaties gebruik willen maken van UPNP via het IPv6 adres, maar dit lijkt de firewall te blokkeren. Iemand enig idee hoe ik dit ook even kan oplossen? IK heb namelijk wel gewoon LAN NET alle toegang op de LAN adapter van de firewall, maar blijkbaar zit multicast over IPv6 hier niet bij.

EDIT:

Nu wordt ik helemaal gek! Ik ping het link-local adres van de server zelf op de server zelf, dus gewoon z'n eigen en dat werkt. En meteen werkt pingen weer op beide laptops. Wat is hier in hemelsnaam mis? Super vreemd. Lijkt wel of link-local stopt met werken om een of andere reden? Maar ook niet op het zelfde moment. Dus het werkt bv niet meer op laptop 1, maar wel nog even op laptop 2. Zit er ook een soort ND op link-local adressen?

[ Voor 14% gewijzigd door Qlii256 op 21-12-2016 22:10 ]

[duronbug]

Wat je ook nog kan proberen is de Asus Routers in Router mode zetten. Dan DHCP en evt andere services uitschakelen, zodat het eigenlijk gewoon een AP is. Onder de motorkap schakelt de router een heleboel zaken uit als je hem omschakelt naar AP mode.

[Qlii256]

duronbug schreef op woensdag 21 december 2016 @ 22:47:
Wat je ook nog kan proberen is de Asus Routers in Router mode zetten. Dan DHCP en evt andere services uitschakelen, zodat het eigenlijk gewoon een AP is. Onder de motorkap schakelt de router een heleboel zaken uit als je hem omschakelt naar AP mode.

Dit is zeker een goede tip! Zal ik morgen eens proberen dan. Jammer dat ik geen extra AP heb waarmee ik zou kunnen testen helaas.

[Aconitum]

IGMP snooping is voor ipv4 ! kijk eens naar MLD snooping dit is namelijk voor ipv6

[Qlii256]

Ow, en hoe zou ik dat moeten uitschakelen?

[ Voor 4% gewijzigd door Qlii256 op 22-12-2016 18:02 ]

[Qlii256]

Ik heb van iemand een andere AP kunnen lenen, namelijk een super oude Apple AirPort Express met enkel b/g WiFi support. Ik kon de server niet meer pingen, ik verbind met die andere AP (de AirPort) en het werkt meteen weer. Maar goed, dit kon toeval zijn. Nu zo'n 4u later werkt het nog steeds! Ik switch terug naar de Asus AP en ja hoor, meteen weer niet te pingen. Dus het ligt nu bijna 100 % zeker aan de AP's!

Ik ben super blij dat ik dit nu weet! Ik ga nu even proberen als de router in normale router mode staat met DHCP en andere functies die ik niet nodig heb uit.

EDIT:

Dit werkt dus niet, na enige tijd (30 min.) kan ik plots een voor een de servers niet meer bereiken over hun IPv6 adres. De andere AP blijft gewoon werken. Ik ping de server op z'n IPv4 adres en meteen werkt het weer. Ik snap echt niet wat hier mis gaat. Waarom is er plots geen verkeer meer mogelijk over IPv6 voor wifi devices en waarom start het plots terug even met werken als ik de server op IPv4 ping?

[ Voor 26% gewijzigd door Qlii256 op 25-12-2016 19:56 ]

[Qlii256]

Niemand die mij verder kan helpen? Ik zit op tal van fora en nergens lijkt iemand te reageren. Ik weet totaal niet hoe ik MLD zou kunnen uitschakelen op de router of de server. Ik vind het nog altijd super vreemd dat het enkel de server is die met problemen zit. De PFSENSE machine heeft geen problemen en ik kan blijven pingen naar zijn IPv6 adres, alsook de Windows computers. Maar waarom werkt het dan wel met een andere AP?

[Qlii256]

Ik heb net nog even geprobeerd met een andere netwerkkaart (via PCI) maar ook dit helpt niet. Wel vreemd dat het ook compleet verschillend is wanneer de servers stoppen met werken. Ik kon bv. nog perfect de host pingen en 1 van de vm's, terwijl een andere vm al niet meer bereikbaar was.

Dit is zo goed als zeker een issue met de AP's die ik gebruik (was ook bevestigd door het testen met een andere AP), maar ik wil deze dure en ik verwacht tot degelijke Asus AC66U apparaten niet zomaar gaan vervangen. Dit moet toch te fixen zijn? Ik heb al tal van posts aangemaakt op het Merlin-WRT forum, maar daar krijg ik gewoon 0 reacties. Lijkt wel of niemand me daar wil helpen. Andere firmware zoals stock Asus-WRT helpen ook niet.

Iemand een idee hoe ik de MLD functionaliteit uit zou kunnen zetten om te testen of dit helpt?

[Qlii256]

Ik geef het op, ik kan nergens een gelijkaardig probleem vinden en niemand lijkt mij te kunnen/willen helpen. Ik snap er gewoon niets meer van. Op 4 fora zit ik tegelijk met dit probleem en nergens krijg ik nog reacties... .

Zelf op het AsusWRT forum krijg ik 0 reacties, en daar zou toch echt iemand moeten zitten die er wat meer van kent dan ik? Maar het is zoals al vaak gezegd, IPv6 is totaal niet klaar voor een release omdat elke implementatie verschilt van wat eigenlijk de vastgelegde standaard is... Ik ben wel voor IPv6 maar het gaat zo veel sneller stuk dan IPv4 net omdat het van zoveel functies (ICMPv6) afhankelijk is.

Ik hoop alsnog dat iemand mij verder kan helpen, maar ik geef voorlopig de zoektocht op. Ik heb ook al geprobeerd of het uitmaakt of ik op de 2.4 of de 5 GHz band zit, maar hier lijkt geen verschil te zitten.

[gekkie]

Komt denk ik omdat men het overzicht onderhand een beetje kwijt is.
(je lijkt van alles dwars door elkaar te testen en het een lijkt wel te werken .. het andere niet .. of toch weer wel).

[Qlii256]

Ja, sorry voor de verwarring en de vele posts, ik heb een duidelijker overzicht op een ander forum staan (wel in het engels). Ik weet niet of het mag dat ik de inhoud daarvan in het Engels hieronder even plak of doe ik dat beter in het Nederlands en misschien best ook in de TS i.p.v. hier?

[Joshuax8]

Als je de Merlin firmware gebruikt, kan je misschien checken of onder "Tools" > "Other settings" > "Advanced Tweaks and Hacks" de setting "Firewall: Drop IPv6 neighbour solicitation broadcasts (default: No)" nog op "No" staat. Is waarschijnlijk wel het geval aangezien dat default is, maar wie weet..

[Qlii256]

Ja die setting staat op "No" en zou verder weinig met mijn probleem te maken mogen hebben. Ik heb dit probleem tevens ook met de stock AsusWRT firmware... .

Ik heb vandaag een antwoord gekregen op het AsusWRT forum waar ook MerlinWRT besproken wordt. Iemand heeft exact hetzelfde probleem (al krijg ik niet veel uitleg) en wijt het aan de firmware van Asus. Ik was ook bijna 100 % zeker dat het aan de firmware ligt, aangezien ieder andere AP die ik getest heb gewoon werkt. Toch wel stom dat dit op zo'n dure en verder degelijke router gewoon voor komt. Niet echt wat over te vinden overigens, dus het is een probleem wat nog niet zo bekend is. Dit is volgens mij mede doordat niet veel mensen lokaal IPv6 adressen gaan gebruiken, maar meestal nog de alzo bekende IPv4 adressen, wat tevens ook in veel gevallen makkelijker te onthouden adressen zijn.

Zou ik ergens een bug report kunnen aanmaken voor Asus en zou dit wat uitmaken denk je?

[Joshuax8]

Ik denk dat je het meeste kans maakt als je RMerlin probeert te benaderen op het SNB forum.. (http://www.snbforums.com/forums/asuswrt-merlin.42/) en je probleem zo goed mogelijk probeert uit te leggen. Hij heeft ook contact met de developers bij Asus geloof ik.

[Qlii256]

Daar heb ik reeds een topic aangemaakt zonder reacties. Zou ik een PM proberen sturen naar merlin zelf op dat forum?

EDIT: Ik heb nu een conversation (PM/DM) verstuurd naar RMerlin op dat forum en hoop spoedig een antwoord van hem te ontvangen. Ik kan alleen maar hopen dat RMerlin de tijd en zin heeft mij verder te helpen. Ik houd jullie verder op de hoogte als er updates zijn omtrent dit probleem.

[ Voor 55% gewijzigd door Qlii256 op 06-01-2017 18:16 ]

[Qlii256]

Dit probleem is nog steeds niet opgelost. Iemand die me nog eens kan helpen? Did kort gezegd de Asus AC66U stopt plots met het forwarden van IPv6 Neighbour Advertisements over Wi-Fi. Het is afzonderlijk per device en per IPv6.

Voorbeeld: pc1 pingt pc3 over IPv6 en dit werkt. Na enige tijd stopt dit met werken, de Neighbour Advertisement van pc3 naar pc1 komt nooit aan. Pc2 pingt pc3 op datzelfde adres en dit werkt zonder problemen. Pc1 kan nog altijd niet pingen. Pc2 stopt na enige tijd ook, zelfde probleem. Pc1 pingt pc3 over IPv4, IPv6 Neighbour Discovery werkt terug tussen pc1 en pc3, voor een tijdje tot het zich opnieuw herhaalt.

Even vermelden nog dat beide pc1 en pc2 verbonden zijn over Wi-Fi op de Asus AP. Pc3 is verbonden via kabel.

[CyBeR]

Als je met de bovenstaande tips geen voortgang maakt, dan is 't apparaat gewoon buggy. Dan kun je 't ding beter vervangen dan door blijven kutten imo. Er is geen technische reden dat IPv6 niet over wifi zou werken namelijk; dat ligt aan je Asus ding.

[Qlii256]

CyBeR schreef op dinsdag 20 februari 2018 @ 23:07:
Als je met de bovenstaande tips geen voortgang maakt, dan is 't apparaat gewoon buggy. Dan kun je 't ding beter vervangen dan door blijven kutten imo. Er is geen technische reden dat IPv6 niet over wifi zou werken namelijk; dat ligt aan je Asus ding.

Daar ben ik het mee eens, maar niemand anders lijkt hier problemen mee te hebben. Ik denk dat dit vooral komt omdat als je als lokaal wil verbinden de meesten dit via IPv4 doen.

[Kabouterplop01]

Hoe groot zijn die pakketjes?

[Qlii256]

Kabouterplop01 schreef op vrijdag 23 februari 2018 @ 00:12:
Hoe groot zijn die pakketjes?

Heb je het hier over de "size" van de NA packet?

Ik merk ook op dat de server op desbetreffende interface network drops geeft. Geen idee of dit er mee te maken heeft en ik heb ook nooit kunnen achterhalen wat het probleem is. Nieuwe kabel, instellingen aangepast etc maar niets lijkt te helpen en verder lijkt het internet het goed te doen op die interface. Maar wat wel vreemd is dat ik nu plots periodes krijg waar er geen drops meer zijn. De drops op zich herhalen zich telkens in een vast aantal. Er lijkt een patroon in te zitten. Maar die drops zijn er dus ook als ik niet met mijn laptop de server probeer te bereiken. Ik heb geen idee of dit gerelateerd is? De drops merk ik op via een munin-node die ik heb draaien op die server en die kan je hier zien: http://melody.rubenportie...rtier/if_err_enp0s25.html

[ Voor 66% gewijzigd door Qlii256 op 23-02-2018 19:43 ]

[Kabouterplop01]

Ja ik heb het over de size van de packets.
MTU wise.... Troubleshooting van laag 1 t/m 7(onderaan beginnen)
link=OK
mac-adressen=OK
IPv4=OK
IPv6 daar zit het hem.
Dan moeten we beginnen met je conf.
ip adressen.

Wat me opviel uit je uitleg is dat de neighbor disc. ineens over v4 wordt gedaan.
Heb je dit al eens native v6 draaiend gehad, zonder v4?

Overigens die drops zou je moeten kunnen zien met iets van IPtables met een debug filter, (permit everything and log) of met draadhaai/tcpdump.

[Qlii256]

Even gerelateert naar de drops. Een tcpdump -i <interface> waarop ik de drops krijg geeft een nonstop spam van dit bericht:

IP6 public-ipv6-adres-macbook.49405 > public-ipv6-adres-server.45914: Flags [.], ack 46553, win 4087, options [nop,nop,TS val 916031958 ecr 3651532831], length 0

Allemaal length 0. Let wel dat dit misschien te maken heeft met de huidige ssh verbinding waarmee ik de tcpdump vanaf mijn macbook kan aflezen. Toch vreemd dat er een lengte van 0 is, niet? Dit is ook niet tijdens het aanmaken van ND want ik heb de laptop verbonden over kabel ipv wifi.

Ook even vermelden dat in de 1 minuut ik tcpdump aan had ik dit resultaat krijg:
119623 packets captured
119717 packets received by filter
93 packets dropped by kernel

Ik wil dus weten waarom deze packets gedropped zijn en welke.

EDIT: Na wat opzoekwerk blijkt dus dat tcpdump packets dropped als z'n eigen buffer vol is, ik gebruik nu de optie -B 4096 en krijg die dropped by kernel niet meer.

[ Voor 26% gewijzigd door Qlii256 op 28-02-2018 17:43 ]