> > [EMAIL PROTECTED]:~/Projects/synce/usb-rndis-lite$ sudo dhclient eth3 > > Internet Systems Consortium DHCP Client V3.0.6 > > Copyright 2004-2007 Internet Systems Consortium. > > All rights reserved. > > For info, please visit http://www.isc.org/sw/dhcp/ > > > > Listening on LPF/eth3/80:00:60:0f:e8:00 > > Sending on LPF/eth3/80:00:60:0f:e8:00 > > Sending on Socket/fallback > > DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 5 > > DHCPOFFER from 169.254.2.1 > > DHCPREQUEST on eth3 to 255.255.255.255 port 67 > > DHCPACK from 169.254.2.1 > > bound to 169.254.2.2 -- renewal in 1260637 seconds. > > What you're witnessing is, i'm guessing, zero-configuration, i say that > because of the IP addresses involved (the 169.254/16 range), i did some > quick checking, this is described in RFC3927. > > Also note that Avahi implements a plugin for dhclient to support > RFC3927. > > I haven't read the specifics yet of both, but here are the links: > RFC3927: http://www.ietf.org/rfc/rfc3927.txt > Avahi: http://avahi.org/wiki/AvahiAutoipd
The reason that I posted that log was not because dhclient "worked", but rather because it got a DHCPOFFER and a DHCPACK. It also got the IP on the first request. If I turn DHCP on my router off, the same command (different eth*) looks like: [EMAIL PROTECTED]:~$ sudo dhclient eth2 Internet Systems Consortium DHCP Client V3.0.6 Copyright 2004-2007 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth2/00:1b:77:2c:5d:83 Sending on LPF/eth2/00:1b:77:2c:5d:83 Sending on Socket/fallback DHCPREQUEST on eth2 to 255.255.255.255 port 67 DHCPREQUEST on eth2 to 255.255.255.255 port 67 DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 19 DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 19 No DHCPOFFERS received. Trying recorded lease 192.168.0.3 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. --- 192.168.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 9.509/9.509/9.509/0.000 ms bound: renewal in 39118 seconds. So the DHCPREQUEST is sent because we /did/ know there was a working DHCP on eth2 (but I just turned it off). It doesnt get any response. So then it sends a DHCPDISCOVER... Any DHCP servers out there?? HELP PLZ??! It can't find any and times out - falling back to other methods to get an IP. In this case, "last known good" got me back on the network. After turning DHCP back on I get: [EMAIL PROTECTED]:~$ sudo dhclient eth2 Internet Systems Consortium DHCP Client V3.0.6 Copyright 2004-2007 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth2/00:1b:77:2c:5d:83 Sending on LPF/eth2/00:1b:77:2c:5d:83 Sending on Socket/fallback DHCPREQUEST on eth2 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.3 -- renewal in 33010 seconds. As you can see the behaviour with and without a DHCP server is quite different. If avahi was involved then I would expected my main network connection to get an IP just as quick as the device did. But no DHCP causes a series of DHCPDISCOVER requests that time out... This seems to back up the idea that (at the very least) the device is packing a pseudo DHCP server so that it is quickly configured on connection to a host PC. > > One thought I have is that the phone has some kind of fake DHCP thing > > going on so that windows can auto configure the device with an IP when > > you plug it in - the values it returns might come from the registry, > > rather than a traditional DHCP server. (This fits with some keys that > > we have been able to change in the past I think). > > It also fits with the zero-configuration system in that the WM device > caches it's last known good ip address. It is possible that link-local zeroconf is used the very first time (hence the IP addresses in that range) but then MS cache the IPs in the devices registry and use them from that point on to answer DHCP requests - speeding up connection. I'm not being stubborn here, as we both agree it seems silly to have a DHCP server. But i'm trying to explain why dhclient is reporting that it is getting DHCP responses from somewhere, and my experiments with my router seem to suggest that avahi would behave differently to what i'm seeing. John ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
