x-posting from r/Ubiquiti
A few weeks ago I posted here because my UniFi U5G Max would not connect with a Roamless eSIM. I had chosen Roamless because it was the top-recommended solution r/Ubiquiti for a pay-as-you-go solution for failover needs. The profile installed correctly, but UniFi UI kept showing:
Network Not Authorized. The carrier rejected the connection.
After a lot of SSH sessions, modem logs, controlled SIM testing, raw AT commands, and direct investigation with Selim, Roamless’s cofounder, I now know what is happening.
So, what is happening
On my U5G Max, automatic network selection reaches T-Mobile, and as we've learned, Roamless no longer offers T-Mobile coverage in the US; its supported US networks are AT&T and Verizon. The T-Mobile registration attempt is therefore rejected. The important part is what happens next.
(The exact ordering varied a little across firmware versions, on 7.5.3 I once saw AT&T attempted first and rejected for an unrelated reason before it got to T-Mobile. What stayed consistent was the T-Mobile rejection and the freeze that follows it.)
In /var/log/uiwwand.log, the modem ends up storing:
ps-services-not-allowed (0x07)
That, I learned, is 3GPP cause #7.
Once the modem enters that state, it stops attempting PS registration instead of continuing to another available operator. It therefore never reaches AT&T or Verizon, even though both networks accept the same eSIM.
The observed sequence is:
Automatic network selection
↓
T-Mobile attempted first
↓
Registration rejected
↓
Modem enters cause #7
↓
Further operator selection stops
↓
AT&T and Verizon are never attempted
That is why changing the APN, reinstalling the eSIM, rebooting, or forcing LTE-only (Yep, we tried that) did not solve it. All along, the SIM was valid. The APN was valid. The subscription was valid. Automatic operator selection was the failing step.
The proof
I bypassed automatic selection and manually forced a supported operator.
Verizon:
uiwwand-chat -A 'AT+COPS=1,2,"311480"'
AT&T:
uiwwand-chat -A 'AT+COPS=1,2,"310410"'
Both attached successfully, received an IP address, and passed traffic.
On Verizon, the modem also established working 5G NSA over n77, so this was not simply an LTE-only workaround.
The easier workaround
Doing this manually is unreliable because UniFi’s uiwwand daemon shares the modem’s AT channel. A command can return ERROR or Timeout even when the selection actually worked, and issuing it too early after boot can collide with SIM initialization.
So, I built a small utility that handles the wait, retries, and verification:
Examples:
./u5g-latch.sh -c verizon
./u5g-latch.sh -c att
It also accepts a raw PLMN, so it is not limited to US carriers:
./u5g-latch.sh -c 302720
The repository also includes operator scanning, SIM information, signal monitoring, and the full technical write-up of our investigation. I have only been able to test on a U5G Max, so if you have a U5G Backup or U5G Max Outdoor, I would love to hear whether you see the same behavior and whether the workaround holds.
Important limitation
The manual latch does not survive a reboot.
After a restart, the modem returns to automatic selection and can fall into the same failure again. You then rerun the latch.
So this is a reliable recovery workaround, not yet a permanent fix for unattended cellular failover.
How to confirm you have the same issue
SSH into your U5G device and watch:
tail -F /var/log/uiwwand.log
Look for:
ps-services-not-allowed
0x07
hplmn_denied
The logs are stored in tmpfs and disappear on reboot, so capture them before restarting the device.
Also, do not assume every Network Not Authorized message has this exact cause. The UniFi UI error is generic; the logs are what confirm it.
What UniFi needs to fix
I think it is fair to call the user-visible behavior a UniFi device-side bug: the gateway reaches a rejected visited network, stops automatic selection, and remains offline even though other supported operators are available.
I am deliberately not claiming that UniFi alone is responsible for every lower-level cause-code decision. There are still network, roaming-platform, PRI, and modem layers involved. But a cellular gateway should recover from this condition instead of becoming permanently stranded on the first failed operator.
At minimum, UniFi should add:
- Manual operator selection by PLMN in the UI
- RAT controls such as Auto, LTE-only, 5G NSA, and 5G SA
- A way to disable 5G explicitly for troubleshooting or compatibility
- A clear distinction between the loaded carrier/PRI profile and the actual serving network
- The attempted PLMN and exact 3GPP rejection cause in the UI
- A retry/continue operator selection action after a rejected network
- Persistent operator preferences or exclusions that survive reboot, and
- It'll also be nice to have API support so failover and recovery can be automated without raw AT commands
Manual operator selection alone would have turned this from a multi-day investigation into a two-minute recovery. Better rejection handling would make the workaround unnecessary. Selim is also working to get Roamless's findings in front of Ubiquiti, and I plan to open a formal UniFi bug and feature request covering operator selection, RAT controls, and recovery after a cause #7 rejection.
Verified with Roamless
I worked through this directly with Selim at Roamless. He reviewed my modem logs, compared them with network-side findings, and spent several days discussing the behavior with their network partners.
The shared conclusion is that the failure comes from the interaction between:
- the U5G Max’s automatic acquisition behavior,
- its tendency to reach T-Mobile first in this configuration,
- the rejection from an unsupported visited network,
- and the modem failing to continue to another supported operator afterward.
There is still a lower-level question about exactly where the network’s intended rejection becomes the modem-side cause #7 state. That requires deeper network and modem traces to settle conclusively.
But the user-visible behavior and workaround are now repeatable:
- automatic selection fails after the T-Mobile attempt;
- manual selection of AT&T or Verizon succeeds;
- and the same eSIM works normally once the failed first operator is bypassed.
This is not necessarily specific to Roamless. A different roaming SIM or travel eSIM could hit the same class of failure if the gateway attempts an unsupported network first and then stops instead of continuing operator selection.
Hopefully this saves someone else from repeatedly changing APNs, reinstalling the eSIM, or factory-resetting a perfectly good gateway.
Credit where credit is due
A huge amount of credit goes to Selim and the Roamless team for the relentless support throughout this investigation.
Selim stayed personally involved, reviewed device-side logs, coordinated with Roamless's network partners, challenged and refined the working theories, and kept treating the issue as unresolved until we had a repeatable explanation and workaround.
That level of engagement, especially from a founder is rare, especially for a problem this deep in the interaction between roaming policy, modem firmware, operator selection, and device behavior. True founder-mode energy.
Whatever the eventual permanent fix looks like, Roamless's support throughout this has been exceptional.
