Re: [freenet-support] Part 2: Probably a bug: please report: 1 peers forcibly disconnected due to not acknowledging packets.

2009-08-29 Thread Matthew Toseland
On Thursday 30 July 2009 13:12:05 Toni Bergman wrote:
 Hi, I got this error again, but this time I got more info about it
 Probably a bug: please report: 1 peers forcibly disconnected due to not
 acknowledging packets.
 1 of your peers are having severe problems (not acknowledging packets even
 after 10 minutes). This is probably due to a bug in the code. Please report
 it to us at the bug tracker at https://bugs.freenetproject.org/ or to the
 support mailing list supp...@freenetproject.org. Please include this message
 and what version of the node you are running. The affected peers (you may
 not want to include this in your bug report if they are darknet peers) are:
 * 165.154.46.119:34072
 
 Versio info
 * Freenet 0.7.5 Build #1223 build01223-real
 * Freenet-ext Build #26 r23771
 
 My machine: modern gaming specs win xp pro, direct connection.
 
 Here's the extra info, it seems that peer is trying to attack my node and
 probably many others. Switching it's port and trying to connect again. Since
 opennet by default won't allow more than 1 connection per IP, I don't see
 the point.. Maybe it's giving me some false info in order to confuse my
 node. Here's what I found at my CONNECTIVITY - stats page. I removed all but
 the 1 attacking ip address so it's clearer to view.

Might be somebody trying to harvest, or it might be a wierd firewall problem - 
symmetric firewalls e.g. create a new port for every connection. I'm leaning 
towards the latter explanation.
 
 
 Packets for UDP Opennet port 7464 by port - Maybe port forwarded (minimum
 tunnel lifetime 5h31m)
 AddressSent/received packetsLocal/remoteStartup to first send
 Online to first receive
 62.202.36.197:25164 1/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25163 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25165 5/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25168 1/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25167 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25170 2/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25169 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25172 2/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25171 5/ 3 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25173 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25175 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25177 5/ 3 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25147 4/ 3 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25148 5/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25149 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25150 3/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25151 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25152 2/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25153 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25154 2/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25155 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25156 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25157 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25158 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25159 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25160 3/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25161 1/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25162 4/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25198 2/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25197 2/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25196 2/ 4 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25195 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25202 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25201 3/ 7 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25200 3/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25199 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25206 1/ 1 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25205 4/ 3 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25204 4/ 2 REMOTE 3h12m 3h12m 3h12m @
 2h23m ago
 62.202.36.197:25203

Re: [freenet-support] Part 2: Probably a bug: please report: 1 peers forcibly disconnected due to not acknowledging packets.

2009-08-15 Thread Matthew Toseland
On Saturday 08 August 2009 11:07:50 Stephen Mollett wrote:
 On Friday 07 August 2009 23:36:05 Juiceman wrote:
  That's very interesting!  That IP resolves to China, I believe:
 
  Pinging 197.36.202.62.cust.bluewin.ch [62.202.36.197] with 32 bytes of
  data: Request timed out.
 
 ..ch is Switzerland (China is .cn); it looks like a dynamically-allocated DSL 
 address, which raises the question: How does Freenet handle nodes that 
 suddenly change their IP if the ISP doesn't allow them to renew their lease 
 on the same address?

It does its best in difficult circumstances? Mostly it manages, even on 
darknet. You want more detail? If your node is port forwarded/open, and one of 
your peers changes its IP (or port, due to NAT issues), it will reconnect. If 
your peer changes its IP and you change your IP (as happens e.g. when you are 
offline for a while), or if you are not port forwarded, life is more difficult, 
but we try to look up the new address via ARKs, keys inserted with our up to 
date noderef. All this depends on knowing our IP address, so it is necessary to 
find that out either from our peers or from STUN servers or the local router 
via UPnP (which also forwards the ports).


signature.asc
Description: This is a digitally signed message part.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Re: [freenet-support] Part 2: Probably a bug: please report: 1 peers forcibly disconnected due to not acknowledging packets.

2009-08-08 Thread Stephen Mollett
On Friday 07 August 2009 23:36:05 Juiceman wrote:
 That's very interesting!  That IP resolves to China, I believe:

 Pinging 197.36.202.62.cust.bluewin.ch [62.202.36.197] with 32 bytes of
 data: Request timed out.

..ch is Switzerland (China is .cn); it looks like a dynamically-allocated DSL 
address, which raises the question: How does Freenet handle nodes that 
suddenly change their IP if the ISP doesn't allow them to renew their lease 
on the same address?

Stephen

___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Part 2: Probably a bug: please report: 1 peers forcibly disconnected due to not acknowledging packets.

2009-08-07 Thread Juiceman
On Thu, Jul 30, 2009 at 8:12 AM, Toni Bergmantoni.berg...@gmail.com wrote:
 Hi, I got this error again, but this time I got more info about it
 Probably a bug: please report: 1 peers forcibly disconnected due to not
 acknowledging packets.
 1 of your peers are having severe problems (not acknowledging packets even
 after 10 minutes). This is probably due to a bug in the code. Please report
 it to us at the bug tracker at https://bugs.freenetproject.org/ or to the
 support mailing list supp...@freenetproject.org. Please include this message
 and what version of the node you are running. The affected peers (you may
 not want to include this in your bug report if they are darknet peers) are:
     * 165.154.46.119:34072

 Versio info
     * Freenet 0.7.5 Build #1223 build01223-real
     * Freenet-ext Build #26 r23771

 My machine: modern gaming specs win xp pro, direct connection.

 Here's the extra info, it seems that peer is trying to attack my node and
 probably many others. Switching it's port and trying to connect again. Since
 opennet by default won't allow more than 1 connection per IP, I don't see
 the point.. Maybe it's giving me some false info in order to confuse my
 node. Here's what I found at my CONNECTIVITY - stats page. I removed all but
 the 1 attacking ip address so it's clearer to view.


 Packets for UDP Opennet port 7464 by port - Maybe port forwarded (minimum
 tunnel lifetime 5h31m)
 Address    Sent/received packets    Local/remote    Startup to first send
 Online to first receive
 62.202.36.197:25164     1/ 1     REMOTE     3h12m     3h12m     3h12m @
 2h23m ago
 62.202.36.197:25163     4/ 2     REMOTE     3h12m     3h12m     3h12m @
 2h23m ago
*snip*

That's very interesting!  That IP resolves to China, I believe:

Pinging 197.36.202.62.cust.bluewin.ch [62.202.36.197] with 32 bytes of data:
Request timed out.
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe