[Bug 657402] New: dhcpcd sends RENEWAL as ethernet broadcast instead of unicast
https://bugzilla.novell.com/show_bug.cgi?id=657402 https://bugzilla.novell.com/show_bug.cgi?id=657402#c0 Summary: dhcpcd sends RENEWAL as ethernet broadcast instead of unicast Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: All OS/Version: openSUSE 11.3 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: martin.konold@erfrakon.de QAContact: qa@suse.de Found By: --- Blocker: --- Created an attachment (id=403341) --> (http://bugzilla.novell.com/attachment.cgi?id=403341) Wireshark Sceenshot User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.8) Gecko/20100723 SUSE/3.6.8-1.1 Firefox/3.6.8 I discovered that the dhcpcd has a regression since SLES10 with regards to DHCP renewals. When dhcpcd got the initial lease successfully it shall perform a DHCP RENEW after T1. In contrast to the initial DHCP REQUEST the RENEWAL is not a broadcast but a unicast message to the DHCP Server. Current (Factory) dhcpcd-3.2.3 as used since OpenSUSE 11.0 has a regression which was not present in dhcpcd-1.3.22pl4 (SLES-10). Correct DHCP renewal semantics as implemented in dhcpcd-1.3.22pl4: * After renewal is due a special DHCP REQUEST is send as a unicast message to the DHCP Server * This unicast message is sent to the IP of the DHCP server * If the DHCP server is within the same LAN this unicast message is sent to the MAC address of the DHCP server on the ethernet layer. * If the DHCP server is in another network the unicast message is sent to the responsible gateway MAC address Incorrect DHCP renewal semantics as implemented in dhcpcd-3.2.3 (Factory) * After renewal is due a special DHCP REQUEST is send as a unicast message to the DHCP Server * This unicast message is sent to the IP of the DHCP server * If the DHCP server is within the same LAN this unicast message is sent to the MAC BROADCAST address (ff:ff:ff:ff:ff:ff) on the ethernet layer. * If the DHCP server is in another network the unicast message is sent to the MAC BROADCAST address (ff:ff:ff:ff:ff:ff) on the ethernet layer instead directly to the responsible gateway MAC address. * At least CISCOs by default don't forward packages received via Ethernet broadcast to the destination server. Consequences OpenSUSE cannot perform DHCP renewals --> After the lease finally expires the network access is interrupted and a new lease has to be aquired. --> errors on the network level, outages etc. Reproducible: Always Steps to Reproduce: 1. obtain a DHCP lease e.g using rcnetwork restart 2. verify that a DHCP lease was granted (check /var/lib/dhcpcd/dhcpcd-eth0.info 3. wait for DHCP renewal (or use /sbin/dhcpcd -n to force it manually) 4. use a network sniffer like wireshark for tracing the DHCP REQUEST Actual Results: 1. A DHCP REQUEST with correct payload is generated. 2. This unicast UDP packet is sent to the IP address of the DHCP server. 3. On layer 2 (ethernet) the package is sent to ff:ff:ff:ff:ff:ff (ethernet broadcast) 4. The package is dropped by the gateway 5. The package is not received by the DHCP Server (which lives in a different broadcast domain) 6. The renewal does not happen 7. Some time later the DHCP lease expires 8. A new lease needs to be requested by dhcpcd 9. A short network outage is noticable and some applications have trouble Expected Results: 1. A DHCP REQUEST with correct payload is generated. 2. This unicast UDP packet is sent to the IP address of the DHCP server. 3. On layer 2 (ethernet) the package is sent to MAC address of the DHCP server (same network) or to the MAC address of the gateway. 4. The package is directly received by the DHCP server or 5. forwarded by the responsible gateway as a unicast package 5. The package is received by the DHCP Server (which might live in a different broadcast domain) 6. The renewal is Acknowledge 7. The lease does never finally expire as the RENEWAL is working as defined in the RFCs 8. No network outages are observed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c1
--- Comment #1 from Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c
Xinli Niu
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c2
Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c3
--- Comment #3 from Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c4
--- Comment #4 from Martin Konold
From discussion with Roy Marples:
I only recently got dhcpcd updated in Debian to dhcpcd-5 from
dhcpcd-3.
That involves a new package the worked alongside dhcpcd-3 because
dhcpcd-5 now works as a single process on all interfaces. It can still
work per interface but not 100% the same way with dhcpcd-3. SuSE may
wish to go the same way.
Yours, -- martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c
Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c5
--- Comment #5 from Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c6
--- Comment #6 from Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c7
Lucas Vieites
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c8
--- Comment #8 from Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c9
Paul Zirnik
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c15
Paul Zirnik
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c16
Marius Tomaschewski
* If the DHCP server is within the same LAN this unicast message is sent to the MAC address of the DHCP server on the ethernet layer. * If the DHCP server is in another network the unicast message is sent to the responsible gateway MAC address
Perhaps I miss something, but it seems it has to be sent directly to the server -- gateway is not involved: http://tools.ietf.org/html/rfc2131#section-4.3.2 "4.3.2 DHCPREQUEST message [...] o DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. A client MAY choose to renew or extend its lease prior to T1. The server may choose not to extend the lease (as a policy decision by the network administrator), but should return a DHCPACK message regardless. [...]" -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c17
--- Comment #17 from Marius Tomaschewski
I've a some early test code that seems to work -- at least in a setup without relay. I've to check why it does not work with a relay between [fw rules?]. I hope, we have a test package ready today - we'll see.
OK, the patch seems to work in a clean setup [without policy routing from previous tests that were still on the server ;-)]. I'll make a cleanup, attach the patch and provide Url to a test package.
Perhaps I miss something, but it seems it has to be sent directly to the server -- gateway is not involved: ^^^^^^^ relay of course...
Forget it: just a little confusion until I wrote it wrong. You didn't wrote it is sent to the dhcp relay as I read it, but to the gateway MAC. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c18
--- Comment #18 from Martin Konold
You write in your initial (and further) comment(s):
* If the DHCP server is within the same LAN this unicast message is sent to the MAC address of the DHCP server on the ethernet layer. * If the DHCP server is in another network the unicast message is sent to the responsible gateway MAC address
Perhaps I miss something, but it seems it has to be sent directly to the server -- gateway is not involved:
Just for clarification. DHCP renewal is always an unicast. Case 1: DHCP server is on the same ethernet segment. In this case the layer II ethernet destination address of the renewal request is the MAC address of the ethernet card of the DHCP server. The unicast destination ip address in the renewal request is the ip address of the DHCP server. Case 2: DHCP server is on a different ethernet segment. In this case the layer II ethernet destination address of the renewal request is the MAC address of the gateway. The unicast destination IP address in the renewal request is the IP address of the DHCP server. This is plain and standard IP. The gateway in this description has nothing to do with a DHCP relay. A DHCP relay does more than a plain IP gateway/router as it acts more like a proxy than a plain IP router. dhcpcd-3.2.3 incorrectly sends the DHCP renewal to the HW broadcast address ff:ff:ff:ff:ff:ff (not to be confused with the IP broadcast address) instead to the _unicast_ _HW_ address of the 1. DHCP server if it resides on the same segment or 2. gateway/router if the DHCP server lives in a different segment. In this case it is the job of the IP gateway to determine the This description has nothing to do with DHCP relay agents as these are according to the relevant RFCs NOT involved in DHCP renewal activities.
http://tools.ietf.org/html/rfc2131#section-4.3.2 "4.3.2 DHCPREQUEST message [...]
configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client.
Please note that in the Internet documentation (RFC) generally, and in this bug report specifically, a gateway is a plain IP-level router not a DHCP proxy or similar. This is different from giaddr which refers to a "Relay agent IP address, used in booting via a relay agent" as defined in RFC 2131. If required I can create a documentation on the byte level of a currently observed IP package during DHCP renewal and a correct package. Please tell me if this would be of some help. Yours, -- martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c19
--- Comment #19 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c20
--- Comment #20 from Marius Tomaschewski
(In reply to comment #16)
Just for clarification.
DHCP renewal is always an unicast.
Sure. I just didn't read carefully enough what you (correctly) initially wrote and have had a _dhcp_ _relay_ in my mind all the time, that forwards (as dhcp relay) the broadcast, but is not involved while _routing_ of the not the unicasts. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c21
--- Comment #21 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c22
--- Comment #22 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c23
--- Comment #23 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c24
Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c25
--- Comment #25 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c26
--- Comment #26 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c27
--- Comment #27 from Martin Konold
So when you see something like "sending DHCP_DISCOVER ... to $IPADDR"
I could not detect such a message in the logs. rt-z9856:/var/log # grep DHCP_DISCOVER messages Feb 22 14:49:47 rt-z9856 dhcpcd[4072]: eth0: sending DHCP_DISCOVER with xid 0x1fb25b79 Things look much improved on my tests sofar. The only thing I am wondering is what happends in the common case that the renewal does not change any DHCP parameters (same ip, route etc.). Does this lead to a reconfiguration of the ethernet device with potential network glitches? Yours, -- martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c28
--- Comment #28 from Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c29
--- Comment #29 from Marius Tomaschewski
I could not detect such a message in the logs.
OK.
Things look much improved on my tests sofar. The only thing I am wondering is what happends in the common case that the renewal does not change any DHCP parameters (same ip, route etc.).
Does this lead to a reconfiguration of the ethernet device with potential network glitches?
AFAIS it should not happen. It first adds the new address [may result in a "already exists" error, that is correctly ignored] and removes the old address only when they differ. Similar but more complex for routes. So the address and routes are never removed, when they didn't changed (but will be readded e.g. in case you've modified something manually). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c30
Martin Konold
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c31
Swamp Workflow Management
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c32
Swamp Workflow Management
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c33
Swamp Workflow Management
https://bugzilla.novell.com/show_bug.cgi?id=657402
https://bugzilla.novell.com/show_bug.cgi?id=657402#c34
--- Comment #34 from Bernhard Wiedemann
participants (1)
-
bugzilla_noreply＠novell.com