Bug 962950 - dhcpd/dhclient create an random listening port in addition to UDP 67/68
dhcpd/dhclient create an random listening port in addition to UDP 67/68
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
25
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Pavel Zhukov
Fedora Extras Quality Assurance
: Reopened
: 984244 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-14 16:17 EDT by Timothy M. Butterworth
Modified: 2017-06-09 15:12 EDT (History)
6 users (show)

See Also:
Fixed In Version: dhcp-4.3.5-2.fc25
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1486801 (view as bug list)
Environment:
Last Closed: 2017-05-26 23:01:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1176046 None None None Never

  None (edit)
Description Timothy M. Butterworth 2013-05-14 16:17:58 EDT
Description of problem:
DHClient creates an additional listening port in addition to UDP 68 which seems to be a random registered port value. This appears to be being caused by the NSUPDATE DNS functionality. Their is currently a bug filed with ISC [ISC-BUGS] #33377.

Version-Release number of selected component (if applicable):
isc-dhclient-4.2.5

How reproducible:
Install dhclient, start the service and perform a netstat -l -u -p and check each of the ports opened by dhclient.
  
Actual results:


Expected results:
That no random port numbers be opened. Please create a way to disable this functionality or repackage an additional version with it disabled.

Additional Info:
http://forums.debian.net/viewtopic.php?f=10&t=95273
http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
Comment 1 Jiri Popelka 2013-05-15 10:29:10 EDT
Disabling tracing (--disable-tracing) as suggested on the forum makes no change.
With --disable-failover it fails to build so I can't prove that it really makes the ports disappear, but anyway failover is crucial server functionality and there's no way we can disable it.
Comment 2 Jiri Popelka 2013-05-15 10:36:55 EDT
(In reply to comment #1)
> With --disable-failover it fails to build ...

fixed, built with --disable-tracing and --disable-failover but it's still the same.
Comment 3 Jiri Popelka 2013-07-15 09:43:37 EDT
*** Bug 984244 has been marked as a duplicate of this bug. ***
Comment 4 Harald Reindl 2013-12-06 08:35:56 EST
well, this affects any Fedora version from 18 to 20 and most likely Rawhide too

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|unspecified                 |medium
           Hardware|Unspecified                 |x86_64
            Version|18                          |20
                 OS|Unspecified                 |Linux
           Severity|unspecified                 |medium
Comment 5 Jiri Popelka 2013-12-11 06:35:48 EST
These ports are opened during libdns' (library from ISC bind) initialization of some managers and contexts.
Pity the code opens both ipv4 and ipv6 ports - I see this comment in bind/lib/dns/client.c:dns_client_createx()
/* TODO: whether to use dispatch v4 or v6 should be configurable */

This initialization can be avoided by undefining NSUPDATE in dhcp/includes/site.h (as suggested on the debian forum) but we can't do this because we need DDNS functionality for server. I doubt we need it on client so It'd perhaps be nice to turn it off for client, but the code is common (dhcp/omapip/isclib.c) for both client and server so it's not possible to turn it off/on only for one of them.

I don't see a way how to fix this atm.
Comment 6 Harald Reindl 2014-03-05 13:05:32 EST
sad to hear that there is no solution

in general i see no valid reason for a *random* port, no sane configured system will allow a incoming package on the one....
Comment 7 cooloutac 2014-09-18 17:02:10 EDT
Yes this is not sane.  To have dhclient, and rpcbind , etc. open half a dozen other random ports listening on my machine on default install for my home desktop doesn't feel to safe.

I've moved to a debian based distro.

Even if the firewall is blocking incoming, if we don't know why these ports are opened,  how do we know there are not other processes on our machines connecting out on them.   Which could be missed in logs, especially since it seems not enough people care to even question these things.
Comment 8 Pavel Šimerda (pavlix) 2014-09-19 05:37:16 EDT
How does Debian solve this issue?
Comment 9 cooloutac 2014-09-20 02:50:27 EDT
It doesn't solve the issue and I wished there was an edit button to delete that when I said it. I don't think dhclient is a specific distro problem.   going static is only thing that solves the issue for me.

I just noticed alot more services and default ports open on a default fedora compared to when using mint.     But when you disable ipv6,   which I finally figured out only worked from grub menu in fedora for me.   It doesn't feel as bad.

The truth is I only went to mint because for some reaosn the cinnamon mixer worked best with my surround sound system.
Comment 10 Fedora End Of Life 2015-05-29 05:03:44 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 11 Fedora End Of Life 2015-06-29 20:38:53 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 12 Harald Reindl 2015-06-29 20:45:19 EDT
still an issue on F21
Comment 13 Dan Berindei 2016-02-19 11:03:27 EST
still an issue on F23
Comment 14 Petr Menšík 2017-04-05 08:54:48 EDT
Hi. I have tried to reproduce this on Fedora 25. Ports are still created, but they are created directly by call from libisc.c:235
I think it should be really simple to change use of dhcp_context_create to not create dns client, unless it is used.

Ports are open after end of:

#0  dns_client_createx2 (mctx=0x55926f32b100, actx=0x7f1ddab2b010, 
    taskmgr=0x7f1ddab2c010, socketmgr=0x7f1ddab2d010, timermgr=0x7f1ddab2e010, 
    options=options@entry=0, clientp=0x55926e00e978 <dhcp_gbl_ctx+56>, 
    localaddr4=0x0, localaddr6=0x0) at ../../../lib/dns/client.c:440
#1  0x00007f1dda831c11 in dhcp_context_create (flags=<optimized out>, 
    local4=0x0, local6=0x0) at isclib.c:235
#2  0x000055926ddacb5b in main (argc=<optimized out>, argv=<optimized out>)
    at dhclient.c:273
Comment 15 Fedora Update System 2017-05-25 08:15:39 EDT
dhcp-4.3.5-6.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c5082937a8
Comment 16 Fedora Update System 2017-05-25 08:27:01 EDT
dhcp-4.3.5-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ceb7218382
Comment 17 Fedora Update System 2017-05-25 15:22:21 EDT
dhcp-4.3.5-6.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c5082937a8
Comment 18 Fedora Update System 2017-05-26 02:03:38 EDT
dhcp-4.3.5-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ceb7218382
Comment 19 Fedora Update System 2017-05-26 23:01:58 EDT
dhcp-4.3.5-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2017-06-09 15:12:07 EDT
dhcp-4.3.5-6.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.