Remote Panel 2 · ExtPlane Plugin

The app won't connect to X‑Plane

Work through this in order. Each step rules out a whole category of cause, so stopping at the first failure tells you where the problem is.

Preflight check

Step by step

  1. Confirm the plugin started

    Open Log.txt in your X‑Plane folder and search for ExtPlane-Plugin. Three lines confirm a healthy start:

    ExtPlane-Plugin: Plugin enabled
ExtPlane-Plugin: Successfully bound to port
ExtPlane-Plugin: Listening on port 51000

    If you see BIND FAILED instead, the next line names the reason. There are two, and they need different fixes:

    • Port is already in use (error 10048) — something else has it, usually a second copy of the plugin or an older ExtPlane still installed. Only one can have it.
    • Permission denied (error 10013) — on Windows, this means the port landed inside a range Windows reserved for itself. Jump to Windows reserved port ranges.

    No ExtPlane-Plugin lines at all means the plugin never loaded. Check where it sits:

    Resources/plugins/your-folder-name/64/win.xpl

    The folder name is entirely yours to choose — extplane, AndroidPanel, anything. What has to be exact is the 64 subfolder and the file inside it: win.xpl on Windows, mac.xpl on macOS, lin.xpl on Linux. Also confirm the plugin is enabled in X‑Plane's Plugin Admin.

  2. Test on the X‑Plane computer first

    This separates a broken plugin from a blocked network. Run it on the computer itself, with X‑Plane open:

    Windows 
    netstat -an | findstr :51000
Test-NetConnection localhost -Port 51000
    macOS 
    lsof -nP -iTCP:51000 -sTCP:LISTEN
nc -vz localhost 51000
    Linux 
    ss -ltn | grep 51000
nc -vz localhost 51000

    You want to see the port listed as listening on 0.0.0.0:51000, and the connection test succeed.

    If this step fails, stop here — the problem is the plugin, and no amount of network or firewall work will help.

  3. Let the connection through the firewall

    The most common cause once the local test passes. A firewall usually discards traffic rather than refusing it, so its signature in the app is a timeout rather than "connection refused".

    Windows

    Run as Administrator, on one line:

    netsh advfirewall firewall add rule name="ExtPlane 51000" dir=in action=allow protocol=TCP localport=51000

    Then set the Wi‑Fi connection to Private, not Public — Windows blocks nearly all incoming connections on Public networks whatever your rules say.

    macOS

    The first time X‑Plane opens the port, macOS asks whether to allow incoming connections. Clicking Deny causes exactly this problem, and it won't ask twice.

    Fix it in System Settings → Network → Firewall → Options: find X‑Plane and set it to allow incoming connections. If X‑Plane isn't in the list, add it.

    Linux

    On Ubuntu and derivatives:

    sudo ufw allow 51000/tcp

    On Fedora, RHEL and openSUSE:

    sudo firewall-cmd --add-port=51000/tcp --permanent
sudo firewall-cmd --reload

  4. Use the right address

    X‑Plane will tell you its own addresses — no command line needed, and it looks the same on Windows, macOS and Linux. Open Settings → Network and read the list under This Machine's IP Addresses.

    X-Plane's Settings window on the Network tab. Under the heading This Machine's IP Addresses it lists 192.168.1.100, 192.168.247.1, 192.168.42.1, 172.24.80.1, and three IPv6 addresses beginning fe80.
    Every address the computer has, in one place. You want the one on the same network as your tablet — here, 192.168.1.100.

    Home networks almost always put every device on 192.168.1.x or 192.168.0.x, so the right address usually begins the same way as your tablet's. You can check the tablet's own address in Android's Wi‑Fi settings, under the network it's joined to — the first three numbers should match.

    The rest of the list is noise. Addresses like 192.168.247.1 and 172.24.80.1 belong to virtual network adapters created by VirtualBox, VMware, Docker or WSL, and they lead nowhere. The fe80:: entries are IPv6, which the app doesn't use.

    If you'd rather read it from a terminal:

    Windows 
    ipconfig

    Use the IPv4 Address of your real adapter — not a VirtualBox, VMware or Hyper‑V one, which often appear first in the list.

    macOS 
    ipconfig getifaddr en0

    That's the Wi‑Fi address on most Macs; try en1 if it returns nothing, or read it from System Settings → Network.

    Linux 
    hostname -I
ip addr show

    Things that regularly send people to the wrong number, on any platform:

    • The computer on Ethernet while the tablet is on a guest or visitor Wi‑Fi network
    • Client isolation switched on at the router — standard on guest Wi‑Fi, and it blocks all device‑to‑device traffic
    • A VPN running on either the computer or the tablet
    • The tablet on mobile data rather than Wi‑Fi

  5. Read the status line in the app

    Tap the gear and enter the computer's address. The line at the top of the app reports exactly what the connection attempt did — it's the fastest way to identify the cause. See the panel below for what each message means.

    You don't need to restart anything while you work: the app retries every four seconds on its own and will connect the moment the path opens.

  6. Rule out an older plugin

    Earlier versions of this plugin used port 55000 and a different greeting. The current app talks only to the current plugin. If the app was updated but the plugin wasn't, that mismatch is the failure — and it shows up as the message "Incompatible X-Plane plugin version".

    Remove any older plugin folder from Resources/plugins/, leave only the current one, and restart X‑Plane.

Windows reserved port ranges

Windows sets aside blocks of network ports for its own use, and those blocks move around between restarts. Hyper‑V, WSL, Docker Desktop and Windows Sandbox all cause this. If port 51000 happens to fall inside one of them, the plugin can't use it — even though no program is actually running there.

How to tell it's this

Log.txt reports error 10013 and permission denied, rather than the port being in use:

ExtPlane-Plugin: BIND FAILED on port 51000 (error 10013)
ExtPlane-Plugin: Permission denied to bind to port 51000

The fix

Claim the port for the plugin so Windows stops handing it out. In an Administrator Command Prompt or PowerShell:

net stop winnat
netsh int ipv4 add excludedportrange protocol=tcp startport=51000 numberofports=1
net start winnat

Stop winnat first. If you add the reservation while it still holds the range, the command fails with an access-denied or file-in-use error — which is the usual outcome, since a held range is the whole problem.

Confirm it worked

netsh int ipv4 show excludedportrange protocol=tcp

Look for a line reading 51000   51000 marked with an asterisk, meaning you reserved it deliberately. The reservation survives restarts, so this is a one-time fix.

Restart the computer, then check Log.txt again for Listening on port 51000.

Windows only. macOS and Linux don't reserve ports this way.

What the message means

Connection refused

You reached the computer, but nothing is listening.

The network is fine. Go back to step 1 — the plugin isn't loaded, isn't enabled, or couldn't claim the port. On Windows, check reserved port ranges too.

Connection timed out

Nothing answered at all.

Wrong address, the two devices are on different networks, or the firewall is discarding the connection. Steps 3 and 4.

Host unreachable

There's no route to that address from the tablet.

Almost always the wrong address, or the tablet on a different Wi‑Fi network. Step 4.

Incompatible plugin version

An older plugin answered.

Install the current plugin and remove the old one. Step 6.

Connected to plugin

The link is up.

If instruments still read zero, X‑Plane needs to be in a flight rather than sitting at a menu.

Not worth checking