Hi all, I'm new to OpenWRT and trying to set it up on a Sky UK FTTP connection (Openreach). Out of the box it acquires an IPv6 address and v6 connectivity works on the LAN, but it acquires an invalid 100.x.x.x v4 address, and IPv4 connectivity is broken.
After my own research, I believe this is because of Sky's use of MAP-T, and seemingly a bug?? in OpenWRT that effectively advertises MAP-T compatibility with DHCPv6 option 95 when the stock install does not support it. I'll link some stuff below to show where I've found all this. I'm not super knowledgeable about DHCPv6 so my use of terminology might be off.
I've played with a few options trying to get this to work but can't figure it out. I tried installing the map package, which does cause another virtual interface to be shown so I assume it's partly working, but v4 connectivity is still broken, both from the router and computer on LAN.
I suppose to fix this I would need to fix the buggy DHCP option 95 request (ideally - as Sky UK don't appear to force MAP-T if it's not supported).
Or alternatively, how could I go about getting MAP-T to function correctly. The install is almost stock, the only change I've made being to change LAN subnet to 192.168.0.0/24
Any suggestions? Thanks for reading!
Links for information: https://helpforum.sky.com/t5/Broadband/Maybe-map-t-problem/m-p/5177542#M543579
Page 23 (Sky specifically mention OpenWRT from their testing): https://indico.netuk.org/event/1/contributions/10/attachments/7/52/Sky%20UK%20MAP-T%20NetUK%20July%202024.pdf
OK just a bit more information that might be useful. If I disable the DHCPv4 interface (or perhaps regardless of it), it looks like MAP-T is doing something if I check the routing table etc - an IP which seems to be from Sky's IPv4 range does show up, and I see some NAT rules created. I also get this line in the system logs (IPs blanked with x):
Tue Mar 3 21:54:05 2026 kern.info kernel: [ 57.355078] nat46: configure device (map-wan6_4) with 'local.style MAP local.v4 94.9.xxx.x/22 local.v6 2a06:xxxx:xxxx::/43 local.ea-len 13 local.psid-offset 6 remote.v4 0.0.0.0/0 remote.v6
Can only attach one picture so routing table it is:
Edit: and one more bit of information: traceroutes to v4 addresses appear to work from inside OpenWRT, but not pings (but I recall reading something about a separate ICMP issue so could just be that). But nothing from PC on LAN.
And I've just found when I attept a 1.1.1.1 ping from LAN, I get:
Tue Mar 3 22:31:29 2026 kern.warn kernel: [ 2070.971227] [nat46] Could not translate v4->v6
Sorry for info spam, I'm actively working on this so posting as I discover stuff.
OK I think I've sorted it. Whichever page I downloaded the firmware from, it appeared the 24.x was the newest version, but I've located the 25.x version and gave it a try. It works immediately, no MAP-T (option 95) requested, and as a result it seems to work out of the box with no further configuration needed. I'll post back if I find any more information, but wanted to update in case anyone else has the same issue.
There was a bug https://github.com/openwrt/openwrt/issues/14056 whereby the DHCPv6 client requested MAP-T even though it wasnt actually supported. This seems to have been fixed in mid 2025 so that MAP-T is only requested if the ‘map’ package is installed (by default its not). This fix probably wasnt in your 24.x version but did make it into the 25.12 version
1 Like
Yes that seems to be the case thankfully. I spent some time trying to get MAP-T to work with the map package without success. It seems I was close as I had some IPv4 connectivity from router but not LAN, something broken with NAT I assumed.
I then focussed my effort into trying to work around the bug myself somehow (as MAP-T isn't mandatory on my ISP) but couldn't find a way to stop odhcp6c from requesting options; I found the reqopts option to add options, but nothing to take them away. I initially assumed a config file was requesting option 95 with reqopts and thought I might be able to remove it, but it seems this was default behaviour. I did come across an option (defaultreqopts 0 I think?) that strips options but the would have to add everything back manually. And it didn't seem particularly well-documented in order to do that; everything I could find was in Google's AI suggestions or linked forum posts.
I did try to follow the github issue tracker but got lost as the linked tickets were either open or unresolved.
But either way, as much as it was odd default behaviour, at least it's resolved in the latest version.
