Yes, the DHCP Offer is sent by the router itself.

This is the strange thing, I get the same results on a router that works, even Wireshark detects the DHCP request as a valid one.

I can only think that the DHCP frame is getting mangled somewhere by the network infrastructure, due to some freak bug in how the packet is constructed.

The only difference I can see is the packet length, so there’s something missing from it somwehere. However I’m no expert on DHCP 😉

Screen capture from a working router setup

de 2E0GXE

Right. I’ve rerun some of my checks with my alternative setup.

It isn’t the MAC address that my router has an issue with, it connected fine.

There seems to be something missing from the DHCP packet, the uRadMonitor is sending a packet 319 bytes long, while my working test device is sending 324 bytes.

Screenshots posted are from Wireshark & my router’s admin interface. My cloned MAC is clearly showing on the bottom line with addresss .250

Peter, the uRadMonitor never gets a DHCP lease, as it seems to be sending an invalid DHCP request packet, or at least it’s sending something that my network equipment doesn’t like. (See attached image on my initial post).

I have done some more testing with a separate SPI network module, the same as is installed in the uRadMonitor, which I can get working on my usual network hardware without issue, using standard example code to enable DHCP. This is pointing me more at a firmware bug on the monitor, rather than my network equipment or the network hardware in the uRadMonitor.

Using another router does work. Unfortunately though, in the long term, segregating a seperate segment of my network is not a solution.

This thread is to get other people to post packet captures from their network, so I can possibly work towards finding out where the problem lies. (IRL, I’m a network engineer) ;).