DHCP does not work ... on 2.2.5 Update 158

That’s my first, fresh install of ipfire.
(I have been sysadmin for the last 20 years, so I don’t think any of my intentions is wrong. :smiley: )
Here we go: Link is Ethernet, direct RJ-45-to-RJ-45. Setting of GRENN on ipfire is 192.168.1.200/24. When I set the client (W10) manually to 192.168.1.13/24 I can use the webGUI on 192.168.1.200:444. Everything okay.
DHCP is ‘enabled’ (blue - ‘Green Interface’). Range is 192.168.1.101-192.168.1.199.
The DHCP page shows, in bold, upper right, IP-adress 192.168.1.200 Netmask 255.255.255.0. No client denied. To me this looks very much okay, and everything a DHCP server usually needs to know.
Alas, when I change the interface setting in the W10-client to DHCP, it tries and tries, in vain. Returning to the fixed IP in the client immediately again makes everything work.
And since this is my first ipfire setup, no, I have not closed any port 67 or likewise on GREEN - actually none! My only firewall rule at this moment is GREEN to RED any protocol any destination.

Appreciate any help with this, otherwise we’ll be stuck.

TIA,

Uwe

Hi @digard

Just for clarification, when you write

Do you mean that both Blue and Green interfaces are enabled and that the Dynamic start and end addresses for the Green Interface are 192.168.1.101 and 192.168.1.199

In terms of trying to find out where the dhcp communication is failing the first thing would be to look at the logs.

less /var/log/messages | grp dhcpd

we will see if there is a DHCPREQUEST coming in from the W10 machine and what the following stages of the dhcp negotiation are doing.

No, no ‘Blue’ interface. I meant the blue box next to ‘Enable’. Currently I have only two NCs.
Your other assumption is correct: start and end addresses.

This is what a controlled experiment brought up:

14:43:50 dhcpd:  Server starting service.
16:41:56 dhcpd:  DHCPDISCOVER from 00:22:68:12:05:99 via green0
16:41:57 dhcpd:  DHCPOFFER on 192.168.1.101 to 00:22:68:12:05:99 (WonT400) via green0
16:41:57 dhcpd:  DHCPREQUEST for 192.168.1.101 (192.168.1.200) from 00:22:68:12:05:99 (WonT400) via green0
16:41:57 dhcpd:  Wrote 1 leases to leases file.
16:41:57 dhcpd:  DHCPACK on 192.168.1.101 to 00:22:68:12:05:99 (WonT400) via green0
16:41:58 dhcpd:  reuse_lease: lease age 1 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.101
16:41:58 dhcpd:  DHCPDISCOVER from 00:22:68:12:05:99 (WonT400) via green0
16:41:58 dhcpd:  DHCPOFFER on 192.168.1.101 to 00:22:68:12:05:99 (WonT400) via green0
16:41:58 dhcpd:  reuse_lease: lease age 1 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.101
16:41:58 dhcpd:  DHCPREQUEST for 192.168.1.101 (192.168.1.200) from 00:22:68:12:05:99 (WonT400) via green0
16:41:58 dhcpd:  DHCPACK on 192.168.1.101 to 00:22:68:12:05:99 (WonT400) via green0
16:41:59 dhcpd:  DHCPINFORM from 192.168.1.101 via green0
16:41:59 dhcpd:  DHCPACK to 192.168.1.101 (00:22:68:12:05:99) via green0
16:42:02 dhcpd:  DHCPINFORM from 192.168.1.101 via green0
16:42:02 dhcpd:  DHCPACK to 192.168.1.101 (00:22:68:12:05:99) via green0
16:42:10 dhcpd:  reuse_lease: lease age 13 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.101
16:42:10 dhcpd:  DHCPDISCOVER from 00:22:68:12:05:99 (WonT400) via green0

and so forth.

Can you make out, what is going on?

From the IPFire side ( that is shown in the logs ) it seems okay.
The client is requesting an address and gets it ( 192.168.1.101 ).
This sequence (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK) is repeated. Maybe W10 is somehow ‘impatient’, but this shouldn’t matter.
The second attempt is closed by a (DHCPINFORM, DHCPACK) sequence, which should show the client has learned his IP.
But just afterwards the client starts a new DISCOVER sequence.
How is your client configured?
Can you log the DHCP packets, on the IPFire or client side?

Configured? What do you mean? Off-the-shelf W7 (sorry, it wasn’t W10). DHCP. Nothing out of the ordinary.
Logging? You mean Ethereal or likewise? Difficult. I don’t know ipfire (yet), and I’m no usual Windows user. It just so happened that this box (lenovo T400) was lying around. It does accept and connect to the closest EnGenius AP without problem using DHCP.

At least I can offer the Errors of the Event Viewer:

Dhcp has received network hint 77962716 for the Network Card with the network address 0x001E656BA134

Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address 0x002556D19458.  The following error occurred: 0x79. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.

Address 192.168.1.101 being plumbed for adapter 11 already exists

An error has occurred in initializing the adapter 11. Error Code is 0x1392

And then it goes in circles.

Currently I have no other Ethernet-RJ-45 offering DHCP around. I can try tomorrow. I can also try a *nix box on that same cable. I’ll report back.

:thinking: Maybe a reset of the network settings will help.
Which system are you using? Win7 or Win10?

If Win10

If Win7 you could try
Run command line as administrator
than type commands:

netsh winsock reset
netsh int ip reset all
netsh winhttp reset proxy
ipconfig /flushdns

After running the above commands, restart your computer.

My excuses. W7. My last W7 box, all others are on W10. Therefore my mistake here. W7 it is.

Have you done a search on dhcp error 0x79 ?

3 Likes

Sorry, guys! - Solved!
My excuses for having taken all of you helpful guys through an unnecessary trip on the crappy OS. :frowning:
I had promised myself to never touch the crappy OS for relevant things. And yet, I didn’t have any machine with an Ethernet port an a proper OS on my hands. Once I pulled out one, everything worked smoothly, of course.
And, no, no mistake on my handling of the network applet on that other machine. You surely know that there are radio buttons where you either select DHCP or a fixed IP, and I was just changing between the two. Most logically!
Why it keeps the static IP once you move to DHCP (thanks to Robert pointing out that error code) beats me. But Dr. Google showed that I’m not the only person falling into this trap.

Thanks again, and please accept my apologies for having bothered you with quite foreseeable crap out of Redmond.

Uwe

All good Uwe,

Glad to hear you got this resolved.