Manually enter IP Address of Android phone #1677
Labels
enhancement
A request for a feature or additional functionality
triage
An issue that needs confirmation and labeling
Describe your request
The scanning process for GSConnect currently only scans the local connection subnet, which will always fail for me.
I have an android phone hosting a wireless access point, which an openwrt router connects to, and my PC is connected to the openwrt router. My phone is my internet, and the wifi access point configuration on Android is not configured properly for an entire home internet network, so I connect with another router.
I have static routes setup on the router so I am able to connect to the phone with adb from the openwrt subnet.
openwrt is in the 10.0.X.X range, phone hotspot is in the 192.168.X.X range. Devices connected to openwrt can successfully communicate with the phone and devices in the 192.168.X.X range.
GSConnect only scans the 10.0.X.X range (the subnet the PC is on) and will never find the phone ip address.
Proposed solution
I need to be able to manually put in the ip subnet for the phone to be able to connect, which should be a very simple implementation. Being able to specify the subnet to search would be preferrable as the hotspot subnet changes on every reset. This could be combined with being able to manually specify the ip address instead of just the range to search.
Alternatives
Having GSConnect scan the local subnet will never work for this scenario.
I may be able to set a static lease/route and translate a local ip address to the phone ip address, but due to new changes in Android, the hotspot ip subnet changes everytime it is reset, so this is not a viable option. There are no alternatives. Changing the IP subnet/address in GSConnect would be much easier than manually changing routes and leases in openwrt on every hotspot reset.
GSConnect version
55
Installed from
OS package manager
GNOME Shell version
44.4
Linux distribution/release
Debian testing (trixie/sid) Kernel 6.4.0-4-amd64
Additional context
I do not have KDE so I do not know if KDEConnect has this functionality but I doubt it. This feature will not be a fundamental change in features for KDEConnect, this is a basic setting that could be implemented without needing KDEConnect to support it first.
The text was updated successfully, but these errors were encountered: