dhclient not finding dhcp server

kavex

kavex

Hello everyone,

I recently installed FreeBSD 13.1-RELEASE on another computer. The installation went fine, except that no internet connection could be established, although my network card was recognized and attached to the alc driver and it having a working network cable attached to it. I know that it (the cable & the network card) are working, because said computer was running on Linux before I installed FreeBSD onto it and under Linux it worked fine. FreeBSD should also not be having any problems with hardware support of my card, because I ran FreeBSD on said computer even before running Linux on it and the network card was working fine.
With that out of the way let me actually describe my current problem: After killing the automatically started dhclient process and starting it again as "dhclient alc0" it only gets DHCPDISCOVER and doesn't find the dhcp server (which can be found by another [actually the one I am writing this with] computer running FreeBSD by connecting it to the same LAN port and the same cable. But I noticed dhclient is searching on 255.255.255.255 I am not really sure what that means but if it is supposed to show my subnet mask that should be 255.255.255.0, so is dhclient configured wrong and searching with the wrong settings, or is the fault somewhere else?
Thanks in advance!
 
What brand/type network card and what driver is used for it?

kavex said:
But I noticed dhclient is searching on 255.255.255.255
Click to expand...
It's supposed to do that. DHCPDISCOVER is broadcast over the whole network, it has to because it has no idea yet where your DHCP server is. So this is normal.
kavex said:
but if it is supposed to show my subnet mask that should be 255.255.255.0,
Click to expand...
But the whole point of DHCP is that the client doesn't know this. Yet. How could it possible know this in advance?

Dynamic Host Configuration Protocol - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Thanks for the replys!
Well then my problem is dhclient timing out looking for a dhcp server, while there was a responsive dhcp server connected to it. The network card is using qualcom atheros alc driver and is called "Killer E2500 Gigabit Ethernet Controller"
 
You're dual booting this system right? Maybe something leaves the card in a weird state. It works on Linux, then you reboot and boot FreeBSD and the card stops working? What happens if you power off the machine and boot FreeBSD directly?

I've had a card like that once, when I booted Windows it worked just fine, rebooted and booted to FreeBSD and the card would stop working (same as yours, sending DHCPDISCOVER but apparently never getting an IP address). If I turned off the machine and booted directly to FreeBSD it would work just fine. Somehow while shutting down Windows it left the card in some weird state.
 
SirDice said:
You're dual booting this system right? Maybe something leaves the card in a weird state. It works on Linux, then you reboot and boot FreeBSD and the card stops working? What happens if you power off the machine and boot FreeBSD directly?

I've had a card like that once, when I booted Windows it worked just fine, rebooted and booted to FreeBSD and the card would stop working (same as yours, sending DHCPDISCOVER but apparently never getting an IP address). If I turned off the machine and booted directly to FreeBSD it would work just fine. Somehow while shutting down Windows it left the card in some weird state.
Click to expand...
No, I am not dual booting the machine. I installed FreeBSD on it, replacing the older Linux install. I already rebooted it multiple times, booting directly to FreeBSD on my hard drjve, which is the only boot entry I have and there are no disks with other operating systems on them attached to the computer.
 
So, machine A can connect to the DHCP server, but machine B cannot... what's the difference between the two machines? (Both seem to run FreeBSD...)
 
astyle said:
So, machine A can connect to the DHCP server, but machine B cannot... what's the difference between the two machines? (Both seem to run FreeBSD...)
Click to expand...
One is a Notebook, the other one is an ordinary pc. I even used the same disk to install FreeBSD onto them.

cy@ said:
alc(4) is wireless. Are you running wpa_supplicant? Or is this an open network?
Click to expand...
I am not running wpa_supplicant. Actually that should be a wired connection, but why is alc(4) attaching then?
Thanks again for all the replies!
 
Is the driver loaded: kldstat | grep alc?
Edit: I see that you said "network card was recognized and attached to the alc driver".
 
Just take two ethernet cables, one for machine A, one for machine B. If you connect both machines to the router running the DHCP server, then dhclient should work on both.
 
There are a couple of dhclient processes. Maybe you didn't kill all of them?
Code: 
$ ps aux | grep dhclient
root   833    0.0  0.0    11416    2640  -  Is   16:02     0:00.00 dhclient: system.syslog (dhclient)
root   836    0.0  0.0    11624    2744  -  Is   16:02     0:00.00 dhclient: igb0 [priv] (dhclient)
_dhcp  915    0.0  0.0    11792    2864  -  ICs  16:02     0:00.00 dhclient: igb0 (dhclient)
$ doas /etc/rc.d/dhclient restart igb0                                                                                                                   
Stopping dhclient.
Waiting for PIDS: 915.
Starting dhclient.
DHCPREQUEST on igb0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.157 -- renewal in 1800 seconds.
$ ps aux | grep dhclient                                                                                                                                 
root  1476    0.0  0.0    11404    2712  -  Is   16:30     0:00.00 dhclient: system.syslog (dhclient)
root  1479    0.0  0.0    11600    2812  -  Is   16:30     0:00.00 dhclient: igb0 [priv] (dhclient)
_dhcp 1498    0.0  0.0    11768    2932  -  ICs  16:30     0:00.00 dhclient: igb0 (dhclient)

The logs on my DHCP server suggest DHCPDISCOVER is only sent upon a cold boot.
 
Sorry for not responding for some time. Currently having some stress in my life.



But I will try your suggestions when I return home today evening and reply with the results
 
Alain De Vos said:
To analyse dhcp traffic you can use:

FreshPorts -- net/wireshark: Powerful network analyzer/capture tool

A network analyzer that lets you capture and interactively browse the contents of packets from a variety of network interface types. Packet data can be read from a file, or live from a local network interface.
www.freshports.org www.freshports.org
You can also have a look at,
Code: 
man 5 dhclient.conf
Click to expand...
Sadly I can't install wireshark without internet, but I will have a look at man 5 dhclient.conf

astyle said:
Just take two ethernet cables, one for machine A, one for machine B. If you connect both machines to the router running the DHCP server, then dhclient should work on both.
Click to expand...
This actually is the current setup I have and sadly only one of the machines works, the other one kinda does not get an offer I think.

Jose said:
There are a couple of dhclient processes. Maybe you didn't kill all of them?
Code: 
$ ps aux | grep dhclient
root   833    0.0  0.0    11416    2640  -  Is   16:02     0:00.00 dhclient: system.syslog (dhclient)
root   836    0.0  0.0    11624    2744  -  Is   16:02     0:00.00 dhclient: igb0 [priv] (dhclient)
_dhcp  915    0.0  0.0    11792    2864  -  ICs  16:02     0:00.00 dhclient: igb0 (dhclient)
$ doas /etc/rc.d/dhclient restart igb0                                                                                                                  
Stopping dhclient.
Waiting for PIDS: 915.
Starting dhclient.
DHCPREQUEST on igb0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.157 -- renewal in 1800 seconds.
$ ps aux | grep dhclient                                                                                                                                
root  1476    0.0  0.0    11404    2712  -  Is   16:30     0:00.00 dhclient: system.syslog (dhclient)
root  1479    0.0  0.0    11600    2812  -  Is   16:30     0:00.00 dhclient: igb0 [priv] (dhclient)
_dhcp 1498    0.0  0.0    11768    2932  -  ICs  16:30     0:00.00 dhclient: igb0 (dhclient)

The logs on my DHCP server suggest DHCPDISCOVER is only sent upon a cold boot.
Click to expand...
I killed all processes of dhclient and started it again, but sadly still no success


But thanks for all of your help and answers!
 
I'm guessing that your DHCP server is resident on the local network?
If so, have you checked the configuration and cleared any existing leases?
Have you tried to use tcpdump to assess what, if any, network traffic is working on alc0:
Code: 
sudo tcpdump -n -v -v -v -w /tmp/log -i alc0
# wait 20 seconds
^C
sudo tcpdump -n -v -v -v -r /tmp/log | less
Have you tried to take DHCP out of the equation, and assign an IP address directly to alc0, e.g. in /etc/rc.conf:
Code: 
ifconfig_alc0="inet 192.168.1.250 netmask 255.255.255.0"
defaultrouter="192.168.1.254"
The subnet and IP addresses must be chosen correctly for your network. There is no short-term harm is testing with a lease address which is not otherwise used. This should help home in on what's faulty.
 
One simple idea is that maybe you have a fried LAN plug on the router... (Most consumer devices have a WAN plug for Internet, and a few LAN plugs). You can use machine A (the one that has a working DHCP connection) to verify that all LAN plugs on your router work.

If there's a faulty plug on the router, label it, or even put a piece or tape over it.

If all LAN plugs on the router are working, then next thing to check is the cable you're using for machine B. Swap the cables and (still using working machine A) check just one working outlet. This will tell you if machine B was just using a faulty cable. I had seen a few cables that had to be swapped out for brand-new replacements before network connections worked.

But if both cables are OK, then yeah, something is up with machine B.

One simple idea is to first make sure that machine B (the one that can't connect) is plugged into the router via the ethernet cable, and after that, just reinstall FreeBSD from scratch.

This assumes that you don't have much of anything to lose on that machine anyway. And there are some benefits to consider:
  • (If your network card works) the install process will find it, and set it up for you from get-go. dhclient, /etc/rc.conf, all that will be taken care of by the installer.
  • This will save the headaches of troubleshooting the DHCP process. The troubleshooting requires that you know how to read the output of tcpdump(1), and familiarity with RFC 2131...
 
gpw928 said:
I'm guessing that your DHCP server is resident on the local network?
If so, have you checked the configuration and cleared any existing leases?
Have you tried to use tcpdump to assess what, if any, network traffic is working on alc0:
Code: 
sudo tcpdump -n -v -v -v -w /tmp/log -i alc0
# wait 20 seconds
^C
sudo tcpdump -n -v -v -v -r /tmp/log | less
Have you tried to take DHCP out of the equation, and assign an IP address directly to alc0, e.g. in /etc/rc.conf:
Code: 
ifconfig_alc0="inet 192.168.1.250 netmask 255.255.255.0"
defaultrouter="192.168.1.254"
The subnet and IP addresses must be chosen correctly for your network. There is no short-term harm is testing with a lease address which is not otherwise used. This should help home in on what's faulty.
Click to expand...
Tcpdump on alc0 returned absolutely nothing. Just an empty file. Deleting all existent dhcp leases for that pc on the dhcp server didn't help either. I also tried setting up alc0 manually as you suggested and set it according to the settings of my router and gave the pc a static ip adress on my router. Sadly still no success
Code: 
# if I try to ping my router

root@FreeBSD-PC:~ # ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
^C
--- 192.168.2.1 ping statistics ---
8 packages transmitted, 0 packages recieved, 100.0% package loss

# if I try to ping google outside of my network

root@FreeBSD-PC:~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 8.8.8.8 ping statistics ---
3 packages transmitted, 0 packages recieved, 100.0% package loss
 
astyle said:
One simple idea is that maybe you have a fried LAN plug on the router... (Most consumer devices have a WAN plug for Internet, and a few LAN plugs). You can use machine A (the one that has a working DHCP connection) to verify that all LAN plugs on your router work.

If there's a faulty plug on the router, label it, or even put a piece or tape over it.

If all LAN plugs on the router are working, then next thing to check is the cable you're using for machine B. Swap the cables and (still using working machine A) check just one working outlet. This will tell you if machine B was just using a faulty cable. I had seen a few cables that had to be swapped out for brand-new replacements before network connections worked.

But if both cables are OK, then yeah, something is up with machine B.

One simple idea is to first make sure that machine B (the one that can't connect) is plugged into the router via the ethernet cable, and after that, just reinstall FreeBSD from scratch.

This assumes that you don't have much of anything to lose on that machine anyway. And there are some benefits to consider:
  • (If your network card works) the install process will find it, and set it up for you from get-go. dhclient, /etc/rc.conf, all that will be taken care of by the installer.
  • This will save the headaches of troubleshooting the DHCP process. The troubleshooting requires that you know how to read the output of tcpdump(1), and familiarity with RFC 2131...
Click to expand...
I already went through all that trouble shooting and there is no faulty cable and no faulty lan port, everything seems to work fine, except for machine B, but only under FreeBSD, so it also can't be faulty hardware on that machine.
I aswell already reinstalled FreeBSD on machine B, but during the installation the dhcp is already unable to aquire a lease and returns empty settings.
 
You must log in or register to reply here.
Back
Top