Feature request - NAT Traversal (NAT-T) & uTP

[demanuel]

Hello amule team,

Is it possible to implement NAT Traversal (NAT-T) and uTP to create direct, reliable peer connections even when both sides sit behind NAT or firewalls?

This would allow UDP hole punching which in turn would allow lowid to lowid transfers.

There's one emule mod that already implements this: https://github.com/eMuleAI/eMuleAI

Thanks and keep up the good work.

[got3nks]

Thanks @demanuel — this is a real UX gap (LowID-to-LowID currently can't transfer at all, and with CGNAT increasingly common at the consumer ISP layer, the share of the network affected keeps growing). NAT-T + uTP hole punching would address it directly.

The eMuleAI reference is a useful starting point — its license is GPLv2+, same as aMule, so the code can be ported directly with proper attribution. I'll dig into the source to see how scoped the protocol changes are and how portable the implementation is (eMule is Windows-only; aMule is cross-platform Linux / macOS / Windows-MinGW).

No commitment yet, but it's the kind of feature worth investing in if the scope turns out tractable. Will report back here with findings.

[got3nks]

Update — got a full end-to-end NAT-T + uTP transfer working between two LowID peers in a closed test mesh, mirroring eMuleAI's wire protocol. Control plane via the source's HighID buddy, data plane carrying OP_SENDINGPART over uTP-encapsulated UDP; file integrity verified byte-for-byte after the hole-punched rendezvous. 🎉

This is still far from deployment-ready — extensive soak + interop testing against eMuleAI clients, security review (encryption posture, NAT-T preference surface), and the missing GUI / EC / preferences integration all still need to land. So it's unlikely to land in 3.0.0; new features are locked for that release and only bug fixes are going in between now and the cut. Continuing the work after.

But the proof point stands: aMule is capable of carrying this feature.

[demanuel]

Wow!!! That was impressive! So fast after i created the feature request!

Just wow!

[mrjimenez]

3.1.0 🤣

[Stoatwblr]

I'm going to point out that whilst useful, this is a kludge which is effectively redundant if ipv6 support is present.

Stuff like this can end up being a vast sink of time and effort when "better" solutions already exist

[got3nks]

Disagree, respectfully — on the network-effect math.

NAT-T pays off asymmetrically: the moment one peer in a transfer pair runs a NAT-T-capable client, reachability improves. eMule and aMule already implement the Buddy-callback half of this (HighID→LowID via a HighID buddy) — it's been universally deployed in the eD2k network for years. What eMuleAI added is the second half: extending the Buddy bond with uTP UDP hole-punching to enable LowID↔LowID transfers. eMuleAI itself is recent, but the infrastructure NAT-T builds on (Buddy bonds, Kad-published buddy IDs) is already part of every peer in the live network. So an aMule client that ships uTP NAT-T sees reachability gains the moment it meets any eMuleAI peer or a fellow updated aMule, and the curve grows from there. IPv6 has the opposite curve: zero benefit until both sides in a given pair have migrated — and in the eD2k/Kad space, with no IPv6 in stock Kad, no IPv6 in the live server list, and no IPv6 in any widely-deployed peer client, that threshold is many years away.

Also worth noting: UDP rendezvous + hole-punching is the same mechanism BitTorrent's µTP, libutp, WebRTC, and every modern P2P stack relies on — it's the de facto NAT traversal standard, not a kludge. And the PoC actually came in faster than expected because eMuleAI's GPLv2+ code was directly portable. The remaining integration scope (GUI, EC, prefs, interop testing) is an order of magnitude smaller than IPv6's, where every wire format, on-disk file, and UI surface would have to grow 128-bit addresses.

None of this argues against IPv6 eventually. They're additive, not substitutional — different timescales of the same problem.

[demanuel]

this is a kludge which is effectively redundant if ipv6 support is present.

No it's not, since not everybody is under ipv6. IPv6 adoption have been really slow because of hacks like cgnat.

For example, my isp offers ipv6 but you need to specifically ask for it. Do you think most people ask? They don't even know what's ipv6...

[got3nks]

No it's not, since not everybody is under ipv6. IPv6 adoption have been really slow because of hacks like cgnat.

That's a good point too, not every CGNAT ISP offers IPv6.

[eMuleAI]

@got3nks

That's great news!

One of the biggest long-term problems of the network has always been the limited participation of LowID users in direct peer connectivity and file distribution. If NAT-T uTP support is implemented properly and adopted across compatible clients, I genuinely believe it could become a very important step for the future of the eD2K/Kad network.

One important design detail I would especially like to mention is the minimum number of Kad and eServer buddies used by eMule AI. In eMule AI, keeping multiple buddy candidates and making these limits configurable became a critical part of the NAT-T uTP design. This significantly improves reliability because LowID-to-LowID connectivity depends heavily on having enough available relay and buddy options when direct traversal is not immediately possible. I strongly recommend considering this architecture from the very beginning. It can make the feature much more stable and effective under real-world network conditions.

I’m very happy to see interest of aMule in this area :) If you ever need any help, testing, protocol discussion, or implementation feedback from the eMule AI side, I’ll always be happy to help.

[danim7]

@got3nks Just let me know if you need help to test this feature. I can set-up a Low ID client behind a CG-NAT to see how effective is the traversal.

[got3nks]

@danim7 sure, will let you know.

Probably the next couple of weeks we’ll be busy with bug fixes, but NAT-T is my first priority as new feature for aMule.

[eMuleAI]

@got3nks , I've improved LowID to LowID via eServer Buddy download mechanism a lot in eMule AI v1.5 code base. So I strongly suggest you to continue your port with eMule AI v1.5 which will be released very soon.

If you want, I can provide before/after codes so you can have a look at diffs.

[got3nks]

@got3nks , I've improved LowID to LowID via eServer Buddy download mechanism a lot in eMule AI v1.5 code base. So I strongly suggest you to continue your port with eMule AI v1.5 which will be released very soon.

If you want, I can provide before/after codes so you can have a look at diffs.

Thanks for the heads up. I’m not currently working on NAT-T yet. You can ping me once the new eMule AI code is ready for deployment.