It’s official. I’m now part of the uRadMonitor network, & assisting in some of the current issues with networking some people (including myself) have been having.
It seems that the uRadMonitor isn’t sending out technically-valid DHCP requests, here is what Wireshark thinks of the DHCP on my production network hardware setup:
As can be seen, the monitor unit is sending a DHCP request of 319 bytes, where a standard length DHCP Request packet should be ~324 bytes, as can be seen on the below screen capture.
This valid one was generated from the same SPI Ethernet module as the monitor, (Microchip ENC28J60) connected to an Arduino. Standard example code from the EtherCard library was used to set up the DHCP. The MAC address of the monitor was also cloned to this setup to rule out the possibility of that being the root cause.
My deductive reasoning in this case points to the firmware on the monitor being at fault, rather than the SPI ethernet hardware, or my network hardware. Radu over at uRadMonitor is looking into the firmware being at fault.
Strangely, most routers don’t seem to have an issue with the monitor, as connecting another router on a separate subnet works fine, and Wireshark doesn’t even complain about an invalid DHCP packet, although it’s exactly the same.
As the firmware for the devices isn’t currently available for me to pick apart & see if I can find the fault, it’s up to Radu to get this fixed at the moment.
Now, for a µTeardown:
Here is the monitor, a small aluminium box, with power & network.
Removing 4 screws in the end plate reveals the PCB, with the Geiger-Mueller tube along the top edge. My personal serial number is also on the PCB.
The ethernet module is on the right, with the DC barrel jack.
Here is the bottom of the PCB, with the control MCU & the tiny high voltage inverter for the Geiger tube.
A Closeup of the main MCU, an ATMega328p
PCB Logo. Very artsy 😉