I'm behind ISP NAT. Once in a while, ISP hardware is restarted, NAT sessions are dropped, and clients are assigned new public addresses for translation. (FOPNU simply says “Reflected location: <new address>”.)

Tixati DHT graph shows this:
https://files.catbox.moe/8c1se2.png
Status says “port blocked”. Peer connections are also dropped. I stop the DHT, change global port number and DHT ID in settings, then start the DHT to get to the assumed clean state. Then everything works as it should.

It is not a big problem, the restarts happen once a month or maybe even less often, and I get to fix it sooner or later. Changing the port each hour just in case might be be a solution, but on a constantly running client it would be a disservice to other peers, and an overkill anyway. But I wonder if there is some mistake in Tixati that might make it stick to the old address, or not react as intended to the change in network conditions.

State Tables in the NAT Router

Even if your app uses standard un-connected UDP (sendto), the user's home router is causing a deadlock due to NAT Connection Tracking (Conntrack).

When your app sends UDP or TCP traffic out to the internet, the router creates a temporary rule in its memory: “Traffic leaving Port X from Local IP A is allowed, and any return traffic to Port X should be forwarded back to IP A.”

When the ISP hardware resets and shuffles everyone's local IPs:

   The Trap: The router's NAT table is completely wiped clean, or worse, it remembers your app's specific Port # as belonging to the old IP address.

   The Deadlock: * If your app keeps sending UDP packets out of the same local port, some cheap routers will see this as a continuation of an old session and fail to route it properly, or block it as an invalid state.

       If the remote server tries to send data back to that port, the router looks at its fresh NAT table, has no idea which machine owns that port anymore, and drops the packet.

   The Fix: The moment the user changes the port # in your app, a brand-new NAT session is forced. The router says, "Ah, a totally new request from the new IP on this new port!" and routing successfully resumes.


You could use the randomize port function in the settings. Or it would otherwise require a new setting so it randomizes the port after x minutes of no traffic.  But it's a workaround for bad router behavior.

AI-generated junk is not a valid substitute for real knowledge. A kid with a toy drill can have all the fun, but you still need real instruments for real work.

This has nothing to do with local router configuration, whether it is provided and managed by the ISP, or installed and configured by you. For one thing, router restarts result in interface down and up events affecting all programs, and subsequent re-initialisation. Its NAT configuration can be fixed with a new UPnP session from the torrent client (because new gateway device identity is broadcasted across the network), or by the static manually added port forwarding rule that is always present. This is not a problem.

What I described is a restart of the ISP NAT, a big server somewhere that handles traffic for tens of thousands of users, and translates private network addresses of their ISP-facing devices to a given allocated public address subnet. It does not happen often (unless there are critical security updates for the system), and you get a different public IP address for the next couple of weeks/months because user address and public address correspondence gets randomly balanced.

use postimages.org for images