ISC dhclient vs Netgear and PD

I'm in the ipv6 trial, and this is on the trial Netgear CG3000DCR modem, not on the SMC.

Or are you implying that this is actually the SMC replying - they are after all on the same L2 network segment...?

Maybe the problem is the multicast nature of the request packet...

But that doesn't make any sense, since the src mac 11:22:33:44:55:66 of the final failing reply belongs to the Netgear.

Hi MazePallas.  At this time IPv6 for Business Customers is still in the trial phase and is limited to trial participants only. Also IPv6 functionality is not enabled on the SMCD3G.

Thank You

What device are you connecting to the trial device?

It's a Fedora 20 x86_64 Linux box with "dhclient-4.2.6-1.fc20.x86_64' which is the "ISC DHCP client daemon".

I'm using a bare minimum config file;

/var/run/dhclient6.${DEV}.pd.conf contains:
send dhcp-client-identifier = hardware;

(perhaps there's something missing in there?)

The command line invocation:

dhclient -6 -P -d -v -pf "/var/run/dhclient6.${DEV}.pd.pid" -lf "/var/run/dhclient6.${DEV}.pd.leases" -cf "/var/run/dhclient6.${DEV}.pd.conf" -sf "/tmp/pd6.sh" "${DEV}"

(pid and lease files start empty, pd6.sh just prints command line and enviornment variables)

PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT: X-- IA_PD cc:dd:ee:ff
XMT: | X-- Request renew in +3600
XMT: | X-- Request rebind in +5400
XMT: Solicit on ${DEV}, interval 1070ms.
RCV: Advertise message on ${DEV} from fe80::1322:33ff:fe44:5566.
RCV: X-- IA_PD cc:dd:ee:ff
RCV: | X-- starts 1396938379
RCV: | X-- t1 - renew +15
RCV: | X-- t2 - rebind +45
RCV: | X-- [Options]
RCV: | | X-- IAPREFIX 2601:yyyy:yyyy:yy82::/64
RCV: | | | X-- Preferred lifetime 30.
RCV: | | | X-- Max lifetime 60.
RCV: X-- Server ID: 00:03:00:01:11:22:33:44:55:66
RCV: Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC: X-- Initial candidate 00:03:00:01:11:22:33:44:55:66 (s: 154, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT: X-- IA_PD cc:dd:ee:ff
XMT: | X-- Requested renew +3600
XMT: | X-- Requested rebind +5400
XMT: | | X-- IAPREFIX 2601:yyyy:yyyy:yy82::/64
XMT: | | | X-- Preferred lifetime +7200
XMT: | | | X-- Max lifetime +7500
XMT: V IA_PD appended.
XMT: Request on ${DEV}, interval 980ms.
RCV: Reply message on ${DEV} from fe80::1322:33ff:fe44:5566.
RCV: X-- IA_PD cc:dd:ee:ff
RCV: | X-- starts 1396938380
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: X-- Server ID: 00:03:00:01:11:22:33:44:55:66
IA_PD status code NotOnLink.
PRC: Soliciting for leases (INIT).

(and repeat)

The '82' above is because this is the 3rd DUID I've asked with -- the DUID is based off of hardware mac address and dhclient startup time, and is stored in the lease file, if I delete the lease file, next time I start dhclient it generates a new one and I get replies from the cablemodem with the next value of '82', If I don't delete the lease and restart dhclient I keep on getting the same value of '82', so the modem is somehow tying the '82' to the DUID (and remembering, haven't tried rebooting the modem).

(Side note: stuff works and I get a valid answer if I pass -S instead of -P asking for stateless configuration (dns servers) instead of prefix delegation but obviously that's not interesting here)

Oh I should probably add that for SELinux to not complain one must:

chcon unconfined_u:''object_r:dhcpc_var_run_t:s0 "/var/run/dhclient6.${DEV}.pd.conf"
chcon system_u:''object_r:dhcpc_exec_t:s0 /tmp/pd6.sh

btw, just tried with the wide dhcp client and appear to hit the same problem:

...

Apr/08/2014 17:32:09: update_ia: status code for PD-0: not on-link
Apr/08/2014 17:32:09: update_ia: IA PD-0 is invalidated

... and loop

I have not forgot about you..  I am testing this as well, are you tring to get a PD assigned to yourself?

🙂

I'm trying to figure out how to get my netgear wndr3800 router/nat/gateway to do PD (it's a super highly customized openwrt image).  Since that's hard I plumbed some vlans through it and the netgear gs108tv2 switch and have been trying to first get this to work on a real linux desktop (still - having no luck).

At this point until I hear otherwise I'm going to just assume there's bugs in the cablemodem firmware since I can't think of any other explanation.  So I've put this on the back burner.  That said my router needs to get upgraded to the latest OpenWrt anyway (and I've been putting that off for years...) since the current kernel on it doesn't do stateful ipv6 firewalling, so I'm currently working on that.