If another device never appears in Warpinator, first separate a discovery problem from a connection problem. This guide is for the empty device list case. If the device is already listed, use the connection troubleshooting guide instead.
Scope: Linux Warpinator and independently maintained compatible clients. Menu names and manual-connect features vary by implementation. The steps below are a diagnostic workflow, not a claim that every device combination has been tested.
1. Write down the starting point
For each device, record the operating system, application name and version, active network adapter, and local IP address. Note whether neither device sees the other, or only one device does. Keep these notes locally; do not publish a group code or unredacted logs.
2. Check the two simplest conditions
Open the applications on both devices. Compare the group code privately and make it identical on the intended devices. Select a unique code rather than leaving the default. Fully quit and reopen the applications after changing their configuration.
Expected result: If the device appears now, send one small test file before changing anything else. If not, continue without resetting unrelated settings.
3. Confirm the devices can share a local network
Check that neither device is on a guest network, isolated wireless segment, or a different VLAN. Wi-Fi and Ethernet can work together when the router bridges them; different connection types alone do not prove a problem.
Compare the IP addresses and subnet masks/prefix lengths. Matching the first three numbers is only a shortcut for a typical /24 IPv4 network, not a universal test. If this is a workplace or school network, ask the administrator whether client-to-client traffic is allowed rather than changing router security settings.
Useful comparison: If you control another trusted network, try the same two devices there. Success points toward a difference in network configuration, but does not identify the exact router setting.
4. Check which adapter the app selected
On a computer with Ethernet, Wi-Fi, virtual adapters, or a VPN, compare the address shown by the application with the adapter used for the intended local network. If available, choose the correct interface in the application’s preferences.
A VPN can affect routing or local-network access; it does not always block every local transfer. Check its LAN-access setting and your organisation’s policy. Record any permitted change so you can restore it after the test.
5. Check discovery and connection rules separately
The Linux project’s troubleshooting notes distinguish transfer traffic, authentication traffic, and mDNS discovery. Its documented defaults are TCP 42000 for transfers and TCP 42001 for authentication; legacy peers can also need UDP on the transfer port. The notes also describe UDP 5353 for Flatpak discovery. Verify your installed application’s configured ports before creating a rule.
Prefer an application-specific firewall exception limited to the trusted local network. Do not turn off the entire firewall or expose these ports through router port forwarding. A device that becomes visible but remains stuck connecting needs a connection-stage check, not repeated discovery changes.
6. Inspect Flatpak settings before changing them
For a Flatpak installation, these commands inspect the installed application and its permissions:
flatpak info org.x.Warpinator
flatpak info --show-permissions org.x.WarpinatorReview whether network access has been restricted by a custom override. Flatpak expresses network sharing as --share=network, not --socket=network. Do not apply a blanket permission reset simply because the device list is empty; compare your configuration with the package’s expected settings first.
7. Interpret a manual connection test carefully
If your client offers manual connection by IP, use the other device’s current local address. If that works while automatic discovery does not, investigate discovery traffic. If it also fails, routing, firewall rules, authentication, or client compatibility may still be involved. Manual connection is not guaranteed and is not available in every client.
What to include in a support request
Record which step changed the symptom, both application versions, and whether the issue occurs on a second trusted network. Check the relevant project’s issue tracker for the same combination before reporting it. Redact usernames, addresses, group codes, and file paths from logs where appropriate.
Sources: Linux Warpinator troubleshooting notes; Flatpak command reference. Editorial correction: the earlier version of this guide omitted the separate authentication port, included an incorrect Flatpak socket argument, and overstated manual-connection reliability.