Android 13 on Unihertz Jelly Star. Never had a problem up until today when I was attempting to use scrcpy and got annoyed enough by the constantly changing port number assignment for the Wireless Debugging server to finally try to solve the annoyance. (I'm referring to the relatively recent change that randomizes the wireless server's port number to somewhere in the range of 30,000-49,999, rather than the long standard 5555.) Somehow I've caused it to start up under the 10.x.x.x IP range even though my home network is on the 192.168.x.x range, and I can't seem to get it to revert permanently.
I've tried "Reset WiFi, mobile, & BT" options twice now, and the relief it gives is very brief. I've turned off mobile data to eliminate that potential source of IP assignment. I've been through several reboots, connecting both wirelessly and via USB from the PC, and I just can't keep the ADB server on the home IP range (WiFi itself remains on the expected range). I suspect it might have something to do with the USB connection, but I can't seem to pin it down. It's just so bizarre to me.
I only have a cursory understanding of TCP/IPv4 that I learned years before I'd ever even heard of IPv6, and I've been out of the tech field of work ever since (a couple decades now) so I'm at a loss on how to further track the problem down. Any help to avoid having to reset the phone and set it up again (assuming that would even resolve the issue) would be appreciated!
=== EDIT ===
Since I apparently can't use comments to expand (which I kinda get, but wasn't expecting), this is in response to Robert's question below.
No root, stock ROM (after one update) - however I am using Shizuku, which gives some root-like abilities to apps programmed to take advantage of it.
The only seemingly acceptable solution I (sort of) found was a reference to "the LADB" fix that didn't actually describe, nor link to it. A bit more looking around made it clear they likely meant using the LocalADB app's ability to run a command upon startup. Basically, it seemed they were using it to restart the ADB server, explicitly telling it to use the standard port in the process via the command adb tcpip 5555.
When I first tried using it, adb complained that there were multiple possible devices to target the command to (I'm a bit foggy because I was up late doing this, but I think I tried this both with the USB plugged in as well as not). I modified the startup command to adb disconnect; adb tcpip 5555 and that seemed to work, but left it in a sort of bootloop where it'd lose the connection (of course) and attempt to reconnect, and then once again run my command string. I dropped the disconnect part and instead gave it the -e option to refer specifically to the tcpip connection, but effectively got the same result (which makes sense).
Further searching/reading up on it gave me the impression (but again no explicit step-by-step) that this was expected - they weren't looking to use LADB anyway, but instead just using it to accomplish the goal of restarting the server on the correct port. As such, once the bootloop-like behavior started, they just killed the LADB app.
That seemed to work for me as well, but somewhere along the way of setting things back up after resetting my network connections - WiFI credentials (I've two local networks), USB ADB connection, Shizuku setup, scrcpy, etc. - the Wireless Debugging server goes back to the 10.x.x.x range and nothing I do changes it.
I will try to step-by-step it later today, but haven't the time at the moment. I was hoping someone with more TCP/IP understanding than I have might point me at the likely problem in the meantime.
N.B.: Of course, in updating this to include a link to the LADB app, I noticed on the site it mentions being incompatible with Shizuku ATM. Seems odd to me that this would be the end result of that, but I'm obviously asking here because I'm not an expert. At the very least, it's an additional avenue of exploration.
=== END of reponse to Robert ===