# dhclient not finding dhcp server



## kavex (Nov 30, 2022)

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!


----------



## SirDice (Nov 30, 2022)

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


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,


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


----------



## Alain De Vos (Nov 30, 2022)

DHCPDISCOVER is send to 255.255.255.255 broadcast address.


----------



## kavex (Nov 30, 2022)

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"


----------



## SirDice (Nov 30, 2022)

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.


----------



## kavex (Nov 30, 2022)

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.


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.


----------



## astyle (Nov 30, 2022)

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...)


----------



## cy@ (Nov 30, 2022)

alc(4) is wireless. Are you running wpa_supplicant? Or is this an open network?


----------



## kavex (Nov 30, 2022)

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...)


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?


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!


----------



## Alain De Vos (Nov 30, 2022)

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
				



You can also have a look at,

```
man 5 dhclient.conf
```


----------



## SirDice (Nov 30, 2022)

cy@ said:


> alc(4) is wireless.


Ehm, it's not?


```
NAME
     alc – Atheros AR813x/AR815x/AR816x/AR817x Gigabit/Fast Ethernet driver
```

Should be the right driver for it:

```
•   Killer E2500 Gigabit Ethernet controller
```


----------



## gpw928 (Nov 30, 2022)

Is the driver loaded: `kldstat | grep alc`?
Edit: I see that you said "network card was recognized and attached to the alc driver".


----------



## astyle (Nov 30, 2022)

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.


----------



## Jose (Dec 1, 2022)

There are a couple of dhclient processes. Maybe you didn't kill all of them?

```
$ 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.


----------



## kavex (Dec 2, 2022)

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


----------



## kavex (Dec 3, 2022)

Alain De Vos said:


> To analyse dhcp traffic you can use:
> 
> 
> 
> ...


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.


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?
> 
> ```
> $ ps aux | grep dhclient
> ...


I killed all processes of dhclient and started it again, but sadly still no success


But thanks for all of your help and answers!


----------



## gpw928 (Dec 4, 2022)

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:
	
	



```
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:
	
	



```
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.


----------



## SirDice (Dec 5, 2022)

kavex said:


> Sadly I can't install wireshark without internet


tcpdump(1) is included with the base OS, no need to install anything.


----------



## astyle (Dec 5, 2022)

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...


----------



## kavex (Dec 5, 2022)

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:
> 
> ...


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

```
# 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 (Dec 5, 2022)

yeah, your pings suggest a fried plug on the router or a bad cable.


----------



## kavex (Dec 5, 2022)

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.
> 
> ...


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.


----------



## Alain De Vos (Dec 5, 2022)

You could try to configure a fixed IP-address and add a route and see if pings work.
Also verify the leds on the ethernet connectors.
Try another cable.


----------



## kavex (Dec 5, 2022)

Alain De Vos said:


> You could try to configure a fixed IP-address. And see if that works.
> 
> ```
> ping 192.168.1.250
> ...


Replaced the 1 with a 2 so it fits my network and got "Host is down" for both of them


----------



## astyle (Dec 5, 2022)

try ping 192.168.2.1 (the router itself)...


----------



## kavex (Dec 5, 2022)

Alain De Vos said:


> You could try to configure a fixed IP-address and add a route and see if pings work.
> Also verify the leds on the ethernet connectors.
> Try another cable.


I think I already did that here:


kavex said:


> 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


Correct me if I am wrong, I might not be getting something


----------



## kavex (Dec 5, 2022)

astyle said:


> try ping 192.168.2.1 (the router itself)...


I think I already did that aswell up here



kavex said:


> root@FreeBSD-PC:~ # ping 192.168.2.1


----------



## astyle (Dec 5, 2022)

kavex said:


> I think I already did that aswell up here


what's the output of `ifconfig alc0`?


----------



## SirDice (Dec 5, 2022)

Either the PHY part of the card is broken, or the driver doesn't initialize it properly. It's possible it's some variant of the chipset that's not recognized properly and thus doesn't initialize it correctly for that variant.

I've had both encounters. The card would be detected just fine, even able to configure it. But the physical part of the card is fried (don't stick your xDSL connection in an ethernet port; they both use the same RJ45 connector). The other issue was just a new variant of the chipset, and the driver just didn't initialize it properly, which resulted in a mostly dead card.


----------



## Alain De Vos (Dec 5, 2022)

Verify the output of:

```
netstat -rn
```


----------



## SirDice (Dec 5, 2022)

Routing table is pretty irrelevant if the ethernet card won't put the right signals on the wire.


----------



## Alain De Vos (Dec 5, 2022)

```
ifconfig -a
```


----------



## bakul (Dec 5, 2022)

Even if an ip addr is not assigned, you should be able to do “ifconfig alc0 up” and then run “tcpdump -ni alc0” as root. Then check if you see *any* traffic. If you don’t, try “ping 255.255.255.255” from another host on the same network. This is just to see if you can receive traffic. Assuming you can, the next thing to try is to watch for dhcp traffic running tcpdump on another host (or the router if possible). You should be able to see the dhcp packets sent by your freebsd host. This is to check you can send traffic from your host.


----------



## VladiBG (Dec 5, 2022)

It's a driver issue. You can try to boot using LiveCD with the latest CURRENT and test with `dhclient alc0` to see if it's working.





						230807 – if_alc(4): Driver not working for Killer Networking E2200
					






					bugs.freebsd.org


----------



## astyle (Dec 5, 2022)




----------



## kavex (Dec 6, 2022)

VladiBG said:


> It's a driver issue. You can try to boot using LiveCD with the latest CURRENT and test with `dhclient alc0` to see if it's working.
> 
> 
> 
> ...


Okay, thank you very much for pointing that out!

When I return home today evening, I will burn the latest FreeBSD-CURRENT version on a rewritable dvd and test it on the computer. I will then post my findings


----------



## VladiBG (Dec 6, 2022)

Don't waste time to burn the DVD, just grab a USB drive it's much faster and less prone to media errors compared to the DVD.


			Index of /snapshots/amd64/amd64/ISO-IMAGES/14.0/
		


FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495-memstick.img

And you don't have to install it, just use LiveCD for a quick test.


----------



## kavex (Dec 6, 2022)

VladiBG said:


> It's a driver issue. You can try to boot using LiveCD with the latest CURRENT and test with `dhclient alc0` to see if it's working.
> 
> 
> 
> ...


Sadly getting the same errors with FreeBSD 14.0-CURRENT


----------



## astyle (Dec 6, 2022)

Yeah, seems like you may need a new network card or adapter... there are USB-to-ethernet adapters out there, and just about any version of FreeBSD will take them like a champ, no extra drivers needed.

I have this one:



			https://www.amazon.com/Ethernet-Adapter-uni-Chromebook-Notebook/dp/B0871ZHCKK/ref=asc_df_B0871ZHCKK/?tag=hyprod-20&linkCode=df0&hvadid=459623382939&hvpos=&hvnetw=g&hvrand=17115124449597705005&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1024429&hvtargid=pla-937498082393&psc=1
		

Works great, you'll see `ue0` for ethernet...


----------



## elgrande (Dec 6, 2022)

I have this one:


			https://www.amazon.de/gp/product/B07Z8S6PN4/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
		


Expensive, but the only one I know that can handle 1 GBit/s stable via USB 3.0 (may be even faster, but had no setup to test with a higher throughput).


----------



## gpw928 (Dec 6, 2022)

I really do like StarTech products, a lot, but sometimes their cost makes my eyes water...

I have a US$17 AX88179 chipset Ethernet adapter on a *USB3.2Gen2* port (the USB standard *matters*).  It works much faster than any other USB gigabit adapter I tried (fairly close to full gigabit speeds in both directions).  Host sherman runs FreeBSD 13.1 and has the USB adapter on ue0.  Host orac runs Linux and has an Intel gigabit PCIe card.  They are connected by a gigabit switch:
	
	



```
[sherman.137] $ egrep "ue0|default" /etc/rc.conf
ifconfig_ue0="inet 192.168.1.27 netmask 255.255.255.0"    # USB3
defaultrouter="192.168.1.254"

[orac.572] $ iperf -c sherman
------------------------------------------------------------
Client connecting to sherman, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.26 port 49066 connected with 192.168.1.27 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

[sherman.131] $ iperf -c orac  
------------------------------------------------------------
Client connecting to orac, TCP port 5001
TCP window size: 32.0 KByte (default)
------------------------------------------------------------
[  1] local 192.168.1.27 port 36950 connected with 192.168.1.26 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.00-10.01 sec   877 MBytes   735 Mbits/sec
```
However, ue0 does not behave quite right in the boot sequence.  The code I added to /etc.rc.local says it all:
	
	



```
#!/bin/sh
# There's a fleeting message on the console at boot indicating that a "route"
# command has failed.  The USB port used by ue0 is coming up AFTER the default
# route is set (through ue0) and this is causing the default route to be
# missing.  So I'm fixing that, and logging it for further observation.
# PMC.  Sat Oct 29 11:47:39 AEDT 2022.

unset defaultrouter
[ -r /etc/rc.conf ] && . /etc/rc.conf
[ "X$defaultrouter" = "X" ] && exit 0
/usr/bin/netstat -rn | /usr/bin/grep -q "^default" && exit 0
ME=$(/usr/bin/basename $0)
MSG="setting default route to \"$defaultrouter\""
echo "$ME: $MSG"
/usr/bin/logger -t "$ME" "$MSG"
/sbin/route add -net 0.0.0.0/0 $defaultrouter
```


----------



## jbo (Dec 6, 2022)

kavex said:


> The network card is using qualcom atheros alc driver and is called "Killer E2500 Gigabit Ethernet Controller"





kavex said:


> because I ran FreeBSD on said computer even before running Linux on it and the network card was working fine.



This sounds a lot like this: https://forums.freebsd.org/threads/dual-boot-freebsd-linux-conflict-with-the-ethernet-adapter.83667/

TL;DR: OP in that thread had an issue with the killer NIC under FreeBSD *after* having booted Linux on the same hardware.


----------



## kavex (Dec 19, 2022)

Actually, I think I will check if MSI-X is enabled and disable it, if enabled, as a comment under the bug report suggested. I will return after I have the results


----------



## cracauer@ (Dec 19, 2022)

kavex said:


> 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"



Isn't the "killer" Ethernet stuff considered garbage, even by Windows gamers?

I'd get a random cheap USB ethernet adapter for this testing run.

I assume the DHCP server is a wifi router that you cannot run tcpdump on yet? Updating the firmware on the router won't hurt and can solve such issues.


----------

