Oskar Sandberg wrote:
>
> The problem with all of these approaches is that it is very hard to tell
> when it is OK for there to be private network addresses and when it is
> not. It is basically either looking at the Interfaces available and
> making a guess, or asking the user.
I brought up a related situation a couple of months ago when I was
setting up a Freenet node behind a firewall. A short recap:
I have a firewall that's has the external IP that other Freenet nodes
should be contacting to coumminicate with the node I'm running.
The firewall forwards connections to the "Freenet" port to the internal
machine.
The internal machine handles all the actual Freenet stuff.
The problem came about in that the real Freenet node would advertise
itself as the non-routable address of the actual machine. Setting the
"nodeAddress" parameter to the Firewall external IP had the unexpected
side-effect of causing the Freenet node to try to contact the Firewall's
external IP (which doesn't work) for some kind of traffic or other (I
don't remember what exactly and I believe it was tagged as a real bug in
the Freenet code someplace).
The solution for me was to do a higged-up split-DNS approach where I put
a hostname into my DNS that, from the "Rest of the internet" resolved to
the Firewall IP, but behind the firewall, resolved to the real Freenet
node. That way people contact the correct IP from the rest of the
internet, but the Freenet node itself just tries to talk to itself.
So just setting "nodeAddress" didn't necessarily help in my case prevent
my Freenet node from advertising itself as a 192.168. address because
setting it made it Just Not Work. Making it work relied on my ability
to manage my own DNS effectively.
There *are* people (at least one :) running full Freenet nodes from
behind a firewall who really want to be able to run a full node on a
non-routable IP and still be an effective member of the Freenet network.
So please take that into consideration whenever you figure out what
you're going to do about non-routable addresses.
> The former isn't foolproof and can't be done in java AFAIK, the latter
> is annoying and will confuse users.
>
> I would suggest:
>
> 4) Change the protocol so that nodes inserting data don't point
> references at themselves, thereby avoiding the issue...
>
> On Fri, Jun 29, 2001 at 05:03:46PM -0700, Mr.Bad wrote:
> > >>>>> "GJ" == Gianni Johansson <[EMAIL PROTECTED]> writes:
> >
> > GJ> I disagree. Truly ridiculous addresses shouldn't make it into
> > GJ> the data store (or whatever the 0.4 routing mechanism's analog
> > GJ> is) in the first place.
> >
> > OK, well, I can think of a few ways to fix this:
> >
> > 1) Change tcpAddress so that it throws an exception if a private
> > address is used. (This would prevent using a private network and a
> > "gateway", however).
> >
> > 2) Change the code in StoreData so that it does a validity check on an
> > address before saving it to the datastore. If the address is bad,
> > it changes the address for use downstream to its own, and it stores
> > a null reference.
> >
> > 3) Change the code in Node so that if the address it's using isn't
> > valid, sets itself to transient and continues on its way.
> >
> > Actually, probably a combo of 2) and 3) is the best thing.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/ http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
