As David stated, Per RFC 1541:
https://tools.ietf.org/html/rfc1541 "DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag" Taking us to RFC 1542: https://tools.ietf.org/html/rfc1542 3.1 Client use of the 'flags' field 3.1.1 The BROADCAST flag Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY messages directly to a client using unicast delivery. The IP destination address (in the IP header) is set to the BOOTP 'yiaddr' address and the link-layer destination address is set to the BOOTP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until they know their own IP address (thus we have a "chicken and egg" issue). Often, however, they can receive broadcast IP datagrams (those with a valid IP broadcast address as the IP destination and the link-layer broadcast address as the link-layer destination). If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY messages it generates. This will provide a hint to BOOTP servers and relay agents that they should attempt to broadcast their BOOTREPLY messages to the client. If a client does not have this limitation (i.e., it is perfectly able to receive unicast BOOTREPLY messages), it SHOULD NOT set the BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0). DISCUSSION: This addition to the protocol is a workaround for old host implementations. Such implementations SHOULD be modified so that they may receive unicast BOOTREPLY messages, thus making use of this workaround unnecessary. In general, the use of this mechanism is discouraged. I'll check DHCP IB implementation from my previous SRU from: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141 For this BROADCAST flag distinction on IB DHCP requests. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1529815 Title: InfiniBand DHCP flow with PRA and DHCP relay not working Status in isc-dhcp package in Ubuntu: Confirmed Bug description: DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast. The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file. this issue exist even when we use always-broadcast statement in configuration file. in other vendors we see that discover request type is broadcast. attached pcap files from working (other vendor) and not working (Ubuntu) clients. DHCP CLIENT (IPoIB) Ubuntu 14.04 kernel 3.13.0-74 Mellanox OFED 3.1-1.0.3 or inbox driver isc-dhcp-client 4.2.4-7ubuntu12.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
