00:02:36 <teor> #startmeeting Sponsor 55 sync
00:02:36 <MeetBot> Meeting started Thu Apr 16 00:02:36 2020 UTC.  The chair is teor. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:02:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
00:02:50 <teor> The pad is https://pad.riseup.net/p/tor-s55-ipv6-project-keep
00:03:54 <teor> I'll start with a status update.
00:04:01 <nickm> ok
00:04:21 <nickm> (I've looked at the tickets a bit and i reviewed the refactor you gave me, but otherwise I've been thrashing around between tasks )
00:04:37 <teor> The refactor and code movement in #33633 got merged.
00:04:52 <teor> I don't think we can move any other code as part of the relay-side extends. Lots of it is used by clients, or heavily tied to client code.
00:05:07 <nickm> makes sense
00:06:17 <teor> (Technically, we could move extend cell parsing to the relay module. But it's heavily tied to the extend cell formatting code.)
00:06:20 <teor> I have finished most of the relay-side IPv6 extend code in #33817, and created a bunch of sub-tickets.
00:07:29 <teor> I found a bunch of quirky bugs, #33918 was probably the weirdest
00:08:02 <nickm> whoa
00:08:14 <teor> some IP addresses are longer than 32 chars
00:09:21 <teor> #33899 and #33901 are in needs_review
00:09:41 <teor> #33917 was also fun
00:10:34 <nickm> wow
00:11:14 <nickm> I thought I was doing weird debugging with the #33837 stuff
00:11:21 <teor> it really wasn't that hard, and the #33817 tests were the only tests that triggered fatal errors
00:11:57 <teor> I wrote code that had a bug in the chutney logs, but chutney wasn't failing with ALL_BUGS_ARE_FATAL
00:13:25 <teor> I think that's all the tickets.
00:13:41 <nickm> ok! I'll try to be prompt with reviews
00:14:05 <teor> I've tried to spread reviews across nickm and ahf, but feel free to swap. I'm not sure if one of you has extra reviews.
00:14:32 <nickm> i think we're both hosed but we'll get through it okay
00:14:49 <nickm> we just need to knuckle down
00:14:57 <nickm> are you blocking on any of these reviews?
00:14:59 <teor> Great
00:16:08 <teor> nickm: not really, I can't be sure that I have made all the required changes for IPv6 extends, until I write some code that sends IPv6 extends
00:16:25 <nickm> yeah, that makes sense
00:17:02 <teor> The code is more complex than I expected, and the IPv4-only checks were spread throughout cell parsing, channel selection, and extend processing
00:17:55 <teor> My plan is to just do a single "does this relay support IPv6" check right before we open a new IPv6 connection
00:18:14 <teor> And otherwise let IPv4 or IPv6 extends just flow through
00:18:32 <nickm> makes sense. So in other words we only check what link specifiers we have when we are about to use them?
00:19:11 <teor> We check that the extend cell has at least one IP address, but it can be either IPv4 or IPv6 or both
00:19:33 <teor> The existing code parses link specifiers early, so we can't really skip that check.
00:19:40 <nickm> ok
00:19:58 <teor> But the only time we need to care if the relay actually has IPv6 is opening a new connection.
00:20:20 <teor> (If there are no new IPv6 connections, there won't be any IPv6 connection re-use either.)
00:20:40 <nickm> ack
00:20:50 <teor> Because any config change marks all previous connections as unusable for new circuits.
00:21:55 <teor> So my plan is to implement a basic IPv6 support check, and then write some relay reachability code that actually uses IPv6 extends
00:22:29 <teor> As part of that, I will need to make extend_info_t support IPv4 and IPv6 addresses
00:23:21 <teor> (in the same extend)
00:23:31 <nickm> ah, and right now it only has one address
00:23:41 <nickm> so we'd need it to have ... ipv4_addr, ipv6_addr?
00:23:47 <nickm> preferred_addr, alt_addr?
00:24:08 <teor> I think so, yes. I don't think preferred and alt make sense, because we're just going to make an EXTEND2 cell anyway.
00:24:22 <teor> Well, they might make sense for a create, but that's out of scope.
00:26:09 <nickm> ok
00:26:38 <nickm> i've been thinking on and off on which data structures I _wish_ we had, but this isn't the best point to refactor the whole link-specifier business
00:26:54 <teor> Yes, let's do incremental change for the moment
00:26:58 <nickm> +1
00:27:09 <teor> I think that's mostly it for the status.
00:27:21 <nickm> okay, that sounds solid to me.
00:27:27 <teor> I assigned you some tickets. Some of them aren't very exciting.
00:27:46 <nickm> that's fine; i need the coding exercise when I'm taking a break from walking-onions-land
00:28:16 <nickm> (though i did get to write a little analysis code in rust, which was positive)
00:28:53 <teor> Yes, I have lots of moments where I think the code I'm writing would be easier in Rust. Lots of my tests would just disappear. (Because of memory safety.)
00:29:05 <teor> I sent an email about IPv6 and PT reachability, but I haven't seen any replies yet. I think people are busy.
00:29:17 <nickm> nod
00:29:49 <teor> I think that's basically it.
00:30:12 <teor> We are working on GSOC and Outreachy applications, but we can't share any details yet.
00:30:13 <nickm> ok, if that's all I think we can call the meeting done?
00:30:17 <teor> yep
00:30:20 <teor> #endmeeting