17:01:44 <isabela> #startmeeting network team meeting
17:01:44 <MeetBot> Meeting started Mon Apr 17 17:01:44 2017 UTC.  The chair is isabela. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:59 <isabela> here is a pad for updates
17:02:01 <isabela> https://pad.riseup.net/p/v23jHPhQjEP3
17:08:18 <armadev> i am catching up on all my things, then i'll mess with isa's google doc for catalyst. i'll also be around if anybody needs anything from me here.
17:09:15 <pastly> armadev: I would highly value your input wrt my question in the pad <3
17:09:23 <ahf> don't think i've ever been on an etherpad with so many people doing updates at the same time :o
17:10:11 <isabela> asn: ping
17:10:12 <isabela> dgoulet: ping
17:11:18 <isabela> i added a discussion point at the top - please add anything you would like to discussion if you have a topic
17:12:58 <ahf> pastly: is http://www.robgjansen.com/publications/kist-sec2014.pdf the KIST stuff?
17:13:10 <armadev> yes, that is the main usenix security paper
17:13:18 <pastly> Yes I'm implementing it now
17:13:24 <ahf> sweet
17:13:30 <pastly> With hopes of getting it merged for real this time.
17:13:39 <armadev> this time for sure! :)
17:14:27 <armadev> ahf: re the consdiff stuff, be sure to notice the tickets sebastian has been making
17:14:35 <ahf> are we done with the pad now?
17:14:39 <ahf> armadev: yep!
17:14:45 <isabela> i think so
17:15:00 <isabela> i dont see the other folks - but i will email this url to the list in case folks want to add their udpate later
17:15:22 <ahf> yep, last week nick collected from those of us who didn't attend as well and merged it in
17:15:34 <isabela> nice
17:15:38 <isabela> ok
17:15:53 <isabela> am i the only one who has a discussion point? :)
17:16:04 <isis> pastly: oh nice, you're implementing KIST :D
17:16:40 <armadev> isis: is your design write-up published anywhere? or rather, made public anywhere?
17:16:42 <pastly> isabela: I just would like a question answered before the meeting is over :) or a promise to talk with arma afterwards
17:17:15 <armadev> pastly: is that the consensus param thing? that's a great question for the whole network team, not just me :)
17:17:42 <pastly> yes
17:19:06 * armadev added it to isa's discussion topic list
17:19:20 <isabela> does anyone know the answer?
17:19:28 <isabela> we can discuss this first
17:19:30 * ahf doesn't
17:19:33 <isabela> i just have no idea :)
17:19:49 <armadev> is there any harm in each relay doing the kist thing, whenever it updates?
17:20:01 <armadev> and the consensus param would be to let us make the relays back out quickly if it turns out to just be broken?
17:20:11 <pastly> None that we've come up with.
17:20:21 <pastly> Other than "oh sh*t we need to disable this NOW"
17:20:56 <armadev> i guess it is possible that some network effects would only show up once many relays had updated
17:21:10 <pastly> I suggest we have the flag be "auto" by default and the consesnsus param be 1, for enable.
17:21:21 <armadev> if it's easy to do in the code, it can't hurt to have the consensus param
17:21:27 <pastly> Kist will work best when everyone is running it, of course.
17:22:07 <armadev> sounds plausible! one goal would be to pick the parameter logic so that relays decide to run kist if the consensus says nothing
17:22:18 <armadev> that way when it's all deployed and we're happy, we can just take out that logic and change nothing else
17:22:37 <isis> i don't want to speak for nickm, but i think he generally wants consensus parameters for new features, just in case something goes wrong
17:23:15 <ahf> i also had the impression that they are "cheap" to add. we added them for the recent onion key rotation time code as well
17:23:23 <pastly> armadev: Paramter logic == dfeault to auto, and auto says behave like the consensus says?
17:24:00 <armadev> pastly: "and if the consensus says nothing, the default default is to do kist"
17:24:49 <pastly> ah. or maaaaaybe the more conservative "do vanilla." But that discussion can be put off a bit longer I think.
17:24:56 <armadev> ok
17:25:13 <armadev> it depends if you want to prepare for success or for failure
17:25:22 <isis> yeah, i was about to say looking at the onion-key-rotation-days is probably a good example of how to do it
17:25:57 <pastly> isis: tyvm. I needed a starting point
17:26:38 <isis> np!
17:27:08 <pastly> I will plan on added a consensus param. /me is satisfied if no more input right now
17:27:31 <isabela> cool!
17:27:43 <isabela> if ppl are good, we can move to the 2nd discussion point
17:28:41 <isabela> i will send an email to the list as well - but wanted to give this udpate here at the meeting too
17:29:24 <ahf> on the roadmap ?
17:29:27 <isabela> I plan on working with all vegas teams to organize roadmaps for each team
17:29:47 <isabela> the goal here is to help everyone know how each teams are planning the work, when something will get done etc
17:30:07 <isabela> but I also want each team to identify and list dependencies their work has on other teams
17:30:12 <armadev> isabela, fyi above asn said "<asn> it's unclear if i will be around. this new 20:00 time is not good for me." so maybe he is expecting a meeting at 20:00
17:30:31 <ahf> it's 20 at his time
17:30:35 <ahf> so it's 20:30 now
17:30:43 <armadev> ok then
17:30:47 <armadev> carry on :)
17:31:14 <isabela> the goal with that is to make sure folks are aware that other teams need their help with something and better coordinate it
17:31:35 <isabela> armadev: thanks
17:31:52 <isabela> i asked nickm to start a draft
17:31:54 <isabela> https://storm.torproject.org/shared/wsv17rnSP63VXu8GaAoZm2ykKbfQiz5TzZpalp1is_R
17:32:26 <isabela> is missing onion services and bridges and other stuff people are working on
17:32:43 <isis> isabela: is the idea to have a milestoning meeting with everyone at some point?
17:33:00 <isabela> isis: everyone 'vegas teams' or ?
17:33:10 <isis> or should each of us just add our stuff and when we think it gets done?
17:33:21 <ahf> isis: is there any news on the mobile proposal? i might be asking too often about that, but brad recently informed me that i should ensure that ~25% of my time is spend on that (over the entire year)
17:33:27 <isis> err, sorry, by "everyone" i meant "everyone on the network team"
17:33:28 <ahf> argh, sorry
17:33:30 <ahf> to isabela
17:33:41 <isis> lol, no worries
17:33:52 <ahf> should learn about this tab completion one day
17:34:14 <isabela> for now the goal is to have the roadmap completed and then identify dependencies we might have with other teams (if thre is none great! - also it can be dependencies you might have on other network team ppl)
17:34:47 <isabela> ahf: we sent then an updated version of the full proposal addressing their feedback and havent heard back yet
17:34:52 <ahf> ack, thanks
17:35:00 <isis> isabela: okay, makes sense
17:35:26 <isabela> then once that is done we will have to talk with those teams or ppl if they can do the work we depend on them to do
17:36:05 <isabela> isis: for instance, TBB has a deliverable that is based on the work you are doing for OTF now
17:36:28 <isabela> so they depend on it and on ux team as well to do that work
17:36:35 <isis> isabela: is it helpful if i add the stuff that nick and i planned for me to work on at some point?  (after this week, since i'm busy finishing the OTF contract this week)
17:36:51 <isabela> isis: super useful!
17:37:28 <isis> okay, will do next monday
17:37:34 <isabela> tx
17:37:53 <isabela> alright - let me know if you have questions on this - like i said i will email the list too
17:38:03 <isabela> but i just wanted to give the heads up at this meeting
17:39:07 <isabela> anything else folks?
17:39:38 <armadev> i think i should thumb-wrestle asn over the "impact" column in catalyst's spreadsheet
17:39:50 <armadev> that will be easier when he's online
17:40:27 <catalyst> does anyone disagree with any of asn's impact ratings?
17:40:33 <armadev> i do!
17:40:45 <armadev> maybe i should make a new column
17:41:08 <isabela> go for it!
17:41:13 * armadev does so
17:44:04 <armadev> catalyst: imo one of the most useful tasks would be the first one. it's also quite open-ended. i appreciate how somebody guessed "1-3 weeks" for it, but i think it could easily be bigger than that.
17:44:44 <armadev> the task in a nutshell is to teach tor how to guess when bootstrapping isn't going to work, and report that via controller events and the like
17:44:56 <catalyst> it would be interesting to see if it's feasible to implement incrementally
17:45:09 <armadev> ooni wants it because right now they try using tor from all over, and all they get is "yes" or "i'm not sure" as answers
17:45:21 <armadev> tor browser wants it because right now the UX of tor browser is awful when you're in a censored place
17:45:42 <armadev> it also ties into the mobile thing that ahf described, since e.g. turkey is almost entirely on mobile devices
17:46:05 <catalyst> i've found Tor Browser UX to be awful when merely on a slow/lossy connection
17:46:21 <isabela> this might be a dependency on network team
17:46:27 <armadev> one area of complexity is that if you're using e.g. obfs4, then we want to know enough about obfs4 to be able to report usefully.
17:46:35 <isabela> from tor browser launcher deliverable
17:46:46 <armadev> e.g. if obfs4 tries to make a handshake and it can't, it needs to tell tor / tor needs to discover it somehow
17:47:17 <armadev> isabela: yes, the network team needs to do this thing in tor, and tor browser can't finish their part until then
17:47:28 <isis> that would be interesting data to know if obfs4 handshakes aren't completing
17:47:31 <armadev> (ooni is waiting on it too, but ooni is more patient)
17:48:07 <armadev> (but i want ooni to have it, because i want the reachability tests of tor around the world to be more useful)
17:48:15 <isabela> is my new mantra 'dependencies, dependencies, dependencies'
17:48:22 * isis is slightly confused because they don't see any doc with "impact" on it
17:48:22 <catalyst> can the obfs4 implementation easily make this intermediate establishment state visible?
17:48:36 <isis> but also the pad stopped loading for me, so
17:48:51 <isabela> ha
17:48:53 <isabela> sorry isis
17:49:04 <isabela> https://docs.google.com/spreadsheets/d/1Xb1mncS2hX9U9EwlHOBf8ESfYw9J8HepFHJIyLMvfgw/edit#gid=0
17:49:08 <isabela> is this spreadsheet
17:49:12 <armadev> catalyst: i'm not sure. probably it depends on your definition of easily. and how much you enjoy go.
17:49:20 <isis> isabela: lol don't do a balmer
17:49:48 <catalyst> i know basically nothing about go (the language) so far
17:49:53 <armadev> catalyst: step one is to explore several PTs, especially quite different ones, like meek and snowflake and obfs4, and see if there's a pattern on how they might notice problems and how they might report them
17:50:28 <armadev> imo isabela can be a balmer if she wants. we're open here.
17:51:15 <isabela> i dont really get it
17:51:18 <armadev> catalyst: but before getting distracted by the PT side, there's vanilla bootstrapping. right now tor keeps trying each step over and over, beating its head against whatever isn't working
17:51:35 <armadev> isabela: somewhere on youtube is a video of steve balmer chanting 'developers developers developers'.
17:52:14 <isis> isabela: oh sorry, i just meant that microsoft dude, steve ballmer, who freaked out on stage yelling "developers! developers! developers!"
17:52:31 <armadev> catalyst: we have some quite simple rules like "for the first nine tls failures, don't worry about it. on the tenth, issue a warning event but keep trying"
17:52:32 <isabela> hehe
17:52:36 <Phoul> https://www.youtube.com/watch?v=KMU0tzLwhbE
17:52:38 <Phoul> Enjoy
17:52:43 <isabela> oh boy
17:52:45 <isabela> hehehe
17:52:48 <ahf> :-D
17:52:49 <isis> lol
17:53:05 <Phoul> I cant find the original, but this isnt bad. lol.
17:53:32 <armadev> catalyst: it's actually not clear how tor ought to behave there. i mean, there are a bunch of relays to try. maybe the blocking is that only port 9001 works, and 443 doesn't, and the first 10 relays we tried were on 443.
17:54:03 <catalyst> huh. how does tor give this feedback? logs? control port?
17:54:05 <armadev> catalyst: so backing up even further, having a map of tor's bootstrap process, and what can go wrong at each step, and how we can detect it, and what it means (what we should tell the controller)...
17:54:11 <isabela> side note folks - is 6 min till tor browser meeting
17:54:17 <isabela> maybe i should quit the bot
17:54:32 <GeKo> isabela: no meeting today, carry on
17:54:37 <isabela> aha!
17:54:39 <isabela> thanks :)
17:54:55 <GeKo> you should read tbb-dev more often ;)
17:54:56 <armadev> catalyst: yes, both.https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n3149
17:54:57 * isis is now confused whether "impact" means "amount of total user happiness increase" or "priority"
17:55:05 * GeKo shuts up again
17:55:12 <isabela> GeKo: haha
17:55:24 <isis> like something can be "urgent, TBB needs this now" but also relatively small impact otherwise
17:56:27 <isabela> hmm
17:56:35 <isabela> i was thinking of both actually
17:56:40 <armadev> catalyst: that url describes a somewhat-adequate map of tor's bootstrapping phases, when not using a PT. i wrote it back in tor's early life. we managed to hack in the scenario where you're using a bridge. nobody has really thought through how it ought to change in the PT case.
17:58:52 <isabela> isis: impact == demand , it can be demand for a feature or for user experience or for better security
17:59:18 <isis> isabela: okay, that makes more sense! thanks!
17:59:26 <armadev> catalyst: here is a related topic, which isn't the same but might be worth keeping in mind: let's say you're in turkey right now, and tor doesn't work for you. how can we improve tor so it gives you the best possible hints about what is going wrong?
17:59:39 <isabela> isis: np
18:00:09 <catalyst> armadev: doesn't that depend a lot on the skills and background of "you"?
18:00:36 <armadev> maybe. pick any 'you' to start.
18:00:58 <armadev> right now our answer is "the progress bar never progresses".
18:01:02 <armadev> so much room for improvement! :)
18:01:18 <catalyst> yeah i guess giving more frequent feedback to avoid frustrating users is generally good no matter what their skills
18:01:50 <armadev> "tor can't bootstrap. please send this cryptic message to the tor people." would still be a great improvement.
18:02:12 <hellais> yes I can confirm that it would be great if we had something better than just waiting for 100% bootstrap of tor to test reachability of it.
18:02:22 <Samdney> armadev: would this be really helpful in every case?
18:02:24 <catalyst> are there useful UX guidelines for how frequently progress should be reported by a program to avoid user frustration?
18:02:27 <isabela> ux has some changes to better communicate that
18:02:39 <isabela> is part of the tor launcher ux work tor browser has as a deliverable
18:03:05 <armadev> i bet linda has thoughts on the ux side of that too
18:03:21 <hellais> Another thing worth consider (not sure if it fits at all in the scope of work you are describing) would be the ability to in some way link Tor from a C++ library so we can instrument it properly. This is currently something that is blocking on being bale to ship a "good" tor test on mobile platforms.
18:03:38 <armadev> catalyst: that said, one case where *we* are the users is ooni. if arturo gets some nice person to run an ooni test from turkey, it will do whatever the test does, and the answer will show up in an ooni report that we look at.
18:03:40 <catalyst> part of the challenge is how long each "phase" takes partly depends on environmental factors that may need to be measured
18:03:40 <isabela> which is based on linda's research -> https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016
18:05:02 <armadev> is it possible to separate the ux question from the underlying bootstrap question?
18:05:14 <armadev> that is, map out how bootstrapping ought to work, how tor can notice what's gone wrong, etc,
18:05:31 <armadev> then the question of how to show it to a user comes next, since the answer for ooni is way different than the answer for tor browser?
18:05:46 <isabela> totally
18:05:55 <armadev> i don't want to get you bogged down in the "how should tor browser keep the user happy" question,
18:06:02 <armadev> since that can be tor browser's problem
18:06:10 <isabela> sure
18:06:16 <Samdney> +1
18:06:17 <armadev> tor's goal is to keep tor browser informed of what it knows
18:06:26 <isabela> unless if the way tor browser wants to solve it depends on a modification at core tor
18:06:30 <hellais> Still on the bootstrapping question, another big limitation to our approach at measuring Tor is that we currently just wait 300 seconds for Tor to bootstrap and if Tor doesn't bootstrap by that time we consider it to not work.
18:06:42 <catalyst> armadev: which IMHO shoud probably include timing estimates for completion if possible
18:06:58 <armadev> hellais: can that 300 seconds be a function of how the test is going? like, if tor sent an "i need more time" message, it gets more time?
18:07:16 <hellais> The 300 second is a magic number that was determined fairly arbitrarily since it can be much more or much less depending on the performance of the network
18:07:46 <armadev> catalyst: i think the timing estimates will vary wildly by internet connection
18:07:55 <hellais> armadev: yeah sure, we can do whatever we want since we control tor. We can even ask for things on the control port if that is needed
18:07:56 <armadev> some tors probably really do take ten minutes to bootstrap
18:08:20 <armadev> (and those tors probably mostly fail right now, due to bad constants inside tor.)
18:08:55 <hellais> The reason why we didn't use the control port is that it is openned by Tor only at some point during the bootstrap and when I looked into it, there didn't seem an obvious point during bootstrap where it would for sure be open
18:08:58 <catalyst> does tor currently do anything to characterize or measure its network connection in general terms?
18:09:24 <asn> kinda here but lots of people around
18:09:31 * asn looking at the spreadsheet
18:09:47 <asn> agree with arma's comments
18:09:52 <armadev> catalyst: there is the 'circuit build timeout'. tor tracks how long circuits take to build, and chooses its own timeout for abandoning circuits, as a function of how previous ones have gone.
18:10:02 <asn> good to see hellais here :)
18:11:33 <armadev> (but that is post bootstrap)
18:11:33 <catalyst> armadev: but nothing like trying to ask the kernel about its TCP state variables for various sockets?
18:11:42 <armadev> correct
18:11:50 <armadev> though, now that you mention it, that's one of the main tricks that kist uses.
18:12:00 <asn> hellais: hmm wrt the "ooni does not know when control port opens" problem, what could tor do to help?
18:12:11 <armadev> (kist is the thing that pastly is implementing)
18:12:18 <asn> hellais: you might be able to hack it by monitoring the tor logs
18:12:45 <catalyst> yeah i skimmed the first few pages of the KIST paper. not sure whether the intent is to deploy it on relays or on clients (or whether it's even applicable to clients?)
18:12:54 <armadev> asn, hellais: tor browser has this same problem, where tor browser loses some of tor's startup messages because tor says stuff before tor browser gets the controller connection up.
18:13:05 <armadev> catalyst: the kist plan is for relays.
18:13:07 <asn> ah there is a ticket about this
18:13:45 <armadev> hellais: but yes, you have a huge advantage over tor browser, because you can look at tor's stdout. tor browser doesn't have a way to see tor's stdout.
18:16:12 <armadev> catalyst: maybe a good place to start is to see control_event_bootstrap() in src/or/control.c (plus the stuff around it),
18:16:17 <armadev> and then look at the various parts of tor's code that call it
18:17:14 <pastly> catalyst: relays. kist's goal is to prioritize web-like traffic. It does so at the relays by holding bytes in the Tor process for as long as possible such that the kernel's buffers will always be emptyish and Tor can be reasonably certain that bytes are leaving with the correct priority
18:17:45 <armadev> there is also control_event_bootstrap_problem()
18:18:11 <armadev> i am a little bit nervous that this project could balloon out of scope for an intro-to-tor, because it touches on many pieces of tor's code.
18:18:18 <armadev> but it touches on them lightly, so maybe it is a good way to get a tour.
18:18:54 <catalyst> i found the baseNN stuff already touched a decent variety of stuff
18:19:40 <hellais> asn: well the best thing would be if the tor control port were open from the beginning, but supported some EVENT that you can listen on that tells you when it's ready to accept commands if the issue is that it can't accept commands before a certain point.
18:20:19 <hellais> asn: alternatively, some particular log line that is easy to look for would also work I guess.
18:20:32 <armadev> hm. i think you can start sending commands to the controller as early as you want.
18:20:48 <armadev> tor will handle them as it sees them
18:21:01 <armadev> did you need something more than that? if so what's missing?
18:21:03 <catalyst> re missing some messages at startup, maybe there could be a command line option for tor to wait for a special command on the control port before doing anything that an app (e.g., Tor Browser) cares to know about?
18:22:00 <armadev> catalyst: that a good idea. i think we hadn't had it before in fact. the previous plan had been some yucky "tor memorizes its log messages and has a way to send them out, but then how does the controller de-duplicate"
18:22:43 <armadev> but the answer would be a controller command which is an atomic "send me what you've queued, and also stop queueing"
18:23:03 * armadev goes to hunt down the ticket #
18:23:13 * asn has been hunting but still hasnt found
18:23:28 <armadev> the race is on!
18:24:05 <isabela> the drl proposal has a deliverable relate to this /me thinks
18:24:19 <catalyst> drl?
18:24:21 <isabela> i need to double check if it was cut from the last review
18:24:30 <isabela> catalyst: is still under approval process
18:25:06 <asn> https://trac.torproject.org/projects/tor/ticket/10059
18:25:11 <asn> \o/
18:25:19 * armadev concedes
18:25:46 <ahf> i need to switch location very soon, i'll catch up on anything i miss when i'm landing in the flat
18:26:17 <armadev> catalyst: drl is the US State Dept's department of democracy rights and labor. they are one of our funders. when ahf mentioned the "mobile" proposal, it is a proposal to drl.
18:26:21 <hellais> armadev: It seems like my tor (0.2.8) will now open the control port as soon as I start it. Maybe the behavior has changed, then scratch my comments regarding the control port.
18:27:03 <armadev> hellais: there is still a race where you start it and make your connection and maybe your tcp socket is faster than that's read-torrc-from-file, process it, open socket
18:27:11 <armadev> s/that's/tor's/
18:27:51 <armadev> hellais: something you might find useful, but hopefully is not needed, is tor's ControlPortWriteToFile option.
18:27:56 <hellais> right, but I guess that is unavoidable
18:28:01 <isabela> fyi 1hr 30min of meeting
18:28:05 <catalyst> oh that gets a bit tricky doesn't it? torrc can specify the control port, and one possible error that an application might care about is torrc being unreadable
18:28:09 <armadev> using that option would let you survive the race, if it's actually a problem.
18:28:21 <catalyst> are we getting into enough detail that we should stop the meeting log?
18:28:31 <armadev> very likely :)
18:28:46 <isabela> (could stop the bot and folks can continue discussion, unless you want this logged by the bot)
18:30:23 <armadev> hellais: the model there would be "you delete the file to make sure it's not there, you start tor with the ControlPortWriteToFile option, then you keep looking for the file until it's there, and when it is you know tor is ready."
18:30:37 <armadev> hellais: we made that option for the "controlport auto" case, where you don't even know where to connect
18:30:53 <armadev> but you could use it for this too. though, you could also just keep trying to connect to the control port until it works.
18:31:05 <hellais> we actually use txtorcon to pilot tor. I found this in the comment for the function we use that gives clues as to some of the possible issues: https://github.com/meejah/txtorcon/blob/master/txtorcon/controller.py#L131
18:31:51 <armadev> sounds like we should tell meejah about ControlPortWriteToFile ?
18:32:39 <catalyst> ControlPortWriteToFile sounds unfriendly if polling for file existence is expensive
18:32:55 <armadev> especially if polling for an open socket is not so bad
18:33:37 <hellais> maybe, though I am not sure that would be a workaround to that hack. I mean if you can poll for the file you can poll for the socket too
18:34:37 <catalyst> some OSes have filesystem event notification APIs right? but i don't know how universal they are
18:36:03 <hellais> yeah that's true, but I think that is only for macOS and linux. The API is also different between macOS and linux
18:37:27 <hellais> hum, there is actually also something on windows. Could be an option. Though if tor were to say in a line "hey, the control port is now ready" it would be for sure easier.
18:38:17 <asn> isnt there a line?
18:38:22 <asn> sec
18:38:37 <asn> Feb 14 14:21:46.828 [notice] Opening Control listener on /home/f/tor-browser_en-US/Browser/TorBrowser/Data/Tor/control.socket
18:38:41 <catalyst> is inability of Tor Browser to look at tor's stdout a hard constraint? does it use ControlPort auto?
18:38:44 <asn> this one?
18:39:22 <hellais> asn: hum, ok. That is good to know. I will file a ticket on txtorcon to remember to check for this.
18:39:25 <armadev> catalyst: tor browser includes a firefox extension called tor launcher, which includes a little binary blob called tor. there's a hack where firefox extensions can run arbitrary binaries, but the hack does not provide a way to see the binary's stdout.
18:40:12 <asn> hellais: and there is also this one: Apr 16 18:39:46.600 [notice] Opening Control listener on 127.0.0.1:9051
18:40:16 <atagar> I'm not sure what the txtocon comment is about. Stem reads the bootstrap messages and I've never had an issue with using the control port once it reports 100% (earlier works too - the tests complete at something lower).
18:40:18 <armadev> asn: have we checked that tor only says that line after its controlcookie, etc are written?
18:40:20 <atagar> https://gitweb.torproject.org/stem.git/tree/stem/process.py#n60
18:40:29 <asn> armadev: :D
18:40:42 <asn> armadev: i have not checked
18:41:39 <atagar> Actually, evidently stem's tests just needs bootstrapping to reach 5%. The control port is one of the first things that's made available (though of course you need to wait longer if you want descriptors, to set up hidden services, etc).
18:41:39 <asn> might be worth checking before recommending it as a solution :)
18:43:43 <hellais> atagar: the logic that txtorcon uses is not waiting for 100%, but rather waiting for the first bootstrap message.
18:45:04 <isabela> ppl
18:45:09 <isabela> i am ending the bot
18:45:32 <isabela> #endmeeting