Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#388 - odhcpd: A default route is present but there is no public prefix on br-lan thus we don't an #5491

Closed
openwrt-bot opened this issue Jan 15, 2017 · 21 comments
Labels

Comments

@openwrt-bot
Copy link

dtaht:

Supply the following if possible:

  • Device problem occurs on: uaplite connecting to archerc7v2
  • Software versions of LEDE release, packages: head as of today

I do have dnsmasq-full installed and this:

config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'

(I will back off dnsmasq-full now that I've learned that the flakyness was triggered by the ra going away, but I had long assumed dnsmasq won't do ras unless you tell it accept_ra. Should I try making odhcpd the main dhcpv4 server?)

  • Steps to reproduce:

Topology:

ComcastModem -> archerc7v2 -> uap-lite -> wifi

odhcpd every ~minute says "A default route is present but there is no public prefix on br-lan thus we don't announce a default route!", even though showing ip -6 addr show shows

24: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fdaf:dc63:6de9:10::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 2601:646:4180:elided::1/64 scope global noprefixroute dynamic
valid_lft 332453sec preferred_lft 332453sec
inet6 fe80::32b5:c2ff:fe75:7faa/64 scope link
valid_lft forever preferred_lft forever

as fast as I can poll it.

The router announcement shows an advertised lifetime of 0 alternating with 64k every 30sec or so.

But for no reason I understand that is seemingly ok. My IPv6 connectivity seems to keep working.

BUT:

Add a client attempting to get a dhcpv6-pd address further downstream, and failing,
and all hell breaks loose.

Snipping from the log

Sat Jan 14 19:51:25 2017 daemon.info dnsmasq-dhcp[3964]: DHCPDISCOVER(br-lan) 80:2a:a8:86:34:17 
Sat Jan 14 19:51:25 2017 daemon.info dnsmasq-dhcp[3964]: DHCPOFFER(br-lan) 172.26.16.241 80:2a:a8:86:34:17 
Sat Jan 14 19:51:25 2017 daemon.info dnsmasq-dhcp[3964]: DHCPDISCOVER(br-lan) 80:2a:a8:86:34:17 
Sat Jan 14 19:51:25 2017 daemon.info dnsmasq-dhcp[3964]: DHCPOFFER(br-lan) 172.26.16.241 80:2a:a8:86:34:17 
Sat Jan 14 19:51:25 2017 daemon.info dnsmasq-dhcp[3964]: DHCPREQUEST(br-lan) 172.26.16.241 80:2a:a8:86:34:17 
Sat Jan 14 19:51:25 2017 daemon.info dnsmasq-dhcp[3964]: DHCPACK(br-lan) 172.26.16.241 80:2a:a8:86:34:17 
Sat Jan 14 19:51:26 2017 daemon.warn odhcpd[1047]: A default route is present but there is no public prefix on br-lan thus we don't announce a default route!
Sat Jan 14 19:51:26 2017 daemon.warn odhcpd[1047]: DHCPV6 SOLICIT IA_NA from 00030001802aa8863417 on br-lan: no addresses available 
Sat Jan 14 19:51:26 2017 daemon.warn odhcpd[1047]: DHCPV6 SOLICIT IA_PD from 00030001802aa8863417 on br-lan: no prefix available 
Sat Jan 14 19:51:28 2017 daemon.warn odhcpd[1047]: DHCPV6 SOLICIT IA_PD from 00030001802aa8863417 on br-lan: no prefix available 

At this point (a few seconds before I see the solicit in the log) the ra induced route is withdrawn and all hosts lose ipv6 connectivity for about 30 seconds. (the pd request also fails)

64 bytes from prod.lwn.net: icmp_seq=888 ttl=50 time=78.5 ms
From prod.lwn.net icmp_seq=889 Destination unreachable: Unknown code 5
From prod.lwn.net icmp_seq=890 Destination unreachable: Unknown code 5
From prod.lwn.net icmp_seq=891 Destination unreachable: Unknown code 5
From prod.lwn.net icmp_seq=892 Destination unreachable: Unknown code 5
...
From prod.lwn.net icmp_seq=920 Destination unreachable: Unknown code 5
64 bytes from prod.lwn.net: icmp_seq=921 ttl=50 time=81.1 ms
64 bytes from prod.lwn.net: icmp_seq=922 ttl=50 time=82.7 ms

And it repeats about every 1-2 minutes. Believe me, having ipv6 working only 50-75% of the time is maddening!

http://www.taht.net/~d/dhcpv6bug/ipv6advert.png - the normal advert

http://www.taht.net/~d/dhcpv6bug/ipv6retract.png - then a short one with lifetime 0

There's a packet capture in the same dir.

...

While debugging and simplifying this today I also eliminated the multicast-unicast code as proximate causes.

    option igmp_snooping '0'      
    option multicast_to_unicast '0'

...

I've seen a few other bug reports like this around, perhaps I've made some progress. (I was originally triggering this chaos with the edgerouter with dhcp-pd requests, now it's lede-head throughout, and pure ethernet rather than a wifi bridge) There has occasionally been prefixes available, but not at the moment, and the effect is the same with or without a prefix being offered.

So my guess is odhcp is not successfully polling for the addresses on the interface (sometimes). Could be subtler.

@openwrt-bot
Copy link
Author

dtaht:

root@lorna-gw:~# ip -6 route
default from 2001:558:6045:bd:c4f5:f41f:elide:297b via fe80::201:5cff:fe63:e446 dev eth0 proto static metric 512 pref medium
default from 2601:646:4180:elided::/64 via fe80::201:5cff:fe63:e446 dev eth0 proto static metric 512 pref medium
2601:646:4180:elided::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2601:646:4180:elided::/64 dev lo proto static metric 2147483647 error -148 pref medium

I will be rebooting this box in a bit. In an earlier run, I WAS getting a /60 from upstream of me. Now I only have a /64 (and thus dhcpv6-pd should be refused) but I shouldn't lose all connectivity elsewhre. while being refused....

@openwrt-bot
Copy link
Author

dtaht:

In dhcp, adding this

    option ra_default '1' 

"fixed it". The uap gets a ula/64. I am no longer getting a /60 from comcast (40+ reboots today), but perhaps that will fix itself overnight, and I can re-re-resume testing.

That said, I think the default route and available prefix check in odhcpd is busted.

@openwrt-bot
Copy link
Author

dtaht:

And this morning I got my first ever dhcp-pd request inside this network to succeed on a real /60.

I will go back and recomplexify, re-enabling the mcast bridge code, moving the pd requestor back to the other side of the bridge, and try to see if being out of ips in the request pool was also a 'cause of the problem. This issue was originally triggered by my trying to put an edgerouter in place (which still crashes horribly) running their default os. I'll put up another couple lede boxes on the net instead, each requesting a subnet.

I'm not in a position to hack directly on odhcp in lede at the moment.

@openwrt-bot
Copy link
Author

EricLuehrsen:

Confirm "me too." odhcpd will delegate for a few minutes then withdraw. TP-LINK WDR3600 and Archer C7. I configured odhcpd+unbound (no dnsmasq) on the head (C7), and dnsmasq-full (no odhcpd) on the extender (WDR3600). I find that while dnsmasq doesn't have all the IP6 features of odhcpd, the DHCPv6 / RA features it does have are more flexible and work more robustly including off-standard clients.

"ra_default 1" will announce a default route, even if WAN6 fails to get an address. Therefore fail over will need to time out on each new web page, rather than assume IP4.

--Side note on Comcast DHCP to get you testing faster. The leases are for 7 days and default delegation is /64. So if you don't pre-configure /60 request before you plug a box in, youre temporarily stuck, and you need to follow few steps. (1) unplug the cable modem. (2) change your WAN MAC. (3) set your prefix request /60. (4) plug in your cable modem.

Comcast Modem -> C7 (AP) -> Wifi -> (Client) WDR (AP) -> Wifi

@openwrt-bot
Copy link
Author

dedeckeh:

Can you attach the complete output of logread in the described error situation ?
The fact odhcpd logs "A default route is present but there is no public prefix on br-lan thus we don’t announce a default route!" indicates odhcpd is triggered probably by an address change which in its turn can be due a wan6 interface change

@openwrt-bot
Copy link
Author

dtaht:

btw: how do you change something to confirmed, and up the priority? Being able to DDOS an entire ipv6 network with a single legit packet, emitted by default by a lede install, is not good.

Updating this comment: the DDOS was essentially coming from the edgerouter on the network. Still hosing the whole net to this extent (netifd's state machine?), was kind of bad...

and I haven't added back in all the stuff I ripped out yet.

@openwrt-bot
Copy link
Author

dtaht:

I have a theory. In testing the edgerouter box, it (using wide I think), goes crazy flooding odhcpd. This is of course, bad in itself (I'll report to those guys), but somewhere in there the ra announcement on the local net goes away. (not sure if this is before or after)

Could odhcpd not be servicing packets from other sources in it's select loop? (e.g. always returning to the first file descriptor returned by select) or the dhcpv6-pd section of the code staying within it's "bit" and not letting other stuff odhcpd is supposed to handle be serviced?

yes, there's also lede issues. I think I have a couple, but need to test each one individually.

@openwrt-bot
Copy link
Author

dtaht:

OK, I have narrowed it down still further - taking the local pd attempt out of the loop. Down to just the one comcast modem - lede router - one linux client. As to why ipv6 was working at all, all this time, for anyone on comcast (or this particular modem) my linux box will see a retraction, and its expires timer will run to -30 seconds, then expire. And odhcp almost always gets a new one out there in roughly a minute. (except when getting flooded or other problems that I was triggering that made it more obvious!).

The "not announcing" thing we started with was a symptom... I think. Even with ra_default 1 I'm still watching my ra on the client appear and disappear. Attached are two tcpdumps the dhcpv6 one is what I'm seeing from comcast, the local-comcast one is what I'm sending internally.

tcpdump -i br-lan -w /tmp/local-comcast.cap icmp6 or udp port 546 or udp port 547

packet 17 makes things go bye-bye, packet 38 brings things back to life.

Mon Jan 16 17:25:47 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:25:50 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:25:53 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:25:54 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:25:55 2017 daemon.debug odhcpd[1074]: Received 72 Bytes from kernel%netlink
Mon Jan 16 17:25:55 2017 daemon.debug odhcpd[1074]: Received 116 Bytes from kernel%netlink
Mon Jan 16 17:25:55 2017 daemon.debug odhcpd[1074]: Received 136 Bytes from kernel%netlink
Mon Jan 16 17:25:55 2017 daemon.debug odhcpd[1074]: Received 136 Bytes from kernel%netlink

Something happened here. Also the route to the main ULA disappears

lorna-gw: # fdaf:dc63:6de9:8::/64 via fe80::822a:a8ff:fe86:3417 dev br-lan proto static metric 1024 pref medium vanishes

and there is no fe80::822a:a8ff:fe86:3417? The switch?

Mon Jan 16 17:25:55 2017 daemon.info dnsmasq[4724]: read /etc/hosts - 4 addresses
Mon Jan 16 17:25:55 2017 daemon.info dnsmasq[4724]: read /tmp/hosts/odhcpd - 0 addresses
Mon Jan 16 17:25:55 2017 daemon.info dnsmasq[4724]: read /tmp/hosts/dhcp.cfg02411c - 4 addresses
Mon Jan 16 17:25:55 2017 daemon.info dnsmasq-dhcp[4724]: read /etc/ethers - 0 addresses
Mon Jan 16 17:25:55 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:25:56 2017 daemon.debug odhcpd[1074]: Sent 64 bytes to ff02::1%br-lan

and this sends that short ra packet presumably retracting everything and my expires timer starts counting down 0, -1, -2 ...

Mon Jan 16 17:25:57 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:25:58 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:25:58 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:00 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:01 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:01 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:03 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:07 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:11 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:14 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:17 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:20 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:22 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:22 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:23 2017 daemon.debug odhcpd[1074]: Received 88 Bytes from kernel%netlink
Mon Jan 16 17:26:24 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:25 2017 daemon.debug odhcpd[1074]: Received 72 Bytes from kernel%netlink
Mon Jan 16 17:26:25 2017 daemon.debug odhcpd[1074]: Received 116 Bytes from kernel%netlink
Mon Jan 16 17:26:27 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:27 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:27 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:28 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:31 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:34 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:34 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:34 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:37 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:41 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:44 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:48 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:50 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:51 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:54 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0
Mon Jan 16 17:26:55 2017 daemon.debug odhcpd[1074]: Received 72 Bytes from kernel%netlink
Mon Jan 16 17:26:55 2017 daemon.debug odhcpd[1074]: Received 116 Bytes from kernel%netlink
Mon Jan 16 17:26:55 2017 daemon.debug odhcpd[1074]: Received 136 Bytes from kernel%netlink
Mon Jan 16 17:26:55 2017 daemon.debug odhcpd[1074]: Received 136 Bytes from kernel%netlink
Mon Jan 16 17:26:55 2017 daemon.info dnsmasq[4724]: read /etc/hosts - 4 addresses
Mon Jan 16 17:26:55 2017 daemon.info dnsmasq[4724]: read /tmp/hosts/odhcpd - 1 addresses
Mon Jan 16 17:26:55 2017 daemon.info dnsmasq[4724]: read /tmp/hosts/dhcp.cfg02411c - 4 addresses
Mon Jan 16 17:26:55 2017 daemon.info dnsmasq-dhcp[4724]: read /etc/ethers - 0 addresses
Mon Jan 16 17:26:56 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:56 2017 daemon.debug odhcpd[1074]: Received 76 Bytes from kernel%netlink
Mon Jan 16 17:26:56 2017 daemon.debug odhcpd[1074]: Sent 176 bytes to ff02::1%br-lan
Mon Jan 16 17:26:58 2017 daemon.debug odhcpd[1074]: Received 144 Bytes from fe80::201:5cff:fe63:e446%eth0

And then we're back!

@openwrt-bot
Copy link
Author

dtaht:

I've done a clean reboot. Got rid of everything (the above was after mucho hacking). Got rid of all firewalling for ipv6 icmp also. Andddddd... I have not seen it reload dns or odhcp in 10 minutes. Perhaps the netifd state got corrupted by the other stuff.

So, now I have a nice, simple, 1 machine network, with dhcp-pd supplying up to a /60 to that lone machine. Not particularly useful, but it is kind of nice to see an RA last for 10 whole minutes!

@openwrt-bot
Copy link
Author

dtaht:

and I got a single lede box up internally with dhcp-pd. :woot:

given all the hell I just went through rebooting the universe, I think it would be nice to be able to advertise even ULAs with a shorter lifetime than forever. Can't always reboot everything.

And be able to override the default supplied leasetime (doesn'tseem to respect "leasetime" in the dhcp file)

inet6 2601:646:4180:elided:elided:a8ff:fe86:3417/64 scope global noprefixroute dynamic 
   valid_lft 341581sec preferred_lft 341581sec

@openwrt-bot
Copy link
Author

dtaht:

OK. I am going to leave it as is overnight, and finally run a few flent tests to stress out the devices I'd intended to stress out.

I will go back to adding more lede routers tomorrow, after writing everything down and backing things up.

@openwrt-bot
Copy link
Author

dtaht:

And I got tempted to deal with the simple config... and a couple reboots of the second dhcp-pd lede router... I'm back where ra's come and go again. At one level, I'm weirdly happy. I can reproduce this at leisure...

... but all I wanted to do originally was run a few ipv6 tests under flent overnight. So. Rebooting the universe again....

@openwrt-bot
Copy link
Author

@openwrt-bot
Copy link
Author

dtaht:

I (accidentally) tested this again. It takes 3 reboots of an internal lede router requesting dhcp-pd for the ra disappearance to start showing up with the typical pattern of this, repeating.

Thu Jan 19 11:03:21 2017 daemon.debug odhcpd[1080]: Received 136 Bytes from kernel%netlink
Thu Jan 19 11:03:21 2017 daemon.info dnsmasq[13844]: read /etc/hosts - 4 addresses
Thu Jan 19 11:03:21 2017 daemon.info dnsmasq[13844]: read /tmp/hosts/odhcpd - 2 addresses
Thu Jan 19 11:03:21 2017 daemon.info dnsmasq[13844]: read /tmp/hosts/dhcp.cfg02411c - 4 addresses
Thu Jan 19 11:03:21 2017 daemon.info dnsmasq-dhcp[13844]: read /etc/ethers - 0 addresses
Thu Jan 19 11:03:22 2017 daemon.debug odhcpd[1080]: Sent 176 bytes to ff02::1%br-lan

I do not know where the state machine is or what it should look like.. BUT, a CLUE!

I see while it is down ifstatus shows the external ipv6 is gone

and ifstatus while it is up - shows the external

In either case, I do have ULAs on the link and these show as gone, too.

Let me put in some commented ifstatus messages.

@openwrt-bot
Copy link
Author

dtaht:

this is where life is "normal" (meaning that I'm in a failure mode that is retracting and resubmitting ras), me doing an ifstatus lan, then a ifstatus wan

ifstatus lan

{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 48915,
"l3_device": "br-lan",
"proto": "static",
"device": "br-lan",
"updated": [
"addresses"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "172.26.16.1",
"mask": 24
}
],
"ipv6-address": [

],
"ipv6-prefix": [
	
],
"ipv6-prefix-assignment": [
	{
		"address": "2601:646:4180:a0::",
		"mask": 61,
		"preferred": 296843,
		"valid": 296843,
		"local-address": {
			"address": "2601:646:4180:a0::1",
			"mask": 64
		}
	},
	{
		"address": "fdaf:dc63:6de9:8::",
		"mask": 61,
		"local-address": {
			"address": "fdaf:dc63:6de9:8::1",
			"mask": 64
		}
	}
],
"route": [
	
],
"dns-server": [
	
],
"dns-search": [
	
],
"inactive": {
	"ipv4-address": [
		
	],
	"ipv6-address": [
		
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	]
},
"data": {
	
}

}

This is wan address:

{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 48772,
"l3_device": "eth0",
"proto": "dhcp",
"device": "eth0",
"updated": [
"addresses",
"routes",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "69.181.214.165",
"mask": 22
}
],
"ipv6-address": [

],
"ipv6-prefix": [
	
],
"ipv6-prefix-assignment": [
	
],
"route": [
	{
		"target": "69.181.212.1",
		"mask": 32,
		"nexthop": "0.0.0.0",
		"source": "69.181.214.165\/32"
	},
	{
		"target": "0.0.0.0",
		"mask": 0,
		"nexthop": "69.181.212.1",
		"source": "69.181.214.165\/32"
	}
],
"dns-server": [
	"75.75.75.75",
	"75.75.76.76"
],
"dns-search": [
	"hsd1.ca.comcast.net."
],
"inactive": {
	"ipv4-address": [
		
	],
	"ipv6-address": [
		
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	]
},
"data": {
	"leasetime": 323904
}

}

@openwrt-bot
Copy link
Author

dtaht:

And this is during the ra retraction. I will reboot in a bit to see what things are like while things are actually working.

{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 48944,
"l3_device": "br-lan",
"proto": "static",
"device": "br-lan",
"updated": [
"addresses"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "172.26.16.1",
"mask": 24
}
],
"ipv6-address": [

],
"ipv6-prefix": [
	
],
"ipv6-prefix-assignment": [
	{
		"address": "2601:646:4180:a0::",
		"mask": 61,
		"preferred": 296814,
		"valid": 296814,
		"local-address": {
			"address": "2601:646:4180:a0::1",
			"mask": 64
		}
	},
	{
		"address": "fdaf:dc63:6de9:8::",
		"mask": 61,
		"local-address": {
			"address": "fdaf:dc63:6de9:8::1",
			"mask": 64
		}
	}
],
"route": [
	
],
"dns-server": [
	
],
"dns-search": [
	
],
"inactive": {
	"ipv4-address": [
		
	],
	"ipv6-address": [
		
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	]
},
"data": {
	
}

}
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 48797,
"l3_device": "eth0",
"proto": "dhcp",
"device": "eth0",
"updated": [
"addresses",
"routes",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "69.181.214.165",
"mask": 22
}
],
"ipv6-address": [

],
"ipv6-prefix": [
	
],
"ipv6-prefix-assignment": [
	
],
"route": [
	{
		"target": "69.181.212.1",
		"mask": 32,
		"nexthop": "0.0.0.0",
		"source": "69.181.214.165\/32"
	},
	{
		"target": "0.0.0.0",
		"mask": 0,
		"nexthop": "69.181.212.1",
		"source": "69.181.214.165\/32"
	}
],
"dns-server": [
	"75.75.75.75",
	"75.75.76.76"
],
"dns-search": [
	"hsd1.ca.comcast.net."
],
"inactive": {
	"ipv4-address": [
		
	],
	"ipv6-address": [
		
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	]
},
"data": {
	"leasetime": 323904
}

}

@openwrt-bot
Copy link
Author

dtaht:

what had seemed to be significant is the wan interface not having an ipv6 addrs. Well, that's on wan6.

diffing the above, yielded nothing, diffing the ifstatus wan6 results, nothing either.

I will add in a known good one after a reboot.....

@openwrt-bot
Copy link
Author

dtaht:

openwrt/odhcpd#79 has the same bug report essentially.

And it was even bisected! Yea!!!!

Big bisect. Booo!

This totally explains why I'd not seen this (very often) before trying to deploy lede-head at more scale.

@openwrt-bot
Copy link
Author

dedeckeh:

odhcpd has been patched to create extra syslog traces for trouble shooting (https://git.lede-project.org/?p=project/odhcpd.git;a=summary).
Meanwhile lede trunk has been updated to the latest odhcpd version (https://git.lede-project.org/?p=source.git;a=commit;h=fa66900eeb213186a7478737ae54e1e6e9bff3cd).
Add the option -l 6 in the odhcpd init script in order to enable the extra syslog traces

@openwrt-bot
Copy link
Author

dtaht:

I will get on this friday at the latest. Thx

@openwrt-bot
Copy link
Author

dtaht:

I have temporarily abandoned odhcpd to dnsmasq in favor of getting stuff getting addresses/prefixes from outside (6rd, odhcp6c) working well first.

and giving up on PD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant