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 #ifdef condition 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.

Thanks Stefan!

(Comments are closed)

Comments

By
Slag (slag) slag@sdf.org
on 2018-05-10 04:14

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. ;-)

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

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.