OpenBSD Journal

What's in -current this week

Contributed by deanna on from the too-many-lists dept.

Here's a summary of interesting CVS changes from the past week, for those who don't have time to follow the list, or wish to discuss it. Last week's notable additions are zyd(4), ripd(8), and two sets of slides. As always, the archives are available at marc.theaimsgroup.com.

New daemon: ripd 

Changes by:     norby@cvs.openbsd.org   2006/10/18 10:11:58

Welcome ripd
   
started by Michele Marchetto some time ago by using the imsg/three
process framework of ospfd. He implemented most of the daemon with a
little help and guidance from Claudio and I.

Currently the daemon is more or less complete, with the exception of
key lifetime and rollover.

Not yet connected to the builds.
New wireless support: zyd now enabled in GENERIC 
Changes by:     damien@cvs.openbsd.org  2006/10/21 12:18:50

huge diff to bring zyd(4) into a working state.
should work with ZD1211 (not ZD1211B!) adapters with either a
RFMD or AL2230 radio chip.
does not support IBSS or HostAP modes yet.

New slides: PF evolution and Network randomness 

Changes by:     mcbride@cvs.openbsd.org 2006/10/12 22:15:36

Modified files:
        .              : events.html

Log message:
Move auug2006 to past events, add links to slides.
And, as usual, tons of bugfixes and improvements.

(Comments are closed)

Comments

  1. By deanna (64.231.232.103) on

    If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

    Comments

    1. By Martin Gignac (192.75.88.232) martin.gignac@gmail.com on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      I for one would certainly would find this useful!

      Comments

      1. By Anonymous Coward (69.70.207.240) on

        > > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)
        >
        > I for one would certainly would find this useful!
        >
        >
        Same here!

    2. By Anonymous Coward (81.10.192.234) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      Very intresting, especially for those not watching the lists.

    3. By Kirill (212.7.30.195) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      Great job, Deanna! I find this very useful, indeed. +1 for this to become a weekly overview.

    4. By Karol Swietlicki (89.78.18.128) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      I like it.
      It is interesting to me.

    5. By Jared (72.207.228.59) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      Add me to the list...

    6. By Anonymous Coward (213.118.21.137) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      very good

    7. By Antonios (89.210.247.148) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      that would be awesome!

    8. By Anonymous Coward (213.196.227.110) on

      *lets you know*

    9. By Aaron Linville (70.108.55.120) aaron@linville.org on http://www.linville.org/

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      I'd find it interesting. If good commentary can bring football to prime-time, maybe it can do it for openbsd-cvs@ now too. :-)

    10. By Anonymous Coward (82.76.195.138) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      Very useful!

      Comments

      1. By Anonymous Coward (167.202.196.71) on

        > > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-) > > Very useful! I would like to see this information on a regular basis too.

    11. By yo2lux (86.125.253.236) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)

      Very useful

    12. By squeege (216.252.80.178) on

      > If you find this interesting/useful, let me know and I'll make it a weekly article. And pay more attention to the list. :-)


      Yes, IMHO this is definitely interesting and on-topic...

  2. By Anonymous Coward (195.29.157.74) on

    It could be useful to have this kind of weekly digest posted to undeadly, but keep in mind not to forget something important. :-)

  3. By Pete (80.203.236.21) on

    I would much rather that any such effort went into keeping the authorative text on the subject:

    http://www.openbsd.org/plus.html

    up to date instead.

    /Pete

    Comments

    1. By sthen (85.158.44.148) on

      > I would much rather that any such effort went into keeping the authorative text on the subject: > > http://www.openbsd.org/plus.html > > up to date instead. agreed.

  4. By Anonymous Coward (195.158.178.232) on

    I always wanted such a condensed weekly summary. Keeping /plus up to date would be an alternative and great but if you don't have cvs commit bit and grunk is unavailable for this kind of work maybe here would be the place to offer such a useful service.

    Comments

    1. By sthen (85.158.44.148) on

      > I always wanted such a condensed weekly summary. Keeping /plus up to date would be an alternative and great but if you don't have cvs commit bit and grunk is unavailable for this kind of work maybe here would be the place to offer such a useful service.

      committing from a cvs diff properly mailed (i.e. where the email can be piped straight through patch with no whitespace problems etc) is a fairly small amount of work and can be done by lots of people from a post to www@, the thing that takes time is working through the list of changes (the owc mailing list is probably the simplest source to work with) and understanding which are worth reporting.

  5. By Nate (74.13.33.246) on

    http://www.openbsd.org/papers/auug2006/pf_evolution/mgp00006.html

    "Developpers?" Ain't that one p to many?

    Comments

    1. By Anonymous Coward (195.158.178.232) on

      > http://www.openbsd.org/papers/auug2006/pf_evolution/mgp00006.html
      >
      > "Developpers?" Ain't that one p to many?

      Ain't that one o too little? :-P

      Comments

      1. By Anonymous Coward (213.118.21.137) on

        > > http://www.openbsd.org/papers/auug2006/pf_evolution/mgp00006.html
        > >
        > > "Developpers?" Ain't that one p to many?
        >
        > Ain't that one o too little? :-P

        They were always a bit special, weren't they? ;o)

  6. By Daniel Melameth (63.228.81.226) on

    Love the slides! What a treat! Thank you Ryan!

    And where can I get an 'I love PF' shirt?!?

    Comments

    1. By Anonymous Coward (208.191.177.19) on

      Where can I get the "I Love PF" shirt model? :)

      Seriously, outstanding work on PF. I don't look forward to setting up iptables on Linux after using it. Thanks to all the devs.

      Comments

      1. By Anonymous Coward (151.188.247.114) on

        > Where can I get the "I Love PF" shirt model? :)
        >
        > Seriously, outstanding work on PF. I don't look forward to setting up iptables on Linux after using it. Thanks to all the devs.


        Aw, c'mon, give ol' iptables/netfilter a break. It is, after all, only Linux. :-D

        Yeah, the syntax is a little intimidating at first, but if you're familiar with Cisco access control lists, iptables really is not that bad. I do a fair amount of it, so it's second-nature to me. Of course, OpenBSD's syntax is a lot easier to read and understand, I'll give you that, and the stateful failover--even for VPN gateways now, I hear--kicks total BUTT. Stateful failover between packet filters is very cool, but stateful VPN failover is just straight-up 31337.

        I'm glad to see that we have different, competing, and above all, Free implementations of packet-mangling code. It's like GNOME vs. KDE--the competition inspires each to become better than they were, and they can, if they wish, crib ideas from each other.

    2. By Anonymous Coward (198.208.251.24) on

      > Love the slides! What a treat! Thank you Ryan!
      >
      > And where can I get an 'I love PF' shirt?!?

      heh. thats a pic stolen from google images or whatever.

      its for some musician... don't recall his name.

      regardless, it should be made and put on the ordering page :)

      Comments

      1. By Anonymous Coward (71.82.175.104) on

        > heh. thats a pic stolen from google images or whatever.
        >
        > its for some musician... don't recall his name.

        actually it's a fashion designer, paul frank.

  7. By Anonymous Coward (68.167.146.78) on

    This is not flame-bait, it's is a serious question. One of the changes is the addition of "ripd". Since we already have ospfd, why would anybody need RIP anymore (kinda like "why use telnetd when sshd exists")? Anybody?

    Comments

    1. By Anonymous Coward (213.196.227.110) on

      Ancient operating systems, such as Windows 2000 or GNU/Linux,
      or some Cisco stuff, which only does RIPv1/RIPv2.

      I wonder if this is going to replace routed?

      Comments

      1. By henning (80.171.66.31) on

        > Ancient operating systems, such as Windows 2000 or GNU/Linux,
        > or some Cisco stuff, which only does RIPv1/RIPv2.
        >
        > I wonder if this is going to replace routed?

        routed must die

        Comments

        1. By Anonymous Coward (193.63.217.208) on

          > > Ancient operating systems, such as Windows 2000 or GNU/Linux,
          > > or some Cisco stuff, which only does RIPv1/RIPv2.
          > >
          > > I wonder if this is going to replace routed?
          >
          > routed must die
          >

          Out of curiosity, why must routed die? Is it simply that bad?

    2. By Dan (87.69.56.199) on

      > This is not flame-bait, it's is a serious question. One of the changes is the addition of "ripd". Since we already have ospfd, why would anybody need RIP anymore (kinda like "why use telnetd when sshd exists")? Anybody?

      I think RIP is a must because there are some stuff which are very hard to do with OSPF. For example: filtering and sumerization.

      In OSPF you can filter routes an summerize them only on ABR, and thats only for internal routes (LSA 1-3). In RIP you can summerize and filter routes whereever you want.

      Some might say that with a good OSPF design there will be no limitation for OSPF, but who wants multiple areas for 10 routers network?

      my 0.02

    3. By Anonymous Coward (63.148.23.56) on

      > This is not flame-bait, it's is a serious question. One of the changes is the addition of "ripd". Since we already have ospfd, why would anybody need RIP anymore (kinda like "why use telnetd when sshd exists")? Anybody?

      ospf is a link-state protocol
      rip is distance-vector protocol

      understand the differences of use, then you may see the cases.

      Comments

      1. By Anonymous Coward (68.167.146.78) on

        > > This is not flame-bait, it's is a serious question. One of the changes is the addition of "ripd". Since we already have ospfd, why would anybody need RIP anymore (kinda like "why use telnetd when sshd exists")? Anybody?
        >
        > ospf is a link-state protocol
        > rip is distance-vector protocol
        >
        > understand the differences of use, then you may see the cases.

        Can you give me a case or two? I'm just not yet seeing it.

        At work, I run a reasonably large enterprise network (about 240 sites). When re-designing that network a few years back, our two realistic choices were OSPF and EIGRP. EIGRP, due to its proprietary nature, got eliminated pretty quickly. We had also briefly considered RIPv2.

        OSPF, due to its link-state nature, is a lot quieter on a network than is RIP and has much shorter convergence time than does RIP. Having used both for several years, I have learned that OSPF is indeed scaleable from very small networks to quite large ones and is a major leap forward over RIP. Not knocking the inventors of RIP here--they made dynamic routing possible at all, kind of like Rudolph Diesel's first engine now lets me get 50 miles per gallon w/ my VW Jetta today (thank you, Rudolph!!). But if you have some cases where RIP's distance-vector nature is an advantage over OSPF's link-state nature, then, one techie to another, I'm definitely interested.

        Comments

        1. By Daniel Ouellet (66.63.10.94) daniel@presscom.net on

          > At work, I run a reasonably large enterprise network (about 240 sites). When re-designing that network a few years back, our two realistic choices were OSPF and EIGRP. EIGRP, due to its proprietary nature, got eliminated pretty quickly. We had also briefly considered RIPv2.

          Didn't you also consider IS-IS?

          Curious why not? If you look at EIGRP and RIPv2, why not IS-IS then and it's simpler then OSPF as well and pretty fast too!

          Comments

          1. By djm@ (206.59.235.113) on

            > Didn't you also consider IS-IS?
            >
            > Curious why not? If you look at EIGRP and RIPv2, why not
            > IS-IS then and it's simpler then OSPF as well and pretty fast too!

            I dunno if IS-IS is more simple than OSPF; while it doesn't have the abominable "virtual link" crap, it looks more complicated on the wire.

            Also, IS-IS isn't as widely supported on network devices as OSPF and the last time I checked (years ago, admittedly) Cisco IOS code that supported IS-IS cost more, or had fewer features.

          2. By Anonymous Coward (151.188.247.114) on

            > > At work, I run a reasonably large enterprise network (about 240 sites). When re-designing that network a few years back, our two realistic choices were OSPF and EIGRP. EIGRP, due to its proprietary nature, got eliminated pretty quickly. We had also briefly considered RIPv2.
            >
            > Didn't you also consider IS-IS?
            >
            > Curious why not? If you look at EIGRP and RIPv2, why not IS-IS then and it's simpler then OSPF as well and pretty fast too!

            We actually did. But then, we looked at what would be easier, conceptually, to maintain, for new people coming in. Those ISO addresses just plain looked too foreign at the time. I know that telcos use IS-IS for the performance and improved scalability over EIGRP and OSPF, so it's gotta be pretty good. Indeed, the telco guys that I've talked to about it like it a lot. But we're an enterprise, so we have to think in those terms. Also, we know that *everybody* and their mother supports OSPF pretty much out of the box, including Cisco, Juniper, OpenBSD, etc (does OBSD support IS-IS--just curious?).

            Basically, OSPF is good enough (actually, *really* good enough) for our enterprise, it's Free as in Freedom to use, and there's tons of support and expertise available within arm's reach. So it made good business sense for us to go with it.

    4. By Anonymous Coward (65.57.245.11) on

      > This is not flame-bait, it's is a serious question. One
      > of the changes is the addition of "ripd". Since we already
      > have ospfd, why would anybody need RIP anymore (kinda like
      > "why use telnetd when sshd exists")? Anybody?

      Two reasons at least:

      1. Lots of network equipment speaks only RIP, so it is good to have a secure implementation

      2. Distance vector routing protocols are fine for tiny networks, and are generally more simple and easy to configure (if not on OpenBSD, which does a good job with OpenOSPFd, then on $big_router_vendor's kit).

      Comments

      1. By Anonymous Coward (151.188.247.114) on

        > > This is not flame-bait, it's is a serious question. One
        > > of the changes is the addition of "ripd". Since we already
        > > have ospfd, why would anybody need RIP anymore (kinda like
        > > "why use telnetd when sshd exists")? Anybody?
        >
        > Two reasons at least:
        >
        > 1. Lots of network equipment speaks only RIP, so it is good to have a secure implementation
        >
        > 2. Distance vector routing protocols are fine for tiny networks, and are generally more simple and easy to configure (if not on OpenBSD, which does a good job with OpenOSPFd, then on $big_router_vendor's kit).
        >

        I partly agree with your point #2. For an enterprise of medium-size or above using OSPF, you really should be doing multiple areas, and that does take a little planning. But I find OSPF about as easy to actually configure--at least on Ciscos--as RIP, once that planning's done, but I do it every day, so I might not be a good example for that one.

        Your point #1 is interesting, though. I had momentarily forgotten that there are still, for example, plenty of old Cisco 2500's out there that have been running for years and years, and due to DRAM/flash limitations, they need to stick w/ older IOS versions. That means that OSPF might not be an option for them. Also, PIX Firewalls, until very recently, spoke only RIP, not OSPF (not that I personally would run *any* dynamic routing protocol on any firewall box, but some do), and despite their insane cost, PIXes are quite popular. So, you have a point there. Of course, that said, if I were allowed to spec the firewall strategy without "Layer 8" interference, I'd be going with OBSD and PF all the way in the first place.

  8. By Krunch (139.165.82.240) on http://krunch.be/

    > http://www.openbsd.org/papers/auug2006/network_randomness/mgp00025.html
    > The selections tend to cluster.
    This is a known problem for hashtables with linear open addressing collision resolution schemes. A possible solution would be to use double hashing: instead of looking for an available port through rnd, rnd + 1, ..., 2^16 - 1, 0, 1, ..., rnd - 1 you could look for an available port through rnd1, rnd1 - rnd2, rnd1 - 2*rnd2, ..., 0, 2^16 - 1 - rnd2, 2^16 - 1 - 2*rnd2, ..., rnd1 + rnd2 with rnd2 coprime with 2^16-1.

    I might try to write a patch some day.

    Comments

    1. By Anonymous Coward (198.205.32.94) on

      > [...] with rnd2 coprime with 2^16-1.

      Why coprime with 2^16-1? Don't you mean coprime with 2^16 (i.e., odd)?

      Comments

      1. By Krunch (82.212.188.164) on http://krunch.be/

        > > [...] with rnd2 coprime with 2^16-1.
        >
        > Why coprime with 2^16-1? Don't you mean coprime with 2^16 (i.e., odd)?

        Indeed (I got confused with indexes starting at 1 in Knuth and 0 in C), but in fact it's coprime with fabs(last - first) with last and first that can be set to virtually anything at runtime via net.inet.ip.port{hi}{first,last} (see sys/netinet6/in6_pcb.c:in6_pcbsetport and sys/netinet/in_pcb.c:307-368).

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.]