All I Wanted Was a 2.4 GHz Network for My Sonos Speakers

The original requirement was not unreasonable

I have older Sonos speakers. They work, they sound fine, and I had no interest in replacing perfectly good speakers just because the rest of the network had moved on around them.

What they wanted was boring: a deliberately simple 2.4 GHz compatibility network using the legacy authentication mode they were happy with.

That should have been the whole project.

No custom router software. No firmware banks. No vendor data model. No Home Assistant network control plane.

Just: please connect the speakers to Wi-Fi.

There was a cleaner answer

In hindsight, we could have attacked the problem from the Sonos side.

Give the speakers the compatibility environment they wanted, isolate it properly, make discovery between the right parts of the network work, and leave the rest of the infrastructure alone.

Small problem. Small solution. Limited blast radius.

From a pure security and maintainability point of view, that is probably the cleaner design.

Obviously, that is not what happened.

The Vodafone Ultra Hub looked capable

I already had a Vodafone Ultra Hub, and the hardware itself was not the problem.

The interesting bit was that the normal Vodafone interface did not expose quite the Wi-Fi configuration I wanted.

That leads to one of the more dangerous sentences in home engineering:

The hardware can obviously do this. The interface just does not let me.

Once that thought takes hold, the problem changes.

It is no longer can the router do this?

It becomes what is stopping me?

And now we had a different project.

We got below the shiny interface

Once we had control of the router, it turned out to be much more interesting than expected.

Underneath the normal web interface there are firmware banks, vendor services, a TR-181-style data model, persistent configuration stores and boot-time machinery that tries very hard to put the router back into the state Vodafone expects.

That was the useful discovery: the Wi-Fi limitation was mostly a product-interface decision, not a hardware limitation.

So the original Sonos problem stopped being particularly difficult.

The new problem was making our changes survive.

Changing a setting once is easy. Changing it so the vendor stack does not politely undo it at the next boot is where the archaeology starts.

We had to work out which configuration was authoritative, which parts were caches, what happened during startup, and which services restored the vendor's desired state.

At that point this was no longer a Sonos fix.

Then we accidentally built a router platform

The first useful outcome was still simple: create the Wi-Fi networks I actually wanted.

One normal network.

One IoT/legacy network.

Keep old devices happy without making the rest of the house pretend it is 2012.

The physical port layout changed as well. Vodafone intended the red 2.5GbE port to be the WAN port. In my layout that was a waste of the fastest Ethernet port: the office side of the house, the Baby extender and the rest of the wired backbone had more use for 2.5GbE than the internet connection did.

So I moved the primary WAN onto a yellow gigabit port and repurposed the red 2.5GbE port as the office / Baby backbone.

That is probably one of the most useful takeaways from the whole exercise. Once the configuration is yours, the colour printed around a socket does not have to define what the socket does.

The other pleasant surprise was the stock Vodafone VDF7111 "Baby" extender. I did not want to throw away working mesh hardware just because the hub had been modified. We got the Vodafone SuperWiFi mesh onboarding working again and kept the Baby as part of the mesh, with Ethernet backhaul over the repurposed backbone.

So the final network is not "custom router plus random access point". The Ultra Hub and Vodafone extender still operate as one SuperWiFi mesh; they just do it inside the topology I actually want.

At the point shown above, the physical layout is deliberately not the Vodafone default:

Physical port	My use	Link
Red 2.5G	Office / Baby backbone	2.5GbE
Yellow 1	Proxmox host	1GbE
Yellow 2	Primary WAN	1GbE

The stock Baby is shown healthy with Ethernet backhaul. The router is still running the SuperWiFi controller and the mesh is using its normal radio machinery; I have changed the topology around it rather than replacing the extender with an unrelated access point.

That distinction matters. The interesting part of the project is not just that the Ultra Hub can be modified. It is that useful Vodafone hardware and features can be retained while the port roles, Wi-Fi policy and local management become mine.

Then persistence needed a control layer.

Once there was a control layer, a better local UI started to make sense.

Once there was a better UI, exposing the useful parts to Home Assistant started to make sense.

And since the router already handles fibre plus mobile backup, it would be rude not to expose that too.

That gives us a rather more interesting list than the original requirement:

• fibre and 4G WAN state
• current upload and download throughput
• daily, weekly and monthly traffic totals
• connected clients and Wi-Fi signal information
• DHCP leases and static reservations
• router health and uptime
• failover history
• separate Legacy and IoT Wi-Fi status
• safe network actions from Home Assistant

You can probably see where this is going.

At some point we had travelled quite a long way from make Sonos play music.

The Home Assistant end game

Home Assistant already knows about the useful state of the house: heating, lighting, energy, solar, battery, EV charging, temperatures and the rest.

The network is just as fundamental, so treating it as a separate black box feels increasingly artificial.

The eventual goal is a proper Network view inside Home Assistant: WAN health, traffic history, connected devices, static DHCP management, Wi-Fi status and infrastructure availability in one place.

Not because Home Assistant needs to become a raw router configuration editor.

It does not.

Firewall internals, low-level vendor configuration and anything capable of taking the whole house offline can stay behind the proper admin boundary.

The useful questions are much simpler:

Is the network healthy?

Which WAN are we using?

Who is connected?

How much data are we moving?

Can I reserve this device's address without opening another admin interface?

That is the level I actually want in Home Assistant.

Was any of this necessary?

For the original Sonos problem?

No.

The Sonos-side solution would have been smaller, cleaner and easier to maintain.

But once we started looking inside the Ultra Hub, the project became useful for a different reason: the hardware I already owned could do considerably more than the vendor interface exposed.

The result is no longer a workaround for three speakers. It is becoming a network platform that fits the house rather than forcing the house to fit the router UI.

That still does not make the escalation sensible.

It just makes it useful.

What I am not publishing

There is a difference between documenting how I repurposed hardware I control and publishing a recipe for attacking deployed routers.

So the public write-up stays on the first side of that line.

I am happy to document the architecture, behaviour, data model, Home Assistant integration and software I wrote around it. I am not publishing Vodafone credentials, device secrets, firmware blobs or an exploit chain that could be useful against somebody else's equipment.

If this becomes a public GitHub project, the useful bits will be the parts another owner can safely reproduce on their own hardware.

And the Sonos speakers?

They work.

Which is fortunate.

It would have been slightly embarrassing to reverse engineer half a router and still not be able to play music.

So yes:

All I wanted was a 2.4 GHz network for my Sonos speakers.

Somehow I ended up with control of a Vodafone Ultra Hub, custom Wi-Fi management, a network split, firmware-bank knowledge and plans for a Home Assistant network dashboard.

Perfectly normal home networking project.