On 19/02/16 14:53, vastik.spbm@yahoo wrote: > Dear all, > > I will explain my problem. > My ISP decided to fight with torrents DHT and changed udp nat > translation timeout to 5 seconds. > What does it mean. It means that if udp packet won't return from > destination within 5 seconds NAT wont create a new rule and wont allow > any other packets goes back to source. To create nat rule the first > packet has to return with in 5 seconds, and it doesn't matter if other > packet will follow the first one, the rest can return much later, but > first one has to return within 5 seconds. > > Right now my client cant connect to any nodes at all. This is initial > connection, when I start my client. > And this can be done by any of ISPs, it is not very difficult and ISP > doesn't brake anything, because UDP exists and enabled. > Freenet wont work this way. > > > Therefore, please: > You need to improve node behavior - it has to replay nearly > immediately after a node receives an attempt to initiate a connection > from a client. > It doesn't mean that node will keep it up, node can reject this > connection late, or just ignore any other packets from client, but not > the first one. > > Sorry, English is not my native language to me, so if you need more > details or log file from tcpdump, just ask. > I use freenet a lot and would like to continue to use it. > I believe Freenet does reply more or less immediately to a connection request. Did your node manage to connect to any seednodes? Have you tried connecting to darknet nodes outside the problematic network?
It might be losing connections to seednodes once it's established them. Currently on an idle connection we send keepalive packets only every 7-14 seconds (see the constant KEEPALIVE_INTERVAL in Node.java, you could just reduce this to say 2 seconds). Another possibility for darknet would be to ensure there is always traffic e.g. by sending files using the node-to-node messaging. However, there are two further problems: 1. Some NATs will break Freenet no matter what we do. E.g. if they use a different port number for each connection, UDP hole punching usually won't work, at least not if the other side is also NATed. 2. It's actually fairly straightforward to block Freenet at present. The trivial attack is to block large UDP packets, but there are other options. In the long run with steganographic transports this would be harder, but still easy with traffic flow analysis (depending on how much of a problem false positives are i.e. blocking other traffic by accident).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
