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