Case Studies / Latest Case A Game Console That Could Not Log In to the Building's WiFi: One Router That Signs In Once and Shares It (Shared Building Network, Darling Square)
On-site · Darling Square, Sydney CityBuilding-supplied shared networkCaptive portal login on every deviceGame console cannot authenticateOne working wall port, 100 MbpsOpenWRT router authenticates once
Shared building internet with a login page is fine right up to the moment you own something without a screen and a keyboard. A games console, a smart TV, a printer, a NAS — none of them can open a web page and type a code, so the network treats them as if they had never asked. The fix is not to argue with the portal. It is to put one device in front of it that can log in, and let everything else sit behind that device.
Why the console was never going to connect on its own
A captive portal works by letting a device onto the network and then intercepting its web traffic until it has been through a login page. That design quietly assumes every device on the network is a thing with a browser, a screen and someone typing on it.
Plenty of devices are not. A games console, a smart TV, a printer, a streaming stick, a NAS — they connect, they wait to be let out, and nothing ever lets them out. From the user's side it looks like the console cannot connect. In fact it connected fine and is sitting behind a door it has no hand to open.
Recognising this is most of the work. Once you know the fault is the gate rather than the link, you stop trying to fix the console and start looking for something that can do the signing in on its behalf.
Where the console was getting stopped
Building network
available
→
Wall port in the room
1 of 2 works
→
Captive portal login
needs a browser
Blocked here
→
Game console
no way to log in
Nothing here is broken and nothing is slow. The console reaches the network perfectly well and is then held at a web page it has no way to display. This is a category of fault that no amount of restarting, re-cabling or speed testing will touch, because the link is fine and the gate is the problem.
Why a switch does not help, and why MAC cloning is a gamble
A switch was the customer's first instinct and it is the wrong tool, for a reason worth stating plainly: a switch has no identity on the network and signs in to nothing. Everything you plug into it still arrives at the portal as itself, and still gets stopped. Splitting one port into four does not get you past a login page.
The second idea — putting an ordinary router in and having it copy the MAC address of a device that has already authenticated — is a real technique and does work in some places. But it is borrowing an identity rather than holding one, and buildings that care about who is on their network often have checks that make it unreliable. We did not want to hand over a setup that might quietly stop working a week later.
So the criterion became: whatever we install has to be capable of going through the login itself, on its own terms, and staying authenticated.
Three ways to get a console past a login page
| Plain switch | MAC cloning on a normal router | OpenWRT router (what we used) |
|---|
| Can it complete the login? | No — it just passes traffic | No — it borrows an identity | Yes — it signs in itself |
| Reliability in a managed building | Fails outright | Uncertain — some buildings check | Works within the portal's own rules |
| How often you authenticate | Every device, every time | Once, for the borrowed identity | Once, for the router |
| Devices with no browser | Still stuck | May work | Work over WiFi and cable |
| What it takes to set up | Nothing | A little configuration | More configuration up front |
One login, then everything behind it
An OpenWRT router meets that criterion because it can be configured to handle the portal authentication itself rather than passing it through to whatever is plugged in behind. Once it is signed in, it is the network's authenticated client, and everything downstream of it — the console over a cable, the desktop over a cable, phones and laptops over its WiFi — simply uses that connection.
The practical difference in daily life is larger than the technical description suggests. Before: every device, every time, someone has to find the login page. After: nothing ever sees a login page again except the router, and the router does it without being asked.
We brought several routers to site and tested until the configuration held, which is the honest way to describe this kind of job — portals differ from building to building, and the only proof that a setup works is that it is still working after you have connected everything to it.
How the visit ran
1
Established what the network actually is
Shared building network with web login
2
Checked the room's wall ports
Two ports, one live, tested 100 Mbps
3
Confirmed the console cannot authenticate
No way to reach the login page
4
Ruled out a plain switch
It cannot sign in to anything
5
Weighed MAC cloning on an ordinary router
Unreliable where the building checks
6
Set up an OpenWRT router to do the login
Router authenticates, then shares
7
Tested with several routers on site
Settled on the working configuration
8
Verified console, desktop and wireless
All stable at 100 Mbps
About that 100 Mbps, and the dead second port
Two smaller findings are worth recording. The room has two wall ports and only one of them is live — common in apartments, where not every faceplate is patched through at the other end, and not something a tenant can change. Worth testing both on day one so you know which one to build around.
And the speed sits at 100 Mbps on both wired and wireless testing, which we confirmed is the port itself rather than anything we installed. On a shared building network that ceiling is what it is; the router in front of it does not lower it, and no router will raise it. What changed here was not speed, it was whether the devices could get on at all.
What to take from this one
- If your building's internet needs a code on a web page, check before you move in how devices without a screen are meant to connect. Often the answer is that they are not.
- A switch will not get you past a login page. It has no identity of its own and signs in to nothing.
- Borrowing an authenticated device's identity works in some buildings and fails in others. Do not build on it if the building actively manages its network.
- A router that can complete the portal login itself turns "every device, every time" into "once, by the router".
- Test every wall port in the room on day one. Half of them being dead is normal, and you want to know which half.
- If you are living somewhere with a shared or authenticated network, a travel router or soft router is worth owning before you need it.
Result
The OpenWRT router now completes the building's portal login itself and shares the connection over both its WiFi and its LAN ports, so the game console and the desktop go online by cable with nothing to authenticate and phones and laptops join its wireless normally. Wired and wireless both test steady at 100 Mbps, which we confirmed is the wall port's own limit rather than anything introduced by the setup.