19:01:55 #startmeeting 19:01:55 Meeting started Wed Jun 25 19:01:55 2014 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:58 nickm: I met with mvdan earlier. Backlog is above; if you can't scroll enough let me know and I'll email 19:02:07 I can get backlog; thanks, Sebastian! 19:02:16 cool 19:02:19 (all still well?) 19:02:24 have fun with your meeting 19:02:25 yes 19:02:28 great 19:02:34 * dgoulet here 19:02:35 He is starting a feature branch 19:02:39 for integration. 19:02:40 grand 19:03:01 So, what's to talk about this week? 19:03:09 We have a couple of issues left in 0.2.5 to solve. 19:03:15 We are still trying to run up to 0.2.6 19:03:34 anything else? 19:03:40 I have some news on the guard nodes front 19:03:44 keen 19:04:00 what's the news? 19:04:04 Ah, 19:04:08 I wrote some unit tests. 19:04:18 The coverage is at 33% atm, and covers some important functions 19:04:26 I'd like someone to read it, and make sure that the unittests are not too artificial 19:04:34 this is #12207 ? 19:04:38 yes 19:04:46 i'm currently writing unittests for my fix of #12202 19:05:00 when I prepare the unittests, I'm going to push my fix and flag it as needs_review 19:05:09 also, I made this post to tor-dev yesterday 19:05:17 about why people have so many guards in their state file 19:05:40 I realized that the current behavior of Tor is actually good. 19:05:50 during inverstigating this behavior 19:05:53 I found a bug, I think. 19:05:57 which I put in https://trac.torproject.org/projects/tor/ticket/12450 19:06:19 during the next week, I'm going to revise my unittests based on any feedback, 19:06:33 and also try to tackle tickets like #12202 and #12205 19:06:57 nickm: if you think that I'm beating around the bush with this unittest business and I should get back to implementing proposal 236, just tell me. 19:07:11 it's just that implementing proposal 236 is not too hard; it's mainly changing a few functions and a few constants 19:07:21 neat. wrt #12207, from a quick glance, I need to look harder at the choose_random_entry_impl refactoring... 19:07:28 prop#236 19:07:42 Isn't there some directory- and bandwidth-related stuff in 236? 19:07:49 yes 19:07:54 that's the hard part of 236 19:08:07 the one that makes new entry guards more likely to be picked. 19:08:21 i will wait till the dev meeting, to discuss this with you and figure out a nice impleemntation plan. 19:08:36 that is, whether we should do this in an external process ( a la bandwidth measurements) etc. 19:09:13 Is there anything else I can help you with nickm? 19:09:35 Any tickets that you asked me to review and I forgot about them, etc. 19:09:55 also re 12207 -- "router_descriptor_is_too_old" has a bad name. Too old for what? 19:10:10 hm, i see. 19:10:14 too old to be accepted by tor, I guess. 19:10:28 but maybe, it should take as an argument the maximum age it could have. 19:10:30 or change its name. 19:11:05 any suggestions on a better name? 19:11:47 the prince symbol 19:11:47 router_descriptor_is_older_than seems like a fine replacement, if it takes a max-age 19:11:57 nickm: ack 19:12:27 (and that's that from me btw.) 19:13:34 re #12450 I wonder if we could have a rule almost like "If the most recent attempt to attempt to a more preferred guard is _before_ our most recent successful attempt to any guard, try the preferred one again before using the replacement" 19:13:40 except that leads to an infinite loop 19:13:42 so, not quite that 19:14:27 yeah, we could make that happen only once. 19:14:34 but maybe something more elegant could be thought of. 19:15:33 armadev has historically thought of good kludges in this area. 19:15:40 Hm. next topic... remaining issues for 0.2.5 ? 19:16:10 we have a little feedback on #12184 now 19:16:40 and we have somehow picked up several tickets in 0.2.5 in state 'new' now. 19:17:20 athena: have you had a chance to look at the 12184 info ? 19:18:24 * nickm has a look at https://trac.torproject.org/projects/tor/query?status=needs_information&status=needs_revision&status=reopened&status=needs_review&status=assigned&status=new&status=accepted&group=status&milestone=Tor%3A+0.2.5.x-final 19:19:01 Has anybody reproduced #12404 ? I tried to build with --disable-curve25519 and it build circuits fine for me. 19:19:05 I think I'll close as worksforme 19:19:49 nickm: no, not yet on #12184 19:20:01 hm 19:21:35 looking at it, does it seem to you like we're queueing a whole bunch of destroys but never actually sending them? 19:22:03 cypherpunks asked (comment since replaced with "") whether the channel is stalled completely, or just the destroys are stalled. 19:25:23 I wonder, how can we fix this one? Do we need more diagnostics? 19:25:29 Should we be reviewing the code? 19:26:53 i'd guess we're almost certainly missing an increment to the outbound circuit count somewhere 19:27:09 That's a possibility for the 4-billion number, yeah. 19:28:15 I'm most concerned with the running-out-of-circuit-ids problem 19:30:37 I'm also very interested in why manual_total_in_map is so much less than manual_total in circuitmux_count_queued_destroyed_cells 19:31:04 the way that function is written, even if manual_total is very high, manual_total_in_map should match it 19:31:47 on the bright side, destroy_ctr == destroy_cell_queue.n == the actual number of elements in destroy_cell_queue 19:32:10 on the darker side, that number is 317177 in one case and 157396 in another 19:34:30 hm. we're probably not going to solve this right now, though we _should_ be trying 19:34:42 do we have time to go over the stuff still in 0.2.5.x? 19:35:48 hmm 19:35:54 time before? 19:36:47 I need to go in 20 minutes :) 19:36:55 or is there other stuff to talk about today? There might be! 19:36:57 right, okay 19:39:34 It seems we already decided to defer #10461, marking it as possible backport 19:40:24 that leaves #12160, #12438, and #12448 19:41:24 given the lack of info on #12448 I think we need to make that 0.2.6, backportable, needs_information ? 19:43:02 for 12160 -- we don't handle that stuff so well now. I guess we could look into it, but maybe we can do even better in 0.2.6? 19:43:27 for 12438 -- if it compiled, it wouldn't really work very well. 19:43:32 should we make it compile anyway? 19:43:45 hmm, agree on #12448 19:45:48 pushed a branch to #12202. I'm happy with how it turned out. I set the milestone to 0.2.6.x. 19:46:48 For additional "fun" -- here are the tickets in component Tor but without a milestone. They should get sorted into milestones. :) 19:47:17 https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&component=Tor&milestone=&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority 19:47:44 i know that 2-3 entrynodes tickets are in this limbo state. 19:47:52 i can put them in 0.2.6.x deferable, if you want me to. 19:48:05 Don't need to mark stuff 'deferrable' or whatever; just give it a milestone. 19:48:09 ok 19:48:12 generally: don't put anything into 0.2.4 or 0.2.3 straight off 19:48:22 put it in 0.2.5 if we shouldn't call 0.2.5 stable without solving it 19:48:31 wow at #11880. 19:48:33 put it in 0.2.6 if IYO it might well belong there 19:48:47 11880 sounds like 0.2.??? 19:48:47 " This implementation is very easy," 19:48:56 ok, I can set it to that. 19:49:21 switching to a better transport than TLS does indeed seem like a one-of-these-days thing 19:51:29 ok, done. 19:51:41 (for the tickets I feel responsible for, that is.) 19:52:10 * asn thinks about #12450 some more 19:53:05 down to 8 unstored. 19:53:10 I think I'll do a first pass 19:54:13 Okay. Most were obviously 0.2.6.x (except maybe they'll get triaged out) 19:54:24 two are tricksy: #12163 and #12378 19:54:37 asn : i was thinking of another situation i encounter regarding #12450 - captive portal logins, at free wifi hotspots. sometimes it is 1, 2, 10 minutes before "network back up" an "have internet access" are both true 19:55:15 coderman: yeah, depending on how fast you pass the captive portal, 19:55:22 (said clearerly, network up at wifi radio leads actual ability to route out of hotspot by many minutes in captive portal situation ;) 19:55:26 indeed 19:55:29 *grin* 19:55:41 coderman: you will either hit #12450, or you will go through all your guards and then add some more (this is the good case). 19:57:25 "Why does Roger has so many guards?" because i have so many guards. 19:58:30 calling both the straggling tickets 0.2.6 because what harm 20:00:23 * weasel puzzles about #12378 20:01:01 what's wrong about 224.0.0.0/3? 20:02:56 it should be /8, and mask added wrong causes potentially bad behavior (more with 8. prefix than 224. ...) 20:03:04 but also minor 20:03:05 if I say 224.0.0.0/3, then that's what I mean. 20:03:09 and i haven't done a patch :( 20:03:24 how would you know that a /8 was meant? 20:04:12 per IANA, /8 is spec. and per binary math, a prefix of /3 implies more network range than 224. contains 20:04:28 erm. what!? 20:04:46 224.0.0.0/3 is the network from 224.0.0.0 to 255.255.255.255. 20:04:52 it's a perfectly valid network range. 20:05:23 prefixlengths are not confined to multiples of 8. that was over 20 years ago. 20:05:33 https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml says not, and that hits broadcast as well, which should not be used 20:05:50 Last Updated 20:05:51 2014-05-20 20:05:59 diff between class based and CIDR with valid prefixes 20:06:16 I don't see how iana assignments are even remotely relevant for this discussion 20:06:33 Okay, gotta go now. Thanks, all 20:06:34 i do see your point though. 224.0.0.0/3 could be seen as "all the rest to the top" mask 20:06:41 the only valid /3 perhaps 20:06:43 are you saying that 10.224.0.0/11 is invalid and clearly 10.224.0.0/16 was meant? 20:06:43 #endmeeting