Contributed by pitrh on from the dept.
Stefan Sperling (stsp@) may not have landed just yet, but he did file this report from the newly concluded hackathon:
The net80211 wireless code has plenty of comments referring to sections of and old version of the 802.11 standard. I started updating such references in the ieee80211.h header to the 802.11-2012 ("11n") version of the standard, and also added new macros for meta data added in this newer version.
Next I wanted to inspect 11n meta data floating around the hackroom. There were two access points run by us, and plenty additional ones already present in the venue. I taught tcpdump(8) about 11n meta data in beacons broadcasted by access points to see which 11n features they support. Because many 11n features are in fact optional (the lowest required feature set of a client provides only 65Mbit/s, not much more than the 54Mbit/s offered by older standards), inspecting feature flags in beacons is the only way to know what a particular 11n AP can really do.
I had brought with me a bag full of USB wifi devices I've collected, some of which already work and some not. Some should be working but are somehow broken, either by hardware issues or because of driver bugs. With help from mpi@ I fixed a problem in the urtw(4) driver which brought down the entire system if a device with a slightly damaged connector was attached. We also tried to fix a problem in the uath(4) driver which fails to initialise any of 3 supposedly supported devices thrown at it. We didn't manage to figure this problem out, though.
I also looked into a crash that is caused by a race condition in the run(4) driver. This is not fixed yet because the solution is a bit more involved than expected. I ended up trying to hunt down a similar race in the iwm(4) driver. I have a diff for this that's almost ready, but testing by jca@ revieled my diff breaks suspend/resume for him most of the time. So more work is required and the diff did not get committed.
Partway through the hackathon tedu@ proposed an old diff of his to make our base ls(1) utlity display multi-byte characters. This led to a long discussion about how to expand UTF-8 support in base. The conclusion so far indicates that single-byte locales (such as ISO-8859-1 and KOI-8) will be removed from the base OS after the 5.8 release is cut. This simplifies things because the whole system only has to care about a single character encoding. We'll then have a full release cycle to bring UTF-8 support to more base system utilities such as vi(1), ksh(1), and mg(1). To help with this plan I started organizing a UTF-8-focused hackathon for some time later this year.
Thanks for the report and the great work, Stefan! We're looking forward to hearing about the upcoming developments already.
(Comments are closed)