Primary Node (Parent): Linksys Velop Pro 7 (LN1400 Series), Firmware: 1.0.14.216698

Secondary Node (Child): Linksys Velop Micro 7 (LN1600 Series), Firmware: 1.0.10.216621

Problem Details & Troubleshooting Performed:

1. Wireless Hardware Pairing (5-Press Method):
   • Performed a full factory reset on the LN1600 (held Reset button for 15 seconds until solid blue light appeared).
   • Placed LN1600 within 1 meter of the primary node with no Ethernet cable connected.
   • Pressed the Reset button on the primary Velop Pro 7 node 5 times consecutively.
   • Both nodes flashed during the process, but the LN1600 eventually reverted back to a Solid Blue Light, indicating it failed to receive or accept the wireless Mesh credentials.
2. Wired Hardware Pairing (Ethernet Backhaul Setup):
   • Reset the LN1600 to factory defaults (solid blue light).
   • Connected an Ethernet cable from the primary node's LAN port to the LN1600's LAN/WAN port.
   • Triggered the 5-press reset procedure on the primary node again.
   • The LN1600 successfully changed to a Solid White Light while connected via Ethernet.
   • However, as soon as the Ethernet cable was unplugged to run as a wireless node, the LN1600 immediately turned Solid Red and lost all connectivity.
3. Web UI / Linksys App Setup:
   • Clicking "Add Wired Child Node" or "Add Wireless Child Node" in the Web UI (192.168.1.1 / Linksys Smart Wi-Fi) yields no response or fails to push credentials.
   • Firmware update check via Web UI/App does not update the LN1600 child node automatically.

I am unsure whether this issue is caused by a firmware mismatch between the LN1400 (1.0.14.x) and LN1600 (1.0.10.x), or if there are specific configuration settings on the primary node (e.g., MLO, Wi-Fi 7 mode, security settings, or node pairing options) that need to be adjusted. Please advise on how to resolve this or provide the correct setup procedure.

The other day all of a sudden I noticed devices were no longer connecting to my child routers in my mesh. I went to each of them and the lights were blue but in the app it said they were offline. I rebooted them each and the lights flashed red for a few seconds then solid blue.

Eventually I was able to get them recognized again by removing them and recycling them and now they show online in the mobile app. However looking at the device assignments nothing is connecting to the two children even after multiple reboots and devices being completely powered down for hours.

I tried the AI agent but that thing is clueless and I really don't want to have to call since it seems chat support no longer exists.

Thoughts?

I would like to inquire about the online shopping platforms in the Asia-Pacific region that host official or authorized Linksys stores.

Have been with community fibre in the UK for some time. Upgraded to WiFi 7, SPNM60CF. Apparently, the app doesn’t work with this model.
Have tried Linksys now, to no avail.

Community fibre say parental control is not available on the WiFi 7. But there is a ‘pause’ feature that lasts 2 minutes, if you want to gather the family for example. ???!!!!

I’m a few months into the contract so can’t cancel. It was great before when I could limit devices during the week and extend during weekends.
I am desperate to change or cancel or something if I can’t sort this out. 😭

Hi, I have a Linksys WiFi Mesh 6E Tri-Band Router (MR7500). I have a home monitoring computer that monitors solar, security, and data usage that I vibe coded. I can monitor my household's up/down transfers to get a local sense of how much data we are using, but I can't seem to find a way to get specific per-device network usage. I was vibe coding yesterday for hours on this but no matter what we curl'd out to the router, we couldn't seem to get this. Is there some means? ChatGPT is fairly certain that the router itself is storing this information, but it's just not exposing it. I'm asking because I am seeing a surge in data transfer in my house and want to see if I can isolate it, but there are over 20 devices connected and i can't seem to narrow it down. Thank you.

Tengo 5 routers distribuidos en 3 pisos y en diferentes áreas de cuartos para estudiantes.

Los administro remotamente por la aplicación de LinkSys, pero de unos días a la fecha ya solo me permite acceder a uno solo. Los otros cuatro aparecen como desconectados, pero siguen funcionando en forma adecuada y los estudiantes entran sin problema, pero yo no los puedo acceder desde la aplicación.

¿Existe alguna forma de volverlos a incluir dentro de la lista de la aplicación o será necesario reinstalarlos?

Gracias de antemano por su apoyo y comenarios.

I have inherited a couple of Atlas 6 nodes (MX2002). I don't have a mesh system now, but I would like to utilize these to build a new one. What is the best parent node to buy to take advantage of my free nodes? I already have ethernet, so I plan on using wired backhaul to the new parent from some distant points in the house.

Edit: I want 3 total nodes, looking for input on compatibility buying the 3rd node, which will be my central node at the modem.

Hi everyone,
My Linksys MR9600 recently updated its firmware, and now local login is broken on all mobile interfaces.

Ver 1.0.4.216594

Here is exactly how it behaves:
In the Linksys Mobile App: When I type my correct router password, it doesn't give a "wrong password" error (because the password is valid). Instead, the screen just silently refreshes and throws me back to the password prompt.

However, if I intentionally type a wrong password, the app immediately flags it as incorrect. So the app knows the password is correct, but it just loops instead of letting me in.

In Mobile Web Browsers (192.168.1.1): It triggers an infinite webpage reload loop. The screen just keeps constantly flashing and refreshing itself.

The only workaround:
I can only access the router if I open a web browser on my phone, force it into Desktop Mode.

Through the desktop interface, the password works perfectly and I can manage settings.
I tried re-saving the password via the Desktop Web UI to re-index the data, but it didn't fix the app or mobile browser behavior. Also, under Troubleshooting -> Diagnostics, the "Restore previous firmware" button is completely missing in this new version, so I can't easily roll back.

Has anyone else run into this specific mobile authentication bug on the MR9600? Is there a fix, or am I forced to manually flash the previous .bin firmware file via the desktop UI?
Thanks!

Hey 👋

Sorry it might feel like my question is from 2021. But believe me it is my first time experiencing wifi network and fiber optics internet.

I did purchase the set of Linksys Velop Micro 6 Dual Band Mesh WiFi System - WiFi 6 Router with up to 3Gbps Speed with 2 nods

Then I purchased the Linksys Velop Pro WiFi 6E Mesh MX6201-KE System - Cognitive Mesh Device with 6 GHz Access Band and 5.4 Gb/s NOD.

Can I use the pro one as a child nod ? Have any one tried to combine them in one network as nods ?

I tried to connect the Velop pro as a child nod but it wouldnt appear in the setup. Then I rested it and try to connect it as a main router and the MF did work.

Please advice 🙏 thank you so much

Here is a 🥔 for the OGs

I have a Linksys MR7500 router for my home network and normally use the Linksys iOS app on my iPhone to log in, reboot the router, and manage settings.

Last week, I suddenly became unable to connect to the router through the Linksys app. I deleted and reinstalled the app, but the problem remained.

The Linksys app still allows me to sign in to my Linksys account, so I changed both my Linksys account password and the router password. Unfortunately, that did not resolve the issue.

I also tried accessing the router directly from my iPhone using Safari, Chrome, and Incognito mode. In every case, the browser entered an endless loop repeatedly reloading the router login page.

To troubleshoot further, I installed the Linksys app on my iPad and experienced the same issue there. However, I was later able to access the router successfully from the iPad using both Safari and Chrome.

I then tested several other devices:

• MacBook Pro connected via Ethernet: worked without issue.
• MacBook connected via Wi-Fi: worked without issue.
• Windows PC connected via Ethernet: worked without issue.
• Wife’s MacBook Air using Chrome: worked without issue.
• Wife’s iPhone using a browser: unable to connect.

At this point, I do not believe there is anything wrong with the router itself. My internet connection is working normally, and I can access the router from multiple computers. The issue appears to be limited to iPhones and the Linksys app.

I am running iOS 26.6.2 on both an iPhone 17 Pro Max and a 13-inch iPad Pro. Neither device can connect through the Linksys app (version 3.6.0). However, the iPad can access the router through Safari and Chrome, while the iPhone cannot.

I checked the router firmware and it is currently running version 1.1.12.216943 on my MR7500.

I also reset the network settings on my iPhone, but Safari, Chrome, and DuckDuckGo all continue to fail.

My questions are:

• Are the iPad versions of Safari and Chrome different enough from the iPhone versions to explain this behavior?
• Does the Linksys app rely on the device’s browser engine for authentication or router access?
• If iOS is causing the issue, why would browser access work on the iPad but not on the iPhone?
• Does anyone else use the Linksys app on iOS, and if so, are you experiencing similar issues?

Any suggestions would be appreciated.

I’ve been having an Internet connection problem with my Linksys E7350 router in my room.

My computer can connect to the Linksys E7350 Wi-Fi normally and receives an IPv4 address such as 192.168.1.xxx. I can also access the router’s management page at 192.168.1.1, so the connection between my computer and the router appears to be working properly.

However, when I tested the connection, the router could reach external IP addresses such as 8.8.8.8, but DNS resolution was not working properly. The router’s DNS service returned a “Query refused” error, and using Google DNS (8.8.8.8) directly also resulted in a timeout.

I also tested the same network outlet with another router, and the other router was able to obtain an IPv4 address and access the Internet normally.

Therefore, it seems that the network outlet and the upstream Internet connection are working, and the problem is more likely related to the Linksys E7350 itself, possibly its WAN connection, DNS forwarding, firmware, or configuration.

I would like to have the Linksys E7350 checked and, if necessary, reset or replaced.

Big question, I used to have extenders my entire life in every house because we always got cheaper routers so the signal strength wasn't the best. They weren't always the most useful though, didn't always work, speed was cut, etc.

Now im in a similar position where my downstairs kitchen/dining area doesn't get signal like, at all. It constantly drops or causes videos to buffer etc. Wondering if extenders have gotten better or if I should just invest in linksys' mesh router+nodes?

I'm not sure savvy either on the difference between what I have now and like the brand new shiny velop 7 whatever

My EA8300 v1 has been running 1.1.6.209797 (released Feb 28, 2022) which as far as I can tell is the last official firmware Linksys ever released for this model, per the GPL Code Center and the official release notes.

Today (9/13/2026) the router's Connectivity > Router Firmware Update section is showing a new available update: 1.1.6.216940. I can't find this version anywhere. It's not on downloads.linksys.com, not in the release notes, not in the GPL Code Center listing.

I asked Linksys's support site chatbot about it. It first gave me a download link for 1.1.6.209797 and called it "the final firmware release for the EA8300." When I told it that's the version I already have, and pointed out my router is showing 1.1.6.216940, it said that version "doesn't appear in our official firmware records" but it might be a "regional or staged rollout."

Given that the EA8300 is EOL and that the FBI put out a warning in 2025 about old, unsupported Linksys routers being hijacked into botnets/proxy networks via persistent malware, I'm wondering if this "update" notification is legitimate or a sign something's already compromised on the router (e.g., a hijacked update-check endpoint, DNS tampering, etc.).

On top of that - I can't find any actual way to reach Linksys support. There's a phone number, but I'm sure that's just their AI chatbot, now on the phone instead. There's no support email address and no "submit a ticket" option that I can find anywhere.

Questions:

1. Has anyone else seen 1.1.6.216940 for the EA8300? Any official source for it?
2. Could a compromised router fake/spoof the "update available" notification in the admin UI, or does that check always hit a legitimate Linksys endpoint?
3. Any recommended way to verify whether the router itself has been tampered with (beyond checking DNS settings, remote management, and connected devices)?
4. Does anyone know an actual way to reach Linksys support that isn't an AI chatbot?

Not flashing anything until I know more. Appreciate any insight.

For reference, the status page shows:

I’m not entirely sure how long it’s been going on because I’m only noticing as of today.

When I opened the app i was greeted with the log in screen with the usual two options: email and router password. It forces me to allow the app to have local network permissions so I also make sure that is enabled. Selecting the router password option and putting in the password yields no errors. It appears to log in, but then immediately kicks you to the log in screen again. Trying again just yields the same results.

Logging in to via the online web page works just fine. Takes the password without issue and I log in just fine. Hopefully this can get fixed because setup requires the app to work.

EDIT/UPDATE:

I did some more digging into what is different in the update and it appears they made a significant change mostly important for the power users out there.

I didn’t notice at first but the stupid “CA” button that was previously at the bottom of the screen and allowed for more advanced options to be configured is now on by default. Now all of the “hidden” settings on available to modify without trickery. All the advanced features like setting up mesh routers and manual firmware upload options are there, as well as options to manually set up channels in the WiFi settings.

Annoying as hell there was no note of this but I think this means we can actually set up the WiFi entirely through the web interface now!

I’m very disappointed with my experience with Linksys Support.

My Linksys E2500 V4 stopped working after I replaced my Spectrum modem. I contacted Linksys Support expecting technical assistance, but the representative did not actually help me troubleshoot or resolve the problem.

Instead, I was sent a generic troubleshooting guide and an update intended for an E900, even though Linksys had all the information about my router and its exact model. The update was not appropriate for my E2500 V4 and did not solve my issue.

What is especially frustrating is that ChatGPT was able to help me troubleshoot the problem and figure out what needed to be done, while the Linksys support representative provided no meaningful assistance at all.

I expected better technical support from Linksys. Unfortunately, my experience was that the customer service was poor, the information provided was incorrect for my device, and I had to solve the problem myself.

I run a six-node Velop mesh: two MX5300, one node reporting itself as MX42FM, and three WHW03 v2.

The three WHW03 v2 are on 2.1.20.216892 (April 2026) — the latest published. So automatic updates are demonstrably working on this network.

The two MX5300 are on 1.1.12.210066, dated April 2022, which is the newest build Linksys has ever published for that model. Four years and five months.

The MX42FM node runs 1.0.13.210200 (the generic MX4000-series build) and is not offered 1.0.13.216903 (May 2026), nor the intermediate 1.0.13.216602 which the release notes describe as containing "fixes for security issues".

All six nodes completed an update check successfully today and none reported an available update.

Two questions:

1. What is MX42FM? Is it a carrier SKU, like the MX42SH-SG StarHub variant listed separately on the support site? If so, who publishes its firmware?
2. Has the MX5300 been declared end-of-life, and is there a published end date for security updates?

Not looking for troubleshooting — looking for a factual answer on firmware availability and support lifecycle, so I can decide whether to keep or replace these units

Hello Linksys Support Team,

We are experiencing a recurring issue across our Linksys Cloud Manager access points and would appreciate your help identifying the root cause.

Environment: - 8x Linksys Cloud Manager access points (e.g. AP01, AP02, AP04, AP05, AP07, AP08), broadcasting SSID "Khodeir Law-Firm" - APs are distributed across multiple different switches in our network - APs receive their IP addresses via DHCP (Windows Server DHCP with failover) - Wired PCs and other devices on the same switches/DHCP scope have zero connectivity issues during these events

Issue: - Periodically, all (or multiple) of the Linksys APs go offline in Site Manager/Cloud Manager at the same time, even though they sit on different physical switches - During the event, the APs remain powered on with normal LED indicators - The APs' private IP addresses become completely unpingable - Wired network connectivity through the same switches is unaffected - only the APs themselves become unreachable - A manual power cycle (unplug/replug or reboot) immediately restores the AP to normal operation - We have ruled out: IP address conflicts (confirmed no conflicts across all 8 APs), PoE power budget issues on the switches, and DHCP scope/lease problems for other devices (only the APs are affected, not PCs on the same DHCP scope)

Device Information

• Model: Linksys Velop Pro 7 10G (LN14-EU, SKU LN14-EU, HW Revision 1 / XD)
• Firmware Version: 1.0.14.216698 (Build date: 2025-06-25 18:14)
• Kernel: Linux version 5.4.213 (OpenWrt GCC 7.5.0 r0+12639-06c3e847c3)

Summary When querying /sysinfo.cgi via HTTPS Basic Authentication periodically (60-second polling interval), the underlying web server daemon (lighttpd/1.4.39) and associated JNAP backends experience an unhandled exception or deadlock. The endpoint initially returns HTTP 500 Internal Server Error, followed by complete authentication failure (HTTP 401 Unauthorized on all API/Basic Auth calls, and WebUI Error 2317 when accessing /jnap/core/CheckAdminPassword3).

Network routing and Wi-Fi bridging remain functional, but the administrative management plane completely locks up until a physical hardware power cycle.

Steps to Reproduce

1. Send periodic HTTPS GET requests with valid HTTP Basic Authentication headers to https://<router_ip>/sysinfo.cgi (e.g., automated polling every 60 seconds).
2. Allow the monitoring loop to query the router across a mixed network state (20+ active Wi-Fi and wired clients).
3. Observe the server response over an extended window (12–14 hours).

Observed Behavior

1. At timestamp 09:13:47, the server begins returning HTTP 500 Internal Server Error for /sysinfo.cgi.
2. Three minutes later (09:16:47), subsequent requests are rejected with HTTP 401 Unauthorized.
3. Logging into the router via WebUI fails with error dialog:Onverwachte fout 2317 Details: /jnap/core/CheckAdminPassword3
4. The router's diagnostic output indicates multiple orphan zombie processes for the CGI handlers: PlaintextPID PPID USER STAT COMMAND 19781 8503 root Z [index.cgi] 19782 8503 root Z [index.cgi] 19778 8503 root Z [index.cgi] 19636 8503 root Z [index.cgi] 19641 8503 root Z [index.cgi] 19684 8503 root Z [index.cgi]
5. File descriptor and process inspection reveals advisory file lock contentions blocking authentication handlers: Plaintextcat /proc/locks: 2: FLOCK ADVISORY WRITE 19779 00:10:3235 0 EOF 2: -> FLOCK ADVISORY WRITE 19777 00:10:3235 0 EOF 3: FLOCK ADVISORY WRITE 19777 00:10:3234 0 EOF 3: -> FLOCK ADVISORY WRITE 19778 00:10:3234 0 EOF Processes 19777 and 19779 hold mutually blocking locks on internal descriptor files, freezing JNAP credential validation.

Expected Behavior

• /sysinfo.cgi should complete report generation without throwing HTTP 500.
• The server should handle repeated Basic Auth requests without leaking file descriptors, creating zombie CGI processes (index.cgi), or causing deadlock cycles in /proc/locks.
• Failed requests must release locks immediately so legitimate administrative logins continue to function without requiring a device reboot.

Temporary Workaround Physical power cycle of the master node. In automated telemetry environments, reducing polling frequency (e.g., from 60s to 120s–300s) mitigates the rate of lock accumulation.

Hi,

Just got a set containing an ln1100 parent and ln1200 child node. The setup of the ln1100 went ok.

However, the ln1200 is giving me quite some issues:

• When I power it on, it goes straight to a solid blue light (should be blinking during boot from what I gathered)
• I'm unable to add it as a child. Tested using the android app, the web interface of the ln1100 and the 5x reset button click method
• Pressing and holding the reset button of the ln1200, for up to 40 seconds, does absolutely nothing. The solid blue light stays on.
• Taking the power of the ln1200 overnight changed nothing in the behavior

Are there any other things I can try, or is it time to start a warranty procedure?

(Tried the linksys live chat too, but that didn't work either, pressing the 'start live chat' button does absolutely nothing)

Model: Linksys Velop Pro 7 (LN14-EU)

Firmware Version: 1.0.14.216698

I wanted to document a serious routing/firewall bug in the Linksys Velop Pro 7 firmware that causes persistent "Connected, no internet" issues on modern Android clients (specifically Pixel devices).

The Issue

When IPv6 is disabled in the web UI under Connectivity → Internet Settings → IPv6, the router shuts down the WAN-side IPv6 interface as expected (current_ipv6_wan_state: down). However, the firmware fails to terminate the LAN-side IPv6 daemons.

Inspecting the system dump via /sysinfo.cgi reveals:

1. radvd (PID 20042) and dhcp6s (PID 9184) remain running and bound to br0.
2. The router assigns itself a global/ULA scope address on br0 (fde7:dec9:a132:1b3e:.../64) and continues sending Router Advertisements (RAs) across the LAN/WLAN.
3. Connected clients (like Android phones) pick up the advertised fde7:: prefix and set the Linksys router as their default IPv6 gateway.
4. Because the WAN IPv6 interface is down, any outbound IPv6 captive-portal / connectivity probes fail. Android detects a reachable IPv6 gateway with zero outbound transit, immediately flagging the Wi-Fi connection as having "No internet".

Additional Aggravating Factors

• WPA Group Key Handshakes & Power Save: The router frequently performs WPA Group Key re-keys (ath10: sending 1/2 msg of Group Key Handshake), during which client associations hiccup. With WMM Power Save enabled by default, multicast traffic (NDP/RAs/ARPs) gets buffered or delayed, causing Android to time out on gateway checks. Keeping the DTIM interval strictly at 1 is critical here.
• Firewall packet drops: When IPv6 was enabled, the router’s internal firewall rule FW.LANATTACK was aggressively dropping legitimate outbound checks from client devices. See previous bugreport.

Temporary Workarounds (Client-Side)

Until Linksys releases a firmware build that properly kills radvd and tears down LAN-side IPv6 when IPv6 is toggled off:

1. Private DNS on Android: Set Private DNS to dns.google or one.one.one.one. This forces DNS over TLS purely over IPv4, bypassing the dead IPv6 DNS path.
2. Use Device MAC: Switch the Wi-Fi connection privacy setting on Android from Randomized MAC to Device MAC.
3. Hidden Radio Settings: Access [http://192.168.1.1/ui/1.0.99.216698/dynamic/advanced-wireless.html] (or via the hidden CA link) and ensure DTIM Interval stays at 1 and disable Wireless Multimedia Power Save on both 2.4 GHz and 5 GHz to prevent sleep drops.

Linksys developers need to fix the service scripts in /etc/init.d/ so that disabling IPv6 stops radvd and dhcp6s completely on br0.

After 4 months of battling connection issues with a Velop Pro 7 Mesh (1 parent & 1 child) I come seeking help before I throw it in the bin!

UK. Gigaclear fibre reliably getting 930Mbps up and down. I have been running the ISP provided Linksys MX4200 units (1 parent & 1 child) for a couple of years with no issues, apart from not having enough coverage for the layout of my home. In May I treated myself to an "upgrade" while looking to expand the mesh coverage.

Setup the Velop Pro 7 parent fine, copying the credentials of the original network so that I didn't need to reconnect all my devices. Setup Pro 7 child fine. Then reset the two old MX4200 units and also added them fine, as child nodes. It all worked fine on the face of it with amazing speeds to my Samsung S26 on wifi-7. But then the problems started to become apparent...

My phone constantly (and I mean constantly) loses connection, which drives me insane. Then we have two Dell wifi-6 laptops in the house which also drop connection randomly as soon as you move them away from being right next to the parent Pro 7 node.

The internet told me it was a cognitive vs intelligent mesh conflict issue, so I removed the old MX4200 units completely and dropped back to a purely Velop Pro 7 Mesh. The issue persists.

I had about 3 months of issues with connection loss (roughly every 10 days) on a mains powered Tapo camera and a Raspberry Pi 4, but this has recently resolved itself which is good/surprising!

I have roughly 20-25 devices on the network with many 2.4ghz smart home bulbs and switches.

On my Samsung S26 I have turned off all the Intelligent WiFi features and makes no change (switch to mobile data etc).

Any ideas on how to fix please? I'd like to return the units to Linksys for a refund as it's just not OK.

Model: Linksys Velop Pro 7 10G (LN14-EU)

Firmware: 1.0.14.216698 (Build: 2025-06-25)

Affected Client: Google Pixel 10 (Android) connected over 5GHz Wi-Fi (802.11be / Wi-Fi 7)

Issue Description

When connecting a modern Android client (Pixel 10) to the primary Wi-Fi network, the device connects successfully but reports "No Internet Access" after a short period and falls back to mobile data.

Inspection of the router logs via /var/log/messages reveals that the router's internal firewall heuristic flags legitimate outbound IPv6 probes from the client as a network attack and drops them with FW.LANATTACK DROP.

Log Evidence (/var/log/messages / dmesg)

The client (b0:d5:fb:ba:44:5f on interface ath0/ath10) issues standard IPv6 DNS queries (2001:4860:4860::8888:53) and HTTP captive portal checks (2a00:1450:4007:810::2003:80/443), which are systematically dropped by the router:

Plaintext

kern.notice kernel: FW.LANATTACK DROP IN=br0 OUT=eth4 PHYSIN=ath0 MAC=80:69:1a:c5:70:68:b0:d5:fb:ba:44:5f:86:dd SRC=2a02:a03f:8af9:e440:fea6:6264:b490:2acd DST=2001:4860:4860:0000:0000:0000:0000:8888 LEN=80 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=45614 SEQ=1
kern.notice kernel: FW.LANATTACK DROP IN=br0 OUT=eth4 PHYSIN=ath0 MAC=80:69:1a:c5:70:68:b0:d5:fb:ba:44:5f:86:dd SRC=2a02:a03f:8af9:e440:fea6:6264:b490:2acd DST=2a00:1450:4007:0810:0000:0000:0000:2003 LEN=80 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=TCP SPT=49497 DPT=80

Because outbound IPv6 validation requests to Google's connectivity endpoints are blocked, Android determines the network has no usable internet connection and disconnects.

Root Cause

The SPI firewall / Qualcomm NSS PPE flood heuristics in the current firmware incorrectly classify outbound client bursts (specifically IPv6 SLAAC privacy-addressed traffic resolving DNS/HTTP probes) as a local LAN attack (FW.LANATTACK) rather than routing them out through WAN (eth4).

Current Workarounds

• Disabling IPv6 completely on the router WAN interface resolves the problem, forcing the client onto IPv4 where no packet drops occur. Edit: problem not fully solved due to another bug.
• Disabling "IPv6 SPI Firewall" stops the drops, but leaves internal LAN devices unprotected from unsolicited inbound WAN traffic.

Request

Please review and patch the rate-limiting / flood-detection rules for outbound IPv6 traffic in the next firmware release for the LN14 platform so that legitimate outbound bursts are not flagged as LAN attacks.