Troubleshooting
The handful of things that actually go wrong, and what to do about them.
Active and passive mode
This is the cause of most “nothing downloads” problems, so it is worth understanding once.
In active mode other users can open a connection to you. In passive mode they cannot, so you have to open the connection to them. That works fine — except when both sides are passive, in which case no connection is possible at all and the transfer simply never starts. A passive client can only reach active ones, which on a typical hub is a minority of users.
Symptoms of being stuck passive: searches return few results, downloads sit at “Connecting” forever, and nobody ever downloads from you.
Getting into active mode
- Open Settings → Connection settings and run the automatic connectivity detection. It will try UPnP on your router and configure ports for you.
- If that fails, set the TCP, UDP and TLS ports manually and forward those same ports to your computer in your router's configuration.
- Allow FulDC++ through Windows Firewall — both the private and public profiles if you are unsure.
- Reconnect to a hub and check the system log; FulDC++ reports the connectivity state it ended up with.
/connection in any chat prints your current mode, external IP and ports, which is
the quickest way to confirm what you have. /testports goes one step further: it asks
the project's own service to connect back to you on your transfer and encrypted-transfer ports
and reports whether each was reachable, refused, or gave no answer. The same test sits behind the
Test ports button on the Connection page.
On a VPN whose address changes
A VPN exit can change its address while the client is running. FulDC++ re-reads its external address when connectivity detection finishes, when the machine's network changes and once an hour, and rejoins hubs automatically when it changes, so the address other users are given follows the VPN. Two things to check when passive users still cannot reach you although everything looks right:
- Run
/testports. Peers that support encryption connect to your encrypted transfer port, not the transfer port, and a VPN that forwards a single port covers only one of them. Both must come back reachable. - With automatic detection on, a port mapping made on your home router is worthless behind a VPN: the router is not your internet exit. The system log says so when it notices, and the address it announces is the one the internet sees, not the router's.
The search port uses UDP and cannot be tested this way; if searches return results, it works.
Downloads that will not move
“No slots available”
Not an error. The user is busy and you are queued. Add more sources: right-click the download and choose Search for alternates.
Stuck at “Connecting”
Usually the passive-to-passive problem above, or the user has gone offline. Find another source.
“File not available”
They have moved or deleted it and not refreshed their share. Remove that source.
Everything is slow
Check you have not left a speed limit set in Settings → Connection settings → Limits & advanced, and that Pause all downloads is not active on the toolbar.
Hub problems
Nick taken
Someone else is using it, or you are already connected. Set a different nick for that hub in
its favourite properties, or use /nick on NMDC hubs that allow it.
Kicked for share size
The hub has a minimum share. Add folders and refresh, then reconnect.
Certificate or keyprint mismatch
The hub's TLS certificate is not the one FulDC++ remembers. That can mean the hub genuinely
changed its certificate — or that something is intercepting the connection. If you have
reason to believe it is legitimate, /allow accepts it for this connection. Do not
make a habit of it.
Hub keeps redirecting
File → Follow last redirect takes you where it wants you to go. Automatic redirect following is a setting in Settings → Advanced.
Sharing and hashing
A first refresh of a large share takes a long time — every file has to be hashed. Watch it in View → Hashing progress. If it seems too slow, or is making the machine unusable, the speed limits are in Settings → Sharing → Hashing.
If your share size looks wrong, or files you know you have are not being found, run
File → Refresh file list. If it still looks wrong, the hash database
may need attention: /optimizedb removes unused entries and /verifydb
checks its integrity. Both report progress to the system log.
Encryption
Prefer adcs:// hubs, which are encrypted. Transfer encryption is configured in
Settings → Advanced → Encryption; the LAN user profile may turn
it off, which is fine on a local network and a bad idea anywhere else. If you picked LAN during the
wizard and are now on public hubs, check that page.
When something crashes
FulDC++ can restart itself after a crash or a hang — see Settings → Advanced → Auto-Recovery. After an unclean shutdown it offers to repair the hash database or restore a backup before it loads anything, so take that prompt seriously rather than clicking past it.
If crash reporting is enabled you can send a report; you control whether the system log is included. Reports are useful — they are usually the only way a bug that only happens on your machine ever gets fixed.
Finding out what happened
System log
View → System log, or click the leftmost status bar panel. Connection problems, port bind failures, refresh results and update checks all report here first. Start here.
Log files
File → Open log directory, or /log system,
/log downloads, /log uploads.
Protocol debug
View → Protocol debug shows the raw conversation with hubs and users. Verbose, but decisive when a hub is behaving oddly.
Where your data lives
Settings, favourites, the queue and logs are in Documents\FulDC++; caches and the
hash database are in %LocalAppData%\FulDC++. Neither is inside the program folder, so
you can replace the program with a newer version freely.
To start completely fresh, close FulDC++ and rename Documents\FulDC++
rather than deleting it — if it turns out you wanted something from it, it is still there.