[GUIDE] How To Unlock Tethering on Nexus 5X.

[Skitals]

The OTA you use is the same one that you need to download to update your phone if your on nougat you downloaded the OTA at least once. Then it's just a matter of extracting it with your favorite zip manager and it's layed out pretty much like your phone.

Yeah I get that, but I'm talking about incremental OTAs that upgrade from one specific build to another. Google doesn't post the links for these, I usually find the links on Android Police. There is no point downloading a 1GB "complete" OTA when the 20MB incremental OTA will do... I'm talking about updates going forward. The incremental OTA wont have the entire boot.img... just the bits that are different.

 

[Mark12343]

Yeah I get that, but I'm talking about incremental OTAs that upgrade from one specific build to another. Google doesn't post the links for these, I usually find the links on Android Police. There is no point downloading a 1GB "complete" OTA when the 20MB incremental OTA will do... I'm talking about updates going forward. The incremental OTA wont have the entire boot.img... just the bits that are different.

I hear what your saying. I would make sure you restore the original unmodified boot.img before you flash any of those though. Me I personally download the full factory image as soon as it's available just so I have it. I guess I'm spoiled with my internet speed. Anyway it was good info you posted and hopefully it helps some other people

 

[nateand]

I can confirm that the following steps worked, as outlined above.

I already have 7.0 installed and running fine on my device. I downloaded the factory image for N, extracted "boot.img" from "image-bullhead-nrd90m.zip", then used the AIK toolkit from the link (I'm on linux) and modified "default.prop" found in "ramdisk" (from opened up boot.img). I added the line "net.tethering.noprovisioning=true" to the end of the file, saved it. Then ran "repackimg.sh" to get a new file "image-new.img". Rebooted into bootloader, ran "fastboot flash boot image-new.img", then "fastboot reboot". Took FOREVER and I suspected I had a boot loop, about 5 minutes of the google/android logo spinning around with the colors. Hard restart (held down power button for a while), then it booted up normally (thank god). Ran "adb shell settings put global tether_dun_required 0", rebooted, and it works!

I'm pretty sure these are the exact steps outlined above, just want to confirm for anyone reading that this definitely works and appears to be relatively safe/easy.

 

[andTab]

So tethering works on 7?

Is there a fix yet to also get Bluetooth tethering to work?
The above mentioned makes it possible to Wifi tether but Bluetooth tethering connects but passes no traffic.

 

[bagsofcole]

This is not true, you can pull boot.img simply by booting to twrp and then pulling it, no root necessary.

---------- Post added at 10:06 AM ---------- Previous post was at 10:06 AM ----------



This works fine if you boot to twrp and then pull via adb. This works fine though, good info.

Yep, works for me too, thanks! Since I've been using this method for a while now I figured it out (after a few failed attempts trying to flash the new file in TWRP), but for the less experienced, might want to note that you do need to boot into TWRP to pull the file (see OP) then boot into bootloader to push it.

 

[andTab]

Yep, works for me too, thanks! Since I've been using this method for a while now I figured it out (after a few failed attempts trying to flash the new file in TWRP), but for the less experienced, might want to note that you do need to boot into TWRP to pull the file (see OP) then boot into bootloader to push it.

So tethering works on 7?

Is there a fix yet to also get Bluetooth tethering to work?
The above mentioned makes it possible to Wifi tether but Bluetooth tethering connects but passes no traffic.

 

[Mark12343]

Bluetooth tethering works fine with this maybe you aren't going into Bluetooth settings on your phone and selecting the internet connection sharing check box after you connect your device.

 

[jrotert]

Bluetooth Tethering

Works for me with Nexus 5X running 7.0 Official BT tethered to N9 tablet, albeit a little slow: 1.3mb/s vs 20+mb/s on WiFI tethering. Fine for run-of-the-mill browsing but not for streaming Hulu/Netflix etc.

 

[tabormeister]

Hey! Here's a little guide that I wrote up that works for sure. In my experience, trying to edit settings db while in TWRP doesn't work. This way, you still keep Pay but get tethering too.

Obviously I'm not responsible for your mom exploding or your phone disowning you, but.....

I got tethering and Android Pay working on stock Nougat - that's Android N, folks - on a Nexus.
(confirmed will work on Marshmallow and up on 5, 5x, 6, 6p...etc.)
Thanks to @Chainfire, @ManHands and @interloper, and you!

click thanks if this helps, or buy me a beer or something.

prerequisites:
working adb and fastboot (from platform-tools in the Android SDK if you don't know where to find it)
twrp .img for your device
latest stable systemless supersu

1. be on Marshmallow or Nougat obviously
2. flash twrp

(volume down + power on nexus gets you into bootloader, then after flashing recovery, use volume buttons to scroll and power button to select recovery mode)

3. flash systemless root while booted into twrp (unsure if .supersu SYSTEMLESS=true in /data is still needed, but can't hurt - mine is still there from earlier.)
4. while still in twrp, go to mount and check system. Make sure you allow changes.
5. from your computer, do this

adb shell
echo "net.tethering.noprovisioning=true" >> /system/build.prop

6. reboot into Android.
7. Install Terminal Emulator from the Play Store.
8. Launch it, and in Terminal Emulator, do this

su
settings put global tether_dun_required 0
exit

9. go into Supersu, expert, scroll to the bottom and hit full unroot. No, you don't want it to patch you back to the stock boot image or recovery*. If it hangs, just reboot and try doing it again.
10. ????
11. Profit! You should have tethering unlocked, be unrooted, and have full Android Pay goodness working.

To take an OTA, do this, because Flashfire gets confused after you've done build.prop edits -

1. go to About Phone, scroll down. Find your build number.
2. download that Nexus Factory Image.
3. Unzip it all. ALL OF IT.
4. Make sure you have Android SDK & platform-tools (or just a working Fastboot and ADB)
5. just flash boot, system, and recovery - you can now OTA with no problems. Then repeat the above guide on your new OTA. Confirmed working 10 minutes ago, OTA'ing from Marshmallow to Nougat and then getting tethering working again

ALTERNATE IF YOU PREFER FLASHFIRE:

All the above steps, but you only have to flash the System image to fix the build.prop hash fail then flashfire should work for you. Wouldn't necessarily recommend upgrading version numbers (6.0.1 to 7.0.0) with Flashfire, but who knows, it might work great! Chainfire is a wizard.

*you can do this if you want, but when I let it patch my boot image I got the dreaded "device corrupt!!!!1" message at boot. Did not try letting it flash stock recovery image.

 

[Skitals]

Hey! Here's a little guide that I wrote up that works for sure. In my experience, trying to edit settings db while in TWRP doesn't work. This way, you still keep Pay but get tethering too.

Obviously I'm not responsible for your mom exploding or your phone disowning you, but.....

I got tethering and Android Pay working on stock Nougat - that's Android N, folks - on a Nexus.
(confirmed will work on Marshmallow and up on 5, 5x, 6, 6p...etc.)
Thanks to @Chainfire, @ManHands and @interloper, and you!

click thanks if this helps, or buy me a beer or something.

prerequisites:
working adb and fastboot (from platform-tools in the Android SDK if you don't know where to find it)
twrp .img for your device
latest stable systemless supersu

1. be on Marshmallow or Nougat obviously
2. flash twrp

(volume down + power on nexus gets you into bootloader, then after flashing recovery, use volume buttons to scroll and power button to select recovery mode)

3. flash systemless root while booted into twrp (unsure if .supersu SYSTEMLESS=true in /data is still needed, but can't hurt - mine is still there from earlier.)
4. while still in twrp, go to mount and check system. Make sure you allow changes.
5. from your computer, do this

adb shell
echo "net.tethering.noprovisioning=true" >> /system/build.prop

6. reboot into Android.
7. Install Terminal Emulator from the Play Store.
8. Launch it, and in Terminal Emulator, do this

su
settings put global tether_dun_required 0
exit

9. go into Supersu, expert, scroll to the bottom and hit full unroot. No, you don't want it to patch you back to the stock boot image or recovery*. If it hangs, just reboot and try doing it again.
10. ????
11. Profit! You should have tethering unlocked, be unrooted, and have full Android Pay goodness working.

To take an OTA, do this, because Flashfire gets confused after you've done build.prop edits -

1. go to About Phone, scroll down. Find your build number.
2. download that Nexus Factory Image.
3. Unzip it all. ALL OF IT.
4. Make sure you have Android SDK & platform-tools (or just a working Fastboot and ADB)
5. just flash boot, system, and recovery - you can now OTA with no problems. Then repeat the above guide on your new OTA. Confirmed working 10 minutes ago, OTA'ing from Marshmallow to Nougat and then getting tethering working again

ALTERNATE IF YOU PREFER FLASHFIRE:

All the above steps, but you only have to flash the System image to fix the build.prop hash fail then flashfire should work for you. Wouldn't necessarily recommend upgrading version numbers (6.0.1 to 7.0.0) with Flashfire, but who knows, it might work great! Chainfire is a wizard.

*you can do this if you want, but when I let it patch my boot image I got the dreaded "device corrupt!!!!1" message at boot. Did not try letting it flash stock recovery image.

This doesn't make any sense to me. You don't need root to edit the settings db. Boot the phone and do it via adb: "adb settings put global tether_dun_required 0"

Second, the only reason the process has changed from the first page is because editing build.prop in twrp doesn't stick in Nougat on the 5X. Add the line to build.prop, boot the phone, pull build.prop and it's not there. Go back to twrp... pull build.prop and it's back. When the phone boots its sym linking an unmodified build.prop from some other partition or something. My workaround was to edit default.prop in boot.img which seems to supersede.

For whatever reason the 5X has always behaved differently than the other Nexuses.

 

[sfhub]

This doesn't make any sense to me. You don't need root to edit the settings db. Boot the phone and do it via adb: "adb settings put global tether_dun_required 0"

Second, the only reason the process has changed from the first page is because editing build.prop in twrp doesn't stick in Nougat on the 5X. Add the line to build.prop, boot the phone, pull build.prop and it's not there. Go back to twrp... pull build.prop and it's back. When the phone boots its sym linking an unmodified build.prop from some other partition or something. My workaround was to edit default.prop in boot.img which seems to supersede.

For whatever reason the 5X has always behaved differently than the other Nexuses.

It took me a little while to figure out what was actually going on when I debugged a patch I wrote to fix a touchscreen problem some people were encountering, which worked in Marshmallow but stopped working in Nougat.

The reason the build.prop change doesn't "stick" in Nougat is the following:

When you make the change to build.prop while inside TWRP, it does make the change on disk/emmc. You can see the change and pull it to your PC and the change is there.

However when you boot to Android using a boot.img (for example stock) that has dm-verity (verified boot) enabled, your "changes" to build.prop are treated as "corruption" of the system partition.

The 7.0 kernel (if dm-verity is enabled) then proceeds to "forward error correct" using the reed solomon redundancy they added into the 7.0 builds/images. So the "on the fly" error correction will "correct" your changes to build.prop (ie corruption) and restore the original information.

You can see this "error correction" in action by typing

dmesg | grep verity-fec

For example:

bullhead:/ $ dmesg | grep verity-fec
[    4.222216] device-mapper: verity-fec: 259:7: FEC 0: corrected 38 errors
[    4.298401] device-mapper: verity-fec: 259:7: FEC 4096: corrected 4 errors
[    4.443486] device-mapper: verity-fec: 259:7: FEC 81920: corrected 17 errors

The reason the method in the post you replied to works is because the installation of SuperSU (in the default systemless install mode) will disable dm-verity in your kernel/boot.img, which also disables the reed solomon forward error correction.

By doing so, his build.prop changes persist into the android boot, at which point he can modify the tether_dun_required setting, which I believe is stored in userdata area.

He then proceeds to restore original boot.img by doing full unroot (and optionally system.img) so the system is pristene again, and ready for differential OTA updates and Android Pay works.

Also any Nexus running Nougat that has the forward error correction code and reed solomon redundancy in the images will behave this way if dm-verity is enabled. It isn't something that is particular to the 5x. Older devices might not get the code or the redundancy in the images, but going forward I would guess all newer Nexus devices will behave this way.

Hope that helps clear things up.

 

[tabormeister]

This doesn't make any sense to me. You don't need root to edit the settings db. Boot the phone and do it via adb: "adb settings put global tether_dun_required 0"

I embarrassingly didn't know that adb shell/su would work for editing settings db over adb, always just used terminal emulator on device and thought you needed root to do so - tried adb shell through twrp to do it and it doesn't work there so just assumed it would only work on device while booted haha

Also any Nexus running Nougat that has the forward error correction code and reed solomon redundancy in the images will behave this way if dm-verity is enabled. It isn't something that is particular to the 5x. Older devices might not get the code or the redundancy in the images, but going forward I would guess all newer Nexus devices will behave this way. Hope that helps clear things up.

Right! I was just trying to compile a simplified method that works reliably across L, M, and N that anybody can do, AND that leaves you with working Android Pay, AND that doesn't give you 'device corrupted' messages. Seems like I stumbled into a way around dm-verity accidentally. So....yay?

 

[Skitals]

It took me a little while to figure out what was actually going on when I debugged a patch I wrote to fix a touchscreen problem some people were encountering, which worked in Marshmallow but stopped working in Nougat.

The reason the build.prop change doesn't "stick" in Nougat is the following:

When you make the change to build.prop while inside TWRP, it does make the change on disk/emmc. You can see the change and pull it to your PC and the change is there.

However when you boot to Android using a boot.img (for example stock) that has dm-verity (verified boot) enabled, your "changes" to build.prop are treated as "corruption" of the system partition.

The 7.0 kernel (if dm-verity is enabled) then proceeds to "forward error correct" using the reed solomon redundancy they added into the 7.0 builds/images. So the "on the fly" error correction will "correct" your changes to build.prop (ie corruption) and restore the original information.

You can see this "error correction" in action by typing

dmesg | grep verity-fec

For example:

bullhead:/ $ dmesg | grep verity-fec
[    4.222216] device-mapper: verity-fec: 259:7: FEC 0: corrected 38 errors
[    4.298401] device-mapper: verity-fec: 259:7: FEC 4096: corrected 4 errors
[    4.443486] device-mapper: verity-fec: 259:7: FEC 81920: corrected 17 errors

The reason the method in the post you replied to works is because the installation of SuperSU (in the default systemless install mode) will disable dm-verity in your kernel/boot.img, which also disables the reed solomon forward error correction.

By doing so, his build.prop changes persist into the android boot, at which point he can modify the tether_dun_required setting, which I believe is stored in userdata area.

He then proceeds to restore original boot.img by doing full unroot (and optionally system.img) so the system is pristene again, and ready for differential OTA updates and Android Pay works.

Also any Nexus running Nougat that has the forward error correction code and reed solomon redundancy in the images will behave this way if dm-verity is enabled. It isn't something that is particular to the 5x. Older devices might not get the code or the redundancy in the images, but going forward I would guess all newer Nexus devices will behave this way.

Hope that helps clear things up.

Thanks, that is great info and definitely explains what is going on! I guess my lingering question is... once you do a full unroot and restore the original boot.img, isn't dm-verity reenabled? The tethering provisioning check would be in place again defeating the whole purpose. Still seems easier to just add the line to the prop in boot.img, and restore your stock boot.img when you are ready to do an ota. Android pay, tethering ,etc all work.

 

[sfhub]

I guess my lingering question is... once you do a full unroot and restore the original boot.img, isn't dm-verity reenabled? The tethering provisioning check would be in place again defeating the whole purpose. Still seems easier to just add the line to the prop in boot.img, and restore your stock boot.img when you are ready to do an ota. Android pay, tethering ,etc all work.

Possibly (regarding the build.prop entry and where to put it)

Regarding dm-verity, if the original pristine boot.img is being restored then dm-verity is reenabled as well as forward error correction and the subsequent reversion of the build.prop changes to original. It is possible in all of tabormeister's testing SuperSU might have backed up a boot.img that already had dm-verity disabled and restored that so I can't tell for sure if that full unroot step actually restored the stock boot.img.

I do not have the details of how the two settings you folks are using to enable tethering relate to each other.

From reading tabormeisters sequence, I got the impression that

net.tethering.noprovisioning=true

was required before you could enter

settings put global tether_dun_required 0

successfully, but once you had global tether_dun_required 0 registered in a sqlite db somewhere (ie stored persistently in userdata), the net.tethering.noprovisioning=true build.prop entry was no longer necessary for tethering to function going forward.

However, that is just my interpretation of the sequence tabormeister listed and a rationalization of how what he did could continue working after the "full" unroot he described (which I believe restores a pristine "stock" backed up boot.img)

Since I don't personally use these changes I might have misread or misunderstood what tabormeister was doing.

 

[Skitals]

Possibly (regarding the build.prop entry and where to put it)

Regarding dm-verity, if the original pristine boot.img is being restored then dm-verity is reenabled as well as forward error correction and the subsequent reversion of the build.prop changes to original. It is possible in all of tabormeister's testing SuperSU might have backed up a boot.img that already had dm-verity disabled and restored that so I can't tell for sure if that full unroot step actually restored the stock boot.img.

I do not have the details of how the two settings you folks are using to enable tethering relate to each other.

From reading tabormeisters sequence, I got the impression that

net.tethering.noprovisioning=true

was required before you could enter

settings put global tether_dun_required 0

successfully, but once you had global tether_dun_required 0 registered in a sqlite db somewhere (ie stored persistently in userdata), the net.tethering.noprovisioning=true build.prop entry was no longer necessary for tethering to function going forward.

However, that is just my interpretation of the sequence tabormeister listed and a rationalization of how what he did could continue working after the "full" unroot he described (which I believe restores a pristine "stock" backed up boot.img)

Since I don't personally use these changes I might have misread or misunderstood what tabormeister was doing.

That's the thing, they are unrelated. Most carriers only require net.tethering.noprovisioning=true to disable provisioning check. Some carriers also require the tether_dun_required 0 so that data isn't flag as tethering and blocked. One doesn't negate the other.

 

[sfhub]

That's the thing, they are unrelated. Most carriers only require net.tethering.noprovisioning=true to disable provisioning check. Some carriers also require the tether_dun_required 0 so that data isn't flag as tethering and blocked. One doesn't negate the other.

From the way I read your response these tethering flags control whether an alternate "tethering NAI/username" is used for tethering data and depending on carrier one or both (or none) of the changes might be required.

So it is possible for tabormeister's carrier he only needed

tether_dun_required 0

because

net.tethering.noprovisioning=true

should have been removed once he did the "full" unroot (which presumably restores original stock boot.img, enabling dm-verity, and forward error correction, thus restoring original build.prop) There is also slight potential that after a lot of testing, the boot.img that got backed up by SuperSU install actually wasn't the original stock one, but one that had dm-verity disabled.

So the net of all this is tabormeister's sequence might possibly only work for his carrier, but we are not completely sure what is going on because we haven't verified the contents of build.prop after the full unroot step in his sequenced procedure.

 

[TauxiC]

Sorry about that. I believe you are right that you would need su to backup your boot.img if you don't do it from twrp. You are also right it's easier to get the stock boot.img from the full ota or system image. The system image wasn't out yet when I posted, and I have no experience with "full" OTA so it didn't occur to me to pull it from there. I usually update using the incremental OTA, which I believe just has the bits of info to patch your current system. So for future updates it will probably still be easiest (and certainly the least bandwidth) to revert your stock boot.img, apply the incremental OTA update, dd, pull, modify and flash the new boot.img.

And yes... all of this is completely pointless if you are going to root your phone.

I downloaded your modified boot.img file and flashed it to my Nexus 5X but I still am not able to tether. When I try to enable it, the toggle for it first turns green as if it is going to work, but then goes back to the disabled/off position after a few seconds. However, after flashing your boot.img, it at least no longer pops up the grey "checking subscription status" box anymore. Any idea?

 

[andTab]

Bluetooth tethering works fine with this maybe you aren't going into Bluetooth settings on your phone and selecting the internet connection sharing check box after you connect your device.

Works for me with Nexus 5X running 7.0 Official BT tethered to N9 tablet, albeit a little slow: 1.3mb/s vs 20+mb/s on WiFI tethering. Fine for run-of-the-mill browsing but not for streaming Hulu/Netflix etc.

So tethering works on 7?

Is there a fix yet to also get Bluetooth tethering to work?
The above mentioned makes it possible to Wifi tether but Bluetooth tethering connects but passes no traffic.

Bluetooth tethering connects, "Internet Connection Sharing" is checked on the Nexus, Windows PC shows as connected, .... NO INTERNET.
Sends traffic fine. Shows ZERO incoming bytes received.

Just updated to 7.0 and followed the instructions to get tethering to work.
Note that I do have to use a VPN to get around carrier restrictions (they do detect tethering otherwise), so I use Torguard. No issues with Wifi tethering.

Happy for suggestions how to get Bluetooth tethering to work.

 

[Lollolollo84]

when i try to push back the edited build prop file to the phone i have this error:
failed to copy build.prop to /system/build.prop: couldn't create file: Read-only file system

 

[govindadas]

when i try to push back the edited build prop file to the phone i have this error:
failed to copy build.prop to /system/build.prop: couldn't create file: Read-only file system

have a custom recovery installed and
>> adb reboot bootloader
in TWRP recovery there is an option to mount the system and then you can push it through adb

otherwise if you are already rooted, there are some apps that you can toggle read/write access of system.