dhcpcd-discuss

Hi Bruce

On 14/01/2016 04:21, bruce m beach wrote:
> I have been using dhcpcd for years, with all sorts of
> devices and never had the slightest problem with it. Never
> paid the any attention to the man pages or config
> files or any thing. Always worked great.

Yay!

> Recently I bought a
> Tp-Link tl-wn722n usb stick which is Atheros AR9271 based.
> It connects fine but when I run "dhcpcd -d wlan0" I get
> nothing but:
> 
>                 169.254.xxx.xxx
> 
> for the ip address. I've searched the web for several days
> now, tried this and that, read the man pages, dhcpcd.conf
> and upgraded to the latest dhcpdcd(dhcpcd-6.10.0.tar.xz) but
> nothing works. I do have another card (ZyDAS ZD1211B
> 802.11g) which is actually running right now and it works
> fine. ( Other than the fact that it's stuck outside in the
> freezing rain 10 feet up a pole with a cable that exceeds
> the length spec so that it takes half an hour to warm up
> before it works ) Below is some output from the system logs.
> (I just noticed that /var/log/dhcpcd.log is actually empty)
> 
> Regards Bruce
> 
> dhcpcd-6.10.0 starting
> wlan0: disabling kernel IPv6 RA support
> wlan0: executing `/libexec/dhcpcd-run-hooks' PREINIT
> wlan0: executing `/libexec/dhcpcd-run-hooks' CARRIER
> DUID 00:01:00:01:1d:66:4e:b3:00:02:72:8c:9a:d0
> wlan0: IAID 20:23:93:0c
> wlan0: delaying IPv6 router solicitation for 0.3 seconds
> wlan0: delaying IPv4 for 0.2 seconds
> wlan0: reading lease `/var/db/dhcpcd-wlan0-Burnaby-Public-Wifi.lease'
> wlan0: rebinding lease of 172.17.155.0
> wlan0: sending REQUEST (xid 0xbb0cb2f1), next in 4.6 seconds
> wlan0: soliciting an IPv6 router
> wlan0: sending Router Solicitation
> wlan0: sending Router Solicitation
> wlan0: sending REQUEST (xid 0xbb0cb2f1), next in 7.3 seconds
> wlan0: probing for an IPv4LL address
> wlan0: probing for 169.254.191.236
> wlan0: ARP probing 169.254.191.236 (1 of 3), next in 2.0 seconds
> wlan0: DHCP lease expired
> wlan0: executing `/libexec/dhcpcd-run-hooks' EXPIRE
> wlan0: soliciting a DHCP lease
> wlan0: sending DISCOVER (xid 0x34f1eb1e), next in 4.0 seconds
> wlan0: ARP probing 169.254.191.236 (2 of 3), next in 1.2 seconds
> wlan0: sending Router S.olicitation
> wlan0: ARP probing 169.254.191.236 (3 of 3), next in 2.0 seconds
> wlan0: sending DISCOVER (xid 0x34f1eb1e), next in 7.8 seconds
> wlan0: using IPv4LL address 169.254.191.236
> wlan0: adding IP address 169.254.191.236/16
> wlan0: adding route to 169.254.0.0/16
> wlan0: adding default route
> wlan0: ARP announcing 169.254.191.236 (1 of 2), next in 2.0 seconds
> wlan0: executing `/libexec/dhcpcd-run-hooks' IPV4LL
> forking to background
> wlan0: sending Router Solicitation
> wlan0: no IPv6 Routers available
> wlan0: ARP announcing 169.254.191.236 (2 of 2)
> wlan0: sending DISCOVER (xid 0x34f1eb1e), next in 16.8 seconds
> forked to background, child pid 15186

Boo!

Well, the good news is that dhcpcd is working fine - the only error is
that there is no DHCP reply - the 169.254.* address is automatic config
when no DHCP server is present. You can disable this behaviour with the
-L or --noipv4ll flag or adding noipv4ll to dhcpcd.conf.
Now assuming that you use exactly the same config and just swap the USB
sticks around and one works and the other doesn't means that any error
is very likely below dhcpcd. In other words, in the kernel driver would
be the place to look.

Saying that, could it be something as simple as the DHCP server being
hard coded to assign IP via MAC address and it not being present?

Roy

PS, respect for your outside freezing but working network :)