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