Need to allow change of fallback carrier id in modem level (5G override problem)

cd18

Hello,
The current setting for "enable carrier overrides" does only what Pixel IMS used to do which is override that configuration to allow different settings. This is the equivalent to modifying the .pb files in ./vendor/google_devices/komodo/proprietary/product/etc/CarrierSettings - but it's not enough for 5G.

It seems "Force 5G" basically changes the nr_availabilities key, however it's not enough to override. This is because specifically for 5G NSA, a feature in the modem is also needed to be enabled for it to work EN-DC (EUTRA-New Radio Dual Connectivity). This is controlled by another place, specifically a database of settings and binary blobs located here (at least for komodo): ./vendor/google_devices/komodo/proprietary/vendor/firmware/carrierconfig/cfg.db

The file formats are unknown but cfg.db is itself a simple sqlite3 database. For "non-supported" countries, the settings of the carrier is used whose id is set in the regional_fallback table, which has only 1 record.

Doing the following statement works to fully enable it for me (tested by my own custom builds on komodo in one such "unsupported" region that has no modem config at all):

UPDATE regional_fallback set carrier_id = $FALLBACK_CARRIER_ID

Running this right before starting build, gives me a working 5G. The value of FALLBACK_CARRIER_ID may differ between device and others, but it corresponds to the primary key of the carrier_info table for the record which has mccmnc of 23820 (Telia Denmark). For komodo FALLBACK_CARRIER_ID = 656.

It would be great if we can have a selectable list of "fallback carrier mcc mnc" and graphene loads it into the modem, because very frequently an "unsupported" country has a very similar 5G rollout to neighbors, and very likely it's possible to choose a PLMN of a country with similar enough bands and setup that it works perfectly well.

An alternative way to do this can involve talking to the modem on every startup and/or sim switch to do the same as what the Pixel 5G and Network Signal Guru to enable it. This involves modifying the transient nvitems by AT commands with secret AT+GOOG commands. However this modification is transient and wiped out on any sim change or system update.

Here's the Pixel 5G app: https://github.com/SaeedDev94/pixel-5g

My suspicion is that these "blobs" beside cfg.db are the stock NVITEMS but in some encrypted and/or signed form.

Also, my understanding is that these methods only apply to the "Shannon" family of modems, the older Qualcomm Pixels need a different way.

Thanks for the great work that goes into this OS.

de0u

cd18 It seems "Force 5G" basically changes the nr_availabilities key, however it's not enough to override. This is because specifically for 5G NSA, a feature in the modem is also needed to be enabled for it to work EN-DC (EUTRA-New Radio Dual Connectivity).

Is it expected that over time carriers currently operating 5G NSA will switch to 5G SA? If so it might turn out to be the best use of GrapheneOS developer resources to just wait for the problem to solve itself.

My understanding is that the team invested in VoLTE forcing because it was believed that a significant number of users were facing the loss of carrier calling due to various countries disabling 2G and 3G calling in the near future. Making 5G available in areas where LTE infrastructure is solid (which I think is the use case for 5G NSA) might be less urgent.

cd18

de0u

It is unknown it depends on the priorities of the country. Some are fast in adopting new technologies, while others consider NSA to be "enough" and have no plans to deploy SA due to cost / value benefit ratio. In my country, new technologies are slow to be adopted and it maybe a 5-10 years before SA deployment happens.

My understanding is that the team invested in VoLTE forcing because it was believed that a significant number of users were facing the loss of carrier calling due to various countries disabling 2G and 3G calling in the near future. Making 5G available in areas where LTE infrastructure is solid (which I think is the use case for 5G NSA) might be less urgent.

Low hanging fruit first of course is fair, the priorities make sense. I have posted my research on how I got it working in hopes it would be incorporated or inspire a feature in a future release, since I have tested it on myself with a custom build and it worked perfectly.

That's all it needs to "unlock" SA+NSA

This is the "temporary" way. I guess this is also easy to implement, maybe a small hidden system app with limited permission to only do this one function can be made that runs every sim change or boot and fixes it without touching the proprietary vendor bundle files themselves during build.

23Sha-ger

Interesting research, the app only sends a specific command to /dev/umts_router which is the way Samsung modems work on Pixels 6-9. That's all it needs to "unlock" SA+NSA. I wonder why they hardcoded it this way, although using 5G in NSA mode in most cases will be same as just using LTE in terms of reliability and speeds.
I keep 5G off to consume battery, but won't mind having it on as a toggle.

cd18

Making 5G available in areas where LTE infrastructure is solid

Unfortunately in my country, they cannibalized part of LTE spectrum to create this NSA, which means that actually those who remain on LTE got downgraded :-(

de0u

cd18 Unfortunately in my country, they cannibalized part of LTE spectrum to create this NSA, which means that actually those who remain on LTE got downgraded :-(

I think that's mostly what carriers were expected to do. Over time (years) the amount of spectrum allocated to LTE will drop. Also over time it's increasingly likely that Google will ship carrier configs including various flavors of 5G on old devices and/or old devices will hit EOL. If not, and it seems that a bunch of people may be stranded, the GrapheneOS project may invest in some override code. But maybe the OEM partnership will go really well, and people will be thrilled with those device(s), and lots of GrapheneOS users will be selling off their Pixels, in which case the "market" for 5G tweaks for GrapheneOS Pixels might be thin.

"It is difficult to make predictions, especially about the future."

cd18

de0u

They already do ship carrier configs for this configuration of 5G for other countries. It's a country problem. They have no plans to sell pixels here thus they have no plans to ship a carrier config for my country anytime soon (if ever). The nvitem rules for the default fallback do not enable the en-dc capability of the modem for some strange reason, but they are binary signed blob of unknown format. So the only possible hack is make the fallback to another config that has almost everything enabled.

So in tools like NetMonster, the fact that 5G is available will be visible, but it will say EN-DC not available, and it will never switch to 5G NSA mode or make use of the bands.

Would the team consider such a contribution if I attempted to add it ? Or would it be declined due to security risks ?
I would probably try the simple modem approach that does not modify google proprietary vendor files, just add similar to Pixel 5G app logic when 5G override is enabled... but I don't know if the override activity code has enough privileges by selinux to talk to the modem, I will have to do some studying.

Is there a policy by the team to not touch vendor files during build ? that is the simplest way to solve it at build time.