Native Linux Client / Linux Release

Hi!

First of all, congratulations on the project. I have been following eMuleBB and I was particularly interested to see that emulebb-rust is now the active forward direction of the project.

I noticed that emulebb-rust is designed as a multiplatform eD2K/Kad client, with Linux explicitly included in the platform policy. The project already has a headless client and an embedded WebUI, so I was wondering whether you would consider providing a user-facing Linux release as well.

For Linux users, having a native build of emulebb-rust would be very interesting, especially since the new Rust implementation is clearly intended to become the future eMuleBB client.

An initial Linux x86_64 release would already be very useful. For distribution, I would particularly suggest:

AppImage
.deb package for Debian/Ubuntu-based distributions

I would also be happy to test an early Linux build and report any issues I encounter.

I think this would be a natural next step for emulebb-rust, given its existing multiplatform architecture and Linux build/test support.

Thank you for your work!

Thank you, lately I have been busy with other things, I might get back to this project at some point, but there is little interest. For now I would suggest to go for amule, as it's been actively developed and has a larger community of developers.

Thank you for the honest reply, and for the aMule suggestion, I do use it, and I know it well.

I'd like to offer a different angle on the "not enough interest" point, though, because I think it looks quite different depending on which platform you're measuring interest from.

On Windows, the eD2K/Kad world has always been extremely crowded: besides official eMule, there have been hundreds of mods, forks, and specialized variants over the years, plus alternative clients like Shareaza. A Windows user interested in this world has therefore always had many options to choose from, so it's understandable that another Windows client doesn't generate much excitement — it's just one more option among many.

For Linux, the situation has been completely different. For decades, anyone wanting a native eD2K/Kad client on Linux has had essentially one real choice: aMule. That hasn't changed in twenty years, even though the number of Linux desktop users keeps growing year after year. It's not that Linux users aren't interested in eD2K/Kad — it's that they've never had a second option to be interested in.

That's exactly why I think a Linux release of emulebb-rust could matter more than the current lack of feedback suggests. It wouldn't be entering a saturated market the way a Windows build would — it would be filling a gap that's existed since the very beginning of the eD2K network. Given that emulebb-rust already has a headless client and an embedded WebUI, a good part of the groundwork for a Linux release already exists; an AppImage or .deb wouldn't be starting from zero.

There's another angle worth mentioning too. Big sharers — people managing very large libraries — often struggle to find stable, efficient clients built for their specific sharing needs: most eD2K/Kad clients out there are designed with the average user in mind, not someone handling sharing at a much larger scale. But that's exactly the design focus emulebb-rust was built around, with its broadband-oriented architecture. So beyond the Linux gap, this client already targets a purpose that other clients haven't identified, or have never paid much attention to — another niche where emulebb-rust would already start with an edge over the competition.

I understand priorities are limited and this may not be the right moment. But if you do pick the project back up, I wanted to make the case that Linux isn't a low-interest platform for this kind of client — it's an underserved one, and that's a different thing. I'd be glad to help test an early Linux build whenever that becomes realistic.

Well, you made your case a little too convincingly 😄

A couple of extra weeks—and a few million AI tokens sacrificed to the build gods—later, we now have a first beta package ready for testing:

https://github.com/emulebb/emulebb-rust/releases/tag/rust-v0.1.0-beta.1

Linux is included with x86_64 and ARM64 builds, both as AppImage and .deb packages. It is very much a beta, so bug reports and real-world testing would be extremely welcome.

If you know anyone interested in contributing—Rust development, eD2K/Kad, Linux packaging, WebUI work, documentation, or simply testing—please send them our way. I find this experimental project genuinely fascinating, but unfortunately I don’t have as much time to dedicate to it as I would like. Community involvement would make a real difference.

And, piccolo colpo di scena: sono italiano anch’io 🇮🇹

Hi!

I already knew you were Italian because I had read your announcement on DDU; it was actually through the link you posted there that I found this issue. 😉

I tested the Linux 0.1.0-beta.1 release using the x86_64 AppImage on LMDE 7.

The client starts correctly and the WebUI works without problems.

Tests with VPN disabled

eD2K connected successfully.
Kad connected and bootstrapped correctly.
An eD2K search returned 512 results.

Tests with VPN enabled

Initially, with no P2P binding configured:

eD2K servers repeatedly timed out.
Kad showed as Connected and had active contacts.
A Kad search returned 0 results.

I then configured the P2P bind interface to use the VPN interface and restarted the client.

After that:

eD2K connected successfully.
Kad connected successfully.
However, both eD2K and Kad searches returned 0 results.

I then also configured the P2P bind IP, keeping the interface binding enabled, and restarted the client again.

The result was the same:

eD2K: Connected
Kad: Connected
eD2K search: 0 results
Kad search: 0 results

The diagnostics showed:

ed2k_connected=true
kad_connected=true
ed2k_high_id=false
vpn_guard_enabled=false

I did not change any other network settings.

Summary

With the VPN disabled, both eD2K and Kad work normally and eD2K searches return results.

With the VPN enabled and no P2P binding, eD2K server connections time out, while Kad can still show as Connected but searches return no results.

With P2P interface binding enabled, eD2K and Kad can both connect, but searches on both networks still return no results.

So at this point I cannot determine the exact cause. It seems to be related to how P2P traffic behaves when the VPN is active. The binding appears to allow the client to establish the connections, but it does not restore search functionality.

I'm happy to perform more tests if they can help identify the problem.

Thank you — this report was specific enough to reproduce the problem.

I tested the exact beta.1 container in WSL2 + Docker behind plain OpenVPN (no Gluetun), both with no P2P binding and with explicit tun0 binding. I could reproduce the important Kad symptom: Kad stayed connected and retained contacts, but the keyword search completed with 0 results.

The root cause was a timing race in our Kad traversal. Rust performed contact discovery first and the actual keyword request second, while both shared one 45-second deadline. On the failing run, discovery consumed almost the whole budget and the keyword request had only about 50 ms left. The VPN reply was valid, but arrived roughly 177 ms after beta.1 had already closed the search. In other words: the packets were not lost; beta.1 had simply left the party before they arrived. 😄

Binding and protocol obfuscation were not the cause. The fix reserves active time for the keyword phase and then mirrors stock eMule's behavior by keeping a 15-second receive-only window for replies already in flight.

0.1.0-beta.2 is now published:
https://github.com/emulebb/emulebb-rust/releases/tag/rust-v0.1.0-beta.2

The fixed release passed both of these deliberately harsh plain-OpenVPN tests with protocol obfuscation disabled and 1,000 ms of injected tunnel delay:

explicit VPN-interface binding: Kad 209 raw / 200 displayed results;
no explicit binding: server 60, global 144, Kad 200 displayed results.

I could not reproduce the eD2K search failure as the same defect: even beta.1 returned 150 server-search results under the 1,000 ms delay. The initial server connection timeouts may therefore be specific to the VPN endpoint, route, or firewall behavior rather than this Kad deadline race.

Could you retest the beta.2 x86_64 AppImage on LMDE 7 with your original VPN setup? Please try Kad and both eD2K server and global search methods. If eD2K still completes with 0 or times out, the final search status and method will help us isolate that separately; please continue to omit VPN credentials and public addresses.

Hi! I haven't abandoned the testing 😄 I've started working through the checklist you gave me, so here's an update on the current status.

Already verified:

WebUI is working.
The server list is present; I had already verified server fallback in the previous tests.
With beta.2, after manually enabling one eD2K server, the eD2K connection works.
Kad completes bootstrapping and connects: 186 contacts, 40,550 users / 4,379,400 files.
Kad search works: ita 2026 → 200 results.
I selected a result from the Kad search and the download started correctly.
The transfer is currently active in both download and upload.

I also tested:

eD2K → Server search: 0 results.
eD2K → Global search: 0 results.
At the moment I have only one server enabled, eMule Sunrise, so I'm keeping this under observation before drawing any conclusions.

I still need to verify:

completion and delivery of the downloaded file;
stopping/deleting a transfer;
one shared folder;
persistence of the configuration after restart;
persistence of search history/deep links;
clean shutdown;
automatic startup of the server and Kad.

I also noticed something interesting: initially, with all servers disabled, Kad remained in Bootstrapping with 0 contacts. After I manually enabled eMule Sunrise and let it connect, Kad completed the bootstrap and connected normally. I'm keeping this separate from the other tests for now to determine whether this is expected behavior.

So far the test is going well, and I'll continue through the checklist as soon as possible. 👍

Thank you — and thank you for taking the time to work through the checklist so carefully. Your feedback genuinely gave me fresh motivation to keep improving this client.

I am also contributing to aMule and the Rust ed2k-server on a compatible extension to speed up publication of large shared-file libraries to eD2K servers:

We have now moved emulebb-rust to nightly builds as well. The first public nightly is available for Windows, Linux, and macOS. These are development builds, so they may be less stable than the beta releases, but they should make it much easier to test fixes and improvements without waiting for the next formal beta.

There are still many open bugs and improvements to work through before the client and its test coverage are where they should be. Every report is very welcome, including partial observations like the current server-search result, because they help us separate client bugs from network- or server-specific behavior.

Thanks again for your patience and for the detailed testing.

Thanks! I completed a few more tests on beta.2.

The shared-folder test passed successfully:

Added one shared folder containing 8 files.
All 8 files were scanned and hashed successfully: 4.8 GiB total, 0 failures.
All 8 files appeared correctly in Shared Files.
After restarting emulebb-rust, the shared folder and all shared files were still present.

I also tested persistence and reconnection after restart:

The server list was preserved, but all servers were disabled again after restart.
Kad initially restarted in Bootstrapping with 0 contacts.
The first server I had previously enabled (eMule Sunrise) did not reconnect.
I enabled another server, which connected successfully, and Kad then populated and became Connected.
This also confirmed the server fallback behavior: when one server is unavailable, another server can connect successfully.

Finally, I retested the searches with an active eD2K connection:

eD2K Server search (ita 2026): 303 results
eD2K Global search (ita 2026): 484 results
Kad search (ita 2026): 200 results

So the previous 0-result eD2K searches were not reproducible once the eD2K connection was properly established.

I also confirmed that a downloaded file completes correctly, that stopping/deleting a transfer works, and that the client can be terminated cleanly with SIGTERM.

The main point I would still flag is that the Enabled/Disabled state of the servers does not appear to persist across restart, and after restart Kad remains in bootstrap until an eD2K server connection is established.

I have not tested the nightly yet; I wanted to finish the beta.2 checklist first.

I tried to run the Linux nightly build rust-v0.1.0-beta.2.nightly.20261004.gbff642d7, but it did not start.

When launched from the terminal, I got this error:

Error: failed to open metadata store under /home/nix/.config/emulebb-rust

Caused by: metadata schema version 22 is not current 23; run the explicit Python soak-profile migration or use a fresh profile

I haven't made any changes to the existing profile.

Let me know how you would like me to proceed.

Yes, when the db schema changes there is not support for evolution, so basically you have to start with a fresh profile for now. Rename /home/nix/.config/emulebb-rust to /home/nix/.config/emulebb-rust_old and retry

The nightly rust-v0.1.0-beta.2.nightly.20261004.gbff642d7 is working well.

After starting the client with a fresh profile, I restored my P2P bind configuration to the VPN interface/IP. From that point, both eD2K and Kad connected successfully.

I tested:

Kad search: 200 results
eD2K Global search: 464 results
2 downloads: both completed successfully
Restarted the client: the P2P bind configuration was preserved, and both eD2K and Kad reconnected automatically.

One interesting observation: with the fresh profile, leaving the P2P bind fields empty, eD2K and Kad did not connect. After setting the P2P bind to the VPN, both networks connected immediately. I'm not sure whether this is expected, but I thought it was worth mentioning.

Overall, the nightly looks good from my side.

Navigation Menu

Repository navigation

Native Linux Client / Linux Release #19

Tests with VPN disabled

Tests with VPN enabled

Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Native Linux Client / Linux Release #19

Description

Activity

itlezy commented on Sep 22, 2026

falcogiallo commented on Sep 23, 2026

itlezy commented on Oct 2, 2026

falcogiallo commented on Oct 2, 2026

Tests with VPN disabled

Tests with VPN enabled

Summary

itlezy commented on Oct 2, 2026

falcogiallo commented on Oct 3, 2026

itlezy commented on Oct 4, 2026

falcogiallo commented on Oct 4, 2026

falcogiallo commented on Oct 4, 2026

itlezy commented on Oct 4, 2026

falcogiallo commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions