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).
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Hello,
I would like to apologize for the noise.
I found access to a different ISP and check response time, it is less then 3
seconds.
If necessary I can provide log, but I do not think.
It looks like my ISP did some nasty stuff to block some udp (sip actually
works).
I am not sure that ISP uses different port number, because sip stun tells that
nat is symmetric.
Yes my node can ONLY connect to seednodes:
15:18:51.567601 IP 192.168.1.2.35394 > 100.xx.xx.xxx.14416: UDP, length 272
15:18:51.750478 IP 192.168.1.2.35394 > 84.xx.xx.xxx.1131: UDP, length 231
15:18:53.617665 IP 192.168.1.2.35394 > 149.xxx.xxx.xxx.61078: UDP, length 285 <---- this is request to seednodes, packet size
correspond with others
15:18:53.662938 IP 149.xxx.xxx.xxx.61078 > 192.168.1.2.35394: UDP, length 325
<--- replay, almost immediately
As long as I cant check the remote side I think I just say thank you for your
help.
Best regards
Vasilii Tikhonov
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
