DHCP – Experimental Engineering

I posted a while back a teardown of the VM Superhub 2 router, as VM has “upgraded” to a rebranded Arris TG2492S/CE CM. Alas Virgin Media in their wisdom have decided that simple router features like being able to change the LAN subnet & DHCP server range are far too complex to trust to the Great Unwashed, so they’ve removed them entirely from the firmware, and locked the local LAN onto the 192.168.0.0/24 range.
As my network is already numbered in the 10.0.0.0/16 range, with several statically addressed devices present and other systems relying on these static assignments, using this router would have meant renumbering everything.

Luckily Virgin had the decency to leave the “modem mode” option in the firmware, effectively disabling the WiFi & routing functions & allowing the connection of a third-party router. Some searching for a suitable replacement for the core of my network turned up the Linksys WRT1900ACS. While I waited for this to arrive, some temporary workarounds were needed to make everything function well enough with VM’s crap router.

These routers have been designed as a modern replacement for the venerable WRT54G series of routers from some time ago, with full support for OpenWRT/DD-WRT firmware, and with a beefy 1.6GHz dual core CPU & 512MB of RAM I doubt I’ll be able to knock this one over with too much network traffic! This was pretty much the most powerful router I could afford, and should mean I don’t need to upgrade for a long time. (No teardown of this yet, as it’s taking care of the network at present. Maybe some point in the future I’ll take the plunge).

The stock firmware isn’t totally awful, and has some nice features, but I decided it needed to be replaced with DD-WRT for more security & future flexibility. I’ll leave the firmware flashing stuff for another post 😉

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

Logo

PCB Logo. Very artsy 😉

Tag: DHCP

Virgin Media Hub 3 Crap & Router Upgrades

uRadMonitor – Node Online!