Only to be replaced with beta7 the next day!OK, so beta6 was quite a big change from beta5 - we re-wrote a lot of the client state engine to work around timeouts and timers instead of mini timeout loops with an overall timeout. This change was needed to integrate the ARP code better so that we can send our ARP announcements /after dhcpcd has forked into the background so we're faster in the userland, and to respect RFC 2131 and RFC 3927 transmission times. This also allows us to defend our IPV4LL address whilst trying to negotiate a DHCP lease, although the conflict and defence part of RFC 3927 hasn't been fully tested yet.Whilst making this change, a small bug crept into the code that converts a timeval structure into a timeout suitable for the poll(2) function which caused some interesting results and frustrated users. Oddly enough, I did see it before I released beta6, but only my core2 quad. I put this down to a bug in gcc-4.3.1 and that glibc-2.8 snapshot as my other machines didn't have it. Turns out that the problem only showed itself on fast machines - heh.We've been testing beta6 for some time, so even with that bug I don't expect anymore issues. I'm also working on getting dhcpcd to send Vendor Encapsulated Options (code 43) in the DHCP messages so it inform DHCP servers about things. This is only useful for custom built devices talking to a custom built server, but I've had a user request it and it's trivial in the DHCP part so won't need much testing.I'm on holiday next week, and hope to release dhcpcd-4.0.0-rc1 soon after I get back so we can start a stable process for this :)
And without any major catastrophic events either :D However, one catastrophe is the lack of wedding pictures on this blog! So here's a picture of a passionate snog on our first holiday.
That picture was taken over 5 years ago now and each and every kiss is new, exciting and very very intoxicating }:) We're still madly in love with each other, probably more-so than ever.