Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#4292 closed defect (fixed)

BOOTP flags BROADCAST is not set for Relay Agent

Reported by: vadim.fedorenko Owned by: sar
Priority: high Milestone: Kea1.1
Component: dhcp4 Version: 1.0.0
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 3 Internal?: no

Description

There is a problem in sending DHCP Offer and DHCP Ack packets via Relay Agent for clients, that cannot receive unicast packet util IP address is set. Such clients sets BROADCAST BOOTP flag to 1 to indicate, that answer should be broadcasted. According to RFC1542 although clients should ignore this flag on received packet, "The relay agent SHOULD examine the newly-defined BROADCAST flag". However, KEA 1.0.0 does not set this flag in Offer and ACK packets even if it is set in Discover or Request packet from client. That's why some clients (most of Windows 7 and some others) cannot get IP address from kea via Relay Agent.
There is a proof in attached files.
The solution is to add some code to Dhcpv4Srv::adjustRemoteAddr method:

if (query->isRelayed()) {

If received relayed message, we should copy BROADCAST flag from
query to make relay answer correctly
response->setFlags(query->getFlags());

Subtickets

Attachments (3)

dhcp_kea_filtered.pcap (5.0 KB) - added by vadim.fedorenko 4 years ago.
dhcp_isc_filtered.pcap (1.6 KB) - added by vadim.fedorenko 4 years ago.
BOOTP_flag.diff (728 bytes) - added by vadim.fedorenko 4 years ago.
Patch to kea-1.0.0 source tree

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by vadim.fedorenko

Changed 4 years ago by vadim.fedorenko

comment:1 Changed 4 years ago by fdupont

BTW the broadcast flag is a hard point for DHCPv4-over-DHCPv6...

Changed 4 years ago by vadim.fedorenko

Patch to kea-1.0.0 source tree

comment:2 Changed 4 years ago by sar

  • Owner set to sar
  • Status changed from new to assigned

comment:3 Changed 4 years ago by sar

Upon review of RFC 2131 Table 3, I think the correct thing is for the server to always copy the flags field from the client request to the server response. I've added code in copyDefaultFields() to do this.

For the ChangeLog? entry I suggest:

10XX.	[bug]	sar
		Always copy the DHCPv4 flags field from a client's request to the server's response.
		(Trac #4292, git ...)

comment:4 Changed 4 years ago by sar

  • Owner sar deleted
  • Status changed from assigned to reviewing

comment:5 Changed 4 years ago by stephen

  • Owner set to stephen

comment:6 Changed 4 years ago by stephen

  • Owner changed from stephen to sar
  • Total Hours changed from 0 to .5

Reviewed commit 5d98905f627f5017738cc3e9184cfe509ee9d9d6

I agree with the analysis that the correct thing is for the server to always copy the flags field from the client request to the server response. Please add a comment line before the copying of the flags stating that, otherwise it is not completely clear why the flags are being copied.

The ChangeLog entry is fine.

I don't need to see this again. Please merge after adding the comment.

comment:7 Changed 4 years ago by sar

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged, commit number 8b7182abdc7ff47eb9b68451e7507b7e4b9872e0

comment:8 Changed 4 years ago by sar

  • Total Hours changed from .5 to 3
Note: See TracTickets for help on using tickets.