IPv6 OnePlus 8 Pro CV8560E (E-router)

[Ex-Netweter]

Mijn setup:

CV8560E | e-router, mac bridging => Archer C3150 v2 | TP-Link router => TL-SG2008P 1.0 | TP-Link switch, vlan id 2 => Asus Aimesh

Na de uitrol van de nieuwe e-router firmware op maandag 15 februari is mijn OnePlus 8 Pro het enige toestel dat IPv6 problemen ervaart. (IPv6 op o.a. onze iPhone, Samsung S9, MacBook Air en Asus laptop werkt prima.)

Zodra mijn OnePlus verbinding maakt met het wifi netwerk is er aanvankelijk sprake van IPv6 connectiviteit. Zowel de verschillende IPv6 testsites als de app Network Analyzer Pro bevestigen dit.

Deze IPv6 connectiviteit op mijn OnePlus is echter van korte duur. Na een aantal minuten valt ze steeds weg.

Zie volgende screenshots die ik heb genomen van de app Network Analyzer Pro. Hetgeen me wel opvalt is dat wanneer mijn Oneplus IPv6 connectiviteit heeft, er bij "DNS Server IPv6" N/A te lezen valt.

Enig idee?

PS Toen ik gebruik maakte van de modem only had ik dit probleem niet.

[Steven-E]

Haha, goed om

horen!

Ja, laat IGMP snooping maar op beide toestellen aanstaan. Multicasts zijn essentieel voor een goede werking van IPv6.

”IGMP snooping is the process of listening to Internet Group Management Protocol (IGMP) network traffic to control delivery of IP multicasts. Network switches with IGMP snooping listen in on the IGMP conversation between hosts and routers and maintain a map of which links need which IP multicast transmission. Multicasts may be filtered from the links which do not need them, conserving bandwidth on those links.”

Een AP is achterliggend ook een network switch. Een router ook.

---

@Ex-Netweter  schreef:

Toch nog een derde vraag:

Nog steeds verschijnt er op mijn OnePlus 8 Pro in de app Network Analyzer Pro bij DNS Server IPv6 N/A. Maakt dat uit?

---

Wat zegt een test naar https://test-ipv6.com ?

Als die 10/10 geeft is het ok, en dan vermoed ik dat die waarde op je OP naar een DHCP value refereert. Maar dit is bij jou niet in gebruik.

RDNSS staat toch nog altijd aangevinkt he op je TP-Link?

[Arnie]

Gelukkig dat alles nu goed werkt.

Het "probleem" hier lijkt te zijn dat je Access-Point eigenlijk een router is, met allerlei extra features. Dit kon zou zijn voordelen, maar ook nadelen hebben (je netwerk wordt complexer).

[Steven-E]

---

@Arnie  schreef:

Het "probleem" hier lijkt te zijn dat je Access-Point eigenlijk een router is, met allerlei extra features. Dit kon zou zijn voordelen, maar ook nadelen hebben (je netwerk wordt complexer).

---

IGMP Snooping is ook iets wat ik op mijn wired switches kan aanzetten hoor.

Dit zijn layer-2 switches, weliswaar managed, maar zonder routerfunctionaliteit.

https://networklessons.com/cisco/ccie-routing-switching/igmp-snooping-without-router

https://routerguide.net/enable-igmp-snooping-on-or-off/

Wat me nog niet duidelijk is: wat als je IGMP snooping afzet?  Dan zou het ook moeten werken omdat de multicasts over alle poorten worden uitgestuurd, alsof het een broadcast was.
Maar misschien ziet die Asus het anders, en dropt hij de multicast pakketten gewoon.

EDIT: dit is interessant:

"However I found out that Wireless Clients do not reliably get RAs sent to the IPv6 Multicast Address (while clients on cable Ethernet got everything as they should). This is explained in more detail here: https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example#Multicast_and_Wireless

Configuring my Mikrotik WLAN AP with "multicast-helper=full" solved the issue. I don't know about your setup but it might be worth to investigate."

Dit komt van https://forums.oneplus.com/threads/hosts-within-local-ipv6-subnet-are-unreachable-from-phone.1168754...

En op die Microtik Wiki staat

"Multicast and Wireless

Multicast (and broadcast) over wireless works over wireless depending on who is transmitting multicast packet:

If AP transmits multicast packet, packet is transmitted over air with multicast receiver address (and yes - only single copy of packet is transmitted no matter how many clients are registered). As there is no single recipient of packet, it does not get acked - therefore delivery is not reliable (no retransmissions in case somebody does not receive packet). Due to this unreliable delivery, lowest basic rate is used to ensure as reliable delivery as possible. So even if you can send unicast stream between AP and Station using 54Mpbs air rate, multicasts are sent only using 6Mbps air rate (assuming that 6Mbps is lowest basic rate).

If Station transmits multicast packet, it is transmitted over air with unicast AP receiver address (as Stations always transmit all packets to AP, and always using unicast receiver address). Due to this, delivery of multicast packets from Station to AP is reliable and subject to normal rate selection process - max throughput can be used. What complicates the matter - when AP receives multicast packet from Station, it processes it locally, but it also must send it back over the air so that the rest of stations in wireless network see it (think of AP as switch in ethernet, except that is does not have to send multiple copies of packet for all clients to receive). This causes AP to execute multicast transmission procedure as described above, therefore every multicast packet gets transmitted over air twice - first time by Station (using its transmit rate) and second time - by AP using lowest basic rate. This behaviour can be altered by disabling "forwarding" option for particular Station on AP (or for all clients using "default-forwarding" option) - disabling forwarding causes AP not to forward traffic between clients and also disables "sending back" multicasts and broadcasts received from client, because that can be considered special case of forwarding traffic between clients."

Mijn aanname is dat je met IGMP snooping er voor zorgt dat de pakketjes vanaf de client naar de AP, niet onnodig opnieuw worden teruggestuurd vanaf de AP naar de client. Dit zou anders problemen geven met de RA's (route advertisements).

Maar dit is een aanname, ben absoluut niet zeker.

Enfin @Ex-Netweter don't touch it now 😉

[NofanTasi]

---

@Ex-Netweter  schreef:

Opgelost!

Oplossing ... op het moederschip van mijn Asus Aimesh (rt-ac88u) IGMP Snooping voor beide bands enablen.

[...]

2.

Waarom heeft enkel mijn OnePlus 8 Pro net dat ene duwtje in de rug nodig?

---

Goede vraag.

Ik zou je willen vragen. Je zei dat er met modem-only geen dergelijk probleem was. Had je toen het modem-only werkte reeds exact dezelfde Asus Aimesh setup? Mijn commentaar was daar intrinsiek op gebaseerd, maar, indien onterecht, want niet het geval, dan moet ik hier graag mijn excuses aanbieden 😅. Ook: precies wanneer is het probleem begonnen? Ik geloof dat je zei: na de upgrade. Maar misschien heb ik ook dat verkeerd gezien. Dan weeral: mijn oprechte excuses.

[NofanTasi]

---

@Steven-E  schreef:

---

Mijn aanname is dat je met IGMP snooping er voor zorgt dat de pakketjes vanaf de client naar de AP, niet onnodig opnieuw worden teruggestuurd vanaf de AP naar de client. Dit zou anders problemen geven met de RA's (route advertisements).

Maar dit is een aanname, ben absoluut niet zeker.

---

De v6 multicast paketten in kwestie (ND, RA, SLAAC etc.) zijn link-local (i.e. enkel bestemd voor dit subnet en worden (mogen) niet naar andere subnets ge-multicast-forwarded worden). Alle hosts (inclusief de, intussen fameuse, 1+8Pro) moeten die krijgen (en er hun plan mee trekken). Zeker als ze naar het all-hosts link-local adres gestuurd zijn. Sommige link-local multicast paketten in kwestie worden naar een ander (nog steeds link-local) adres gestuurd, niet dat van een specifieke host maar wel naar een 'speciaal' adres (zoals die zogenaamde v6 ARP paketten). Maar ook deze moeten alle hosts te zien krijgen. IGMP snooping (IGMP, wat, overigens, MLD heet voor v6) is een protocol waar L2 switches L3 de headers van multicast paketten onderscheppen om ze niet nodeloos uit te sturen over poorten waarachter geen host is die in dat multicast adres geinteresseerd is. Maar, dat gaat om global multicast paketten (i.e. bedoeld om te multicast forwarden naar verdere subnets). De idee is: als niemand op de LAN (zelfs geen PIM multicast forwarding router) achter deze poort geinteresseerd is, waarom dan (CPU intensief, e.g. voor high bitrate video) uitsturen? Nochtans, voor link-local multicast is het net omgekeerd. Elke host moet die multicast paketten zien (als een host liever niet wil zien, dat is de keuze van die host). Misschien bestaat er iets als v6 link-local multicast MLD snooping. Ik heb er nooit van gehoord (en het lijkt me niet eenvoudig). Dus, in het kort: v6 link-local multicast tegen houden is om problemen vragen. En, de oplossing voor @Ex-Netweter (enable snooping) is, op eerste zicht, net om dat te doen: dingen tegen houden (niet uitsturen (of weerkaatsen)). Verder: WiFi access points (i.e. tenminste een "switch" 'poort' is niet wired, maar wireless) weerkaatsen wireless ofwel geen ofwel alle global multicast paketten. Maar, de link-local paketten moeten allen door alle hosts gezien worden. Vandaar: hoe v4 IGMP global multicast snooping iets met v6 MLD link-local multicast snooping te maken heeft is me een klein raadsel. Wellicht is het een misverstand en/of verkeerde terminologie en/of onbegrip (om diplomatisch niet de vinger proberen te wijzen naar mogelijke bugs). Hoe dan ook: snooping aanzetten (i.e. minder paketten uitsturen) lijkt me een eigenaardige 'verbetering'.

[Steven-E]

---

@NofanTasi  schreef:

---

En, de oplossing voor @Ex-Netweter (enable snooping) is, op eerste zicht, net om dat te doen: dingen tegen houden (niet uitsturen (of weerkaatsen)). Verder: WiFi access points (i.e. tenminste een "switch" 'poort' is niet wired, maar wireless) weerkaatsen wireless ofwel geen ofwel alle global multicast paketten. Maar, de link-local paketten moeten allen door alle hosts gezien worden. Vandaar: hoe v4 IGMP global multicast snooping iets met v6 MLD link-local multicast snooping te maken heeft is me een klein raadsel. Wellicht is het een misverstand en/of verkeerde terminologie en/of onbegrip (om diplomatisch niet de vinger proberen te wijzen naar mogelijke bugs). Hoe dan ook: snooping aanzetten (i.e. minder paketten uitsturen) lijkt me een eigenaardige 'verbetering'.

---

Inderdaad. Mijn initiële vraag was ook om na te kijken of er geen multicasts geblokkeerd werden. Niet om IGMP snooping aan te zetten. Dus we zitten nu met een probleem wat opgelost is, maar we weten niet goed waarom 🙂
@Ex-Netweter idd interessant om te weten sinds wanneer je OP het probleem heeft.  Wat het gedrag was met de modem-only en welke wijzigingen je sindsdien nog hebt aangebracht.

[NofanTasi]

---

@NofanTasi  schreef:

---

Verder: WiFi access points (i.e. tenminste een "switch" 'poort' is niet wired, maar wireless) weerkaatsen wireless ofwel geen ofwel alle global multicast paketten. 

---

correctie ... ik bedoelde: wireless is een shared medium en (global multicast) paketten worden ofwel door alle (indien gezonden) ofwel door geen (indien niet gezonden) hosts gezien. Maar link-local multicast paketten zijn bestemd voor alle hosts op het wifi subnet. En er bestaat dan ook niet zo iets als een IGMP/MLD multicast join voor een link-local multicast group.

[NofanTasi]

---

@Arnie  schreef:

[...]

Het "probleem" hier lijkt te zijn dat je Access-Point eigenlijk een router is, met allerlei extra features.

---

Dit soort 'te veel (goed) willen doen' kan inderdaad soms '(meer) kwaad doen' en, in dit geval, misschien de eigenaardigheden in @Ex-Netweter  's v6 setup helpen verklaren. In het algemeen zou een Layer n device zich beter niet moeien (ook niet 'om bestwil') met Layers m>n. Maar in praktijk gebeurt dat, soms onvermijdelijk, wel degelijk. Layer 3 multicast IGMP/MLD snooping op een Layer 2 switch is een (weliswaar Internet RFC standaard) voorbeeld. Ooit had ik overigens een gelijkaardige v4/v6 probleem situatie (1 toestel (een Windows 7 of 8, ik ben het vergeten) kon systematisch na een tijd niet (meer) op het Internet). Ik beschrijf die situatie in appendix, voor de geinteresseerden. Daarom ook stelde ik trouwens de vraag aan @Ex-Netweter  of, wanneer v6 uit valt op de 1+8Pro, v4 wel of niet correct over neemt (zulks gebeurde namelijk niet op de Windows, en, daar was ook een verklaring voor).

appendix

Ooit, vanaf VDSL vectoring geimplementeerd werd, verving ik een (niet vectoring capabele) cisco vdsl router door een b-box3 in modem-only met eigen gemaakte linux gentoo eigen-router er achter. Later, om redenen hieronder gedetailleerd, verving ik de b-box3 door de, ook vectoring capabele fritz!box 7490, maar, die was initieel (nog) niet Proximus geverifieerd (de cisco ook niet maar Proximus begon te dreigen niet geverifieerde aparatuur op hun netwerk te weigeren of te degraderen). Mijn provider was EDPnet en ik had een vast IP abonnement. Ik had de eigen-router of cisco trouwens nodig omdat EDPnet toen geen enkel type modem (ook later de 7490 niet) aanbood waarop zowel v4 als v6 met statisch subnet geconfigureerd kon worden (i.e.: voor mijn abonnement). Alles werkte jaren prima voor al onze devices. Maar...

Eens per jaar kreeg ik een week een vriend uit Hong Kong op bezoek. Die had een Windows laptop en werkte met VPN naar Hong Kong. Die verbinding viel steeds na een tijd (voorgoed) uit. De voorlopige oplossing voor hem was: telkens Windows rebooten. Wij hebben hier geen Windows aparatuur dus had ik elk jaar maar 1 week tijd om het probleem te onderzoeken. Maar, typisch, omdat die vriend hier natuurlijk niet alleen kwam on te werken, spendeerde ik er niet al te veel tijd aan.

Uiteindelijk bleek de b-box3 modem het probleem te zijn, dit gecombineerd met het feit dat ik een poort van de b-box3 met de centrale LAN switch had verbonden (enkel en alleen om de, Layer 1, b-box3 via IP te kunnen managen en monitoren). Wat gebeurde fout? De b-box3 verzond link-layer v6 multicast paketten op de LAN via die management poort. Onder andere om zich zelf als Layer 3 v6 default gateway aan te kondigen. Maar, niets was minder waar, de b-box3 had geen enkele Layer 3 (zelfs geen Layer 2) functie. Bleek dat de Windows laptop de v6 default gateway veranderde naar de b-box3 toe (wat men gemakkelijk kan verifieren). Waarom andere aparatuur zulks niet deed weet ik niet. Misschien is het een Windows 'zwakte'. En v4 nam niet over, want: alles leek nog perfect te werken (toch volgens de Windows: die nam de nieuw aangekondigde weg naar het Internet), alleen: alle v6 (of toch zeker de VPN) werd naar een zwart gat gestuurd. De eenvoudige pragmatische oplossing werd: als mijn vriend op bezoek komt, trek gewoon tijdelijk (1 week) de management poort van de b-box3 naar de centrale switch uit. Dat werkte: QED. Later (nadat de 7490 Proximus geverifieerd was), heb ik de b-box3 door fritz!box 7490 vervangen (ook in modem-only). Deze fritz!box had niet de onhebbelijkheid zich als Layer 1 device tot v6 default gateway te kronen via LAN management poort.

[Arnie]

@NofanTasi, we lijken een beetje hetzelfde profiel te hebben. Ik was vroeger ook EDPnet klant met vast IP, en een Cisco router. Thuis heb ik wel wat ervaring met windows (werk laptop, en ook OS keuze voor vrouw en zoon), maar zelf ben ik linux gebruiker.

Ik ben ook al tegen verschillende vreemde problemen aangelopen in de loop der jaren. Een interessant leer-traject. Daarom ook dat ik hier redelijk aktief ben. Door de problemen van anderen leer ik regelmatig toch weer iets bij.

[Ex-Netweter]

---

@NofanTasi  schreef:

---

@Arnie  schreef:

[...]

Het "probleem" hier lijkt te zijn dat je Access-Point eigenlijk een router is, met allerlei extra features.

---

---

Ja, en dat was ook niet duidelijk in de originele post met de probleemstelling 🤔.

OK, kenners wisten misschien wel dat bij een "Asus Aimesh (AP)" nog een router hoort (RT-AC88U), maar ik zag dat gewoon als een AP.

Zo zie je maar dat het heel belangrijk is bij een probleemstelling, ook de volledige info te geven 😊.

[Ex-Netweter]

---

@Steven-E  schreef:

Wat zegt een test naar https://test-ipv6.com ?

Als die 10/10 geeft is het ok, en dan vermoed ik dat die waarde op je OP naar een DHCP value refereert. Maar dit is bij jou niet in gebruik.

RDNSS staat toch nog altijd aangevinkt he op je TP-Link?

---

RDNSS aangevinkt:

IPv6 OnePlus 10/10 + in app Network Analyzer Pro DNS Server IPv6 "N/A"

RDNSS niet aangevinkt en als IPv6 dns servers die van Cloudflare:

Idem

[Ex-Netweter]

---

@Arnie  schreef:

Gelukkig dat alles nu goed werkt.

Het "probleem" hier lijkt te zijn dat je Access-Point eigenlijk een router is, met allerlei extra features. Dit kon zou zijn voordelen, maar ook nadelen hebben (je netwerk wordt complexer).

---

Als volgt een screenshot van de geavanceerde wifi instellingen in Asus Aimesh:

[Ex-Netweter]

---

@NofanTasi  schreef:

---

---

Ik zou je willen vragen. Je zei dat er met modem-only geen dergelijk probleem was. Had je toen het modem-only werkte reeds exact dezelfde Asus Aimesh setup? Mijn commentaar was daar intrinsiek op gebaseerd, maar, indien onterecht, want niet het geval, dan moet ik hier graag mijn excuses aanbieden 😅. Ook: precies wanneer is het probleem begonnen? Ik geloof dat je zei: na de upgrade. Maar misschien heb ik ook dat verkeerd gezien. Dan weeral: mijn oprechte excuses.

---

Je hoeft je absoluut niet te verontschuldigen, hoor!

Ik kan je bevestigen dat toen ik met een modem only werkte mijn OnePlus zijn IPv6 niet verloor en dat er in de app Network Analyzer Pro bij DNS Server IPv6 geen N/A kwam te staan maar wel degelijk een dns server.

Ook kan ik je bevestigen dat mijn huidige setup dezelfde is als toen ik met een modem only werkte. Uiteraard zijn er onderwijl wel enkele firmware-updates de revue gepasseerd.

Met na de upgrade bedoelde ik de firmware/patch die Telenet op 15/02 heeft uitgerold. Toen kwam ik tot de conclusie dat in tegenstelling tot mijn andere toestellen - waaronder een Samsung S9 - mijn OnePlus IPv6 problemen ervoer.

[Ex-Netweter]

---

@Steven-E  schreef:

---

@NofanTasi  schreef:

---

En, de oplossing voor @Ex-Netweter (enable snooping) is, op eerste zicht, net om dat te doen: dingen tegen houden (niet uitsturen (of weerkaatsen)). Verder: WiFi access points (i.e. tenminste een "switch" 'poort' is niet wired, maar wireless) weerkaatsen wireless ofwel geen ofwel alle global multicast paketten. Maar, de link-local paketten moeten allen door alle hosts gezien worden. Vandaar: hoe v4 IGMP global multicast snooping iets met v6 MLD link-local multicast snooping te maken heeft is me een klein raadsel. Wellicht is het een misverstand en/of verkeerde terminologie en/of onbegrip (om diplomatisch niet de vinger proberen te wijzen naar mogelijke bugs). Hoe dan ook: snooping aanzetten (i.e. minder paketten uitsturen) lijkt me een eigenaardige 'verbetering'.

---

Inderdaad. Mijn initiële vraag was ook om na te kijken of er geen multicasts geblokkeerd werden. Niet om IGMP snooping aan te zetten. Dus we zitten nu met een probleem wat opgelost is, maar we weten niet goed waarom 🙂
@Ex-Netweter idd interessant om te weten sinds wanneer je OP het probleem heeft.  Wat het gedrag was met de modem-only en welke wijzigingen je sindsdien nog hebt aangebracht.

---

Mijn OnePlus heeft het probleem sinds ik mijn modem only vaarwel heb gezegd. Sindsdien heb ik geen wijzigingen aangebracht; afgezien van enkele firmware updates.

Pas vanaf de uitrol van de nieuwe CV8560E firmware op 15/02 kwam het OnePlus IPv6 probleem tevoorschijn.

[Ex-Netweter]

---

@Ex-Netweter  schreef:

---

@NofanTasi  schreef:

---

@Arnie  schreef:

[...]

Het "probleem" hier lijkt te zijn dat je Access-Point eigenlijk een router is, met allerlei extra features.

---

---

Ja, en dat was ook niet duidelijk in de originele post met de probleemstelling 🤔.

OK, kenners wisten misschien wel dat bij een "Asus Aimesh (AP)" nog een router hoort (RT-AC88U), maar ik zag dat gewoon als een AP.

Zo zie je maar dat het heel belangrijk is bij een probleemstelling, ook de volledige info te geven 😊.

---

Behalve de IGMP Snooping aanpassingen in Asus Aimesh zijn alle andere instellingen stock.

Hierbij screenshots van de modus van mijn Asus rt-ac88u (Aimesh moederschip) en de Aimesh topologie.