Puffy and the Cryptonauts: What's New in OpenBSD 4.3by Federico Biancuzzi
As usual there are a lot of improvements and new tools and features, and it sounds amazing that they keep delivering these results with a six month release cycle.
Federico Biancuzzi interviewed a large group of developers to talk about the new networking tools (snmpd and snmpctl), the new features and scope of relayd (previously known as hoststated), how the configuration of carp was simplified, improvements in wireless drivers, storage limits and speed-ups, SMP support in sparc64, bug fixes and audits for some tricky coding practices, and much more!
I read that dhcpd(8) was working by luck, using overflow buffers to store options... would you like to tell us more?
Kenneth Westerback: In October 2007, shortly before 4.2 was released, Nahuel Riva and Gera Richart discovered that a carefully crafted client request could cause dhcpd to crash. A fix was developed by millert@ for 4.3 and lead to the first errata for the about to be released 4.2. In essence a client could request a specific size for the response generated by dhcpd which violated assumptions within the code and resulted in stack corruption.
In January Peter Hessler discovered that another carefully crafted request could cause the option storing logic to write data in memory it shouldn't be using and thus crash dhcpd. As with the October bug, the fault was straightforward to discover once someone encountered a failure.
In between these two discoveries the option processing logic in dhcpd got a thorough going over as I tried to make the logic clearer and understandable. As a result several bugs in handling option storage into the two overflow buffers were fixed. e.g. actually using the second of the overflow buffers! Safer initialization was introduced and more care taken to ensure all option buffers were correctly utilized.
The end result is a much more robust dhpcd for 4.3, which can return more options in each response by correctly utilizing all the option space available to it.
None of these changes should introduce interoperability issues. If anything it should reduce them by more correctly implementing the standards.
What changed in the way TCP responses to highly fragmented packets are constructed?
Markus Friedl: It's just a bug fix. When creating a response to a TCP packet, the stack made some assumptions about the layout of the original mbuf chain. After some IPv6-related changes these assumptions where no longer true, so now we create a packet from the scratch when sending TCP responses (usually for TCP-Resets).
You developed snmpd(8) an implementation of the Simple Network Management Protocol, and snmpctl(8), its control tool. What is the status of the implementation?
Reyk Floeter: I started working on working on snmpd(8) because I needed an alternative to net-snmp which is more secure, less complicated, reduced to basic functionality, and designed for OpenBSD. Many people picked it up and started using it even when it still was in a very early development stage. It has been tested with net-snmp, Nagios and some other free and commercial SNMP implementations or Network Monitoring Systems (NMS).
I also like to thank the user community and some developers for the very good feedback with useable bug reports, code review, and testing. We also tested it against the PROTOS test suite which helped to find some remaining issues; snmpd(8) is running very stable now.
For the future I neither plan to implement every existing MIB nor any exotic SNMP extensions like Agent-X, but there will be further work to add more MIBs related to TCP/IP networking and OpenBSD monitoring. It currently supports most of the SNMPv1/v2c MIBs, IP-MIB, BRIDGE-MIB, HOST-RESOURCES-MIB, IF-MIB, and the OPENBSD-SENSORS-MIB. It is also possible to send SNMPv2 traps via snmpctl(8) or from relayd(8).
hoststated(8)/hoststatectl(8) were renamed to relayd(8)/relayctl(8)... What is the new scope of the tool and what features have you added in this release?
Reyk Floeter: hoststated(8) has been started as a daemon for health checks on load balanced hosts - it was the "Host State Daemon" as a helper to extend pf's load balancing capabilities. The layer 7 relaying code I wrote extended the daemon in a significant way and the old name was a little bit misleading.
relayd(8) is a fully-featured TCP/IP relay, or Application Layer Gatway (ALG), where the health checking of hosts is just a part of the functionality. It currently supports TCP, HTTP, and DNS relaying, SSL "acceleration" or termination and the traditional layer 3 redirections. The grammar of the new relayd.conf(5) configuration file has been redesigned which will need some attention when migrating from hoststated. The grammar is more obvious, "services" became "redirections" because they're using the rdr functionality in pf, and tables look more like in the pf.conf(5) grammar.
relayd(8) is now also able to send SNMP traps via snmpd(8) when the state of a monitored host changes. This is a very nice feature to monitor load balancers in existing NMS. I also like the interface to make this happen; external daemons can open the /var/run/snmpd.sock and send TLV-based IMSG to snmpd(8) - there is no need to link relayd(8) against a SNMP library or to handle any ASN.1/BER encoding outside of snmpd(8) itself.
I heard you simplified the configuration of carp(4) load balancing. Please tell us more...
Marco Pfatschbacher: It has always been a minor inconvenience to set up CARP load balancing. You'd have to create multiple interfaces with the same address, manage those hostname.carp* files, and make sure to get the advskew and the link flags just right. To get rid of the need for multiple interfaces, I had to factor out the virtual host portion of carp into a separate struct that is kept in a list per carp interface. This makes it possible that one carp interface can now contain up to 32 virtual host instances. Rather than creating multiple interfaces with the same address, we can now just create a single carp interface and assign it multiple carpnodes with their respective advskews. This is a time-saver and should ease troubleshooting across CARP members.
Furthermore I replaced the link flags with more descriptive ifconfig balancing options.
Setting up an IP balanced cluster with two hosts now becomes as simple as:
host-A# ifconfig carp0 192.168.1.10 carpnodes 1:0,2:100 balancing ip host-B# ifconfig carp0 192.168.1.10 carpnodes 1:100,2:0 balancing ip
The resulting state on host-A should be sth. like:
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:00:5e:00:01:01 carp: carpdev sis0 advbase 1 balancing ip state MASTER vhid 1 advskew 0 state BACKUP vhid 2 advskew 100 groups: carp inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
To have things more consistent there's now also an "ARP balancing" equivalent for IPv6: "NDP balancing".
Would you like to talk about the new wireless drivers you worked on?
Damien Bergamini: There will be four new drivers for 802.11 wireless devices in 4.3:
- bwi(4) for Broadcom AirForce devices was written for DragonFlyBSD by Sepherosa Ziehau and ported to OpenBSD by Jonathan Gray and Marcus Glocker.
- upgt(4) for Conexant PrismGT USB devices was written by Marcus Glocker thanks to the reverse engineering done by the people at prism54.org.
- iwn(4) for Intel Wireless WiFi Link 4965AGN devices was written by me from the reverse engineering of the Intel Linux iwlwifi driver.
- ral(4) RT2860 was written by me based on documentation provided by Ralink Technology (documentation that has been obtained thanks to Theo de Raadt.)
Special thanks go to Jonathan Gray and Theo de Raadt for their efforts to free the firmware for the ral(4) RT2860 devices. Thanks to their determination, we were able to ship the RT2860 firmware under the MIT license just in time for the 4.3 release! bwi(4), upgt(4) and iwn(4) require non-free firmware to operate.
Although iwn(4) and RT2860 are 802.11n devices, they only work in 802.11g mode for the moment. More work needs to be done in our generic 802.11 layer (net80211) to fully support these devices. I plan to work on 802.11n support after WPA support is integrated which is something I'm actively working on.
Is it true that you improved the speed of flash drives? How?
Stuart Henderson: We noticed that Sandisk CompactFlash cards were a lot faster than most others and wondered why. Naddy pointed out that the cards which performed slowly all needed single-sector I/O and that DMA transfer was being disabled for these. I looked at other OS and found a simple change made in NetBSD that looked promising, ported it across and did some testing - it didn't cause any negative effects, and improved performance a great deal in some cases, so into the snapshots it went. After a little while with no reported problems it seemed pretty safe, so it's now committed.
Looking at the dmesg submitted since then, I noticed that some of the new machines with solid-state hard drives (like the Eee PC) are also affected, so it turns out it was a really good time to make this change.
What limits does this release have when dealing with storage?
Otto Moerbeek: We finished very large parts of large disk support. Large disks are disks that have more than 2TB capacity, the sector count of such disks overflows an 32-bit integer variable. We now use in all layers of disk related code (disklabel, buffer cache, drivers, ffs and ffs2) 64-bit integers to address disk blocks. The disklabel format has also changed to support large disks and partitions (up to 128PB, though the current code limits it at 64PB).
The actual largest file you can create did not change, with the default block size the maximum file size FFS can store is 1PB. But the kernel limits file sizes to a maximum of 2^31 pages, so it ends up at being 8TB on most platforms. You'll probably need to create a sparse file to actually create one like that ;-)
The original version of FFS supports up to 1TB filesystems, due to it's larger inode FFS2 can support up to the largest partition we can handle. There are important issues though: a filesystem check of a large filesystem takes a lot of memory. That is, is may need more memory than a user process can allocate. To be able to actually use a large filesystem you'll need to newfs(8) it with larger fragment and block sizes than the defaults normally used. Solving this is high on the wanted features list, of course. Also, using FFS2 for any filesystem used in the install or upgrade process is not supported.
As for other filesystems we support, I do not know the limits of either the format itself or our implementation.
Platforms and Drivers
What's new in OpenBSD/sparc64?
Mark Kettenis: The most exciting new feature in OpenBSD/sparc64 is SMP support. All supported systems should work, with the exception of the Enterprise 10000 (for which support was added after the 4.3 release was made). The release has still some stability issues on systems with more than 4 CPUs (most of these are already fixed in -current), but in general the sparc64 SMP kernel is remarkably stable. Snapshots have been built on a dual UltraSPARC-IIIi machine since November, less than half a year after Theo complained that his shiny new Sun Fire V215 only "half" worked.
Adding SMP support to OpenBSD/sparc64 was fairly easy after Art Grabowski (art@) changed the scheduler code to be more machine independent. The fact that Sun obviously designed the UltraSPARC CPUs with the intention to build SMP machines also helped a lot.
Device support has been extended, and more of the onboard hardware such as temperature sensors and gigabit ethernet devices now work. Some of this work has been made possible because Sun opened up lots of documentation. David Gwynne (dlg@) played a major role in making this happen.
With SMP working on sparc64 adding support for Sun's new UltraSPARC T1 and T2 CPUs makes a lot more sense. And I'm happy to announce that OpenBSD 4.4 will include support for at least the UltraSPARC T1 machines.
What features have you added to eeprom(8)?
Mark Kettenis: One of the nice things about sparc and sparc64 systems is that they have Open Firmware. Open Firmware includes a full description of what hardware is present in the system. This information is used by OpenBSD to attach the right device drivers. Solaris has a tool to get a nice printout of the device tree, and I had been collecting the output for sparc64 machines. These dumps proved to be an invaluable tool for supporting new systems and new hardware. I really wanted a similar tool for OpenBSD. Federico G. Schwindt (fgsch@) saw that he could do this without too much effort and integrated it into eeprom(4). Since macppc systems are also based on Open Firmware, I later added support for these systems to eeprom(4) too.
Would you like to talk about the new audio drivers you worked on?
Alexandre Ratchov: The new envy(4) driver is for certain "professional" audio interfaces like the M-Audio "Delta" series. It plays and records in full-duplex 10/12 channel audio streams with 24-bit precision at up to 96kHz sample frequency. Basically, such cards are intended for multi-tracking, that's why they do not support the usual stereo 16-bit linear format.
Unfortunately most audio ports expect the device to support stereo 16-bit format, which makes envy(4) devices nearly unusable with them. However recent ports by jakemsr@ make such cards much more usable in the future (some are already in -current).
Having devices that support a large number of channels and "unusual" encodings gives the basics for working on interesting userland code. It also constrains the generic audio(4) driver which helps us spotting (and fixing) bugs in the code common to all audio drivers.
Jacob Meuser: At the beginning of the release cycle, work was still focusd on fixing existing issues in audio(4) ad ossaudio(3), the userland OSS emulation layer. Once the high level audio interfaces were working to a satisfactory level, focus switched to the low level drivers.
Changes for auich(4), eso(4), auvia(4) and ac97(4) were brought in from NetBSD, which fixed most of the unresolved bugs in the gnats database.
The ac97(4) and auvia(4) changes allowed for multichannel playback if the codec supported it. It just so happens that I have such devices. I kind of liked that, so I added support for multichannel playback to cmpci(4) as well.
Pages: 1, 2