dhclient not finding dhcp server

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.
Click to expand...
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
Click to expand...
Correct me if I am wrong, I might not be getting something
 
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.
 
Routing table is pretty irrelevant if the ethernet card won't put the right signals on the wire.
 
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.
 
1670265106048.png
?
 
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:
Works great, you'll see ue0 for ethernet...
 
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:
Code: 
[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:
Code: 
#!/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
 
kavex said:
The network card is using qualcom atheros alc driver and is called "Killer E2500 Gigabit Ethernet Controller"
Click to expand...
kavex said:
because I ran FreeBSD on said computer even before running Linux on it and the network card was working fine.
Click to expand...

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.
 
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
 
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"
Click to expand...

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.
 
If you created a bridge, then it should have the same MAC address as the wireless interface that's attached to it. Otherwise it might not work. If you need further details, write back and I can show you how to do it.
 
ahev said:
If you created a bridge, then it should have the same MAC address as the wireless interface that's attached to it. Otherwise it might not work. If you need further details, write back and I can show you how to do it.
Click to expand...
ummm, this thread is nearly 2 years old at this time... I think it's safe to assume that the issue is resolved. Not that many people will want to come back to a hardware issue after 2 years - they usually have a newer piece of hardware, or they see that up-to-date software has solved the issue by then.
 
astyle said:
ummm, this thread is nearly 2 years old at this time... I think it's safe to assume that the issue is resolved. Not that many people will want to come back to a hardware issue after 2 years - they usually have a newer piece of hardware, or they see that up-to-date software has solved the issue by then.
Click to expand...
I agree, but the issue with MAC address is still relevant today, as of the end of 2024. 14.1 FreeBSD.
 
ahev said:
I agree, but the issue with MAC address is still relevant today, as of the end of 2024. 14.1 FreeBSD.
Click to expand...
Are you having same issues with your own hardware these days? Then please mention them, and describe your hardware/software and the errors you get, in a bit more detail. I don't think it makes much sense to simply try to join a conversation that ended 2 years ago. Because that's what necroposting is.
 
You must log in or register to reply here.
Back
Top