Opened 3 years ago

Last modified 3 years ago

#18273 new defect


Reported by: Catalin Patulea <cronos586@…> Owned by: developers
Priority: normal Milestone:
Component: packages Version: Trunk
Keywords: ipv6 6to4 Cc:


# ubus call network.interface.wan6 status

"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "6to4",
"data": {},
"errors": [{

"subsystem": "6to4",




# ubus call network.interface.wan status

"up": true,
"pending": false,
"available": true,
"autostart": true,
"uptime": 519872,
"l3_device": "eth1",
"proto": "dhcp",
"device": "eth1",
"metric": 0,
"delegation": true,
"ipv4-address": [{

"address": "",
"mask": 27


"ipv6-address": [],
"ipv6-prefix": [],
"ipv6-prefix-assignment": [],
"route": [{

"target": "",
"mask": 24,
"nexthop": "",
"source": "\/0"

}, {

"target": "",
"mask": 0,
"nexthop": "",
"source": "\/0"


"dns-server": [


"dns-search": [],
"inactive": {

"ipv4-address": [
"ipv6-address": [
"route": [
"dns-server": [
"dns-search": [

"data": {


eth1's upstream is a cable modem which, when it has lost coax connection to my ISP, hands out DHCP leases in the range (I know this could be considered "broken" network behaviour but I don't have control over it.) When the coax connection is established, the cable modem starts forwarding DHCP requests to my ISP, which assigns a public IP as shown above.

I *suspect* that "wan" previously came up with 192.168.100.x, 6to4 attempted to come up, but failed due to:

test_6to4_rfc1918 "$ipaddr" && {

proto_notify_error "$cfg" "INVALID_LOCAL_ADDRESS"


Later, I got the public IP, but wan6 was still stuck in INVALID_LOCAL_ADDRESS state.

Can INVALID_LOCAL_ADDRESS be made retriable, so that when 'wan' IP address changes the second time, 6to4 makes another attempt at bringing up wan6?

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by Catalin Patulea <cronoss586@…>

I'm still running into this regularly. IPv6 is not a critical service on my network, but it would be nice for it to work reliably.

To recap what I think is happening:

  • My cable modem reboots for whatever reason (triggered by ISP, or maybe occasional crash, I don't know).
  • OpenWrt notices link cycle, and when link comes back up, starts DHCP client.
  • The *cable modem* gives the router an IP in 192.168.100.* because the CM isn't on the upstream (coax) network yet.
  • OpenWrt acquires this IP, and triggers wan6 6to4 to start, too.
  • 6to4 notices the RFC1918 and wedges wan6 in 'INVALID_LOCAL_ADDRESS' state.
  • Somehow (not clear on this part), when the cable modem registers on the network, OpenWrt acquires a new DHCP lease, with a valid IPv4 public routable address. This lease comes from further up in the network (cable modem switches to DHCP relaying). If 6to4 retried at this point, it would succeed and bring up IPv6.

Is there a recommended workaround here? I do want to have connectivity to my modem before it registers on the coax network.

Can 'INVALID_LOCAL_ADDRESS' be made retriable (I think I saw other errors that are retriable, and could adapt that handling), so that wan6 retries after wan gets its real public IPv4?

Add Comment

Modify Ticket

as new .

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.