Contributed by pitrh on from the well traveled bits dept.
Suprise upgrade to Business! Yay! Bumped by a paying customer to a seat with a non-functional entertainment unit. Boo. Running the length of Frankfurt airport to meet Theo's flight in time. Yay! No Theo. Boo. I can still meet the ANZAC contingent in Prague to share trip downtown. Yay! They walk right past me even with my UQ hat on. Boo. Yet Another Hackathon Travel Adventure.
The hackroom was awesome and guenther@ was kind enough to warn me not to sit at the desk that got too much morning sun.
First order of business, stsp@'s weird setup involving bridges and multiple dhclient clients. A bit of bpf(4) programming to restrict dhclient to handling ethernet packets unicast to its interface worked. Cool. Unfortunately it turned out some lazy dhcp servers always use ethernet broadcasts just because some lesser, non-OpenBSD clients ignore unicast packets until they have configured IP. Classic chicken and egg. So this was backed out just before 6.0. Sigh.
On the long lonely flight FRA to PRG I had an idea to improve our handling of dhcp leases on wireless interfaces. Why not record in the lease the SSID the lease was received on? And only retry leases from the current SSID when restarting dhclient on that interface? This might speed up reconnection and preserve leases relevant to other SSID's.
A day or so of hacking and it worked! A lively discussion with sthen@ resulted and the idea was shelved for further consideration post-6.0. Double sigh.
I then reopened a discussion with phessler@ on tweaking our routing messsage generation to ensure that relevant PID's are present in routing messages generated by the kernel in response to ioctl's. This would simplify and increase reliability of dhclient by ensuring it could recognize routing messages it caused. This was Peter's second or third tilt at this issue and he made some good progress. In the same vein we discussed getting SSID info into a routing message to make dhclient more aware of the details of SSID changes. Both are works in progress.
Diving back into dhclient code I discovered that in situations where multiple offers were received the unused offers were not being declined and discarded. Despite a clear comment saying that's what was being done! Thus dhclient might gradually use up more and more memory. And possibly be retrying offers that should have been discarded. The fix for this did make 6.0! Yay!
After the normal talk to interested parties at our hosting institution, I was delighted when David Vasek introduced himself. David has been a long time collaborator on 4K disk issues and had found another one. Our inode density calculation is a bit wonky on disks with non-512-byte sectors. I tried to put in a quick hack fixing this but David pointed out my fix was wrong and it was backed out for 6.0. Triple sigh.
David also produced a USB device we weren't handling correctly. But I didn't get to work on it at the hackathon.
And then it was over. Prague is an awesome city to visit. If only fewer people knew about it. Alexander and friends ran an excellent hackathon. Many thanks!
Thanks for the report and excellent work, Ken! And nice that some of this is even making it into 6.0!
(Comments are closed)