DHCP does not work.

[bga]

Since a long time ago, DHCP stopped working on my machine (it used to work). I have worked this around by assigning a static IP but I decided to open a ticket anyway. Here is what I see on syslog:

~> grep DAEMON /var/log/syslog
DAEMON 'DHCP': DHCP for /dev/net/marvell_yukon/1, status: Address already in use
DAEMON 'DHCP': DHCP timeout shift: 4 secs (try 0)
DAEMON 'DHCP': DHCP timeout shift: 8 secs (try 0)
DAEMON 'DHCP': DHCP timeout shift: 2 secs (try 1)
DAEMON 'DHCP': DHCP timeout shift: 4 secs (try 1)
DAEMON 'DHCP': DHCP timeout shift: 8 secs (try 1)
DAEMON 'DHCP': DHCP timeout shift: 2 secs (try 2)
DAEMON 'DHCP': DHCP timeout shift: 4 secs (try 2)
DAEMON 'DHCP': DHCP timeout shift: 8 secs (try 2)
DAEMON 'DHCP': DHCP for /dev/net/marvell_yukon/0, status: Operation timed out
2009-05-05 19:30:46 DAEMON 'DHCP': DHCP for /dev/net/marvell_yukon/1, status: Address already in use
2009-05-05 19:30:46 DAEMON 'DHCP': DHCP timeout shift: 4 secs (try 0)
2009-05-05 19:30:50 DAEMON 'DHCP': DHCP timeout shift: 8 secs (try 0)
2009-05-05 19:30:58 DAEMON 'DHCP': DHCP timeout shift: 2 secs (try 1)
2009-05-05 19:31:00 DAEMON 'DHCP': DHCP timeout shift: 4 secs (try 1)
2009-05-05 19:31:04 DAEMON 'DHCP': DHCP timeout shift: 8 secs (try 1)
2009-05-05 19:31:12 DAEMON 'DHCP': DHCP timeout shift: 2 secs (try 2)
2009-05-05 19:31:14 DAEMON 'DHCP': DHCP timeout shift: 4 secs (try 2)
2009-05-05 19:31:18 DAEMON 'DHCP': DHCP timeout shift: 8 secs (try 2)
2009-05-05 19:31:26 DAEMON 'DHCP': DHCP for /dev/net/marvell_yukon/0, status: Operation timed out

The line that says "Address already in use" is fishy. Specially considering that /dev/net/marvell_yukon/1 is the card that is actually plugged in to a cable while /dev/net/marvell_yukon/0 is disconnected (yes, I have 2 network cards).

As a reference:

~> ifconfig
loop    Hardware Type: Local Loopback, Address: none
        inet addr: 127.0.0.1, Mask: 255.0.0.0
        MTU: 16384, Metric: 0, up loopback link
        Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Collisions: 0

/dev/net/marvell_yukon/0
        Hardware Type: Ethernet, Address: 00:1e:8c:3a:6c:64
        inet addr: 169.254.0.160, Bcast: 169.254.255.255, Mask: 255.255.0.0
        MTU: 1500, Metric: 0, up broadcast auto-configured
        Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Transmit: 9 packets, 0 errors, 2664 bytes, 0 mcasts, 0 dropped
        Collisions: 0

/dev/net/marvell_yukon/1
        Hardware Type: Ethernet, Address: 00:1e:8c:3a:65:24
        Media Type: 100 MBit, 100BASE-TX
        inet addr: 192.168.0.2, Bcast: 192.168.0.255, Mask: 255.255.255.0
        MTU: 1500, Metric: 0, up broadcast link auto-configured
        Receive: 932 packets, 0 errors, 599744 bytes, 0 mcasts, 0 dropped
        Transmit: 809 packets, 0 errors, 113448 bytes, 0 mcasts, 0 dropped
        Collisions: 0

The card ending with a 0 has no cable connected to it so it is expected that it gets a IP like the one it gets. The card ending with 1 has a cable connected and has a valid IP only because it is statically configured.

[michael.weirauch]

I can confirm seeing the DHCP timeout shifts occassionally. Sometimes my ipro1000 (fbsd_compat) just works (c), and sometimes it won't get an IP address via DHCP. Mostly it gets one assigned, though. (Only one NIC as opposed to Bruno) Can't recall having seen the "address already in use", my remembrance might fool me, though.

[bga]

I am on it.

Michael, your problems is different from mine. Mine happens exactkly because I have multiple interfaces.

[bga]

So, the problem is that when you have 2 interfaces, bind will be called twice for the same port and using INADDR_ANY. This is why it complains address is already in use.

It seems the correct way to go about it would be to binding to a specific device instead of binding to INADDR_ANY. As the devices have no IP yet, there must be a way to bind to them without the need for an IP. Is this implemented in our stack? If so, how would one go about doing this?

[bga]

Forget it, already figured it out. Fix coming up later today.

[bga]

Fixed in hrev30656.