from the wannabe-beer dept.
Mark Uemura (mtu@)
returns with the seventh installment from his experience at the
Network Hackathon in Japan:
Network Hackathon (Part 7) - May 5-10, 2008, Ito, Japan
The following two individuals have impressed me for many years now.
Ryan McBride (mcbride@) and Henning Brauer (henning@)
are the best of friends and each in his own right has done so much
Mark's account continues below with interviews and
Ryan was one of the main guys
responsible for bringing high availability clusters to OpenBSD,
along with Mickey Shalayeff (mickey@), Christopher Pascoe (pascoe@)
and Marco Pfatschbacher (mpf@).
Henning has either written and/or rewritten more privilege separated daemons
than any other OpenBSD developer. Yet, as you'll see below, what they are doing
together is very important and daunting if done on their own. Their
efforts now are paving the way for great things to come in OpenBSD!
I have the pleasure of working very closely with Ryan on a daily basis.
His OpenBSD contributions are long and impressive on their
own. Besides CARP
and PFSYNC, he added
IPv6 support for PF, PF layer 3/4 load balancing,
tons of pf.conf(5)
improvements along with sane defaults and managed to trick/encourage
Henning to do the heavy
lifting on other PF things. Yet, I can tell you that Ryan is every bit
the Security Professional that I strive to be. I've got my work cut out
for me. :-) Ryan is a very experienced OpenBSD kernel
and network stack developer. He is technical to the core, extremely
professional when it comes to security and experienced beyond his years.
He can also be very
theatrical at times
when giving talks. ;-)
Here is what Ryan had to say about his work at the Network Hackathon:
Henning and I are on a multi-year project to
reorganise PF's internals. Since we have two hackathons in quick
succession, we're trying to do the major work over the next few months.
So I knew I already had my work cut out for me this hackathon. I
needed a bit of a warm up, so I first
some longstanding issues with
carp logging, making it much more tunable and making it log state
changes (now enabled by default).
Then, while Henning worked on the next phase of the state table
reorganisation, I helped David Gwynne (dlg@) on his project to make PF handle
asymmetrical routing correctly, making some minor changes to
handling of state insertion (still uncommitted).
While I was finishing this, Henning finished his rework of the state
handling code, with one "minor" caveat: All the parts of PF that deal
with translation (nat, rdr, binat) were commented out and needed to be
rewritten. I spent the last two days of the hackathon slowly working
through this; it should be completed soon with a goal of committing this
work before the general hackathon this June.
For me, Henning Brauer has always been one of the main
OpenBSD icons. His work is formidable and he has added so much
functionality to OpenBSD. His code is exemplary for anyone interested
in writing bloat-free, secure privilege-separated daemons.
are good examples of where Henning's framework used in
was used in other daemons that he didn't write.
Henning is every bit a character in person as he is on misc@. Well, on
misc@, he is more like a demi-God; at least that was my impression of
him. His replies to misc@ posts were usually authoritative and to the
point. You couldn't help but learn something insightful. In person,
this is also true.
Henning couldn't help but make fun of the beer that I brought to the
hackathon. Rather than bring only Japanese beer, I brought along some
Corona and Heineken. It was the only thing that I could get in bulk at
CostCo. Actually, I brought too much beer, if you can believe it.
Anyhow, after bringing the beer into the hacking room, I noticed a note
on the white board in Henning's chicken scratch, of course. It had some
derogatory comments about the beer selection in descending order with
the last choice akin to some beer wannabe. The funny thing is that
when I questioned him later after many beers and a beer wannabe in
hand, he replied, "after four beers, they all taste the same! *hiccup*"
Later I was thanking myself for not wasting the expensive beer on
Here is what Henning had to say about his work at the Network Hackathon:
Two years ago (or three already?) Ryan and I were on a ferry in the
Vancouver Island region and were talking about PF internals. We had wild
ideas about structural changes, linking states together to save lookups,
and link other states to that. This, unfortunately, requires a major
rework of the state table logic - besides other not exactly easy
modifications. We have worked on preliminary stuff during previous hackathons
and a bit in between and got that in. Now it was time for the big state
table changes. For the first couple days I was writing the new state insertion
and search routines. After that, I went through the code ripping out the
old routines and replacing them with the new ones. While doing so, I dropped
features nobody needs anyway: all forms of NAT and pfsync. For some
reason Ryan is interested in having these, so I passed my diff over to
him to add that stuff back.
While he was doing that, I spent some time on further integrating Claudio
Jeker's (claudio@) route priority code. This is another multi-year project.
Claudio and I first came up with it certainly more than a year ago -- maybe two.
I looked for and found cases where the route priority was not
set appropriately (arp, cloning) and fixed that. I had all routing
daemons inserting their routes with an appropriate priority. For the
routing daemons themselves, there will be much more required though. Routing
priorities, which allow you to have multiple routes to the same
destination -- the one with the highest priority wins, help to make
the routing daemons more efficient since they can just blindly insert their routes
and don't have to care if there already is a route. This is especially important
for bgpd, though, since it needs to verify whether next hops are reachable. There
are some other parts that require looking at the current routing
situation which are a bit more complicated. I expect the other routing
daemons' kroute code to profit big time from route priorities and they
nicely make sure the interaction between the routing daemons is right
(whoms route has priority over whoms? now it is easy). I started looking
at bgpd's kroute code, but haven't finish that yet.
In between, I worked on the time code in bgpd, now using a timewheel
there, allowing us to move some stuff to regular times that use manual
And I learned some Japanese words, had weird Japanese food, beer and
(n2k8 hackathon summary to be continued)
Thank you Mark, Ryan and Henning for sharing a bit from n2k8 with us.