|Summary:||Sending dhcpv6 reply to wrong port number|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Vanboxtel <redhat-support>|
|Component:||dhcp||Assignee:||Jiri Popelka <jpopelka>|
|Status:||CLOSED ERRATA||QA Contact:||Ladislav Jozsa <ljozsa>|
|Version:||6.3||CC:||ljozsa, lnovich, ovasik, psimerda, rupatel|
|Fixed In Version:||dhcp-4.1.1-35.P1.el6||Doc Type:||Bug Fix|
Cause: DHCPv6 request from DHCPv6 client came from a random port number instead of defined 546/udp. Consequence: DHCPv6 server sent reply back to the source port of the message instead of defined 546/udp. Fix: Reply handling in the DHCPv6 server code was modified. Result: Server sends reply to a 546/udp rather than to the source port for the incoming message.
|Last Closed:||2013-11-21 07:43:50 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Vanboxtel 2013-04-15 09:06:06 UTC
Description of problem: when a device does a DHCPv6 request from a random port number, the DHCPv6 service reply back to the random port number and not communicate back to the IPv6 standard port number. In the RFC they doesn't specify the source ports, thus you may send a request from a random port. The RFC specifies only the destination port. DHCPv6 standard (http://www.ietf.org/rfc/rfc3315.txt) Version-Release number of selected component (if applicable): - How reproducible: Always when sending a DCHPv6 request from a random port number. Steps to Reproduce: 1. The client sends a request from UDP port 49159 to all dhcpv6 services on the lan 2. The DHCPv6 services sending a replies back to the same port number 3. The client get a reply back on port number 49159 Actual results: the DHCPv6 service sends the reply to the wrong port number instead of UDP port 546 as was defined in Expected results: The DCHCPv6 service sends a reply back to UDP port 546 Additional info: When doing the same tests with a Microsoft 2008 R2 operating system. The client still sends request from a random port to the Windows 2008 DCHPv6 server, The DHCPv6 server sends it back to the UDP 546 port. The client accepts the message and configurate a dns server adress.
Comment 3 Jiri Popelka 2013-04-22 10:21:03 UTC
(In reply to comment #0) > 1. The client sends a request from UDP port 49159 to all dhcpv6 services on > the lan > 2. The DHCPv6 services sending a replies back to the same port number Reply [tech-list] from Neil Horman: Its not very well defined behavior to say the least. Arguments can be made both ways on this subject. But regardless, given that server behavior is varied on this front, certainly the most compatible thing for a client to do is simply send data on port 546.
Comment 4 Vanboxtel 2013-04-22 11:46:27 UTC
(In reply to comment #3) > (In reply to comment #0) > > 1. The client sends a request from UDP port 49159 to all dhcpv6 services on > > the lan > > 2. The DHCPv6 services sending a replies back to the same port number > > Reply [tech-list] from Neil Horman: > Its not very well defined behavior to say the least. Arguments can be made > both > ways on this subject. But regardless, given that server behavior is varied > on > this front, certainly the most compatible thing for a client to do is simply > send data on port 546. The client is a dedicated device where it is not possible to change ports. I have contacted the manufacturer of the client with this problem, they said: 'We follow the RFC standard and the Red Hat DHCP server doesn't. They always need to follow international standards' In my opinion the most obvious solution is forcing the replies to the port as it was defined in the RFC standard.
Comment 5 Jiri Popelka 2013-04-22 12:28:37 UTC
You're right, it's a bug and has already been fixed upstream. From dhcp-4.1-ESV-R3 release notes: [ISC-Bugs #23196] - Modify the reply handling in the server code to send to a specified port rather than to the source port for the incoming message. Sending to the source port was test code that should have been removed. The previous functionality may be restored by defining REPLY_TO_SOURCE_PORT in the includes/site.h file. We suggest you don't enable this except for testing purposes.
Comment 9 Vanboxtel 2013-04-23 13:59:04 UTC
I have installed the test built packages, now the DHCPv6 service behave as prescribed in the RFC document. When can we expect this test built packages in a stable release of the Red Hat enterprise operating system ? Thanks
Comment 17 Pavel Šimerda (pavlix) 2013-09-10 19:15:28 UTC
(In reply to Jiri Popelka from comment #6) > Created attachment 738509 [details] > patch I see it's too late to confirm.
Comment 18 Ladislav Jozsa 2013-10-15 14:59:13 UTC
Verified with dhcp-4.1.1-38.P1.el6.x86_64. dhcpd now sends response to standard dhcpv6-server port even if client uses non-standard port to query server.
Comment 19 errata-xmlrpc 2013-11-21 07:43:50 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1572.html