Afternoon, kids.
Just thought I'd post a wee bit of info I gleaned about this last night.
As those of you who use - or have in the past used - this utility are probably aware, Dukto is specifically built for LAN use only. It was never intended to work across the wider internet. Some LAN file-transfer utilities "pull" data from another machine, others "push" said data to the other machine. Dukto is one of the latter; it goes without saying that one needs to have it running on both machines for things to work.
One of Dukto's features that contribute to its extreme ease-of-use is its ability to 'auto-discover' any other machines on the network, along with their host names. For this to work, it's a more or less mandatory requirement that the firewall should be disabled. Now, I don't know about the rest of you, but even under a purely local environment, I've never been too happy about doing this, since invariably the system is still connected through the router, etc., to the outside world!
Since there's absolutely no info provided on the Dukto site about port requirements, I have for years reluctantly forsworn Dukto's simple, easy-to-use benefits.....until yesterday, that is.
===================================
I was messing around with the Dukto-portable I'd built some time ago, and got into a bit of research on the app itself.....and somehow (don't ask, because I forget how I got the link to the site; I was jumping around all over the place last night) I ended up here:-
https://learnubuntumate.weebly.com/dukto.html
There ARE references on many sites about allowing Dukto through a firewall, but almost all refer to a firewall capable of allowing items through BY NAME.....with the exception of the above site. Don't ask me how the author of the article found out, but here we're talking port numbers, which for our purposes is what we want.
The info is quite simple. All you need to do is to allow port 4644 as an exception in your firewall - on both machines - and you can leave your firewall enabled.
The one downside to this is the loss of the "auto-discovery" feature.....but since Dukto lets you connect to another machine by merely entering its LOCAL IP addy - 192.168.1.xxx; that's all that's needed.....no 'http' or 'https', etc - it's very simple to work around this. And the ability to just drag'n'drop not just files, but directories as well, onto the app is the icing on the cake....
Dukto just 'works', with no fuss at all (once set-up correctly). I like it..!
This version of Dukto (the older, Qt4-based R6 build; there IS a recent, re-vamped Qt5 build now available at Github from a new author, though I haven't even looked at it because R6 works so well!) can be obtained from here:-
https://drive.google.com/drive/folders/ ... drive_link
I built .pets a few years back - these Xenial-era ones seem to work pretty much anywhere, so long as Qt4 is 'on the system'. It's lucky I did, since the Linux packages are no longer available from Emanuele Colombo's website; he candidly admits he lost interest in it some time ago.
(A few Qt packages are available at my GoogleDrive. You need to check to see if you have it installed first, since if two versions end up on the system, Dukto will stamp its little foot, pout, go into a massive sulk & point-blank refuse to come out and play. This isn't exclusive to Dukto, but applies to all apps that need Qt to function. It's simple if you think about it; as an example, all versions of Qt4 - and there were a LOT - use the file libQtCore.so.4 (the core package needed by everything else). If two versions end up on the system, you'll end up with overwritten symlinks, some files will be referenced by one 'soname', others by another.......naturally enough, the app won't have a clue what it's doing!
https://drive.google.com/drive/folders/ ... drive_link
Specific versions aren't quite so important here; Qt4 was a heck of a lot more forgiving than its later offspring, Qt5.....which is incredibly fussy about the version in use.
Anyways; DO check first. Don't say I didn't warn you.)
Hope that all helps.
Mike. 
