[ipxe-devel] BOOTP_FL_BROADCAST 0x8000 trouble

[Michael Brown]

On Friday 20 Apr 2012 10:09:07 Juergen Brunk wrote:
> I'm working on a iPXE solution and unfortunately I've run into trouble with
> the DHCP part. I've checked the forum and found a unanswered question: "
> So how can I ensure that iPXE uses #define BOOTP_FL_BROADCAST 0x8000 when
> doing DHCP?" This discribe my problem exactly.
> 
> <snip>
> Test with standard PXE:
> FLAGS: 7f80				<<<=== !
> 
> Test with iPXE:
> FLAGS: 0				<<<=== !
> <snip>
>
> Without this flag our firewall block such traffic - and unfurtunately it's
> not option to change something in the firewall. I'm not a C-Guru and tried
> to find the problem insite the src c-files but without success. Could you
> give me an advice how to ensure that the "FLAGS 7f80" is also set with
> iPXE?

RFC2131 section 2 defines the flags fields as:

  Bit 0x8000 : BROADCAST flag
  Remaining bits: MUST BE ZERO (reserved for future use)  

RFC2131 section 4.1 describes the intended use of the BROADCAST flag:

   A client that cannot receive unicast IP datagrams until its protocol
   software has been configured with an IP address SHOULD set the
   BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
   DHCPREQUEST messages that client sends.  The BROADCAST bit will
   provide a hint to the DHCP server and BOOTP relay agent to broadcast
   any messages to the client on the client's subnet.  A client that can
   receive unicast IP datagrams before its protocol software has been
   configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
   clarifications document discusses the ramifications of the use of the
   BROADCAST bit [21].

which references RFC 1542 (section 3.1):

  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.

  3.1.2 The remainder of the 'flags' field

   The remaining bits of the 'flags' field are reserved for future use.
   A client MUST set these bits to zero in all BOOTREQUEST messages it
   generates.  A client MUST ignore these bits in all BOOTREPLY messages
   it receives.


So, in summary:

a) your "standard PXE" stack is violating the DHCP specification, and

b) your firewall configuration is demonstrably broken.  :)

I would strongly recommend fixing the firewall configuration.  If this isn't 
possible, then you can force iPXE to always use BOOTP_FL_BROADCAST by patching 
dhcp_chaddr() in net/udp/dhcp.c to swap the order of the first two "if()" 
statements.

Michael