[tor-dev] Potential regression when binding sockets to interface without default route

[René Mayrhofer]

Am 2016-09-19 um 20:01 schrieb grarpamp:
> On Mon, Sep 19, 2016 at 9:14 AM, René Mayrhofer <rm at ins.jku.at> wrote:
>> Sep 19 11:37:41.000 [warn] I have no descriptor for the router named
>> "ins1" in my declared family; I'll use the nickname as is, but this may
>> confuse clients.
>> Sep 19 11:37:41.000 [warn] I have no descriptor for the router named
>> "ins2" in my declared family; I'll use the nickname as is, but this may
>> confuse clients.
>> Sep 19 11:37:41.000 [notice] Your Tor server's identity key fingerprint
>> is 'ins0 01A9258A46E97FF8B2CAC7910577862C14F2C524'
>> Sep 19 11:38:34.000 [warn] You specified a server "ins1" by name, but
>> the directory authorities do not have any key registered for this
>> nickname -- so it could be used by any server, not just the one you
>> meant. To make sure you get the same server in the future, refer to it
>> by key, as "$CD9FD887A4572D46938640BA65F258851F1E418B".
>> Sep 19 11:38:34.000 [warn] You specified a server "ins2" by name, but
>> the directory authorities do not have any key registered for this
>> nickname -- so it could be used by any server, not just the one you
>> meant. To make sure you get the same server in the future, refer to it
>> by key, as "$7C3AF46F77445A0B1E903A5AF5B730A05F127BFC".
> A side note, unless you have a reason not to, or the other nodes
> are offline, you should fix up the MyFamily lines in the configs of
> your nodes, to at least save noise in your logs.
You're right, should have done that long ago. For the record, those two
fingerprints are Tor exit/relay nodes that we test on small ARM boxes
(Odroid XU3 at the moment) for trying out new configuration and
experimenting e.g. with IPv6. Unfortunately, as nice as it would have
been to run the main relay on a 5W computer, it simply couldn't push the
bandwidth we wanted to provide (and we haven't spent enough time
figuring out the bottlenecks why one ARM core maxes out and the
remaining ones remain at around 20-30%). Nonetheless, since they are all
co-located in the same server closet, traffic should never go through
more than one at any time.

best regards,
Rene


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160919/47b45b3f/attachment.sig>