Issues getting DHCP assigned WAN address

rjcrowder

I have a new pfsense build on a 1U server that is showing strange behavior when getting a DHCP assigned WAN address. Basically, if I hook the WAN port of my new build up to my existing pfsense box LAN port, it boots up and gets an IP address (DHCP assigned). However, if I disconnect the existing pfsense box from the modem and put the new build in its place, the modem will not assign the new box an IP address at boot time. Then, if I go into the console menu and reconfigure the WAN - telling it to use DHCP - it gets an IP address!

The bottom line - the new build doesn't get an IP address from DHCP when hooked to the modem. It works fine when hooked to my existing pfsense box. I've tried several things to fix it including setting hint.apic.0.disabled=1 in the loader.conf.local but nothing seems to help.

Any ideas? Thanks!

wallabybob

What version of pfSense are you using?

What are you doing to test if you have fixed "it" - do you repeatedly switch the "1U" pfSense WAN port between LAN port of "old" pfSense and modem?

dhclient is the application used to request DHCP configuration information. I suggest you note the times at which you do the various components of your test, wait a couple of minutes then see what dhclient reports in the system log - use pfSense shell command:

# clog /var/log/system.log | grep dhclient
```Then see what matches up in the dhclient reports with the times you have previously recorded.

If I recall correctly, there were some circumstances where _dhclient_ would exit and not get restarted.

rjcrowder

@wallabybob:

What version of pfSense are you using?

What are you doing to test if you have fixed "it" - do you repeatedly switch the "1U" pfSense WAN port between LAN port of "old" pfSense and modem?

dhclient is the application used to request DHCP configuration information. I suggest you note the times at which you do the various components of your test, wait a couple of minutes then see what dhclient reports in the system log - use pfSense shell command:
# clog /var/log/system.log | grep dhclient
```Then see what matches up in the dhclient reports with the times you have previously recorded.

If I recall correctly, there were some circumstances where _dhclient_ would exit and not get restarted.

Version 2.01

What I'm doing to test it is - shutting down and then starting the box. It never gets assigned an address when it boots. The old box - plugged into the same modem - gets an address every time it boots.

I should also add that I haven't been able to find anything in the boot logs that indicates a problem. However, it pauses for several seconds (during boot) when it says it is setting up the WAN connection.

stephenw10

Please give more details on your new box. Importantly what NIC are you using that's failing to get an IP?
As Wallabybob asked please give us your system log for the period when it doesn't connect correctly. DHCP entries specifically.

Steve

Edit: Ah you edited while I was typing. ::)
It's ~~probably~~ possibly an ethernet negotiation problem. Do you have any diagnostic LEDs on either the new box or the old box that show whether there is a good connection?

wallabybob

@rjcrowder:

I should also add that I haven't been able to find anything in the boot logs that indicates a problem.

What have you looked for?

After your system has booted try this pfSense shell command```

ps ax | grep dhclient

rjcrowder

OK… problem solved after a long and arduous process of elimination. BTW... there was no mention of dhclient in ANY of the log files in /var/log (system.log and dmesg.boot included). Also, dhclient was not running (via ps -ax | grep dhcli)

The problem was the network cable!!! Interesting enough, the same network cable works absolutely fine to the old box. In addition, if I run the bad network cable to a switch and then connect the switch to the new box - it also works fine!

A manual inspection of the cable makes it apparent that not all of the pins are connected. There must be something with the Intel NIC's on the new box that require the additional pins? That's all I can figure...

stephenw10

Not having all the pins connected can cause a negotiation problem with Gigabit Ethernet. This often happens if you have a 'cable economiser' type device, 2X 10/100 connections down one cable.
Gigabit requires all 4 pairs in the cable but only uses 2 pairs for negotiation. If both devices are Gigabit capable they will negotiate 1000Mbps and then fail to connect.

Some NICs have an ability to detect that condition, broadcom have name for it, others do not.

Steve

rjcrowder

@stephenw10:

Not having all the pins connected can cause a negotiation problem with Gigabit Ethernet. This often happens if you have a 'cable economiser' type device, 2X 10/100 connections down one cable.
Gigabit requires all 4 pairs in the cable but only uses 2 pairs for negotiation. If both devices are Gigabit capable they will negotiate 1000Mbps and then fail to connect.

Some NICs have an ability to detect that condition, broadcom have name for it, others do not.

Steve

That's very interesting Steve… thanks for the info. I had no idea how this worked. Yea... obviously the Realtek NIC's in the old box handled it OK (missing pins). The NIC's in the new box did not! I also went around and checked some of my other cables - the cable issue seems to explain why a few devices were only connecting at 100Mbps.

stephenw10

The really interesting thing is that earlier you said:

@rjcrowder:

Then, if I go into the console menu and reconfigure the WAN - telling it to use DHCP - it gets an IP address!

Possibly the default state of the NIC, when the machine first boots, does not check for all 4 pairs connected. However when the driver is loaded this check is enabled in the hardware such that subsequent negotiations are able to fall back to 100Mbps. I guess. ;)

Anyway using the correctly wired cable is the right solution.

Steve