I am currently investigating a peculiar issue with DHCP on a custom board/firmware based around an STM32H743.
The firmware uses the STM32 HAL drivers and LWIP middleware which are configured courtesy of CubeMx before the project is imported into Visual Studio using the VisualGDB plugin.
The 46-bit MAC address assigned to each device consist of my organizations 24-bit OUI with remaining 24 bits made up with a unique sequential number assigned to each unit. By default, the devices will use DHCP to obtain an IP address.
The crux of the issue that we are having is that we have observed that certain MAC addresses cannot obtain an IP address using DHCP when connected to our corporate network despite working correctly when connected to a smaller network (i.e. directly to a Netgear DG type router acting as a DHCP server).
As an example, five units where assembled with MAC addresses ending as follows:
00:00:92
00:00:93
00:00:94
00:00:95
00:00:96
The unit with the MAC address ending in 95h does not work.
When attached to the corporate network and monitoring with wireshark it is possible to see the DHCP discovery packets originating from a device which has been given a non-working MAC address. The DHCP discovery packets look perfectly valid when compared to the same requests originating from a device with good MAC address. We have been able to capture packets in such a way that we can observe the request broadcast from the device and the response from the DHCP server (should it reply).
We have already tried/eliminated the following:
- If DHCP isn't used and a static IP address is assigned the unit will talk on the network without any issues, regardless of the MAC address.
- Using the same device and changing the MAC from a non-working one to a working work causes DHCP to work (i.e. changing the MAC address in the unit originally programmed with 95h to 96h).
- Used the same drivers and LWIP middleware to create a test project for an STM32H743 Nucleo dev. board and observed the same issue (some MAC addresses work, some do not).
- Changed the MAC address on the ethernet port of a Raspberry Pi to one that does not work in our devices (using raspian and the macchanger application). This works, the DHCP discovery packet from the Raspberry Pi does contain a few more optional fields we have subsequently added into the requests originating from our device but to no avail. The Raspberry Pi is also using IPV6 and MDNS which we do not use in our device. Note that the RPi is not on the network at the same time as the device with the same MAC.
We have raised the issue with corporate IT and apparently there are no block/allow lists/filtering which could be causing this issue. In addition to this these MAC addresses have not been used in the organization prior to assembling this first batch of products. The obvious immediate solution is to do final testing of the product on a separate LAN, not on the corporate network, however we hope to find the root cause of the issue so that our end users do not experience the same problem in the field.
Any suggestions are welcome.
