Mission Planner claims UDP socket already bound

Ground Control Software Mission Planner
1

When I try to start listening on a UDP port, sometimes MP refuses, saying the port is already in use. netstat shows nothing for UDP. Restarting MP has no effect. Even restarting Windows doesn’t always solve the problem. This seems to happen with port 14550 specifically.

There’s got to be something very simple I’m missing.

2

It appears that as soon as MP starts, it opens a number of ports, including 14550 and 14551. I wonder if there is some bit of persistent data that tells it to open these specific ports (I’ve used both previously), and then it tries to open them again. Using 1.3.74 (build 1.3.7563.27684)

$ netstat -anbp UDP | grep -A2 MissionPlanner
 [MissionPlanner.exe]
  UDP    0.0.0.0:5050           *:*                    
  CDPSvc
--
 [MissionPlanner.exe]
  UDP    0.0.0.0:5353           *:*                    
  Dnscache
--
 [MissionPlanner.exe]
  UDP    0.0.0.0:5601           *:*                    
 [MissionPlanner.exe]
  UDP    0.0.0.0:14550          *:*                    
 [MissionPlanner.exe]
  UDP    0.0.0.0:14551          *:*                    
 [MissionPlanner.exe]
  UDP    0.0.0.0:50948          *:* 
$
3

these are part of the autoconnect. so you need to have your remote end broadcasting already

4

Thank you, @Michael_Oborne. I’m not sure how this is supposed to work. I have Ardupilot running on a Linux board, sending UDP packets to gcs:14550. MP comes up, it shows the connection icon as disconnected. I click “connect,” it asks me about the port, I say 14550, then it says it can’t because the socket is already bound. What should i be doing instead?

5

what it the bound port you are sending from on the linux side? is it 14550? or random asignment?

6

you can turn off the autoconnect, but currently you need to manualy edit the config file
goto your home dir > mission planner > config.xml

and edit
[
{
“Label”: “Mavlink default port”,
“Enabled”: true,
“Port”: 14550,
“Protocol”: 1,
“Format”: 0,
“Direction”: 0,
“ConfigString”: “”
},

change the enabled to false.

7

Random, I assume. But I haven’t seen the code.

9

Just FYI, if someone sees this on Windows systems, I had a problem with Mission Planner not auto detecting the ESP8266mod wireless, and all params looked correct. I turned on the help → show console window, and MP said that another program was listening on 14550. I pulled up the task manager, and turns out a zombie windows MP had been running, probably since yesterday. I ended it, restarted MP and it detected the wireless module no problem. Hope this helps if you run into the same issue.

10

ELRS 3.5.0-RC1/Backpack 1.5.0 and GCS

I’ve had interesting and somewhat successful experiences with RC and bi-directional MAVLink over WiFi with the latest Backpack firmware over the last weekend.

Successful:
MP connected to internet via ethernet, connect to backpack’s AP via WiFi adapter. UDP 14550 connects and works a charm.
[Just for background - QGC connected to internet via ethernet, backpack connected to home network. (if MP is already running, QGC complains port 14550 is protected. Stop MP and QGC connects). Connect via MP from Chromebook, QGC from iPhone, QGC from Android Phone when backpack connected to home network. BTW, none of the above work when connected directly to the backpack AP.]

Unsuccessful:
MP connected to internet via ethernet, backback connected to home network. UDP 14550 fails port already in use.
MP connected to internet via wifi to home network, backback connected to home network. UDP 14550 fails port already in use.
MP connected to internet via ethernet and wifi to home network, backback connected to home network. UDP 14550 fails port already in use.

My after editing config.xml:
{
“Label”: “Mavlink default port”,
“Enabled”: false,
“Port”: 14550,
“Protocol”: “Udp”,
“Format”: “MAVLink”,
“Direction”: “Inbound”,
“ConfigString”: “”
}

Enabled true or false - doesn’t affect behavior.

Any other ideas?

Setup:
MissionPlanner 1.3.82 build 1.3.9007.4717 on Win11
5" Quad (Titan Dynamics Quark)
SpeedyBee F405 V4, ArduPilot 4.5.4
SpeedyBee BL32 50A
Matek ELRS-R24-D, ExpressLRS 3.5.0-RC1, MAVLink protocol
RadioMaster Boxer ELRS2.4 Internal, EdgeTX 2.10.4, ExpressLRS 3.5.0-RC1, MAVLink protocol, Backpack 1.50

11

OK. Pulled up my own socks…

I have run mavproxy in the past to forward telemetry to my home network. (not running it currently thanks to cool new MAVLink over ELRS)

There was a dangling entry in the DNS cache :-/

ipconfig /flushdns

no more conflict & everything starts fine :slight_smile:

At least it’s working now

1 Like