Re: [freenet-dev] fred:s IP detecting strategy

Nick Tarleton ([EMAIL PROTECTED]) wrote: > But I don't get the problem with invalid IP reporting - I > can't think of any worse consequence than an invalid announcement getting > out. These can be created anyway. The problem is the node never gets any requests, so it doesn't participate in the

Re: [freenet-dev] fred:s IP detecting strategy

On Tuesday 03 June 2003 05:12 pm, Dave Hooper wrote: > True, that is simpler. I've just realised the flaw, however, that both > your and my schemes have: We never actually check that C is using a.b.c.d > to contact A. Which is, after all, the whole point. > > For example, "A->C connect to a.b.c.

Re: [freenet-dev] fred:s IP detecting strategy

> How about this, which is simpler: > A->B what's my ip (same as above) > B->A a.b.c.d (same as above) > A->C connect to a.b.c.d and say 'foo' > C->a.b.c.d: foo > > If A receives 'foo' from C, then a.b.c.d can be assumed to be valid. True, that is simpler. I've just realised the flaw, however, th

Re: [freenet-dev] fred:s IP detecting strategy

>> So: >> A->B what is my IP address >> B->A it is aaa.bbb.ccc.ddd >> A creates a long random number and makes it available at its FNP port as >> something like 'entropy.txt' >> A->C get the entropy.txt from aaa.bbb.ccc.ddd and send me the result >> C->aaa.bbb.ccc.ddd what is your entropy.txt? >> a

Re: [freenet-dev] fred:s IP detecting strategy

On Tuesday 03 June 2003 01:26 pm, Dave Hooper wrote: > So: > A->B what is my IP address > B->A it is aaa.bbb.ccc.ddd > A creates a long random number and makes it available at its FNP port as > something like 'entropy.txt' > A->C get the entropy.txt from aaa.bbb.ccc.ddd and send me the result > C->

Re: [freenet-dev] fred:s IP detecting strategy

> * Node must know its own IP address somehow. (Doesn't always work.) >> >> Greg's Proposal: >> * New node asks two other nodes what its own IP address is. > > Best idea IMHO. More than 2 actually. I think my proposal from quite some time ago was for the node to ask another node (possib

Re: [freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 11:33:14PM +0100, Dave Hooper wrote: > This was discussed before, you can check the devl archives. The > conclusion then seemed to be "it isn't worth the hassle" which I thought > was strange-- the original complaint was by someone (I forget who) whose > external IP changes

Re: [freenet-dev] fred:s IP detecting strategy

On Monday 02 June 2003 06:47 pm, Greg Wooledge wrote: > Current Freenet: > * Node must know its own IP address somehow. (Doesn't always work.) > > Greg's Proposal: > * New node asks two other nodes what its own IP address is. Best idea IMHO. More than 2 actually. > Kjell's Proposal:

Re: [freenet-dev] fred:s IP detecting strategy

Kjell Rune Skaaraas ([EMAIL PROTECTED]) wrote: > Case A: You get a connection from IP 80.23.53.56, > saying "contact me on IP 80.23.53.56, port 2334" > Case B: You get a connection from IP 80.23.53.56, > saying "contact me on my IP, port 2334." Announcements are passed deeper than one hop. My n

Re: [freenet-dev] fred:s IP detecting strategy

> The first node, the one getting the request will know, > and route requests. He can replace the IP in any > broadcasts, though that wouldn't work if the message > is signed, which I suppose it is (haven't read that > part of the code). It is (see my duh-mail) >So I see how estabilishing new > c

Re: [freenet-dev] fred:s IP detecting strategy

Duh. Replace pretty much any reference to 'encrypted noderef file' in my previous mails with 'signed noderef file' and 'encrypting noderef file' with 'signing noderef file'. /N ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/

Re: [freenet-dev] fred:s IP detecting strategy

> So, if that noderef contains an "override" value, to > use the IP it was contacted with instead, somebody > else could send the same packet and invalidate the > noderef. Yup.. Much of freenets routing then relies on these noderefs. The node that owns the public/private key has to generate the no

Re: [freenet-dev] fred:s IP detecting strategy

--- Niklas Bergh <[EMAIL PROTECTED]> skrev: > Sorry for being rude. I have hellish migarine today. > > I will do another try at explaining why a node needs > to know its own IP. > > Consider this.. you request a file from your node. > Your node doesn't have > this file in its cache. In order to

RE: [freenet-dev] fred:s IP detecting strategy

--- Niklas Bergh <[EMAIL PROTECTED]> skrev: > >Oh and I really don't see why it is important for > *my* > >node to know its public IP address. If I manage get > a > >packet back at all, I have already achieved what I > >wanted to do! > > Yes, you as a person has got the webpage or whatever > you

Re: [freenet-dev] fred:s IP detecting strategy

Sorry for being rude. I have hellish migarine today. I will do another try at explaining why a node needs to know its own IP. Consider this.. you request a file from your node. Your node doesn't have this file in its cache. In order to deliver this file to you your node has to fetch it from some

RE: [freenet-dev] fred:s IP detecting strategy

>Oh and I really don't see why it is important for *my* >node to know its public IP address. If I manage get a >packet back at all, I have already achieved what I >wanted to do! Yes, you as a person has got the webpage or whatever you requested of of freenet but that doesn't really help the networ

Re: [freenet-dev] fred:s IP detecting strategy

> Kjell Rune Skaaraas ([EMAIL PROTECTED]) wrote: > > However, rather than defining it myself > > whenever my IP changes, or running some kind of > > dynamic DNS, applications like mIRC do a > server-side > > lookup. How difficult would it be to do the same > for > > Freenet? > --- Greg Wooledge <[

Re: [freenet-dev] fred:s IP detecting strategy

OK, unified format version here then. Btw greg, I haven't managed to apply your routing patch. The problem seems to be related to the file CPAlgoRoutingTable.java.bak that is mentioned on the second line of the patch. /N Index: freenet/node/IPAddressDetector.java ==

[freenet-dev] fred:s IP detecting strategy

OK, unified format version here then. Btw greg, I haven't managed to apply your routing patch. The problem seems to be related to the file CPAlgoRoutingTable.java.bak that is mentioned on the second line of the patch. /N -- next part -- An embedded and charset-unspecified t

Re: [freenet-dev] fred:s IP detecting strategy

Niklas Bergh ([EMAIL PROTECTED]) wrote: > Tell me if there is something wrong with the diff (or the code), it is the > first one I have ever created. Oh, and another thing, I indented some > sections of the code when I happened to edit in that area. I haven't looked at the logic, but I can commen

Re: [freenet-dev] fred:s IP detecting strategy

> What I really meant with my suggestion was that if fred encounters two or > more, accrording to whatever filtering scheme used, valid IP addresses then > why can't it just have a check to see if one of those addresses are the one > currently in use and in that case continue using it. It is simply

[freenet-dev] fred:s IP detecting strategy

Niklas Bergh (niklas.bergh at tific.com) wrote: > Tell me if there is something wrong with the diff (or the code), it is the > first one I have ever created. Oh, and another thing, I indented some > sections of the code when I happened to edit in that area. I haven't looked at the logic, but I ca

[freenet-dev] fred:s IP detecting strategy

> What I really meant with my suggestion was that if fred encounters two or > more, accrording to whatever filtering scheme used, valid IP addresses then > why can't it just have a check to see if one of those addresses are the one > currently in use and in that case continue using it. It is simply

Re: [freenet-dev] fred:s IP detecting strategy

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have no problem with this approach if it can be implemented in a backwards-compatable fashion (which should be straight-forward) - in fact, there was a time when this is what I thought Matthew had implemented for the automatic IP address detection -

Re: [freenet-dev] fred:s IP detecting strategy

This was discussed before, you can check the devl archives. The conclusion then seemed to be "it isn't worth the hassle" which I thought was strange-- the original complaint was by someone (I forget who) whose external IP changes daily, if not more often. I tried to point out that it's more hassle

Re: [freenet-dev] fred:s IP detecting strategy

Kjell Rune Skaaraas ([EMAIL PROTECTED]) wrote: > However, rather than defining it myself > whenever my IP changes, or running some kind of > dynamic DNS, applications like mIRC do a server-side > lookup. How difficult would it be to do the same for > Freenet? mjr and I have told Matthew, more tha

Re: [freenet-dev] fred:s IP detecting strategy

While we're on the topic of IP detecting: I've routed my Freenet node through a NAT (masquerading), so I have an internal LAN address, with an appropriate return port that gets routed back to me. However, rather than defining it myself whenever my IP changes, or running some kind of dynamic DNS, a

Re: [freenet-dev] fred:s IP detecting strategy

>> What I really meant with my suggestion was that if fred encounters two >> or >> more, accrording to whatever filtering scheme used, valid IP addresses >> then >> why can't it just have a check to see if one of those addresses are the >> one >> currently in use and in that case continue using it.

Re: [freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 04:24:35PM +0100, Toad wrote: > On Wed, May 28, 2003 at 11:45:02AM +0200, Frank v Waveren wrote: > > On Wed, May 28, 2003 at 11:30:19AM +0200, Niklas Bergh wrote: > > > >Also, does Fred check for reserved address ranges? It seems this would > > > >be able to rule out most

Re: [freenet-dev] fred:s IP detecting strategy

> IP) of which of the valid addresses to use. > >0.0.0.0 IS NOT A VALID IP ADDRESS. Well, that I agree with, but where did that address come from? In my problem situation the address was 5.0.1.0 00- was the mac address of the same interface. /N ___

Re: [freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 07:20:11PM +0200, Niklas Bergh wrote: > >> Would it be too much to ask that fred, when it scans through all of the > >> computers available interfaces, at least tries to stay with the interface > >> that can be found in the 'node' file if it still is present in the system >

Re: [freenet-dev] fred:s IP detecting strategy

>> Would it be too much to ask that fred, when it scans through all of the >> computers available interfaces, at least tries to stay with the interface >> that can be found in the 'node' file if it still is present in the system >> (even if a new interface or two have appeared). > >Fred iterates th

Re: [freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 11:45:02AM +0200, Frank v Waveren wrote: > On Wed, May 28, 2003 at 11:30:19AM +0200, Niklas Bergh wrote: > > >Also, does Fred check for reserved address ranges? It seems this would > > >be able to rule out most publicly inaccessible interfaces. > > That I know it does :) >

Re: [freenet-dev] fred:s IP detecting strategy

On Tue, May 27, 2003 at 10:32:25PM +0200, Niklas Bergh wrote: > This is from the fascinating world of Microsoft.. > > I was very surprised to notice that after the last restart fred was bound to > this to me previously unknown interface on my computer: > > Ethernet adapter Local Area Connection 3

Re: [freenet-dev] fred:s IP detecting strategy

On Tue, May 27, 2003 at 03:39:44PM -0500, [EMAIL PROTECTED] wrote: > Also, does Fred check for reserved address ranges? It seems this would > be able to rule out most publicly inaccessible interfaces. Yes. tcpTransport.Address(). 0.*, 192.168.*, 10.* etc will all be rejected as invalid addresses

[freenet-dev] fred:s IP detecting strategy

While we're on the topic of IP detecting: I've routed my Freenet node through a NAT (masquerading), so I have an internal LAN address, with an appropriate return port that gets routed back to me. However, rather than defining it myself whenever my IP changes, or running some kind of dynamic DNS, a

[freenet-dev] fred:s IP detecting strategy

This was discussed before, you can check the devl archives. The conclusion then seemed to be "it isn't worth the hassle" which I thought was strange-- the original complaint was by someone (I forget who) whose external IP changes daily, if not more often. I tried to point out that it's more hassle

[freenet-dev] fred:s IP detecting strategy

>> What I really meant with my suggestion was that if fred encounters two >> or >> more, accrording to whatever filtering scheme used, valid IP addresses >> then >> why can't it just have a check to see if one of those addresses are the >> one >> currently in use and in that case continue using it.

[freenet-dev] fred:s IP detecting strategy

> IP) of which of the valid addresses to use. > >0.0.0.0 IS NOT A VALID IP ADDRESS. Well, that I agree with, but where did that address come from? In my problem situation the address was 5.0.1.0 00- was the mac address of the same interface. /N ___

Re: [freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 11:30:19AM +0200, Niklas Bergh wrote: > >Also, does Fred check for reserved address ranges? It seems this would > >be able to rule out most publicly inaccessible interfaces. > That I know it does :) Not all of them apparantly, 5.0.0.0/8 is marked IANA RESERVED. -- Frank

Re: [freenet-dev] fred:s IP detecting strategy

From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 27 May 2003 15:39:44 -0500 >Also, does Fred check for reserved address ranges? It seems this would >be able to rule out most publicly inaccessible interfaces. > That I know it does :) /N ___

[freenet-dev] fred:s IP detecting strategy

>> Would it be too much to ask that fred, when it scans through all of the >> computers available interfaces, at least tries to stay with the interface >> that can be found in the 'node' file if it still is present in the system >> (even if a new interface or two have appeared). > >Fred iterates th

[freenet-dev] fred:s IP detecting strategy

Kjell Rune Skaaraas (skaaraas at yahoo.no) wrote: > However, rather than defining it myself > whenever my IP changes, or running some kind of > dynamic DNS, applications like mIRC do a server-side > lookup. How difficult would it be to do the same for > Freenet? mjr and I have told Matthew, more

[freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 07:20:11PM +0200, Niklas Bergh wrote: > >> Would it be too much to ask that fred, when it scans through all of the > >> computers available interfaces, at least tries to stay with the interface > >> that can be found in the 'node' file if it still is present in the system >

[freenet-dev] fred:s IP detecting strategy

An embedded and charset-unspecified text was scrubbed... Name: msg.pgp URL:

[freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 11:45:02AM +0200, Frank v Waveren wrote: > On Wed, May 28, 2003 at 11:30:19AM +0200, Niklas Bergh wrote: > > >Also, does Fred check for reserved address ranges? It seems this would > > >be able to rule out most publicly inaccessible interfaces. > > That I know it does :) >

[freenet-dev] fred:s IP detecting strategy

On Tue, May 27, 2003 at 10:32:25PM +0200, Niklas Bergh wrote: > This is from the fascinating world of Microsoft.. > > I was very surprised to notice that after the last restart fred was bound to > this to me previously unknown interface on my computer: > > Ethernet adapter Local Area Connection 3

[freenet-dev] fred:s IP detecting strategy

On Tue, May 27, 2003 at 03:39:44PM -0500, scgmille at freenetproject.org wrote: > Also, does Fred check for reserved address ranges? It seems this would > be able to rule out most publicly inaccessible interfaces. Yes. tcpTransport.Address(). 0.*, 192.168.*, 10.* etc will all be rejected as inva

[freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 04:24:35PM +0100, Toad wrote: > On Wed, May 28, 2003 at 11:45:02AM +0200, Frank v Waveren wrote: > > On Wed, May 28, 2003 at 11:30:19AM +0200, Niklas Bergh wrote: > > > >Also, does Fred check for reserved address ranges? It seems this would > > > >be able to rule out most

[freenet-dev] fred:s IP detecting strategy

On Wed, May 28, 2003 at 11:30:19AM +0200, Niklas Bergh wrote: > >Also, does Fred check for reserved address ranges? It seems this would > >be able to rule out most publicly inaccessible interfaces. > That I know it does :) Not all of them apparantly, 5.0.0.0/8 is marked IANA RESERVED. -- Frank

[freenet-dev] fred:s IP detecting strategy

From: scgmi...@freenetproject.org Reply-To: devl at freenetproject.org Date: Tue, 27 May 2003 15:39:44 -0500 >Also, does Fred check for reserved address ranges? It seems this would >be able to rule out most publicly inaccessible interfaces. > That I know it does :) /N

[freenet-dev] fred:s IP detecting strategy

This is from the fascinating world of Microsoft.. I was very surprised to notice that after the last restart fred was bound to this to me previously unknown interface on my computer: Ethernet adapter Local Area Connection 3: Connection-specific DNS Suffix . : Description . . . .

[freenet-dev] fred:s IP detecting strategy

Also, does Fred check for reserved address ranges? It seems this would be able to rule out most publicly inaccessible interfaces. Scott On Tue, May 27, 2003 at 10:32:25PM +0200, Niklas Bergh wrote: > This is from the fascinating world of Microsoft.. > > I was very surprised to notice t

Re: [freenet-dev] fred:s IP detecting strategy

Also, does Fred check for reserved address ranges? It seems this would be able to rule out most publicly inaccessible interfaces. Scott On Tue, May 27, 2003 at 10:32:25PM +0200, Niklas Bergh wrote: > This is from the fascinating world of Microsoft.. > > I was very surprised to notice t

[freenet-dev] fred:s IP detecting strategy

This is from the fascinating world of Microsoft.. I was very surprised to notice that after the last restart fred was bound to this to me previously unknown interface on my computer: Ethernet adapter Local Area Connection 3: Connection-specific DNS Suffix . : Description . . . .