IAID value in the ClienID for IPMC

1

Dear CERN IPMC experts,

Please see below the findings of the people working on the OpenIPMC firmware for some of the boards used in CMS.

They initially use IAID = 2 and the CERN IPMC uses IAID = 4 so the DHCP with ClientID which was designed to work with the CERN IPMC did not work.

Could you confirm IAID = 4 should be used ?

Could you maybe explain the reason why IAID = 4 is used rather than IAID = 2 as I have difficulty in understand the explanations in the spec and their meaning/implications ?

Many thanks for any information you can provide.

Marc

I’ve been working on the OpenIPMC firmware for the CMS Serenity ATCA boards. The DHCP client code was implemented following the Custom hardware network interface specification for Phase‑2 CMS (EDMS 2735323), and I wanted to share a recent finding that might be worth noting in the spec.

We ran into an issue where the DHCP server was not assigning IP addresses to the IPMCs. After some investigation, we compared the Client ID sent by the OpenIPMC with the expected configuration on the DHCP server. Everything matched except for the IAID field (bytes 1–4).

The OpenIPMC was sending 0x00000002, while the DHCP server expected 0x00000004.

According to the PICMG HPM.3 specification:

  • IAID = 2 means the IPMI LAN channel is connected to the first Fabric Interface Channel (ignoring IPMI LAN indices 0 and 1).

  • IAID = 4 means the IPMI LAN channel is connected to the first LAN Interface (ignoring IPMI LAN indices 0 through 3).

In our setup, the DHCP server was configured to recognize IAID = 4. Changing the firmware to use 0x00000004 (i.e., switching from Fabric Interface Channel to LAN Interface Channel) resolved the issue. The board immediately received its IP and responded to ping.

Given that the CMS implementation expects IAID = 4 for the Serenity boards, it might be worth updating the spec document to reflect that.

I’m happy to share Wireshark captures or the exact code change if useful. I’ve also attached a presentation I gave at last week’s Hardware & Integration meeting about this issue.