Contributed by rueda on from the mechanical-fish dept.
Stefan Sperling (stsp@) kindly sent in a report on his activities around p2k18:
The first item I worked on in Nantes was an update of the Apache Subversion port to the freshly released version 1.10.0. This in itself was a very small amount of work to do. However, having implemented several new features in the upstream code base since Subversion 1.9 was released over 3 years ago, committing this update to the OpenBSD ports tree felt like a huge relief. Doing some downstream packaging meant finally applying the last bits of finish to the coating after years of work. Stuart Henderson (sthen@) and Philip Guenther (guenther@) provided feedback and helped with testing.
With that done, I tried to find out why there was no package for net/tor on armv7 in OpenBSD 6.3. This turned out to be a side-effect of an upstream change for libbacktrace support. Mark Kettenis (kettenis@) confirmed my suspicion that we don't need this feature on OpenBSD anyway, so simply dropping the -fasynchronous-unwind-tables compiler option from the build scripts fixed the problem.
Looking through the list of packages on armv7 I realized that Subversion was missing as well. This was due to a build failure in the Apache Portable Runtime (APR) library, which is one of SVN's dependencies. This problem turned out to be an
#ifdefcondition added in upstream code which redefined the
offsetof()macro for some platforms for some reason. This replacement was disabled for FreeBSD already, and just adding OpenBSD to the list fixed the build. I mailed my patch to the APR project, advising caution that #ifdefs which require an ever-growing list of platforms to be added over time are not a good idea in the long term. I have received no response from the APR team yet…
Some time ago I noticed that during bsd.rd upgrades over iwm(4) dhclient was printing an error message about closed pipes. A quick discussion with Kenneth Westerback (krw@) resulted in the quick conclusion that this was just a cosmetic issue. With Ken's OK I committed a change which made dhclient only print such messages when debug output is requested.
A huge surprise to me was that OpenBSD's wireless department acquired new volunteer (and hopefully permanent) staff members during this hackathon: Both Peter Hessler (phessler@) and Paul Irofti (pirofti@) were sharing a table with me and were determined to work on the wireless stack! I'll leave the details to their respective reports but will add that this was a fun and very productive effort, with occasional additional support from Martin Pieuchot (mpi@) and Theo de Raadt (deraadt@). In particular, while hunting down an apparent issue related to Peter's work and WEP, we eventually figured out that Peter's changes weren't responsible at all, but that a commit of mine from 8 months ago had entirely broken WEP support in our wireless stack. Is anyone out there still using WEP?
I also fixed some minor issues with background scan support. The background scanning code was being triggered even on drivers that don't do background scanning. I made a small tweak to avoid the trigger in the first place if the driver cannot make use of it.
While testing Peter's changes, Peter and I found out that background scans were sometimes using stale scan results and tried to connect to APs which were no longer there; this problem is now also fixed.
On the final day of the hackathon, Jesper Wallin submitted a patch to the tech@ mailing list, which properly disabled background scanning if a fixed access point is hard-coded with the 'ifconfig bssid' command. This was a very welcome contribution which I committed on the same day.
While traveling home from Nantes I encountered a problem in access point selection. OpenBSD would prefer a 2 GHz AP even though a better 5 GHz AP was available. It turned out that this particular AP is sending beacons with rather low Tx power, so the 5 GHz AP appears to be more "distant" than the 2 GHz AP even though both APs were part of the same physical box. This could be fixed by preferring stronger received signal strength measurements from probe response frames which this AP sends at a regular Tx power level.
Nantes is a beautiful city and I took some time away from computer screens to take it in. After my previous visit in 2016 (p2k16) I regretted never having visited les machines de l'île which were in walking distance from the hackroom. This time I went multiple times to compensate. Diving down below les machine's carousel in a big yellow mechanical fish with Paul frantically pulling levers to wave the fish's fins around was a memorable moment. I took some photos of fish in the carousel and posted them here: https://mastodon.social/@stsp/99930230260077095
Thanks to Gilles Chehade (gilles@) for organizing this event and to Epitech Nantes for hosting it! I am also grateful to the sponsors of the OpenBSD Foundation, which covered our accommodation in Nantes.
(Comments are closed)
By Slag (slag) firstname.lastname@example.org on
Thanks for the great work, Stefan. Actually, I have half a closet full of older equipment that makes occasional use of WEP and WPA1 for moving files around (via older 16-bit pcmcia adapters) when a wired connection is not handy or convenient. I do not keep WEP or WPA1 enabled on the AP for obvious reasons, but having the ability to push data around to older machines wirelessly is a nice fallback capability, even if it ends up being deprecated some day. If you need an older IBM 560 with an Orinoco card for testing, I can probably supply you with one. ;-)
By Slag (slag) email@example.com on
Brief correction: most wifi adapters (incl. Orinoco) and newer ethernet cards are 32-bit cardbus cards, though the early generation pcmcia ethernet/token-ring cards are all generally 16-bit peripherals.
By Stefan Sperling (stsp) firstname.lastname@example.org on http://stsp.name
Thanks for the offer but I don't need more old hardware right now. I still have a pcmcia orinoco card, and also USB wi(4) devices.
Back when OpenBSD didn't support WPA yet a common recommendation was to not bother with WEP at all but run an open wifi and layer a VPN from client to AP on top of it. I think that's still a better solution than WEP and WPA1 today, as long as your wireless clients can run the necessary VPN software (which is the case for OpenBSD clients).
By Paul 'WEiRD' de Weerd (weerd) email@example.com on https://undeadly.org
Bit of a late reply, but still.
I think there's still a benefit in WEP over open networks: the security of the client device.
Many clients auto-connect to "known" networks. They broadcast the full set of known networks, looking for them frequently while their wifi nic is on and not connected. Having a WEP key in place prevents someone from just setting the SSID and making the client connect.
Open networks are evil. Those of us who are security conscious may be OK connecting to open networks and protecting our traffic with higher layer encryption (VPN / SSH / TLS etc), but the majority of users need (technological) help to protect their devices. That's why I think WEP is better than open networks.