Re: dhcpcd experiments

[Dan Williams <dcbw redhat com>]

On Mon, 2004-12-13 at 22:45 -0500, Bill Moss wrote:
> Experiment 1. In the dhcpcd directory of the NetworkManager CVS and did 
> a make which produces dhcp_test.
> I ran 'dhcp_test eth1' and got
> 
> dhcp_test: dhcp_interface_init: MAC address = 00:0e:35:14:60:d0
> dhcp_test: ClassID  = "Linux 2.6.9-1.681_FC3 i686"
> ClientID = "61.7.1.00.00.00.00.00.00"
> dhcp_test: Broadcasting DHCP_DISCOVER
> dhcp_test: DHCP: Starting request loop
> dhcp_test: DHCP: Sending request packet...
> dhcp_test: DHCP: Sent request packet.
> dhcp_test: DHCP: Waiting for reply...
> dhcp_test: DHCP waiting for data, overall timeout = {1102995483s, 905480us}
> dhcp_test: DHCP waiting for data, remaining timeout = {4s, 999223us}
> dhcp_test: DHCP waiting for data, remaining timeout = {3s, 999737us}
> dhcp_test: DHCP waiting for data, remaining timeout = {2s, 999887us}
> dhcp_test: DHCP waiting for data, remaining timeout = {2s, 40us}
> dhcp_test: DHCP waiting for data, remaining timeout = {1s, 278us}
> dhcp_test: DHCP waiting for data, remaining timeout = {0s, 345us}
> dhcp_test: DHCP: Sending request packet...
> dhcp_test: DHCP: Send timeout
> 
> It would appear that the SMC Barricade never responded with a DHCPOFFER.
> 
> Experiment 2. In went to http://www.phystech.com/download/ and 
> downloaded the source for the lastest version of dhcpcd,
> version 1.3.22-pl4. I compiled and then ran 'dhcpcd -d eth1' and 
> instantly got the output.
> 
> dhcpcd: MAC address = 00:0e:35:14:60:d0
> dhcpcd: your IP address = 192.168.2.3

Ok, this is some useful data.  I've also observed instances where the
built-in DHCP client won't do what we want it to.  They seem related to
the format of the DHCP datagrams.  During the recent re-work of the DHCP
code, I switched from constructing the raw ethernet frames myself in the
dhcpcd code, to letting the kernel & networking layer handle everything
underneath the DHCP datagram itself, something I've come to regret (for
instance, when the vpnc IPSec client is active, the source IP address of
the datagram is the tunnel's IP, not 0.0.0.0 which we've explicitly set
on the card).  I think I may have to revert some of those changes and
return to constructing the whole ethernet frame and shoving that out to
the wire.

Dan