On 20/02/16 12:31, vastik_spbm wrote: >> 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). >> > 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.
IIRC symmetric means exactly the problem above: Different port number for each pair of IPs, can only connect to nodes that aren't NATed. :( > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
