Bug 11293

I reset the assignee to default because the package is patched with a lot of patches, unfortunately, these patches are not documented so the update of this package is a number too big for me. Sorry. But I will look what I can do that the package get updated.

Regards Jonatan

This is still causing problems out in the field. See this forum post:

https://bugzilla.ipfire.org/show_bug.cgi?id=11293

Whoops! Wrong link: https://forum.ipfire.org/viewtopic.php?f=27&t=19943

One last note: This affects (at least) the proper display of hostnames in the QUI on the DHCP and Blue Access lists, plus the implementation of dynamic DNS updates from DHCP.

Seems like this was in the wrong category. :-)

This issue can be reproduced here with Core Update 116.

Hi!

I'm working on an update to 4.4.1 where this and other bugs are fixed.

Release notes: https://kb.isc.org/article/AA-01571/82/DHCP-4.4.1-Release-Notes.html

See also: https://bugzilla.ipfire.org/show_bug.cgi?id=11697

First tests with 4.4.1 are looking good. Running right now on Core 119 without (seen) problems so far.

Best,
Matthias

Hi,
I'm running Core 120 and I still see the problem, and I believe this is expected because dhcpd was not updated with the fix in the Core120 release.

will this fix be available in Core 121 (may 2018) ?

thanks a lot for fixing this ...

This update wasn't scheduled for Core 120 and isn't for Core 121 yet since I
have not received any positive feedback from the testers. Did I miss anything?

I'm not an official tester but if there is an easy way to test the new version on a Core 120 I can give it a go...
:-)

ah! I just saw (from the other bugzilla) the commit for it on

https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=af82bfde5c844927f20b068479e61bab12bd7eb5

I see that all the files are related to teh dchp folder.

is there a way to get just that folder as a tar file??

if that is possible .. I can rename the one on Core 120 and swap with this new version, reboot the ipfire box and test it for a while before reporting.

I have few common cases (raspberrypi, Drobo) that never worked correctly due to this bug (no hostname recorderd into the dhcp list), if they work with the new version ..  we will have an immediate feedback
:)

(In reply to gianluca from comment #10)

> 
> is there a way to get just that folder as a tar file??

please disregard.

I see that the commit is for the linux LFS build system, so I will have to setup a build machine to get the full folder. I never did a build of IPfire myself .. but I might try ... just to get the new dhcp package

Matthias, could you just upload this as a binary package for him?

(In reply to Michael Tremer from comment #12)
> Matthias, could you just upload this as a binary package for him?

No problem.

Download:
=> http://people.ipfire.org/~mfischer/dhcp/4.4.1/dhcp-4.4.1-for-ipfire.tar.gz

Built on Ubuntu 16.0.4 / 32bit. This version is running here since 2018-04-29. No seen problems with Core 120.

Installation instructions (just in case they're needed):

- Open a root console (e.g., PuTTY)
- Download archive
- Copy archive to root dir
- Stop running dhcp with "/etc/init.d/dhcp stop"
- Extract with "tar xvf dhcp-4.4.1-for-ipfire.tar.gz -C /"
- Start dhcp with "/etc/init.d/dhcp start"
- Watch console output and check running process with "/etc/init.d/dhcp status"
- Check in GUI: LOGS / SYSTEM LOGS / Section:  DHCP Server

- Console should give you something like:

***SNIP***
root@ipfire: ~ # /etc/init.d/dhcp status
dhcpd is running with Process ID(s) 3842.
unbound-dhcp-leases-bridge is running with Process ID(s) 3852.
***SNAP***

HTH,
Matthias

excellent.

it is running on my Core 120 .. I will test for a week and report.

btw: I got an error that I don't think is related to the binary itself:

[root@fw sbin]# /etc/init.d/dhcp start
Starting DHCP Server...
/etc/rc.d/init.d/functions: line 509: /usr/sbin/dhcpd: No such file or directory                                                                                                      [ FAIL ]
Starting Unbound DHCP Leases Bridge...                                                                                                                                                [  OK  ]

but if I check I do have the binary in place:

[root@fw sbin]# ls -al /usr/sbin/dhc*
-rwxr-xr-x 1 root root 3551816 May 11 18:04 /usr/sbin/dhcpd
-rwxr-xr-x 1 root root 2004992 Dec 13 07:32 /usr/sbin/dhcpd_ORIG
-rwxr-xr-x 1 root root 2935656 May 11 18:04 /usr/sbin/dhcrelay
-rwxr-xr-x 1 root root 1519776 Dec 13 07:32 /usr/sbin/dhcrelay_ORIG

mmm... weird

Hi,

(In reply to gianluca from comment #14)
> excellent.
> 
> it is running on my Core 120 .. I will test for a week and report.

Great.

> btw: I got an error that I don't think is related to the binary itself:
> 
> [root@fw sbin]# /etc/init.d/dhcp start
> Starting DHCP Server...
> /etc/rc.d/init.d/functions: line 509: /usr/sbin/dhcpd: No such file or
> directory                                                                   
> [ FAIL ]
> Starting Unbound DHCP Leases Bridge...                                      
> [  OK  ]
> 
> but if I check I do have the binary in place:
> 
> [root@fw sbin]# ls -al /usr/sbin/dhc*
> -rwxr-xr-x 1 root root 3551816 May 11 18:04 /usr/sbin/dhcpd
> -rwxr-xr-x 1 root root 2004992 Dec 13 07:32 /usr/sbin/dhcpd_ORIG
> -rwxr-xr-x 1 root root 2935656 May 11 18:04 /usr/sbin/dhcrelay
> -rwxr-xr-x 1 root root 1519776 Dec 13 07:32 /usr/sbin/dhcrelay_ORIG
> 
> mmm... weird

Indeed - I never saw this error here. Just checked for myself:

***SNIP***
root@ipfire: / # /etc/init.d/dhcp stop
Stopping DHCP Server...                                                [  OK  ]
Stopping Unbound DHCP Leases Bridge...                                 [  OK  ]

root@ipfire: / # /etc/init.d/dhcp start
Starting DHCP Server...                                                [  OK  ]
Starting Unbound DHCP Leases Bridge...                                 [  OK  ]

root@ipfire: / # /etc/init.d/dhcp status
dhcpd is running with Process ID(s) 14713.
unbound-dhcp-leases-bridge is running with Process ID(s) 14723.
***SNAP***

What stands in line 509 of your '/etc/rc.d/init.d/functions'?

I can't find the string 'dhcpd' or even 'dhcp' anywhere in this file.

Best,
Matthias

bah... this is a Core 120 "as is" ... never changed anything myself.

and it was started as a "fresh install" from core 118, brand new machine.

line 509 at the end of the loadproc() function where you see:

${cmd}
evaluate_retval # This is "Probably" not LSB compliant, but required to be compatible with older bootscripts
return 0


thanks

actually I take it back: the issue is the binary file.

I noticed that the dhcp server was NOT running, so I did a stop, swapped the original file and did a start : no issues this time.

my machine is an x86_64 arch .. 

Linux fw 3.14.79-ipfire #1 SMP Tue Dec 12 23:42:46 GMT 2017 x86_64 Intel(R) Atom(TM) CPU 230 @ 1.60GHz GenuineIntel GNU/Linux

(In reply to gianluca from comment #17)
> actually I take it back: the issue is the binary file.
> 
> I noticed that the dhcp server was NOT running, so I did a stop, swapped the
> original file and did a start : no issues this time.
> 
> my machine is an x86_64 arch .. 
> 
> Linux fw 3.14.79-ipfire #1 SMP Tue Dec 12 23:42:46 GMT 2017 x86_64 Intel(R)
> Atom(TM) CPU 230 @ 1.60GHz GenuineIntel GNU/Linux

one thing I noticed is that your binaries are twice the size of the original ones.

[root@fw sbin]# ls -al dhc*
-rwxr-xr-x 1 root root 2004992 May 11 19:18 dhcpd
-rwxr-xr-x 1 root root 3551816 May 11 19:18 dhcpd_441
-rwxr-xr-x 1 root root 2004992 Dec 13 07:32 dhcpd_ORIG
-rwxr-xr-x 1 root root 1519776 May 11 19:21 dhcrelay
-rwxr-xr-x 1 root root 2935656 May 11 19:21 dhcrelay_441
-rwxr-xr-x 1 root root 1519776 Dec 13 07:32 dhcrelay_ORIG

Hi,

(In reply to gianluca from comment #18)
> (In reply to gianluca from comment #17)
> > actually I take it back: the issue is the binary file.
> > 
> > I noticed that the dhcp server was NOT running, so I did a stop, swapped the
> > original file and did a start : no issues this time.
> > 
> > my machine is an x86_64 arch .. 

That's why I wrote "...32bit." - sorry.

> > Linux fw 3.14.79-ipfire #1 SMP Tue Dec 12 23:42:46 GMT 2017 x86_64 Intel(R)
> > Atom(TM) CPU 230 @ 1.60GHz GenuineIntel GNU/Linux
> 
> one thing I noticed is that your binaries are twice the size of the original
> ones.
> ...

Yep.
I noticed this, too. This could be because I have not managed to remove the integrated 'bind'-version despite several attempts.
The '001-dhcp-remove-bind.patch' and nearly all other patches wouldn't apply. I had to remove them.

See:
https://bugzilla.ipfire.org/show_bug.cgi?id=11697#c6

And:
https://bugzilla.ipfire.org/show_bug.cgi?id=11697#c7

Anyone here who could build a 64bit-version?

Best,
Matthias

if someone is willing to post a 64bit version ... I'll be happy to test it out.

sorry I don;t have a proper setup to built it myself

thanks

We have had this installed at one site since Friday, and all seems well. Hostnames are reliabily showing in the WUI, too.

excellent Tom!

if you have the binaries compiled for x64 arch please share those two files and I will be happy to test on my ipfire box too.

this way we might have a chance to include the update in the next release.

I've been waiting for this update for a looong time... pleeeeease
:-)

Shipped with Core 121 (dhcp 4.4.1):

https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=8441d469b0067e5fd126ceb4833bd3158537716d

Best,
Matthias