dhcpcd-discuss

On 2017/04/22 10:00, Roy Marples wrote:
> Hi Stuart
> 
> On 22/04/17 00:13, Stuart Henderson wrote:
> > I ran into a small problem when updating, the new file locations
> > meant I get a new DUID and my Zen (my ISP)'s dhcpv6-pd server refused
> > to give me a lease right away with this.
> 
> Yeah, that does suck.
> I didn't really want to move the file locations, but with people just
> cloning new VM's from a master /etc they had to be moved out of there
> just to solve a lack of proper management from users.

Ouch! So they probably use common ssh host keys too.

> > I haven't yet tested what would happen if I bounce the VDSL connection
> > and retry at that point or leave it to see if it works eventually (I would
> > certainly hope so!)
> 
> Well, that really depends on upstream ISP.
> 
> >, but am wondering if it might make sense to help
> > ease the transition by reading the value from /etc/dhcpcd.duid as a
> > fallback iff /var/db/dhcpcd/duid doesn't exist at startup.
> 
> I thought about that as well, but rejected it as it's a lot of effort in
> dhcpcd itself for something that is effectively one shot.
> This is better handled by the packaging.
> 
> dhcpcd copies the old files over via it's Makefile, so a full `make
> install` from source is fine (as long as it's installing to / and not
> some destdir):
> https://dev.marples.name/source/dhcpcd/browse/master/src/Makefile;85a4d9004e12fd2696a29e050c4df662dc603068$92

Fair enough, I'll do that too.

> Fixed the silly error appending here:
> https://dev.marples.name/rDHC24abc42d92cfbd3e4681d54c8ad62af6dc7adc92

Thanks.

> > # zen
> > interface pppoe1
> >   iaid 1
> >   ia_pd 2 vlan2/1 vlan3666/2 vlan5/3
> 
> You might want to use different iaid's for your vlans to remove those
> warnings:
> (iaid is based on MAC address)
> 
> interface vlan2
> 	iaid 2
> 
> interface vlan3666
> 	iaid 3666
> 
> interface vlan5
> 	iaid 5
> 
> I should probably try and add some code to special case vlan, but I'm
> not sure (and not checked either) if I can work out it's a vlan from
> userland.

As far as OpenBSD goes, calling ioctl SIOCGVNETID with struct ifreq
and checking for ifr_vnetid > 0 might be a good way. It will be set to
the vlan tag number on a vlan interface, and also act as a stable id
for vxlan(4) interfaces (http://man.openbsd.org/vxlan) - these do
have a MAC address but it's typically randomly generated.

Example code in getvnetid() in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/ifconfig/ifconfig.c?rev=HEAD&content-type=text/x-cvsweb-markup

The only problem is where you have the same vnetid number on multiple
interfaces (e.g. vlan with a certain tag number on multiple interfaces),
but it would cope with the common cases automatically, and is no worse
than the status quo if there are duplicates.