@Hank21 - Software controller is 5.13.22.  Previous EAP613 firmware was 1.3.2 Build 20230414 Rel. 54437.

I setup the test as PPSK without RADIUS with three passphrase mapping to three different VLANs, but no MAC bindings.  The WLAN group had two SSIDs, but only one active on the EAPs in question (the one with the PPSK configuration).

The problem seems tied specifically to PPSK. I reverted to a non PPSK configuration with the same 1.4.2 beta build and the problem goes away.

I diagnosed by taking icmp6 packet captures at three points: on the router interface, from the EAP on the wired side, and from the EAP on the wireless side. The wireless client was an iPhone (ios17).  With a PPSK configuration, the router solicitations from the client showed on the wireless side of the EAP, but did not show on the wired interface, and obviously not at the router.  Reverting to the non-PPSK configuration, the router solicitations go through to the router as expected.  (The router is not tp-link.)

UPDATE: just after writing that, I encountered the symptom again (A device not getting a v6 address until an unsolicited RA is sent out) with PPSK off, so maybe the PPSK is just making the problem occur more reliably? I'll do some more testing, and may revert back to 1.3.2.

  @Hank21 More investigation, I think PPSK is not actually relevant here. I went there because I first noticed the symptoms shortly after enabling it. I'm not certain how I observed router solicitations going through after disabling it yesterday. Further testing today with the 1.4.2 firmware, I see router solicitations from wireless clients being dropped reliably, regardless of whether PPSK is being used.  Reverting to the latest release, EAP613(US)_v1_1.3.2 Build 20230414, router solicitations pass through as expected.  So it seems to be more generally a 1.4.2 issue, not a PPSK issue.  Such is life with betas!

Hank21 wrote

Hello @seacycle,

 

To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID231246832, please check your email box and ensure the support email is well received. Thanks!

Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.

Many thanks for your great cooperation and patience!

@Hank21 — Thanks, I've loaded up the on-track-to-release firware provided in the issue and it does resolve the problem of all router solicitation packets being dropped.

There is still a related issue where a client using Optimistic Duplicate Address Detection (RFC 4429) issues an initial router solicitation packet without the source link-layer address option, as mandated by the RFC.  This initial router solicitation packet is dropped by the EAP in both the pre-release firmware supplied in the ticket, and the currently released firware (1.3.2 Build 20230414 Rel. 54437).  Once the full duplicate address detection workflow completes, the client then sends another router solicitation packet with the source link-layer option.  This second packet does go through the EAP, but the drop of the first solicitation introduces a 4-5 second delay in configuring the v6 stack on the client, effectively breaking Optimistic DAD.

RFC 4429 is, what, 17 years old?  Seems like that would be sufficient time to write up a test suite to run the firmware through to ensure proper behavior.  I've been using omada stuff for switching for a couple years and am pretty satisfied. I just bought a couple EAPs to test out going all-omada. Based on other forum posts and my own experience, I must say that the IPv6 situation with the EAPs is disappointing.