Grandstream IPv6 weirdness with VLAN

Forums › LAN (ethernet/Wifi/routers/Bluetooth) › Grandstream IPv6 weirdness with VLAN

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#318248 30-Dec-2024 13:33

Decided to set up a new SSID for my IOT devices and put them in their own VLAN.

I have a Mikrotik RB5009 and have a couple of Grandstream GWN7665 access points which are connected on ether1 and ether2. I have two SSIDs configured (lets call them Home and HomeIOT) on the GWN7665. HomeIOT is tagged with VLAN20 within the SSID configuration. I am with 2degrees and have a static IP address.

I have added a VLAN interface to the bridge (called bridge_iot) and set that to VLAN 20. It is also added to the LAN interface list "group".

I added a bridge VLAN and set the bridge, ether1 and ether2 to be tagged.

VLAN filtering is enabled and the bridge is PVID 1.

I've added both IPV4 and IPV6 subnets and ip addresses. IPV4 is 192.168.20.0/24 subnet (the bridge_iot interface has IP 192.168.20.1 and has a DHCP server bound to it for the IPv4 subnet). Likewise I've added IPV6 address to the interface from the IPV6 pool (which is named 2degrees). I use different subnets for the Home SSID and default network (192.168.94.0/24)

Almost everything works perfectly. Connecting to the Home SSID I get IP addresses from the correct subnets (both IPv4 and IPv6). This works fine. The "weirdness" comes from connecting to the HomeIOT SSID. Again; I get IP addresses from the correct subnets (both IPv4 and IPv6). Here IPv4 works perfectly, however, IPv6 has some problems. Pings work fine (both locally and across the internet) and no dropped packets are seen. However; websites have problems loading. Running some curl tests, forcing IPv6 with -6 option, the page will return fine in about 4 out of 5 calls but then randomly just hang. Ive tried a whole heap of things I can think of with no improvement. At the moment I havent set any different firewall rules at all for either subnet (at the moment they can see each other and traverse subnets too) - actually things are pretty open right now. I suspect MTU settings but have tried a few different sizes with no changes (at the moment everything is the default of 1500).

For now I've disabled IPv6 on the VLAN - not really needed for IOT devices. However; I'd like to set up some other VLANs (in the future) for some separation and would like IPv6 on those.

Anyone got any ideas I can try?

1 | 2

1295 posts

Uber Geek
+1 received by user: 423

#3326384 30-Dec-2024 23:10

If the IPv6 works on your local network but is flakey when accessing the Internet, that is often caused by MTU problems with a PPPoE connection to your ISP. PPP has a bug with IPv6 which is that it does not send ICMPv6 "packet too large" replies when it drops a packet that is too large. IPv6 requires that any packet that is dropped for being too large will cause an ICMPv6 reply - failing to do that breaks a fundamental part of IPv6, MTU path discovery. IPv6 packets can not be automatically fragmented into smaller packets if they try to pass through an interface that has an MTU that is too small for them - they can only be dropped. So IPv6 does MTU path discovery to find the maximum available MTU between the source and destination before it starts sending packets using that discovered MTU. Any interface that does not reply on dropping large packets breaks this. The fix for NZ fibre connections is that the fibre here is overprovisioned by 8 bytes, which is the number of bytes used for the PPP headers. So you set your router up with the WAN Ethernet connection to the fibre (and VLAN connection if one is used) as MTU 1508, and the PPP connection to MTU 1500 (instead of 1492).

For IPv4, the same PPP bug is also present, but that does not break IPv4 because the over long packets will just be fragmented into smaller packets instead of being dropped. Having that framentation going on can slow the connection though - fragmentation is frequently passed over to the router CPU to be done there, instead of being done offloaded in the special routing hardware. Router CPUs are not generally powerfull enough to do much packet handling, so a connection sending MTU 1500 IPv4 packets having them all routed on the CPU will usually be slowed down substantially. So IPv4 also benefits from the MTU 1508 settings for PPP.

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3326387 30-Dec-2024 23:23

I'm with 2degrees and use DHCP/IPoE for the internet connection - not PPP.

I have tried extending the MTU on the internet (and associated VLAN) interfaces but that made no difference.

And to be completely clear, I have IPv6 working fine on my default network (and Internet). Its just this new VLAN where its a problem (and on IPV6 only)

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3326396 31-Dec-2024 00:10

Probably should have checked this earlier, but it might be its the GWN7665 access points that are the issue here...

I set up ether6 as PVID 20 and added ias an untagged port on the bridge VLAN settings. And everything seems to work fine.

So I think I have eliminated the RB5009 as being the problem. In fact, this reply is on that network (Wifi disabled FYI).

fe31nz

1295 posts

Uber Geek
+1 received by user: 423

#3326674 31-Dec-2024 22:51

If you can put a PC or laptop on the problem VLAN and still get the IPv6 problem, then you can run Wireshark and see exactly what is happening to the packets.

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3326775 1-Jan-2025 11:40

fe31nz:

If you can put a PC or laptop on the problem VLAN and still get the IPv6 problem, then you can run Wireshark and see exactly what is happening to the packets.

Been trying this but havent spotted anything obvious (to me). Packets just dont come back and because of the above I think the Grandstream access points are just swallowing them. I've opened a ticket with Grandstream too.

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3328344 6-Jan-2025 17:19

Looks like Grandstream have acknowledged the bug. Had a bit of to/fro with them confirming configuration and set up etc. Today they've responded with "We will fix the issue ASAP , and we can update you with the new version.". So I think they've been able to confirm it.

Be great if an admin could update the title please - its really a Grandstream VLAN issue - not Mikrotik.

HP

Shop now for HP laptops and other devices (affiliate link).

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3329437 9-Jan-2025 08:41

Last night Grandstream updated my ticket.

They have provided me an updated firmware file and have said the fix will be in the next official release too (didnt provide a date and I have asked if they have an ETA).

I have installed the firmware on one of my GWN 7665 access points and IPv6 now seems to work flawlessly on the the VLAN tagged SSID. About to update my other AP with it too. It does report firmware version 0.1.8.2 (which is a little weird... was expecting something like 1.0.26.0).

If anyone else wants this firmware file I'm happy to provide it - probably best to DM me. Note: Its only for a GWN 7665

Once again: Would an admin please update the title to be for Grandstream (and not Mikrotik). Possibly explicitly calling out the GWN7665 as Im unsure if it affects other APs too.

RunningMan

9191 posts

Uber Geek
+1 received by user: 4842

#3329609 9-Jan-2025 16:02

@nzkc if you want the title changed either contact the mods via PM or report the post. They are not going to read every post in every thread on the off chance somebody wants a change made.

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3329652 9-Jan-2025 19:00

Thanks to whomever changed the title 😀

freitasm

BDFL - Memuneh
80662 posts

Uber Geek
+1 received by user: 41090

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#3329653 9-Jan-2025 19:03

I did change it. You can also invoke the mods with an @ mods tag.

Referral links: Quic Broadband (free setup code: R587125ERQ6VE) | Samsung | AliExpress | Wise | Sharesies

Support Geekzone by subscribing (browse ads-free), or making a one-off or recurring donation through PressPatron.

freitasm

BDFL - Memuneh
80662 posts

Uber Geek
+1 received by user: 41090

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#3329654 9-Jan-2025 19:03

Question: was the AP connected via a switch?

Referral links: Quic Broadband (free setup code: R587125ERQ6VE) | Samsung | AliExpress | Wise | Sharesies

Support Geekzone by subscribing (browse ads-free), or making a one-off or recurring donation through PressPatron.

Lenovo

Shop now for Lenovo laptops and other devices (affiliate link).

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3329688 9-Jan-2025 20:08

freitasm:

Question: was the AP connected via a switch?

I have two. One is directly connected to the router (RB5009). The router port's PVID is set to 1, the VLAN ID in question is 20 (but could be anything really).

The second is via an unmanaged POE switch and the router port the switch is connected to is also PVID 1.

A VLAN interface was added to the bridge.

Within the bridge configuration of Router OS I added the VLAN for ID 20 and set the bridge and the two ports the APs are connected to (directly and indirectly) as tagged. A dynamic VLAN for ID 1 appears also with ports as untagged. VLAN filtering on the bridge is on (obviously) and set to PVID 1.

Before the firmware update both APs exhibited the same issue. And I also tried one at a time also (I tried a lot of different configurations!)

After the firmware update both work as expected.

I was close to investing in a managed switch (and still likely will in the future). The ticket to Grandstream was a last throw of the dice before that step.

Thats all to say the TLDR is: it didnt matter if it was direct or via a switch.

3l3m3nt

120 posts

Master Geek
+1 received by user: 152

ID Verified

Trusted

Lifetime subscriber

#3351577 8-Mar-2025 20:37

Same setup Mikrotik RB5009 with GWN7665 AP's and facing the same issue! Thanks for your post! Doesn't look like an update has been publicly released yet however.

Dunedin, NZ
Quic Broadband | Rocket 1G/1G Hyperfibre (Yes, you read that right!)
Dunedin Live Webcam (4K) | Quic Smokepings

Referral Links:
Quic (use R282731EPGJMG on checkout for free setup, and to help me pay for my fast internet addiction)
Contact Energy (use FRTDD2R for $100 credit)

nzkc

1634 posts

Uber Geek
+1 received by user: 1041

#3408361 29-Aug-2025 00:43

They have released a beta firmware (v1.0.25.42) this afternoon for the GWN7665 (and other APs): https://www.grandstream.com/support/firmware/gwn76xx-beta-firmware

I have installed it on my two GWN7665 APs and it appears things are good. The bug I initially found is fixed in this version. Performance is improved too (whist it worked on custom firmware throughput was limited to about 500Mbps...seems line speed now). I also found a related bug which I have an unanswered ticket open. The custom firmware they gave me still had ssh issues into IPv6 addresses on a VLAN tagged SSID. With the beta firmware... I have had it work sometimes...not others... so unsure if fixed.

All in all... an improvement but I'll wait to see if they respond to my ticket (been over a month).

cc @3l3m3nt

cddt

1973 posts

Uber Geek
+1 received by user: 1906

#3408460 29-Aug-2025 10:00

I have also recently found a bug with Grandstream VLANs on APs, am considering raising a ticket, although I did find a workaround.

After configuring a few SSIDs and assigning VLANs, roaming between APs was failing only on the SSID which was assigned the default VLAN (VLAN 1). Creating a new VLAN and assigning this SSID to it worked around the issue.

I spent quite a bit of time tracking this down and confirming what the problem was, removing any other components or configuration which could be causing the issue. Was puzzling that roaming was working fine on the guest SSID but not the primary SSID...

My referral links: BigPipe | Mercury

1 | 2