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

[karolyi]

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]

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.

[sec-oops]

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?

[karolyi]

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?

[kunzstef]

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.

[matchboxbananasynergy]

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

[karolyi]

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)

[matchboxbananasynergy]

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.

[kunzstef]

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)

[onlycparra]

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

[karolyi]

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.

[onlycparra]

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.

[thestinger]

@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.