1 |
On Friday 07 December 2007, b.n. wrote: |
2 |
> Mick ha scritto: |
3 |
> >> The point is: be careful when using dhcp from a LiveCD. Your system |
4 |
> >> might act differently the next time you boot the hard drive. |
5 |
> > |
6 |
> > The dhcpcd was changed recently and not all dhcp servers take kindly to |
7 |
> > it, when it uses DUID the way it does (some servers depend on DUID |
8 |
> > passing on to them the MAC of the client). The solution I also found was |
9 |
> > to set the vram flag. |
10 |
> |
11 |
> I'm really ignorant on networks. What has changed on the dhcp side so |
12 |
> that *client* behaviour alters *server* behaviour? Isn't this horribly |
13 |
> broken (from the server side), or there is some reason to behave that? |
14 |
|
15 |
I am no less ignorant I'm afraid, but this is how I understand it in simple |
16 |
terms: |
17 |
|
18 |
net-misc/dhcpcd-3.1.5-r1 has introduced a usage of DUID which is compliant |
19 |
with RFC 4361, and creates a client ID (this can be any string uniquely |
20 |
identifying the client interface). However, a number of DHCP server |
21 |
implementations expect the DUID to contain the MAC of the client and unless |
22 |
this is in a particular format the server falls over. |
23 |
|
24 |
The vrm flag allows the MAC to be used in the DUID field and then the server |
25 |
is happy to issue an IP address to the client. As an alternative one can try |
26 |
the dhcpcd -I option to specify the MAC of the client, but when I tried it I |
27 |
couldn't get it to work. |
28 |
|
29 |
I guess eventually all dhcp implementations will catch up with this change, |
30 |
although for now it is bound to create some problems with particular DHCP |
31 |
servers (cisco being one of them). On the other hand RFC 4361 may be |
32 |
superseded/reversed, dhcpcd will go back to how it was and the world will be |
33 |
a simpler place to live and network. :) |
34 |
|
35 |
HTH. |
36 |
-- |
37 |
Regards, |
38 |
Mick |