Bypass regional restrictions #2665
Comments
|
There are per-region regulations on radios limiting the allowed bands, etc. Which region are you referring to? It likely only determines this based on your carrier. |
I have a US version of the pixel, purchased in the USA, which has no vendor restrictions (Verizon, etc) and so far there has been no SIM card in it at all. But the first time I started it (not graphene), it said to select a region, and I chose not US. After installing GOS, the system did not ask to specify the region, but in the hotspot settings this is now prohibited. In earlier versions, this could sometimes be circumvented by using a Google account in another country, but GOS doesn't seem to integrate Google services into the system, so this method is unlikely to work. Unless you delete GOS, install Pixel OS, log into your Google USA account, and then install GOS back |
|
In theory this issue can be resolved by forcing the US code (its enable only 5Ghz not 6?) or UK/India (for all) to be setting on the WiFi driver. On Linux this is done with the command iw reg set US, but for pixel it looks like it requires editing the WiFi driver itself. |
|
It doesn't know your region so that's why you're seeing what you are. |
|
GrapheneOS supports the Pixel 8, so it's not clear what you mean by what you said about the Pixel 8. |
Is there anything that can be done about this to make it possible to create 5 and 6Ghz Wi-Fi hotspots? I realize this is not a Grapheneos problem most likely, but the only way other Pixels users have found so far (not grapheneos) is to take action in the source code of the Bcmdhd driver to change the WiFi country code. Such actions are not possible in Grapheneos and verified boot. Therefore GrapheneOS users in countries where Pixels are not sold are forced not to use GOS or to use it but with limited features |
|
Put a SIM card for your region in it. |
This didn't help as the sim and the actual location of the smartphone is a region where pixels are not sold and not supported. The smartphone can connect to 5ghz networks but cannot create them |
|
I have a PR for this: GrapheneOS/platform_packages_apps_Settings#246 I haven't tested it and am probably unable to if I can't do it in the emulator as I live in a "supported" country (USA). EDIT: To add, I don't know if this will cause legal trouble in countries without 6 GHz Wi-Fi or use different 5 GHz bands than the phone. |
|
I am unable to test this since I cannot get into the Speed & compatibility screen shown. I will keep my PR open in case someone is able to test this. |
|
Only Gos developers can verify, right? A normal user with verified boot can't replace the system settings apk with this PR? |
|
Experiencing the same problem. Normal US pixel 6a, Russia, I have three Russian sims (one physical, two e) and one from another country where 5Ghz is fine too (Georgia) which is off right now. The system language/region is set to English/US I may be misremembering but i feel like this only started after i've activated Georgian sim. Unfortunately i can't delete it to test. If there is some debug info i can get from my phone via eg adb to figure out the reason for this strange behaviour i can do that |
|
That's probably not the reason. Pixel determines the region not by sim but by cell tower data. Your cell tower reports the country russia for which Pixel blocks 5 and 6 GHz functions, as this country does not have official Pixel stores. |
|
@dill-shower It's not enabled based on whether Pixels are sold or not in a country... |
In that case what does it depend on? In russia the law allows you to create your own 5 and 6Ghz networks, about a year and a half ago this patch was officially adopted in the Linux kernel and wireless-regdb. Desktop Linux OS can create such networks and don't break any law, Pixel can't. On Google Pixels forum users asked questions about this, the answer of Google representative was that Pixels are not sold in this country, so this problem will not be solved |
|
That's a low-level support employee, not an official statement from the company, and it's wrong. They support these kinds of features in plenty of countries they'd not sold in. |
|
That may be the case. But it doesn't look like Google is going to fix this problem or even consider it a problem at all, and the option of emigrating for the sake of supporting this feature is not being considered by users. And... I found this theme https://support.google.com/pixelphone/thread/242493101 |
|
I wanted to include the linked PR in my own local build, but was wondering why it's a massive 10k lines? From skimming it, I see that most changes seem to be unrelated to the issue at hand. Or am I missing something? |
You only need this GrapheneOS/platform_packages_apps_Settings@a795a9b |
|
If we do allow users to bypass these restrictions, a similar warning to the one for call recording should be added as well. Specifically, that the user is responsible for following any and all laws in their region. Anyway, I came across this issue because 6GHz is greyed out for me. I am in the USA, and preliminary research suggests that it's disabled here because the band was only approved for indoor use. Since Google can't ensure that users will do this, they disabled it entirely. Bypassing the restrictions in this case could be done legally, and could be very useful (e.g. in areas where 5GHz is congested). I don't believe there would be any considerable security impact with enabling this, but 6GHz networks are still fairly rare in most places, so its use could cause the user to stand out. Ideally, someone with more knowledge on the subject could confirm that there are no fingerprinting issues; most importantly, it must not be possible for an unaffiliated individual within range to determine that the AP is an Android device. If this were possible, it would drastically reduce the set of potential devices, possibly even to only those running GrapheneOS (I do not know if any other ROMs remove these restrictions). |
|
@dill-shower (To be sure that it works) Have you tested this patch on device by build&flash? |
It's far harder for people to understand the regulations and consequences of something like this than call recording. We do not know what led to the current configurations ourselves and don't particularly want to deviate from the stock OS in this area without understanding the reasons for it. |
In many countries Google Pixel is not officially certified for some bands because of many cases (in my assumption just because these devices are primarily made for specific sets of markets where bulk approvements were granted and also they were intended to be sold in these regions only). But not approved by time for other countries even if it is legally allowed to use these bands and many consumer devices like routers, laptops, other phones already use and support them. This causes certain problems with even basic wifi 5GHz tethering in areas noised with 2.4 AP's. I would suggest to add warning on top of settings page and popup with disclaimer and warning about legal consequences when selecting band that is not approved. In addition, tethering settings may be set to reset (with notification for user acknowledgment) on border passing and/or region change |
This is not AOSP problem. This is not pixel problem. What should we do to fix this error? All attempts to contact Google failed, Google is not going to fix this problem or use wireless-regdb from Linux kernel and not their own. |
|
Neither of those is an actual official answer just the clueless front line support. |
Can you tell me how to get to the next level of support or where to contact them so that this problem can be fixed by Google at some point? |
|
Same problem was closed [email protected][email protected]Nov 13, 2024 08:26PM |
On the new Pixel 7 and Pixel 8 devices, when used in a region where Pixels are not officially sold, some of the stock OS features are disabled. For example, you cannot create an access point with 5Ghz and 6Ghz. Some custom roms allows you to bypass this limitation, but GOS also blocks points with an unsupported frequency. Can we fix this?
The text was updated successfully, but these errors were encountered: