/bugtracker

Tethering broken on Nexus 5X with default T-Mobile APN (for some users) #623

Closed
craftyguy opened this Issue Apr 12, 2017 · 28 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
4 participants
@craftyguy @thestinger @211217613 @Lindseym3
@craftyguy

craftyguy commented Apr 12, 2017

CopperheadOS Release: 2017.04.06.23.05.54

Carrier: T-Mobile USA

It appears that USB, Wifi, and bluetooth tethering do not work on the Nexus 5x with CopperheadOS. Devices connecting to the Nexus 5x receive an IP, but are unable to reach IPs outside the phone. I'm guessing something with the routing table is screwed up on the device. I wasn't able to find any upstream bugs on this, which is why I filed it here. Let me know what other info you need to diagnose this.

@thestinger thestinger added Type: bug non-security-related labels Apr 12, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 12, 2017

Contributor

It works here with Rogers and other carriers, so it's not a carrier-independent issue.
Contributor

thestinger commented Apr 12, 2017

It works here with Rogers and other carriers, so it's not a carrier-independent issue.

@thestinger thestinger added the Device: Nexus 5X label Apr 12, 2017

@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 12, 2017

craftyguy commented Apr 12, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 12, 2017

Contributor

It will require making builds of the operating system to narrow down the cause and perhaps building just plain AOSP with android-prepare-vendor to compare it with that. It's not something I can do since I don't have access to T-Mobile. They might be intentionally doing something to break tethering, or it may just be the usual T-Mobile issues related to their IPv6 that have never been diagnosed / debugged. There's not going to be progress without someone able and willing to debug issues like this with access to it. It's just another US carrier quirk with no way for us to confirm it or make progress on it.
Contributor

thestinger commented Apr 12, 2017

It will require making builds of the operating system to narrow down the cause and perhaps building just plain AOSP with android-prepare-vendor to compare it with that. It's not something I can do since I don't have access to T-Mobile. They might be intentionally doing something to break tethering, or it may just be the usual T-Mobile issues related to their IPv6 that have never been diagnosed / debugged. There's not going to be progress without someone able and willing to debug issues like this with access to it. It's just another US carrier quirk with no way for us to confirm it or make progress on it.
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 12, 2017

craftyguy commented Apr 12, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 12, 2017

Contributor

All I could do is make builds for testing with more and more features disabled until it's just AOSP, some of which will require a fresh flash of the device. If it occurs with AOSP + android-prepare-vendor then it's not an issue that's in scope. There are features that could feasibly cause this so there's some more targeted stuff to test before rolling everything back to AOSP though.

I've tried to do this before, and there hasn't been follow through with testing the builds and reporting back even within a few days so it doesn't work as a way of narrowing it down. It can't really work well compared to someone debugging it themselves with access to it regardless.
Contributor

thestinger commented Apr 12, 2017

All I could do is make builds for testing with more and more features disabled until it's just AOSP, some of which will require a fresh flash of the device. If it occurs with AOSP + android-prepare-vendor then it's not an issue that's in scope. There are features that could feasibly cause this so there's some more targeted stuff to test before rolling everything back to AOSP though.

I've tried to do this before, and there hasn't been follow through with testing the builds and reporting back even within a few days so it doesn't work as a way of narrowing it down. It can't really work well compared to someone debugging it themselves with access to it regardless.
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 12, 2017

craftyguy commented Apr 12, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 12, 2017

Contributor

No I'm just saying I'm uneasy about investing time in that.

And this isn't broken for "US users". It's broken for your specific T-Mobile setup.
Contributor

thestinger commented Apr 12, 2017

No I'm just saying I'm uneasy about investing time in that.

And this isn't broken for "US users". It's broken for your specific T-Mobile setup.
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 12, 2017

craftyguy commented Apr 12, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 12, 2017

Contributor

Are you using the standard T-Mobile APN or a custom configured one?
Contributor

thestinger commented Apr 12, 2017

Are you using the standard T-Mobile APN or a custom configured one?
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 12, 2017

Yes, using the standard t-mobile APN.

I figured it out though, the standard APN is missing the 'dun' APN type. When I added that, tethering worked. Do you modify or ship a different APN config from AOSP in COS? It might be worth correcting that to save others the trouble. I'm guessing the APNs you tested were properly configured.

craftyguy commented Apr 12, 2017

Yes, using the standard t-mobile APN.

I figured it out though, the standard APN is missing the 'dun' APN type. When I added that, tethering worked. Do you modify or ship a different APN config from AOSP in COS? It might be worth correcting that to save others the trouble. I'm guessing the APNs you tested were properly configured.
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 13, 2017

Contributor

We ship the APN configuration from AOSP which AFAIK matches stock Android.
Contributor

thestinger commented Apr 13, 2017

We ship the APN configuration from AOSP which AFAIK matches stock Android.

@thestinger thestinger added the upstream label Apr 13, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 13, 2017

Contributor

Using 'dun' isn't a proper solution to this.
Contributor

thestinger commented Apr 13, 2017

Using 'dun' isn't a proper solution to this.
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 13, 2017

craftyguy commented Apr 13, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 13, 2017

Contributor

Using a legacy protocol to work around an undiagnosed problem with the standard one isn't a solution.
Contributor

thestinger commented Apr 13, 2017

Using a legacy protocol to work around an undiagnosed problem with the standard one isn't a solution.
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Apr 13, 2017

craftyguy commented Apr 13, 2017

@thestinger thestinger added unconfirmed and removed non-security-related labels Apr 13, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 13, 2017

Contributor

My suggestion is for someone with access to T-Mobile that's able to replicate this or other problems that have been reported to narrow down whether it's caused by CopperheadOS changes or with a regular build of AOSP. If it's caused by CopperheadOS, it's straightforward to narrow down the cause to a specific feature. No programming knowledge is required for any of that, only rolling back commits with Git and building.

If it's caused by AOSP, that's more problematic and it will require debugging work to figure out what's going wrong. Maybe it's something wrong with how android-prepare-vendor works, which should be reported to https://github.com/anestisb/android-prepare-vendor/issues.

It can't be assumed that this is a CopperheadOS issue without doing that. That's what the unconfirmed tag really means: not confirmed to be a CopperheadOS issue (I meant to use that originally not non-security-related).
Contributor

thestinger commented Apr 13, 2017

My suggestion is for someone with access to T-Mobile that's able to replicate this or other problems that have been reported to narrow down whether it's caused by CopperheadOS changes or with a regular build of AOSP. If it's caused by CopperheadOS, it's straightforward to narrow down the cause to a specific feature. No programming knowledge is required for any of that, only rolling back commits with Git and building.

If it's caused by AOSP, that's more problematic and it will require debugging work to figure out what's going wrong. Maybe it's something wrong with how android-prepare-vendor works, which should be reported to https://github.com/anestisb/android-prepare-vendor/issues.

It can't be assumed that this is a CopperheadOS issue without doing that. That's what the unconfirmed tag really means: not confirmed to be a CopperheadOS issue (I meant to use that originally not non-security-related).
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Apr 13, 2017

Contributor

It also can't be known whether this is a bug / incompatibility or something else without something looking into it. For example, it might be that there's missing functionality from Google Play or vendor blobs that aren't included for the standard T-Mobile APN configuration to work. CopperheadOS doesn't have everything that's in stock. Adding more blobs to support carrier features is different than narrowing down, debugging and fixing an actual bug.
Contributor

thestinger commented Apr 13, 2017 •
edited
Edited 1 time
  • @thestinger thestinger edited Apr 13, 2017

It also can't be known whether this is a bug / incompatibility or something else without something looking into it. For example, it might be that there's missing functionality from Google Play or vendor blobs that aren't included for the standard T-Mobile APN configuration to work. CopperheadOS doesn't have everything that's in stock. Adding more blobs to support carrier features is different than narrowing down, debugging and fixing an actual bug.

@thestinger thestinger changed the title from Tethering broken on Nexus 5x to Tethering broken on Nexus 5X with default T-Mobile APN (for some users) Apr 15, 2017

@211217613

This comment has been minimized.

Show comment Hide comment
@211217613

211217613 May 26, 2017

I can follow up when I get back to the US. I have a spare N5X and T-Mobile service. I can install COS an AOSP build with android-prepare-vendor and try to duplicate craftguys problem.

211217613 commented May 26, 2017 •
edited
Edited 1 time
  • @211217613 211217613 edited May 26, 2017

I can follow up when I get back to the US. I have a spare N5X and T-Mobile service. I can install COS an AOSP build with android-prepare-vendor and try to duplicate craftguys problem.
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger May 26, 2017

Contributor

It needs to be checked if it's a problem in an AOSP build with android-prepare-vendor. I don't need someone to confirm if it occurs in CopperheadOS. Either way, the real need is for someone willing to dedicate time to working on resolving it.
Contributor

thestinger commented May 26, 2017

It needs to be checked if it's a problem in an AOSP build with android-prepare-vendor. I don't need someone to confirm if it occurs in CopperheadOS. Either way, the real need is for someone willing to dedicate time to working on resolving it.
@211217613

This comment has been minimized.

Show comment Hide comment
@211217613

211217613 May 26, 2017

I have a few free days I can spend on it. I'm somewhat familiar with preparing AOSP builds but not with android-prepare-vendor. I'll check out the link you have to anestisb's github and set something up.

211217613 commented May 26, 2017

I have a few free days I can spend on it. I'm somewhat familiar with preparing AOSP builds but not with android-prepare-vendor. I'll check out the link you have to anestisb's github and set something up.
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Jul 27, 2017

Contributor

This is addressed by the upcoming release.

On the other hand, whatever issues there are preventing the proper modern APNs from working for at least some people are not solved. Help is needed to resolve those issues. It's important for that to happen before the legacy APNs stop working.
Contributor

thestinger commented Jul 27, 2017

This is addressed by the upcoming release.

On the other hand, whatever issues there are preventing the proper modern APNs from working for at least some people are not solved. Help is needed to resolve those issues. It's important for that to happen before the legacy APNs stop working.

@thestinger thestinger closed this Jul 27, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Aug 3, 2017

Contributor

@craftyguy If you have some time to test some builds for me, let me know. There's a possible workaround for the default APN not working but I need someone able to test it.
Contributor

thestinger commented Aug 3, 2017

@craftyguy If you have some time to test some builds for me, let me know. There's a possible workaround for the default APN not working but I need someone able to test it.
@craftyguy

This comment has been minimized.

Show comment Hide comment
@craftyguy

craftyguy Aug 3, 2017

craftyguy commented Aug 3, 2017

@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Aug 3, 2017

Contributor

You won't lose any data. It will be an update you can sideload. Can you come on IRC when you have some time?
Contributor

thestinger commented Aug 3, 2017

You won't lose any data. It will be an update you can sideload. Can you come on IRC when you have some time?
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Aug 3, 2017

Contributor

I can just do the builds for you, signed with our keys, essentially, and give you update zips.
Contributor

thestinger commented Aug 3, 2017

I can just do the builds for you, signed with our keys, essentially, and give you update zips.
@Lindseym3

This comment has been minimized.

Show comment Hide comment
@Lindseym3

Lindseym3 Aug 15, 2017

Just to add a data point I have a Nexus 5x, switched from project fi to T-Mobile yesterday and am unable to tether despite a couple hours with T-Mobile tech support. Thanks for trying to figure it out.

Lindseym3 commented Aug 15, 2017

Just to add a data point I have a Nexus 5x, switched from project fi to T-Mobile yesterday and am unable to tether despite a couple hours with T-Mobile tech support. Thanks for trying to figure it out.
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Aug 15, 2017

Contributor

As far as I know, the tethering issues are resolved. If you still have problems you should make sure your APN settings are reset to the standard configuration. Non-standard configurations aren't supported.
Contributor

thestinger commented Aug 15, 2017

As far as I know, the tethering issues are resolved. If you still have problems you should make sure your APN settings are reset to the standard configuration. Non-standard configurations aren't supported.
@thestinger

This comment has been minimized.

Show comment Hide comment
@thestinger

thestinger Aug 15, 2017

Contributor

Bugs and regressions of carrier compatibility are still in-scope for Nexus devices but existing compatibility issues that are shared with AOSP like this aren't bugs (I already fixed the non-AOSP issues) so they're no longer in scope now that the 2 year period of device-specific feature work for Nexus devices is coming to a close. August and September will be dedicated to migrating to Android 8.0 and September 2017 is the 2 year partial end-of-life for Nexus devices. Android 8.0 porting will be the last bit of device-specific feature work for them. October will be the release of 2nd generation Pixel phones, and then 1st and 2nd generation Pixel phones will be the devices receiving active device-specific feature work with Nexus devices only receiving device-independent features and bug / security fixes until their final EOL in September 2018.
Contributor

thestinger commented Aug 15, 2017 •
edited
Edited 1 time
  • @thestinger thestinger edited Aug 15, 2017

Bugs and regressions of carrier compatibility are still in-scope for Nexus devices but existing compatibility issues that are shared with AOSP like this aren't bugs (I already fixed the non-AOSP issues) so they're no longer in scope now that the 2 year period of device-specific feature work for Nexus devices is coming to a close. August and September will be dedicated to migrating to Android 8.0 and September 2017 is the 2 year partial end-of-life for Nexus devices. Android 8.0 porting will be the last bit of device-specific feature work for them. October will be the release of 2nd generation Pixel phones, and then 1st and 2nd generation Pixel phones will be the devices receiving active device-specific feature work with Nexus devices only receiving device-independent features and bug / security fixes until their final EOL in September 2018.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment