OpenBSD Journal

KernelTrap interview with Ryan McBride

Contributed by grey on from the don't-lose-the-story-in-the-move dept.

OpenBSD Press Page reports: In this interview conducted by Jeremy Andrews, Ryan McBride discusses the new CARP and pfsync protocols which allow for firewall failover, and covers the ongoing struggle with the IETF for truly open standards unencumbered by patents.

See the complete KernelTrap interview here: http://kerneltrap.org/node/view/2873

This is a week late, and was posted on the obsdj.baselabs.org site as a news story while it lasted, but we didn't want it forgotten to undeadly amidst all the shuffling around.

(Comments are closed)

Comments

  1. By Anonymous Coward (67.70.165.105) on

    Wasn't this already covered on deadly.org? Not that hurts to have it again, especially that I thought it was a great read/interview.

    Comments

    1. By Dunceor (130.243.30.36) on

      yes it was already covered. Has undeadly got deadlys archive yet?

    2. By grey (207.215.223.2) on

      The interview is from April 7th, after deadly.org stopped adding stories. So no, it was never posted to deadly.

      This was however posted to obsdj.baselabs.org while it was running for the past week or two, and I made note of that in the full story post (though not in the headline).

      After combing over undeadly, I didn't see it here either. I realize it's a repost after a fashion if you've been keeping up with OpenBSD forums of the past couple of weeks, but with the baselabs.org site gone, and deadly.org in stasis, I thought it would be good to give it a point of exposure where it will have more of a shelf life (short of the already mentioned openbsd.org/press.html page).

      Comments

      1. By Anonymous Coward (67.70.164.193) on

        Ohhhhh, that's where I saw it. :) I didn't mean it in the a bad way, and I see your point now for having it here. Well done! Thank you!

    3. By Anonymous Cheese (207.215.253.53) on

      Not on deadly.org, but on OpenBSD Journal nonetheless. Which brings to mind a shirt Jason Wright has worn in the past; "The Department of Redundancy Department." ;)

  2. By Anthony (192.208.10.217) on

    Something I've been thinking about is a mechanism that would allow userspace programs to attach some programmer-definable state to a connection, and have that synchronized across the various hosts with pfsync.

    The tricky part would be setting it up so that reading and writing to the socket would update the state atomically in such a way that connections could be picked up by another host at any time without missing a beat. I can't think of a way to do that without quite a bit of overhead.

    I'd like to fool around with that this summer if I have time. Even if it's an idiotic idea, I'll probably learn enough to contribute with something else. And I'd like to do that.

    Comments

    1. By Peter Hessler (66.243.2.34) spambox@theapt.org on

      Something like authpf(8)?

      Comments

      1. By Anthony (68.145.159.179) on

        I was thinking mostly of the ftp proxy. authpf could potentially benefit as well (just about anything could), but you'd need authpf and sshd to work together and that would be hard to do cleanly...

        1-when a socket to be made redundant across hosts is opened, it's opened atomically on all the CARP hosts
        2-when a packet comes in, the CARP master node mirrors the packet to the other hosts, by wrapping it in a pfsync packet. This would have to be atomic too.
        3-the other hosts use the packet to maintain their mirror of the socket in an identical state, including all the buffering and so forth in the network stack. It could be in the kernel but I think there are advantages to doing it in user space... it could be done by something like inetd, it would only need a call similar to listen() and a few other things to get all the information.
        4-The process dealing with the socket on the master host would do everything normally, but whenever it does anything that could touch the outside, it updates the state on all the other machines. So everything needed can be redone from existing states and buffers at all times.
        5-If the master host goes down, the process in charge of maintaining the state of the socket in step 3 would fork a new process, like inetd would, giving the new process a file descriptor(s). The new process could look up the state information, and pick up where the other one left off.

        You wouldn't even need to use the same program binary for resumed connections.

        The network used for pfsync stuff would have to be FAST

        There'd clearly be other issues, but for something like the ftp proxy that doesn't need to touch anything on the host machine, it makes sense. Having a single API for it would make it easier to add failover to other programs.

  3. By Brian P. (4.15.55.79) on

    this was quite a good read. i always enjoy kernel hacker interviews. it was nice to read about pf and some of the new features:-) i have gained new respect for pf because i just recently learned iptables and feel that pf is simpler to write and more powerful. thanks for pf!!!!!!!!! i also wanted to thank daniel because i was very sad when i saw the notice on deadly and am now happy that someone else has stepped up to the plate:-) i feel no grudge or animosty towards the deadly founders and empathize with them. thanks again daniel for carrying the torch and bringing happiness to me!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]