Genymobile
[Compatibility Issue]: Gnirehtet Breaks Peer Discovery!
Please Note: This "issue" is still being worked on and is also supposed to provide possible solutions and alternatives to get Peer Discovery Working.
Describe the issue
There are many tools which utilize mechanisms like peer discovery to establish a connection between two devices on a local area network (LAN). Use of IPv4 & IPv6 addresses with UDP and TCP protocols is common in that regard. There are several issues (#395, #421, #446, etc.) regarding Services which use Peer Discovery with the LAN IP Addresses to find other Devices.
The issue: Peer Discovery does not work with gnirehtet: Clients are within a subnet and not the LAN network the Host Device is in ~ thus both devices cannot "find" each other via peer discovery.
Conclusion: Not being able to use Certain Services to Connect Client & Host Device breaks many workflows!
Describe the Solution you propose
Basically the needed functionality is for Client Devices to get a LAN IP-Address from the Routers DCHP-Server ~ and be in the Local Network of the Router rather than a (encapsulated) Subnet.
Maybe gnirehtet could "register" Clients as "Virtual Network Devices" and make the Host Device (Desktop) look like a switch to the DCHP - Server (which is usually running on the Router nowadays).
Or simply some kind of request forwarding or rerouting to allow Services on Both Devices to find each other.
Would it be possible to implement without much hassle?
You're absolutely right — the current architecture of Gnirehtet (which creates a VPN tunnel from the Android device to the host) breaks peer discovery and LAN-based communication, because:
Why Peer Discovery Fails in Gnirehtet: Android gets a private, virtual IP (e.g., 10.0.0.2) inside a VPN-like subnet.
That subnet is not bridged to the LAN — it’s NAT’d and isolated.
Multicast, mDNS (Bonjour/Avahi), SSDP, broadcast UDP, etc. do not work across that boundary.
Android cannot participate in LAN-level service discovery — so apps like Spacedesk, AirDroid, VLC casting, etc. break.
Workaround Concepts
- Bridge gnirehtet traffic into the LAN (Advanced) This would involve:
Creating a TUN-to-bridge adapter
Bridging the gnirehtet VPN interface with your actual Ethernet/Wi-Fi NIC
Forwarding multicast and broadcast packets
Possibly spoofing DHCP leases so Android appears as a native LAN device
This is non-trivial and not supported by gnirehtet natively.
- Use USB RNDIS (Reverse Tethering with ICS) A low-level alternative:
Set up RNDIS (USB Ethernet gadget) on Android
Share PC's internet to Android via ICS or bridged adapter
Android gets a real LAN IP address from the router, enabling peer discovery
You can do this via:
reverse-tethering-no-root (Linux)
EasyTether or PDANet+ (limited free use, proprietary)
Tethering with iptables & dnsmasq on rooted Android
Pros:
Android is now really on the LAN
Services like Spacedesk, VLC, Chromecast, file sharing, Zeroconf, etc. work
Cons:
Complex setup
Often requires root access or special USB drivers
Breaks easily between updates
- Feature Proposal: mDNS & Multicast Proxy in gnirehtet You’re right — a feature request to make gnirehtet act as a multicast/broadcast proxy would be feasible.
Concept: Host PC listens for mDNS, SSDP, broadcast packets from Android
Re-broadcasts them on the host's LAN
Also forwards LAN mDNS/broadcast traffic to Android side
Tools like Avahi Reflector or mdns-repeater could be adapted for this.
This doesn’t require Android root — it’s all on the host side and could be integrated into the relay.
Suggested Solution for the Feature Request "Allow gnirehtet to act as a Multicast Forwarder / LAN Proxy, bridging discovery protocols like mDNS, SSDP, broadcast UDP and optionally forwarding DHCP packets to allow Android to request a real LAN IP."
This could be a relay mode toggle like:
gnirehtet relay --lan-bridge or a config to enable:
mDNS reflection
SSDP rebroadcasting
UDP broadcast routing
