os-issue-tracker icon indicating copy to clipboard operation
os-issue-tracker copied to clipboard

Connected ethernet reverts back to wifi/cellphone network when going to sleep

Open karolyi opened this issue 2 years ago • 12 comments

Hey,

I've got a pixel 7 pro with the latest GrapheneOS where Android 14 recently arrived. I've got two USB Type-C ethernet adapters, one is a simple "Amazon basics" adapter, the other one is a USB hub with an ethernet connector on it, both can be used with a phone.

With this latest update, my daytime USB connected ethernet disconnects when the phone is going into sleep mode. Just tested, no matter which adapter it is, both have the same phenomenon. When going to sleep, the ethernet lights turn off, so the interface is turned off, seemingly.

Just thought I'll report it here.

karolyi avatar Oct 13 '23 08:10 karolyi

Correction: the phone keeps periodically switching the Ethernet adapter on and off. When it goes to sleep, I see the green link LED turning off for various periods, until it turns on again for a certain amount of time. The duration of these cycles vary, as I've observed so far.

karolyi avatar Oct 13 '23 14:10 karolyi

I've tried to replicate this issue using a P7P + generic amazon USB C > Ethernet on the latest build and not been able to reproduce, can you confirm if this is still occurring?

sec-oops avatar Oct 17 '23 09:10 sec-oops

Hey,

either I still don't have the latest update (I'm on the stable channel, build number UP1A.231005.007.2023101300, the updater says it's the latest), or I still can reproduce it.

I'm using trackercontrol but I've turned it off for the time of testing to make sure it doesn't interfere.

If you can point me into a direction as to where to start looking for details, I can try and do so. It still switches back and forth, while bringing the phone back from sleep mode sometimes doesn't happen instantly. Maybe it dozes itself way too much somehow?

karolyi avatar Oct 17 '23 10:10 karolyi

I can confirm this issue with a USB-C/Ethernet charging adapter and a Pixel 7 (Android 14, GrapheneOS Build UP1A.231105.003.2023111500). When the display is turned off, the mobile device stops sharing the Internet connection via Ethernet tethering. Disabling the display timeout as workaround results into a stable Ethernet tethering connection. This issue exists since the Android 14 update.

kunzstef avatar Nov 28 '23 14:11 kunzstef

Is this still an issue on the QPR1 release? Can someone confirm whether this happens on the Stock OS as well?

matchboxbananasynergy avatar Dec 12 '23 13:12 matchboxbananasynergy

hey @matchboxbananasynergy,

not sure what QPR1 is, but I can confirm that the issue still persists on the build number UQ1A.231205.015.2023120800 (pixel 7 pro)

karolyi avatar Dec 12 '23 13:12 karolyi

QPR1 is the first quarterly release of Android 14 which was released very recently, and is what GrapheneOS is now based on.

It would be really helpful if people were able to check whether they can reproduce this on the Stock OS so that it can be determined if this is upstream behavior, or specific to GrapheneOS.

matchboxbananasynergy avatar Dec 12 '23 13:12 matchboxbananasynergy

I cannot confirm this on stock OS, but with Graphane Ethernet tethering is only reliable with screensaver enabled during charging. In this case the displayed Ethernet tethering toggle in the settings still gets deactivated and disabled (can be edited and activated again after reattaching the Ethernet adapter), but tethering continues. Rarely when the device is then unplugged from the Ethernet adapter while tethering, the OS crashes and reboots:

type: crash
Process: system_server
Build: google/panther/panther:14/UQ1A.231205.015/2023121200:user/release-keys
Crash-Handler: com.android.internal.os.RuntimeInit$KillApplicationHandler
Loading-Progress: 1.0
Dropped-Count: 0

java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
at android.net.connectivity.com.android.server.ethernet.EthernetNetworkFactory.getInterfaceState(EthernetNetworkFactory.java:170)
at android.net.connectivity.com.android.server.ethernet.EthernetTracker.unicastInterfaceStateChange(EthernetTracker.java:328)
at android.net.connectivity.com.android.server.ethernet.EthernetTracker.lambda$addListener$4(EthernetTracker.java:435)
at android.net.connectivity.com.android.server.ethernet.EthernetTracker.$r8$lambda$u74wXsW90rogcJx8NNlJoTHWh6U(EthernetTracker.java:0)
at android.net.connectivity.com.android.server.ethernet.EthernetTracker$$ExternalSyntheticLambda5.run(R8$$SyntheticClass:0)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.os.HandlerThread.run(HandlerThread.java:67)

kunzstef avatar Dec 22 '23 17:12 kunzstef

I confirm the behavior: Shortly after going to sleep, the ethernet adapter powers off (not even lights in the ethernet port).

Android 14 Pixel 6 pro Build number: 2024050700

onlycparra avatar May 15 '24 15:05 onlycparra

I've originally added a comment that I accidentally discovered that this bug ceased to exist, however it wasn't the case. I still can reproduce it but it happens later with the latest update 2024053100 on my Pixel 7 pro.

It seems that the device keeps the Ethernet connection for much longer, then goes to sleep, and connects back again within 10 seconds. Then, after a 5-6 minutes of screen blanking now, it turns off the interface, then comes back again (LED on) but it doesn't ping anymore and the delayed screen-on effect is still there.

This wasn't the case before since it disconnected right after screen blanking. Upon disconnect, the link led also stops flashing.

Right now, the interface is up but it doesn't ping, and upon unlocking it restarts the interface (LED off/on) and starts pinging again.

karolyi avatar Jun 03 '24 12:06 karolyi

A thought here... I haven't tried this yet: Settings/Security/USB-C Port. Has interesting options for enabling/disabling usb-c when the device is locked.

Right now my selected option is "charging-only when locked".

That sounds a lot like it could be the root of the issue.

If anybody can test, that would be nice. I'll try once I get some free time.

onlycparra avatar Jul 02 '24 18:07 onlycparra

@onlycparra No, please read https://grapheneos.org/features#usb-c-port-and-pogo-pins-control. It blocks new USB connections immediately and only blocks USB data when existing USB connections end. If the connection ends, it's supposed to be blocked from reconnecting.

thestinger avatar Jul 02 '24 18:07 thestinger

Is this still an issue?

thestinger avatar Mar 07 '25 19:03 thestinger

Last time I checked, yes.

karolyi avatar Mar 07 '25 19:03 karolyi

Please check again after you update to Android 15 QPR2. Today's release based on it should reach the Stable channel but there's an earlier one without many issues in Alpha.

thestinger avatar Mar 07 '25 19:03 thestinger

Would that be build number 2025030300?

karolyi avatar Mar 07 '25 20:03 karolyi

No, 2025030500 in Alpha or today's upcoming release (2025030700) which will likely reach Stable.

thestinger avatar Mar 07 '25 20:03 thestinger

Okay, I'll wait for 2025030700 and see what gives. My phone is a 'production' device so I don't want to risk bricking it.

karolyi avatar Mar 07 '25 20:03 karolyi

No risk of bricking it but you might as well wait for today's release reaching at least Beta.

thestinger avatar Mar 07 '25 20:03 thestinger

2025030800 arrived today.

I put the phone on the dongle for about 2x10 minutes in standby (with a wakeup inbetween) and the ethernet link never disconnected. It also jumped back from standby instantly, which wasn't the case before.

The link loss happened before in about maximum 30 seconds, after putting the phone in standby mode. I think this might just have been fixed, but maybe others could test as well.

karolyi avatar Mar 09 '25 23:03 karolyi

Probably fixed by the update to Linux 6.1. It would be good if others tested it but we're fine with closing it as resolved now. We knew moving to Linux 6.1 would fix a ton of the issues.

thestinger avatar Mar 09 '25 23:03 thestinger