touch-packages team mailing list archive

[Rafael David Tinoco <rafael.tinoco@xxxxxxxxxxxxx>]

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