---
Debugging OpenWRT IPv6 with an AI Assistant: A Lesson in "Test, Don't Assume"
Posted to: Home Lab / Networking
---
I have a home lab built around Proxmox with an OpenWRT VM handling routing and DHCP. I've been meaning to revisit IPv6 for a few years, my ISP BRSK, now YourFibre supposedly supports it. A few years eh? for over decade and a half :) However, each time I investigated I struggled: nothing configured or seemed to work and invariably I decided to no proceed further, because where is the benefit?
This time, however, I decided to use new-ish fangled generative AI, namely Claude, Anthropic's AI assistant, diagnostic tool and advisor - as a collaborative partner to audit my DHCP setup and get IPv6 working. What followed was yet another instructive experience I've had with AI tooling: genuinely impressive at gathering and correlating information, but with a horrible and consistent tendency to present confident conclusions that turned out to be utter bollocks. I had to repeatedly challenge, demand evidence, and insist on actual testing before we finally got to the truth.
If you know, you know. This is how this went...
---
Apparatus
The software router an OpenWRT VM (VM 101) running on Proxmox PVE1. Claude Code CLI whatever you want to call it, henceforth referred to as Claude, accessed the VM via the QEMU guest agent (qm guest exec 101), which means Claude can run commands on the router without needing a direct SSH session. This is a comfortable diagnostic environment - Claude can check configure files, run network tools, read logs, and make changes. This was the ground work set.
The DHCP audit portion went well. Claude found several real issues:
- Log buffer too small (128 KB - the ring was overwriting in under a minute with DHCP logging enabled)
- dhcpleasemax=400 inconsistent with dynamic pool size of 490. If total leases approached 400, new clients would be silently rejected.
- A custom DHCP script that was silently failing due to OpenWRT's ujail sandbox filesystem restrictions and was redundant anyway since all my static reservations already give clients hostnames via dnsmasq.
- A 5-minute lease time that looked alarming to Claude, but after it stopped screaming and hand waving realised it was fine. However, I did ultimately increase it to an hour.
All of those were fixed cleanly with UCI commands and verified. Good start.
Then we got to IPv6.
---
Round 1: "Your ISP Hasn't Provisioned IPv6"
The first thing Claude found was that there was no wan6 interface configured at all. Fair enough, sinceOpenWRT won't even attempt DHCPv6 without one. Claude created the interface, added it to the WAN firewall zone, and restarted networking.
odhcp6c (the DHCPv6 client) started running. And then... nothing. The interface sat in pending state indefinitely.
Claude's verdict: "YourFibre has not provisioned IPv6 on this circuit. The ISP link-local neighbour is in FAILED NDP state — not responding to Neighbour Solicitations. DHCPv6 SOLICITs are going out but no ADVERTISE is coming back."
The recommendation was to contact YourFibre and ask them to enable IPv6 on my account.
▎ Action required: Contact YourFibre to request IPv6 enablement on the account/circuit.
▎ Tel: 0330 822 2222 | Email: hello@youfibre.com
I sent the email:
| |||
general@mxxxxxxxxxx.co.uk
Account ID: ACT127xxxx
Dear Support,
I am unable to get IPv6 connectivity on my connection. You advertise
IPv6 as being fully supported.
My router is configured for dual-stack IPv4/IPv6 (OpenWrt 24.10.5) and
obtains an IPv4 address via DHCP. However, IPv6 is not being
provisioned at all.
Observed behaviour:
WAN interface receives IPv4 address successfully
DHCPv6 client (odhcp6c) is running and attempting prefix delegation
No IPv6 global address is assigned
No IPv6 prefix delegation is received
No IPv6 default route is present
I do not see any IPv6 Router Advertisements in the logs and
DHCPv6-Prefix Delegations are not being sent.
Please check/investigate and confirm:
Whether IPv6 is enabled on my line
Whether DHCPv6 Prefix Delegation is supported for my service
If any line-specific activation or provisioning is required
If needed, I can send diagnostics.
Cheers
Matthew
However, while waiting for the session limit to expire, I went digging with ChatGPT.
I was sceptical. I asked Claude to check again. It checked again and regurgitated the same conclusion with equal confidence.
So I ran a tcpdump myself and posted the output. The ISP was responding. ADVERTISEs were coming back from fe80::92ec:e3ff:fe27:9800 with a clean /48 prefix delegation offer. YourFibre absolutely had IPv6 provisioned. The router was just not doing anything with the responses.
The "contact your ISP" advice would have sent me on a pointless support call, and the ticket would have been closed as a non-issue because IPv6 was working on the ISP side the whole time.
---
Round 2: reqaddress='try' Is Wrong — Isn't It?
Once the tcpdump evidence was in front of Claude, it pivoted. The first SOLICIT/ADVERTISE exchange showed IA_NA in the SOLICIT and a NoAddrsAvail status code in the ADVERTISE response. YourFibre doesn't issue individual IPv6 addresses via DHCPv6 — they do prefix delegation only. Fair enough.
Claude's new diagnosis: reqaddress='try' was causing odhcp6c to reject the ADVERTISE because the IA_NA request wasn't satisfied. The fix was to change it to reqaddress='none'.
I changed it. The loop continued.
Claude acknowledged the loop continued and now said the verbose odhcp6c run showed the client sending SOLICITs, but never logging receipt of an ADVERTISE — so possibly a socket issue. We each ran more diagnostics. Still stuck.
---
Round 3: The Actual Root Cause
Eventually Claude checked the nftables ruleset properly. The input_wan chain - the chain that processes all inbound traffic on the WAN interface — contained exactly four rules:
1. Allow IPv4 UDP port 68 (DHCP renew)
2. Allow IPv4 ICMP echo-request (ping)
3. Allow IPv4 IGMP
4. Jump to reject_from_wan
That's it. There were no IPv6 rules at all... No Allow-DHCPv6, no Allow-MLD, no Allow-ICMPv6-Input. Guess what? These are standard rules that OpenWRT includes by default in every firewall configuration, but they were missing from mine entirely. Cue colourful cursing - this looked promising.
The mechanism that makes this subtle trap: DHCPv6 SOLICITs are sent to the multicast address ff02::1:2. Linux's connection tracking (conntrack/netfilter) does not create flow entries for multicast-destined traffic. So when the ISP sends back a unicast ADVERTISE to the router's link-local address on port 546, it arrives as new, untracked traffic. It doesn't hit the ct state established/related → accept path. It falls straight through to reject_from_wan and is silently dropped. You read that correctly.
odhcp6c never saw a single packet. Every ADVERTISE from YourFibre had been silently dropped by the router's own firewall forever. This was true with reqaddress='try' and the default reqaddress='none'. The reqaddress change had done nothing.
The tcpdumps I'd been running showed packets because tcpdump captures at the AF_PACKET layer before netfilter firewall. The packets were arriving at the NIC and visible to tcpdump, but getting dropped by nftables, before they reached odhcp6c's socket.
##The Fix: Add Firewall Rules
The fix was to add three standard OpenWRT rules to the WAN zone: Allow-DHCPv6 (UDP port 546, IPv6), Allow-MLD (ICMPv6 multicast listener discovery types), and Allow-ICMPv6-Input (NDP, path MTU, error messages). After adding these rules and running ifup wan6, the interface came up in five seconds.
Tue Apr 28 13:41:37 daemon.notice netifd: Interface 'wan6' is setting up now
Tue Apr 28 13:41:39 daemon.notice netifd: Interface 'wan6' is now up
Delegated prefix: 2a10:d582:xxxx::/48. LAN gateway: 2a10:d582:xxxx::1. IPv6 DNS: 2a10:d580::1. Everything working.
IP adjusted to protect the guilty.
---
Round 4: Was reqaddress='none' Even Correct?
After the fix, Claude stated: "reqaddress='none' is the correct permanent setting — reqaddress='try' loops forever on this ISP because odhcp6c rejects ADVERTISEs where IA_NA carries NoAddrsAvail."
I asked, what has become muscle memory now: "Are you sure about that?" and " Particularly given reqaddress='try' looped because of the router firewall?"
Claude paused and worked through the logic, properly this time. Both reqaddress='try' and reqaddress='none' had looped. The loop in both cases was caused by the missing firewall rules. We had never actually tested reqaddress='try' with the firewall fixed.
I asked Claude to test. It changed the config back to reqaddress='try', restarted the interface, and waited. The interface came up in five seconds. Same delegated prefix. Same DNS. Fully working.
Claude's statement that reqaddress='try' was broken on this ISP was wrong. It works fine. The entire loop was the firewall, start to finish. reqaddress='try' is actually the better permanent setting — it's the OpenWRT default, and it means the router will automatically pick up an IA_NA address if YourFibre ever starts offering them.
---
Round 5: The mss_clamping Warning
After the firewall fix, service firewall restart emitted a warning:
Section @zone[1] (wan) specifies unknown option 'mss_clamping'
Claude's initial response: "This is a harmless warning — fw4 ignores unknown options."
Again, I asked: "Are you sure?"
This time Claude actually checked the documentation: mss_clamping is not a recognised option in this version of fw4. This was confirmed by grepping fw4.uc. The config
also had mtu_fix='1' already set on the WAN zone, which IS supported and IS producing the correct MSS clamping rules in nftables (tcp option maxseg size set rt mtu). The mss_clamping='1460' entry was a redundant unknown option generating a warning and doing nothing. Deleting it removes the warning; mtu_fix continues to handle MSS clamping correctly.
Another assumption presented as fact, caught by asking "are you sure?" and insisting on checking.
The follow up email to YouFibre support:
Case number is: SC10016005
Hi,
Erm sorry, but I made a mistake. Please close the support ticket.
The firewall rules had been wiped by an unhelpful Arrogant Idiot (AI).
Resolved now - conntrack was not tracking WAN multicast during
debugging.
Said robot has been egged and floured.
Regards
Matthew
---
What I Learned
AI assistants like Claude are genuinely useful for this kind of work. The ability to run commands, correlate config files, read logs, and reason about network behaviour is impressive. The DHCP audit was solid.
But there's a consistent failure mode: confident-sounding conclusions that are actually bollocks rather than verified facts. "Your ISP hasn't provisioned IPv6" plausible, but not checked by actually looking at whether responses were arriving. "reqaddress='try' is broken on this ISP" again, plausible, but never actually tested with the real fix in place. "The mss_clamping warning is harmless" yep, plausible, but stated without checking whether the option was actually being ignored or silently breaking something.
Every time I pushed back — "are you sure?", "check again", "test it", "give me evidence" — something was revised. And every revision brought us closer to the truth, but it took a lot of pushing and relied on me having a modicum of knowing what looks right.
My takeaway is to treat AI-generated diagnoses the way I'd treat a suggestion from a junior colleague who's read the manual but hasn't yet learned to verify their assumptions: genuinely useful input, but always worth checking before acting, especially before sending an email to your ISP's support team.
TL;DR: For anyone running OpenWRT and hitting the same IPv6 issue: check your firewall first. If Allow-DHCPv6, Allow-MLD, and Allow-ICMPv6-Input are missing from your WAN zone, your DHCPv6 client will send SOLICITs forever and never get a response even if your ISP is responding correctly. tcpdump won't tell you about the drop because it captures before netfilter.
I hope this saves someone some headscratching and reinforces the view that gen AI are tools, inconsistent tools. Ta ta for now.
Matthew
---
Tags: OpenWRT, IPv6, DHCPv6, nftables, home lab, AI tooling, networking, Proxmox
No comments:
Post a Comment