Guy Van Sanden wrote:

I was wondering what this message in the logs meant:
dhcpcd[162]: broadcasting second DHCP_DISCOVER


from the dhcpcd man page:

-S  Forces dhcpcd to send second DHCP_DISCOVER  message  even  after
    receiving  DHCP_OFFER on the first one. Some DHCP servers expect
    the client to send second DHCP_DISCOVER message before  replying
    on DHCP_REQUEST.

So I guess you've started your dhcpcd with option -S, or maybe sending a second DISCOVER message is the default behavior.

This is an entire log snippet of a failed connection, if you know what
it going wrong...
---
Dec 28 09:36:14 centurion dhcpcd[162]: sending DHCP_REQUEST for
81.83.123.215 to 195.130.132.97
Dec 28 10:18:26 centurion dhcpcd[162]: broadcasting DHCP_REQUEST for
81.83.123.215
Dec 28 10:18:26 centurion dhcpcd[162]: DHCP_NAK server response received
Dec 28 10:18:26 centurion dhcpcd[162]: broadcasting DHCP_DISCOVER
Dec 28 10:18:27 centurion dhcpcd[162]: broadcasting second DHCP_DISCOVER
Dec 28 10:18:27 centurion dhcpcd[162]: DHCP_OFFER received from (195.130.132.97)
Dec 28 10:18:27 centurion dhcpcd[162]: broadcasting DHCP_REQUEST for
81.83.123.215
Dec 28 10:18:28 centurion dhcpcd[162]: DHCP_ACK received from (195.130.132.97)

Looks pretty normal to me. What is not working? Have you tried to enforce a DHCP_RELEASE with dhcpcd-bin -k <interf>?

Reinhard

--
Reinhard Brandstaedter   [EMAIL PROTECTED]  GPG: 0x033B81DB
-    Student of Computer Science - J.K. University of Linz     -
-        <ICQ: 73059068>    <Mobile: +43 699 12419541>         -
-                  http://adelaide.dnsalias.net                -

--
[EMAIL PROTECTED] mailing list



Reply via email to