On Fri, Dec 21, 2012 at 01:17:06PM +0000, sickm...@lavabit.com wrote: > On 12:25 Thu 20 Dec , Stefan Sperling wrote: > > On Wed, Dec 19, 2012 at 09:43:18PM +0000, sickm...@lavabit.com wrote: > > > Hi, > > > > > > I have been using OpenBSD for quite a long time, and find it awesome. > > > I've got some spare time lately and decided to hunt some bugs, but I > > > don't really know where to start. Any suggestions? > > > > > > P.S. Yeah, I know about openbsd-bugs, but I suppose that's not all there > > > is. > > > > I could provide a list of things that need doing in locales/wireless/IPv6 > > if any of those areas are of interest to you. > > They are. Except for locales, never used them.
Cool! Below is a todo list written off the top of my head. Wireless: There are performance issues with ral(4) and possibly other devices. I believe it's because the rate adaptation algorithm is too basic and doesn't cope well in noisy environments. The dragonfly commit log for ral(4) contains some interesting work by sephe@dragonfly which I've been taking a closer look at. http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/sys/dev/netif/ral (Careful: Some of sephe's commits have been reverted in a giant "sync with freebsd" commit -- I'm not sure whether the person who made that commit knew what he was doing...) Note that parts of these rely on other changes made to the generic net80211 layer in dragonfly. I hope that we might be able to fix performance issues with ral(4) and perhaps other chips based on sephe's work. But this needs a bit of research. I'm not entirely sure if that really is the case. For some reason, hostap mode seems to be affected most by the performance issues, which is why I believe the rate adapation approach might to blame (but it might just as well be something else). ral(4) does not support power saving in hostap mode for rt2560 and rt2661 chips. Power-saving support for newer chip variants exists. In general, adding support for power-saving in hostap mode to any drivers which support hostap mode is needed. See here for the spec: http://standards.ieee.org/getieee802/download/802.11-2012.pdf (Chapter "10.2 Power management") and look at ral(4) (rt2860.c), athn(4), and acx(4) for example code. There are chips that ath(4) should support but does not. See http://marc.info/?l=openbsd-misc&m=134901419419278&w=2 There are chips that athn(4) should support but does not. I'm already working on AR9485 and could use some help there if you have access to such hardware. The equivalent Linux driver is ath9k which supports several models athn(4) lacks support for. Adding support for any of these would be great. ipw(4) is buggy: http://marc.info/?l=openbsd-misc&m=134929439329011&w=2 Could also be a hardware/firmware issues. Needs research. urtwn(4) is buggy: http://marc.info/?l=openbsd-misc&m=134666785524449&w=2 http://marc.info/?l=openbsd-misc&m=134666785524449&w=2 This could also be a problem in the USB stack, not sure. Needs research. There is no driver for BCM43228 chips. There is a BSD-licensed driver for linux: http://linuxwireless.org/en/users/Drivers/brcm80211 Writing a driver for this will be very difficult! I'm mentioning this for completeness. FreeBSD has a driver for some other broadcom chips we don't support: http://svnweb.freebsd.org/base/head/sys/dev/bwn/ It would be nice (but far from trivial) to get this ported to OpenBSD. Of course, it's best to start off hacking on drivers for hardware you own and actually use. IPv6: Carp does not support unicast peers over IPv6, only multicast. Support for IPv4 unicast was added by reyk in this commit: http://marc.info/?l=openbsd-cvs&m=121348006024130&w=2 The equivalent should be implemented for IPv6. ospf6d(4) does not support multiple areas as specified in RFC 5340 and thus isn't really RFC-compliant. Also, it does not support virtual links (same RFC). ospf6d(4) does not support authenticated OSPF packets. It should be using IPsec for this, according to RFC 5340 (the MD5-based approach used in OSPF for IPv4 is not applicable to OSFP for IPv6). Currently we require users to manually configure IPsec flows between routers. It would be great if there was a way to tell ospf6d to configure ipsec flows automatically. Obviously, IPsec secrets would need to be installed on any routers taking part in the OSPF network, but beyond that ospf6d should just do whatever is necessary to secure OSPF traffic. I hope this list helps you getting started. If you have any questions just let me know.
