Symptoms:

• Unable to boot Xterminal
• DHCP client is unable to obtain an IP address
• BOOTP client is unable to obtain an IP address
• BOOTP client unable to boot across device
  • DHCP client unable to boot across device
• Diskless workstation cannot get IP address
• device ignores the “broadcast flag” in BOOTP packets

Facts:

• CoreBuilder 3500
• CB3500 Extended Software v2.1.0-5
• CB3500 Extended Software v2.1.0-6
• BOOTP
• DHCP

Causes: RFC 1542 states the following about the flag field:

The relay agent SHOULD examine the newly-defined BROADCAST flag.

If this flag is set to 1, the reply SHOULD be sent as an IP broadcast using the IP limited broadcast address 255.255.255.255 as the IP destination address and the link-layer broadcast address as the link-layer destination address.

If the BROADCAST flag is cleared (0), the reply SHOULD be sent as an IP unicast to the IP address specified by the 'yiaddr field and the link-layer address specified in the 'chaddr field. If unicasting is not possible, the reply MAY be sent as a broadcast, in which case it SHOULD be sent to the link-layer broadcast address using the IP limited broadcast address 255.255.255.255 as the IP destination address. When flag is set to 0 in the BOOTP reply, the CB3500 SHOULD forward this reply as a unicast to the client per RFC. It SHOULD send this unicast to the address specified in the “client server-assigned IP address” field. The CB3500 forwards the BOOTP reply always as a broadcast, no matter what the flag is set to.

In versions prior to v2.1.0-5, the CB3500 would ignore the broadcast flag in the BOOTP/DHCP header and would always relay the BOOTP/DHCP reply as a layer 2 and layer 3 broadcast.

The software was modified so that it would now respect the broadcast flag, and relay the BOOTP/DHCP reply as a unicast if the broadcast flag was 0. A portion of this software was incorporated accidentally in v2.1.0-5 and v2.1.0-6. This caused the BOOTP/DHCP reply to be relayed as a unicast, but instead of using the client's hardware address from the BOOTP/DHCP header, it would try to resolve this via ARP.

Since the client didn't yet have it's IP address, it would not respond to ARP, and hence the BOOTP/DHCP reply could not be delivered to the client. Version 2.1.0-7 will work as versions prior to v2.1.0-5 did - it will ignore the broadcast flag and always relay the BOOTP/DHCP reply as a layer 2 and layer 3 broadcast.

Version 2.1.0-8 will respect the broadcast flag, and if it is to send a unicast, it will use the client's hardware address as contained in the BOOTP/DHCP header, rather than trying to resolve the address via ARP.

Fixes: Fixed in S/W v2.1.0-7 or higher

Product(s): CoreBuilder Sub Product(s): CoreBuilder 3500 Family

— David Gonzalez 2021/04/14 09:58