EAP650 dropping IPv6 traffic
I have an EAP650 AP and an EAP245 AP. Both APs are connected to the same switch, have the same trunk (port profile) settings, the same WLAN and VLAN settings, pretty much everything is the same. Clients roam between the two APs and use both IPv4 and IPv6.
When clients connect to the EAP245 IPv4 and IPv6 traffic is working as expected, however, when clients connect via the EAP650 AP, all IPv6 traffic is dropped and I can't work out why!?! I have ruled out any issues with the router, VLANs, or WLAN configuration - everything is the same (other than the model of the APs and the physical port they are connected to on the switch).
I have also tried the latest Beta firmware for the EAP650, but it doesn't fix the issue.
Any ideas?
Thanks.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi there,
Thank you for coming to TP-Link Community for help!
If you suffer from the same IPv6 issue with the EAP650/ EAP670/ EAP653 as it's described below (thank you @codersr for the detailed information), please follow this post for available solutions. Thanks for your cooperation and patience. See you in the community soon!
codersr wrote
I have an EAP650 AP and an EAP245 AP. Both APs are connected to the same switch, have the same trunk (port profile) settings, the same WLAN and VLAN settings, pretty much everything is the same. Clients roam between the two APs and use both IPv4 and IPv6.
When clients connect to the EAP245 IPv4 and IPv6 traffic is working as expected, however, when clients connect via the EAP650 AP, all IPv6 traffic is dropped and I can't work out why!?! I have ruled out any issues with the router, VLANs, or WLAN configuration - everything is the same (other than the model of the APs and the physical port they are connected to on the switch).
- Copy Link
- Report Inappropriate Content
After some further analysis with Wireshark I can see that the issue is that the EAP650 is dropping all DHCPv6 ADVERTISE and REPLY packets from my router. Other IPv6 traffic is being allowed, including the DHCPv6 SOLICIT packets that come from clients. SLAAC eventually works, but is signficantly delayed.
The EAP650 is behaving as if the "Legal DHCP Servers" option was enabled. However, I have double-checked and the "Legal DHCP servers" option is disabled for all my Networks, so all DHCP traffic should be allowed. Indeed, my EAP245 AP happily lets all DHCPv4 and DHCPv6 packets pass.
This must be a bug with the EAP650 firmware.
Compounding the issue is the fact that "Legal DHCP Servers" option doesn't appear to support DHCPv6 servers yet, so I can't just add my DHCP server's IPv6 addresses!
- Copy Link
- Report Inappropriate Content
Are you pursuing this via support or just here? If true, nice find. :) Would appreciate hearing any updates on this one. BTW, what router/dhcp server are you running? Thanks.
- Copy Link
- Report Inappropriate Content
Yeah, got a support case open. I'm fairly certain it's a firmware bug, but they haven't confirmed yet.
I'm using a PfSense sense router, which is running my DNS and DHCPv4/DHCPv6 etc.
- Copy Link
- Report Inappropriate Content
OK, the reason I asked is that your description of the problem is both different and similar to something I was recently looking at independent (I think) of access points. I have a situation where it seems like radvd is not answering ipv6 router solicitation requests, although like you, the regular advertisements do finally allow a host to connect to ipv6 using SLAAC, but it takes a while depending on the interval and when the next one is scheduled. I've only tested this with wireless hosts. On OPNsense, I can do a packet capture and see the solicitation packet, but never see a reply. But you do see the reply coming from your router...? Or does the router never receive the request? I was stumped into trying to determine if radvd somehow was never receiving the solicitation from the wireless host (in this case, ipad/iphone). Because of this, I was not sure if this was an issue with freebsd (there is some chatter about a kernel bug blocking the solicitation...maybe) or radvd perhaps ignoring the request. That's where I stopped, and just made the interval a little tighter on the radvd advertisement interval. This was tested with an EAP670 (similar I believe to the 650...at least with the recent bug/beta firmware). I guess this is just a coincidence. Once the host receives an ipv6 address, no problems...and never any problems roaming between this AP and an EAP245v3.
Cheers!
- Copy Link
- Report Inappropriate Content
@GPB From my analysis using wireshark on a mirrored port on the core switch, the router sees all packets from the client (i.e. SOLICIT and REQUESTs) and sends the appropriate ADVERTISE/REPLY packets in response. Its's the ADVERTISE and REPLY packets that seem to get black-holed by the EAP650.
To me, this seems consistant with how a "Legal DHCPv6 Servers" setting ought to work, if only there was such a setting...
- Copy Link
- Report Inappropriate Content
Update: TP-Link have confirmed they can reproduce the issue in their lab. Anyone know from past experience how long it's likely to be for a fix (or at least beta firmware) to be released?
- Copy Link
- Report Inappropriate Content
Like I said, probably a coincidence regarding adv/solicit behavior from different parts of the network. I'm by no means an expert and never heard of the "Legal DHCPv6 Servers" option. And good work finding the bug. You can request a beta (I'd be willing to test it too if it's common to the EAP670) and hopefully they make that available as they did with the prior one. And maybe (?) that is related to the problem I was seeing too...I need to test with a wired host to verify similar results...never occurred to me.
- Copy Link
- Report Inappropriate Content
It looks like it's not a coincidence, it's the same problem. Without doing additional packet captures (I will as time permits), standing next to my EAP245v3 and simulating the same test (wifi off/wifi on) I instantly receive ipv6 address information. However, when on the EAP670, the host is obviously waiting for the next advertisement interval, up to about three minutes in my case.
Since you have a contact, you might mention this thread and note it's being seen on the EAP670 and I can provide information if needed, or I can contact TPL separately.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Another issue beside the TCP issue.
Looks like 650 and 670 are no good APs at all. The 660HDs dont have these issues/bugs.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 3
Views: 8679
Replies: 42