# equery uses dhcpcd
+ + vram : Disable DUID due to volatile media, such as a LiveCD
I had just previously booted to a Damn Small Linux LiveCD when the
trouble started so I'm thinking the CD tried to dhcp from my cable
internet provider without a DUID which caused the provider to change
something which means that I need to disable the DUID from now on?
It's confusing but that's the best I can come up with.
The point is: be careful when using dhcp from a LiveCD. Your system
might act differently the next time you boot the hard drive.
- Grant
--
gento...@gentoo.org mailing list
The dhcpcd was changed recently and not all dhcp servers take kindly to it,
when it uses DUID the way it does (some servers depend on DUID passing on to
them the MAC of the client). The solution I also found was to set the vram
flag.
--
Regards,
Mick
Something must have changed on my ISP's end when my router tried to
dhcp via the Damn Small Linux LiveCD. It had been running dhcp just
fine ever since I switched to this ISP (Cox) and failed every time
after I booted that LiveCD until I enabled vram.
I'm really ignorant on networks. What has changed on the dhcp side so
that *client* behaviour alters *server* behaviour? Isn't this horribly
broken (from the server side), or there is some reason to behave that?
m.
--
gento...@gentoo.org mailing list
I am no less ignorant I'm afraid, but this is how I understand it in simple
terms:
net-misc/dhcpcd-3.1.5-r1 has introduced a usage of DUID which is compliant
with RFC 4361, and creates a client ID (this can be any string uniquely
identifying the client interface). However, a number of DHCP server
implementations expect the DUID to contain the MAC of the client and unless
this is in a particular format the server falls over.
The vrm flag allows the MAC to be used in the DUID field and then the server
is happy to issue an IP address to the client. As an alternative one can try
the dhcpcd -I option to specify the MAC of the client, but when I tried it I
couldn't get it to work.
I guess eventually all dhcp implementations will catch up with this change,
although for now it is bound to create some problems with particular DHCP
servers (cisco being one of them). On the other hand RFC 4361 may be
superseded/reversed, dhcpcd will go back to how it was and the world will be
a simpler place to live and network. :)
HTH.
--
Regards,
Mick
You could try disconnecting your cable modem for about 10 minutes,
ensuring the ISP recognizes that it's offline, and thus remove the
entries in it's DHCP table for your connection.
then when you boot your system normally, it might work like it used to.
--
gento...@gentoo.org mailing list
When the regular os comes back up in this situation, it wants /its/ old
ip back. This might hang on a server restriction on only one ip per
subscriber/mac address, or it might just trigger a bug somewhere.
--
gento...@gentoo.org mailing list