Opened 12 years ago

Last modified 7 years ago

#529 closed defect (Fixed)

v3 client confused about which servers are named

Reported by: arma Owned by: nickm
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.0.7-alpha
Severity: Keywords:
Cc: arma, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Running r11968 as a client, it complains about things like
Oct 16 01:05:36.303 [warn] You specified a server "DrazziBTorNode" by name, but
this name is not registered, 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 k

ey, as "$F268430A96705AC0BB52117AC5122F4DC934727E".

It turns out this is caused by vidalia doing a getinfo on this nickname.
I caught Tor while Vidalia was asking about Bellum:
#0 router_get_by_nickname (nickname=0x8306672 "Bellum", warn_if_unnamed=1)

at routerlist.c:1783

#1 0x08083c5e in getinfo_helper_dir (control_conn=0x8681e20,

question=0x8306668 "desc/name/Bellum", answer=0xbfc4342c) at control.c:1314

#2 0x08085d1b in handle_getinfo_helper (control_conn=0x8681e20,

question=0x8306668 "desc/name/Bellum", answer=0xbfc4342c) at control.c:1804

#3 0x08085df0 in handle_control_getinfo (conn=0x8681e20, len=19,

body=0x8adda00 "desc/name/Bellum\r\n") at control.c:1829

#4 0x08088670 in connection_control_process_inbuf (conn=0x8681e20)

at control.c:2685

#5 0x0807442e in connection_process_inbuf (conn=0x8681e20, package_partial=1)

at connection.c:2638

#6 0x080725a1 in connection_handle_read (conn=0x8681e20) at connection.c:1813
#7 0x080adfc0 in conn_read_callback (fd=24, event=2, _conn=0x8681e20)

at main.c:470

#8 0xb7ee6c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#9 0xb7ee6f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#10 0xb7ee6dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#11 0x080afe3b in do_main_loop () at main.c:1389
#12 0x080b127d in tor_main (argc=1, argv=0xbfc43804) at main.c:1928
#13 0x080e90e2 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:28

It turns out there was a circuit building at that time:
Oct 16 01:26:41.539 [info] exit (high-uptime) circ (length 3, exit chaoscomputer
club23): $5C854C6CE50727F32E51274B1CF4DF9693A206EA(open) Bellum(open) $4121B07A3
86AA1A8015D618D213B1980BA388487(closed)

Now, clearly some part of Tor thought Bellum was Named, so it used the nickname.
But then the other part of Tor thought it wasn't.

In this case, the cached-consensus file said
r Bellum 7j/MKmnxheiRBy8T7pkIzW7ZvqU 22tvSKhAXrqKWmvs53JdUlWDr70 2007-10-15 22:2
7:52 62.75.223.163 9001 9030
s Fast Guard Named Running Stable V2Dir Valid
v Tor 0.1.2.14

but in my cached-status/* directories, which haven't been updated in a few hours
since I'm allegedly not using them anymore, tor26's networkstatus didn't have
an entry for Bellum -- so according to v2 it wouldn't be considered Named.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (11)

comment:1 Changed 12 years ago by weasel

Tue Oct 16 10:22:24 UTC 2007

weasel@asteria:~$ wget -q -O - http://moria.seul.org:9031/tor/status/authority | grep -A1 -i Bellum
r Bellum 7j/MKmnxheiRBy8T7pkIzW7ZvqU 22tvSKhAXrqKWmvs53JdUlWDr70 2007-10-15 22:27:52 62.75.223.163 9001 9030
s Fast Guard Stable Running V2Dir Valid
weasel@asteria:~$ wget -q -O - http://tor.noreply.org/tor/status/authority | grep -A1 -i Bellum
r Bellum 7j/MKmnxheiRBy8T7pkIzW7ZvqU 22tvSKhAXrqKWmvs53JdUlWDr70 2007-10-15 22:27:52 62.75.223.163 9001 9030
s Fast Guard Named Stable Running V2Dir Valid
weasel@asteria:~$ wget -q http://tor.noreply.org/''tor/status-vote/current/consensus -O - | grep -A1 -i Bellum
r Bellum 7j/MKmnxheiRBy8T7pkIzW7ZvqU 22tvSKhAXrqKWmvs53JdUlWDr70 2007-10-15 22:27:52 62.75.223.163 9001 9030
s Fast Guard Named Running Stable V2Dir Valid

looks like this Bellum is named. Maybe the old v2 status from tor26 didn't know of a Bellum at all?

comment:2 Changed 12 years ago by nickm

So, it looks like the code has a few problems:

1) When we get a new consensus, we update the status of every routerinfo_t that has a status

listed in the consensus. Routers that are not listed stay as before. Probably, that's wrong.

2) We don't update ri->is_named. That's wrong too.

I'm fixing 2, but 1 is unpleasant. My first idea for an obvious fix would be, "If you're not listed
in the consensus, then all of your 'i am a good router' flags (valid, running, named, fast, stable, guard, exit)
get cleared." This would be fine, except for routers that are managed by Tor (like bridge and control)
routers. So how about "if you're a general router and you're not listed in the consensus, all your flags get cleared."

(Mostly, this is not a big deal, since we remove unlisted routers fairly eagerly. But hey.)

comment:3 Changed 12 years ago by nickm

I was wrong about 2: we <i>do</i> update router->is_named.

Also, bug 1 appears (I think) in 0.1.2.x.

comment:4 Changed 12 years ago by nickm

10:25 < weasel> we are keeping routers that are not in a status because we

still use them?

10:26 < nickm> we're keeping them for a few reasons
10:26 < nickm> routers with purpose BRIDGE or CONTROLLER will never appear in a

status, but that's fine.

10:27 < weasel> yes, I'm just wondering about general routers
10:27 < nickm> s/will/will probably/
10:27 < weasel> since those are the only ones we will ever name, or call guard,

or fast, or anything like that

10:27 < nickm> basically, we're keeping them because they might be listed in

the next consensus and dropping them would be dumb.

10:27 < weasel> can we still use them?
10:28 < nickm> we can if their flags aren't all set to 0.
10:28 < weasel> so it would make us look different than somebody who just got

their first view of the network with the current consensus

10:29 < weasel> will clearing all the flags ensure we don't use it for anything?
10:29 < nickm> yes
10:29 < nickm> I believe so....
10:29 < weasel> do we require Valid for middle nodes?
10:29 < nickm> though hm. I suppose if some fool has AllowInvalidNodes set...
10:29 < weasel> that just means we should get rid of AllowInvalidNodes
10:30 < nickm> and hm. By default, we allow invalid nodes for middle and

rendezvous.

10:30 < weasel> ah thanks, was just going to check that
10:30 < weasel> there's little reason for this nowadays
10:30 < weasel> we should change that too
10:30 < weasel> since not having invalid really means "we think you should stay

away from this router for a reason"

10:31 < weasel> s/inv/v/
10:36 < nickm> another possibility is adding an internal flag, is_unlisted.
10:36 < nickm> My current thought is: wait and see what roger says.
10:37 < weasel> yup

comment:5 Changed 12 years ago by arma

A) To solve bug 529, I think clearing all the flags is a safe thing to do. And
it would appear that it will solve this problem?

B) Wrt the bug weasel brings up, about how Valid has shifted its meaning over
the years, I still think we should leave it as-is. This bug has little to do
with 529, since once we remove the Running flag it doesn't matter whether Valid
is set. And if we want the definition of Valid that weasel thinks it is now,
then we should use !reject, not !invalid.

comment:6 Changed 12 years ago by nickm

A) Yes.

B) That's not the bug weasel brings up.

The bug is not routers that are listed but not valid: The bug concerns routers that don't get listed in the
consensus at all. What should we do with them? Right now, we clear all their flags if they're
ROUTER_PURPOSE_GENERAL, but that doesn't categorically stop them from getting used IIUC.

comment:7 Changed 12 years ago by arma

Can you name a place where we use a server that isn't listed as Running in our
routerstatuslist?

comment:8 Changed 12 years ago by nickm

If we request one by ID, we might, under some circumstances, I think. Also, I worry that somewhere in our code
there's a bug that will use such a server.

comment:9 Changed 12 years ago by arma

If we have some behavior in the code that uses a server despite its lack of
a Running flag, chances are good that it would use the server despite its lack
of a Valid flag too. I opened bug 532 to investigate the overall issue, which
I think is separate from 529.

comment:10 Changed 12 years ago by arma

flyspray2trac: bug closed.
Fixed in r11985

comment:11 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.