ISC DHCP Users

dhclient binary size

Classic

List

Threaded

11 messages Options

Bancroft, Matt

dhclient binary size

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Thomas Markwalder

Re: dhclient binary size

On 9/28/16 10:23 AM, Bancroft, Matt wrote:

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

Hello Matt:

If you do not need the client to support DNS updates, you can compile it out. To do so you need to:

1. Undefine NSUPDATE (comment it out) in includes/site.
2. dhclient_ddns_cb_free(), needs to be wrapped with NSUPDATE conditional compilation.

Rebuild.

I have attached a diff, containing these changes. The resulting client is notably smaller. Please note that, these changes have
not been tested and are use-at-your-own-risk.

Sincerely,

Thomas Markwalder
ISC Software Engineering

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

nodns.diff (1K) Download Attachment

/dev/rob0

Re: dhclient binary size

In reply to this post by Bancroft, Matt

On Wed, Sep 28, 2016 at 02:23:47PM +0000, Bancroft, Matt wrote:
> Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient
> significantly increased.
>
> I've had a search back through posts and cannot see any discussion
> about why this is; presumably the DDNS changes?

I think it was the inclusion of external libraries in the project;
this occurred with the now-EOL 4.2 branch. Compare the sizes of the
source tarballs of 4.3 and 4.1-ESV branches.

> Is there any way to compile a minimum feature version to maintain a
> small binary size for the client?

Stick with 4.1-ESV for the client. If necessary to coexist with a
4.3.4 server, build 4.1-ESV with a --prefix configure setting.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

A.L.M.Buxey

Re: dhclient binary size

In reply to this post by Thomas Markwalder

Suggest a --without-ddns configure flag option

alan
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bancroft, Matt

RE: dhclient binary size

In reply to this post by Thomas Markwalder

Thomas,

Thanks for the suggestion. Your changes reduce the binary size by 100Kb. However, the binary went from ~500Kb to 2Mb when updating from 4.1-ESV-Rx to 4.3.4, so the 100Kb is not really a significant reduction.

I am compiling for arm if that makes any difference. And the main reason for the upgrade is to support all the new dhcpv6 options, particularly the –D option introduce in 4.2.

The client is being used in an embedded environment so binary size is an important issue.

Can you suggest any other way to reduce the binary size?

Kind Regards,

Matt Bancroft

From: dhcp-users [mailto:[hidden email]] On Behalf Of Thomas Markwalder
Sent: 28 September 2016 15:55
To: [hidden email]
Subject: Re: dhclient binary size

On 9/28/16 10:23 AM, Bancroft, Matt wrote:

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

_______________________________________________

dhcp-users mailing list

[hidden email]

https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Thomas Markwalder

Re: dhclient binary size

Matt:

To get a 4.1 size of 500Kb, the executable must be stripped. The default bin produced isn't stripped, so you can start there.

Thomas

On 9/30/16 6:23 AM, Bancroft, Matt wrote:

Thomas,

Thanks for the suggestion. Your changes reduce the binary size by 100Kb. However, the binary went from ~500Kb to 2Mb when updating from 4.1-ESV-Rx to 4.3.4, so the 100Kb is not really a significant reduction.

I am compiling for arm if that makes any difference. And the main reason for the upgrade is to support all the new dhcpv6 options, particularly the –D option introduce in 4.2.

The client is being used in an embedded environment so binary size is an important issue.

Can you suggest any other way to reduce the binary size?

Kind Regards,

Matt Bancroft

From: dhcp-users [[hidden email]] On Behalf Of Thomas Markwalder
Sent: 28 September 2016 15:55
To: [hidden email]
Subject: Re: dhclient binary size

On 9/28/16 10:23 AM, Bancroft, Matt wrote:

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

Hello Matt:

If you do not need the client to support DNS updates, you can compile it out. To do so you need to:

1. Undefine NSUPDATE (comment it out) in includes/site.
2. dhclient_ddns_cb_free(), needs to be wrapped with NSUPDATE conditional compilation.

Rebuild.

I have attached a diff, containing these changes. The resulting client is notably smaller. Please note that, these changes have
not been tested and are use-at-your-own-risk.

Sincerely,

Thomas Markwalder
ISC Software Engineering
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bancroft, Matt

RE: dhclient binary size

It is 1.8Mb stripped with the changes you suggested J

It would be great to have it at about 500Kb.

Matt

From: dhcp-users [mailto:[hidden email]] On Behalf Of Thomas Markwalder
Sent: 30 September 2016 13:30
To: Users of ISC DHCP
Subject: Re: dhclient binary size

Matt:

To get a 4.1 size of 500Kb, the executable must be stripped. The default bin produced isn't stripped, so you can start there.

Thomas

On 9/30/16 6:23 AM, Bancroft, Matt wrote:

Thomas,

Thanks for the suggestion. Your changes reduce the binary size by 100Kb. However, the binary went from ~500Kb to 2Mb when updating from 4.1-ESV-Rx to 4.3.4, so the 100Kb is not really a significant reduction.

I am compiling for arm if that makes any difference. And the main reason for the upgrade is to support all the new dhcpv6 options, particularly the –D option introduce in 4.2.

The client is being used in an embedded environment so binary size is an important issue.

Can you suggest any other way to reduce the binary size?

Kind Regards,

Matt Bancroft

From: dhcp-users [[hidden email]] On Behalf Of Thomas Markwalder
Sent: 28 September 2016 15:55
To: [hidden email]
Subject: Re: dhclient binary size

On 9/28/16 10:23 AM, Bancroft, Matt wrote:

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

Hello Matt:

If you do not need the client to support DNS updates, you can compile it out. To do so you need to:

1. Undefine NSUPDATE (comment it out) in includes/site.
2. dhclient_ddns_cb_free(), needs to be wrapped with NSUPDATE conditional compilation.

Rebuild.

I have attached a diff, containing these changes. The resulting client is notably smaller. Please note that, these changes have
not been tested and are use-at-your-own-risk.

Sincerely,

Thomas Markwalder
ISC Software Engineering
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Thomas Markwalder

Re: dhclient binary size

Hi Matt:

I suspect a fair portion of the size increase comes along with moving to the use of the Bind9 libraries, versus the code that resides in the "minires" directory. We gained a good great deal by having common code, with improved performance and robustness as well as in functionality, but apparently at a price of binary footprint.

It may be possible to reduce the size of the Bind9 libraries based on capabilities excluded through compilation flags when building them but this would have to be researched.

Regards,

Thomas Markwalder
ISC Software Engineering

On 9/30/16 9:09 AM, Bancroft, Matt wrote:

It is 1.8Mb stripped with the changes you suggested J

It would be great to have it at about 500Kb.

Matt

From: dhcp-users [[hidden email]] On Behalf Of Thomas Markwalder
Sent: 30 September 2016 13:30
To: Users of ISC DHCP
Subject: Re: dhclient binary size

Matt:

To get a 4.1 size of 500Kb, the executable must be stripped. The default bin produced isn't stripped, so you can start there.

Thomas

On 9/30/16 6:23 AM, Bancroft, Matt wrote:
Thomas,

Thanks for the suggestion. Your changes reduce the binary size by 100Kb. However, the binary went from ~500Kb to 2Mb when updating from 4.1-ESV-Rx to 4.3.4, so the 100Kb is not really a significant reduction.

I am compiling for arm if that makes any difference. And the main reason for the upgrade is to support all the new dhcpv6 options, particularly the –D option introduce in 4.2.

The client is being used in an embedded environment so binary size is an important issue.

Can you suggest any other way to reduce the binary size?

Kind Regards,

Matt Bancroft

From: dhcp-users [[hidden email]] On Behalf Of Thomas Markwalder
Sent: 28 September 2016 15:55
To: [hidden email]
Subject: Re: dhclient binary size

On 9/28/16 10:23 AM, Bancroft, Matt wrote:

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

Hello Matt:

If you do not need the client to support DNS updates, you can compile it out. To do so you need to:

1. Undefine NSUPDATE (comment it out) in includes/site.
2. dhclient_ddns_cb_free(), needs to be wrapped with NSUPDATE conditional compilation.

Rebuild.

I have attached a diff, containing these changes. The resulting client is notably smaller. Please note that, these changes have
not been tested and are use-at-your-own-risk.

Sincerely,

Thomas Markwalder
ISC Software Engineering
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bancroft, Matt

RE: dhclient binary size

That was my thought also. I am looking at the bind configure and make to see what I can do ;)

Any ideas or pointers would be helpful.

Regards,

Matt

From: dhcp-users [mailto:[hidden email]] On Behalf Of Thomas Markwalder
Sent: 30 September 2016 14:38
To: [hidden email]
Subject: Re: dhclient binary size

It is 1.8Mb stripped with the changes you suggested J

It would be great to have it at about 500Kb.

Matt

From: dhcp-users [[hidden email]] On Behalf Of Thomas Markwalder
Sent: 30 September 2016 13:30
To: Users of ISC DHCP
Subject: Re: dhclient binary size

Matt:

To get a 4.1 size of 500Kb, the executable must be stripped. The default bin produced isn't stripped, so you can start there.

Thomas

On 9/30/16 6:23 AM, Bancroft, Matt wrote:
Thomas,

Thanks for the suggestion. Your changes reduce the binary size by 100Kb. However, the binary went from ~500Kb to 2Mb when updating from 4.1-ESV-Rx to 4.3.4, so the 100Kb is not really a significant reduction.

I am compiling for arm if that makes any difference. And the main reason for the upgrade is to support all the new dhcpv6 options, particularly the –D option introduce in 4.2.

The client is being used in an embedded environment so binary size is an important issue.

Can you suggest any other way to reduce the binary size?

Kind Regards,

Matt Bancroft

From: dhcp-users [[hidden email]] On Behalf Of Thomas Markwalder
Sent: 28 September 2016 15:55
To: [hidden email]
Subject: Re: dhclient binary size

On 9/28/16 10:23 AM, Bancroft, Matt wrote:

Hi,

Between 4.1-ESV-R12b1 and 4.3.4 the binary size of the dhclient significantly increased.

I‘ve had a search back through posts and cannot see any discussion about why this is; presumably the DDNS changes?

Is there any way to compile a minimum feature version to maintain a small binary size for the client?

Kind Regards,

Matt Bancroft

Hello Matt:

If you do not need the client to support DNS updates, you can compile it out. To do so you need to:

1. Undefine NSUPDATE (comment it out) in includes/site.
2. dhclient_ddns_cb_free(), needs to be wrapped with NSUPDATE conditional compilation.

Rebuild.

I have attached a diff, containing these changes. The resulting client is notably smaller. Please note that, these changes have
not been tested and are use-at-your-own-risk.

Sincerely,

Thomas Markwalder
ISC Software Engineering
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Timothe Litt

Re: dhclient binary size

In reply to this post by Bancroft, Matt

On 30-Sep-16 10:07, [hidden email] wrote:

> Message: 1
> Date: Fri, 30 Sep 2016 09:38:25 -0400
> From: Thomas Markwalder <[hidden email]>
> To: [hidden email]
> Subject: Re: dhclient binary size
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Matt:
>
> I suspect a fair portion of the size increase comes along with moving to
> the use of the Bind9 libraries, versus the code that resides in the
> "minires" directory. We gained a good great deal by having common
> code, with improved performance and robustness as well as in
> functionality, but apparently at a price of binary footprint.
>
> It may be possible to reduce the size of the Bind9 libraries based on
> capabilities excluded through compilation flags when building them but
> this would have to be researched.
>
> Regards,
>
> Thomas Markwalder
> ISC Software Engineering
>
>

Matt,

The other obvious approach is to make the libraries sharable, which will
help when more than one of dhclient, dhcpd and bind is present. To be
effective, the libraries need to be modular enough that including one
doesn't drag in everything. Optimizing code placement can also help;
many embedded environments have VMs, and can tolerate dead code storage
(but not activation). FLASH is fairly cheap. But if you're storage
limited and stuck with existing hardware, you're left with shrinking the
code. And of course if you only need dhclient, sharable libraries are
counter-productive. This is probably an exercise best left to ISC - or
at least, done once and contributed.

Finally, you can tweak your compiler flags to optimize for (small) code
size at the expense of speed. The defaults will do unrolling & inlining
that you probably don't need. dhcpd can be performance critical (though
rarely when it's embedded). DHClient shouldn't care how slowly it
runs. Perhaps the DHClient build flags should recognize this.

In any case it's nice to hear that there's someone else who care about
embedded systems. I mention them to ISC fairly regularly, but it's not
obvious that we're heard. Yet just about every NAS, router, and CPE
gateway that I look into uses dhcpd/dhclient.

I run dhcpd and bind on old, slow XSCALE processors (and RPi) - but I
have the advantage of USB disks so I just let VM negotiate a reasonable
working set. I don't run DHclient.

Good luck.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

smime.p7s (6K) Download Attachment

Vicky Risk

Re: dhclient binary size

Administrator

The reason we kept DHCP 4.1.x around, after its planned EOL date had passed, was specifically to preserve an option for people who needed a smaller footprint.

All of the support we get for ISC DHCP today is for the server, so that is where we have been focusing our efforts. We do not have any financial support for maintaining or optimizing the client (despite the many devices apparently running the software).

If anyone on the list wants to discuss funding an engineer to work on reducing the client footprint, or funding a client based on Kea, you can contact me off-list at [hidden email]. We are certainly open to it.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

signature.asc (859 bytes) Download Attachment