I have my Mikrotik hAP AX2 connected in station-pseudobridge mode over wifi1 (5GHz) to my primary router, a Linksys EA9300 802.11ac router. I have the Mikrotik set to DHCP Client mode and wifi2 (2.4GHz) set to AP mode. IPv4 internet access is working for all Ethernet ports and the wifi2 AP. The main issue is I have no been able to get IPv6 working after hours of troubleshooting.
I tried various configurations using DHCP Client, Server, Pool and Addresses with an IPv6 prefix derived from the addresses I saw in ipconfig in Windows when connected directly to the primary router’s W-iFi network. I really did try as hard as I can for a long time, but in the end I could only ever see “searching” when applying any attempted DHCP Client config. My ISP is Spectrum if that helps.
Has anyone successfully gotten IPv6 to work in station-pseudobridge mode? What do I need to do? And If it will not work in station-pseudobridge mode, what other configuration can I use to route wireless from the primary router to the Mikrotik in DHCP client mode with working IPv6?
Update: Apparently Station Bridge mode is only for Mikrotik devices. Is there a setting or firmware modification that can allow this mode to work with a Linksys router? Or a way to get IPv6 to work in Station or Station-Pseduobridge mode?
Recently, I debugged internet connectivity issues on a newly set up Debian Trixie system running inside podman containers. It took some time to identify the root cause.
I was able to reach public IPv4 addresses without any problems, but IPv6 connectivity was not working at all. The interface had both an IPv6 LLA and a SLAAC address assigned, so at first glance the configuration seemed correct. However, IPv6 traffic did not work. It appears that Neighbor Discovery was not functioning properly.
The affected device is connected to a mAP lite configured as a station-pseudobridge to a wireless network. I also have other station-pseudobridge devices in use, including one running ROS v6 where the IPv6 package had previously been disabled. For testing purposes, I enabled the IPv6 package there as well, but IPv6 still did not work.
This suggests that IPv6 is generally not functioning correctly over station-pseudobridge mode, I suspect issue with ND.
In the end, I resolved the issue by disabling IPv6 on the Debian server.
station-pseudobridge is not really transparent ... in particular it has problems with MAC addresses (the upstream only sees MAC address of wifi side of station). Which can translate into problems with broadcasts and multicasts (there's only broadcast on L2) ...
If AP converts a broadcast frame into multiple unicasts (one for each connected station) to make delivery more reliable (allows for station sleeping, allows for using higher-throughput transmissions instead of lowest speed, etc ... it's the functionality enabled on MT's devices via multicast-enhance=enabled property) ... then station-pseudobridge will receive such frames set with own MAC address ... but won't have any idea that it's contents are supposed to be broadcasts/multicasts ...
The idea of station-pseudobridge is that station does sort of NAT but on MAC level ... every frame passing from wired side towards AP will have SRC-MAC replaced with station's own MAC address making return frames able to reach station device and replace DST-MAC with actual destination's MAC address on those. With proper broadcast frames that's not a problem since frame, received over WiFi, will have broadcast DST-MAC address set. But if upstream AP "plays the optimization game", frames will have DST-MAC set to station (as usually), but the "L2 NAT table" won't have any matching pair ... and will thus not be converted to "broadcast" frames and sent over wired ports.
The above might not be entirely true for IPv4 (the L2 NAT table might work with SRC/DST IP addresses as well), but with IPv6 things are more complex (there are many IPv6 multicast prefixes and it's possible that station-pseudobridge doesn't deal with them).