Tim Tuxworth 4c98c9221a
pre-commit / ci (push) Canceled after 0s
test Renode / cubeorangeplus-quadplane (push) Canceled after 0s
test scripts / build (astyle-cleanliness) (push) Canceled after 0s
test scripts / build (check_autotest_options) (push) Canceled after 0s
test scripts / build (logger_metadata) (push) Canceled after 0s
test scripts / build (param-file-validation) (push) Canceled after 0s
test scripts / build (param_parse) (push) Canceled after 0s
test scripts / build (python-cleanliness) (push) Canceled after 0s
test scripts / build (shellcheck) (push) Canceled after 0s
test scripts / build (validate_board_list) (push) Canceled after 0s
AP_Networking: accept UDP client replies from a different source port
NET_Pn set to UDP_CLIENT connect()'d its socket to the configured
destination, which makes the kernel filter incoming packets to match
that exact source address *and port*. That's fine for the common case
of a device that replies from the same socket it was queried on, but
some devices (confirmed against a real Topotek KHP415 gimbal) reply
from a different, fixed source port instead - every reply was silently
dropped before ArduPilot's own code ever saw it, regardless of NET_Pn
config being otherwise correct.

For a unicast destination, stop calling connect() and use sendto()/an
unconnected recv() instead, checking the source IP ourselves (but not
the port) before accepting a packet. Broadcast and multicast
destinations keep the original connect()-based path unchanged, since
connect() also does necessary setup for them (joining the multicast
group via IP_ADD_MEMBERSHIP) unrelated to this fix, and neither is a
point-to-point relationship that could hit this problem in the first
place.

Verified against the real KHP415 (which replies from a fixed but
different port than it's queried on) by hand-crafting its wire
protocol and sending it from an unconnected socket. Regression-tested
against the existing TestLogDownloadMAVProxyNetwork suite (unicast/
multicast/broadcast UDP client, UDP server, TCP client/server) and the
full AP_Mount network autotest suite - no regressions.
2026-09-26 08:07:18 +10:00
…
2026-09-02 12:32:52 +09:00
…
…
…
…
…
…

ArduPilot Project

Discord

Test Copter Test Plane Test Rover Test Sub Test Tracker

Test AP_Periph Test Chibios Test Linux SBC Test Replay

Test Unit Teststest size

Test Environment Setup

Cygwin Build Macos Build

Coverity Scan Build Status

Test Coverage

Autotest Status

OpenSSF Best Practices

ArduPilot is the most advanced, full-featured, and reliable open source autopilot software available. It has been under development since 2010 by a diverse team of professional engineers, computer scientists, and community contributors. Our autopilot software is capable of controlling almost any vehicle system imaginable, from conventional airplanes, quad planes, multi-rotors, and helicopters to rovers, boats, balance bots, and even submarines. It is continually being expanded to provide support for new emerging vehicle types.

The ArduPilot project is made up of

User Support & Discussion Forums

Developer Information

Top Contributors

How To Get Involved

License

The ArduPilot project is licensed under the GNU General Public License, version 3.

Maintainers

ArduPilot is comprised of several parts, vehicles and boards. The list below contains the people that regularly contribute to the project and are responsible for reviewing patches on their specific area.

Languages
C++ 62.3%
Python 17.7%
C 10%
Lua 4.8%
C# 2.1%
Other 2.7%