Sunday, January 21, 2007
Of All The Confounded Stupidity
IPv6 in FreeBSD 6.2-RELEASE is broken. It's also broken in 6.2-STABLE. It has been known to be broken since September. It was known to be broken in December. It was still broken when FreeBSD 6.2 was released on January 15. This isn't something that's just a tiny nuisance with a trivial workaround. This is a major piece of system functionality that is totally broken. With a stock release of FreeBSD 6.2 or 6.2-stable, you cannot use an IPv6 tunnel at all. Everything will report "no route to host".
Yet, despite this being a known problem, there's no mention of it at all in the release notes, and as of this writing there is still no mention of it in the errata.
This is the type of BS I'd expect from Linux or something. This is not the kind of low-quality, rush-job cockup that I'd expect out of the FreeBSD project. I'm sorely disappointed. I would never have built 6.2 and installed it had I known that IPv6 was in a nonworking state.
There's a fairly easy fix/workaround for those who want 6.2 (or have already gone to the trouble of installing it) and still need IPv6 to work:
First, go grab the diff between versions 1.48.2.15 and 1.48.2.16 of src/sys/netinet6/nd6.c. Save this in a file in your home directory called nd6.c.patch starting with the line that says "--- src/sys/netinet6/nd6.c 2006/10/07 18:31:27 1.48.2.15" (or if you save the whole thing, just delete the lines that precede this one).
Next,
Finally, rebuild your kernel. Do a
Maybe the FreeBSD project can gets its head out of its collective ass and add documentation about this major malfunction to the errata, and then for an encore, perhaps someone can see fit to fix this longtime breakage. IMO, 6.2 should never have been released with major feature set breakage of this severity.
And why aren't there test suites catching this kind of crap?
This is so disheartening. If I wanted to suffer through major feature set breakage, I'd run Linux. I have used FreeBSD for a good 11 years because of its former dedication to stability and quality, not because I liked to spend my afternoons chasing problems.
Yet, despite this being a known problem, there's no mention of it at all in the release notes, and as of this writing there is still no mention of it in the errata.
This is the type of BS I'd expect from Linux or something. This is not the kind of low-quality, rush-job cockup that I'd expect out of the FreeBSD project. I'm sorely disappointed. I would never have built 6.2 and installed it had I known that IPv6 was in a nonworking state.
There's a fairly easy fix/workaround for those who want 6.2 (or have already gone to the trouble of installing it) and still need IPv6 to work:
First, go grab the diff between versions 1.48.2.15 and 1.48.2.16 of src/sys/netinet6/nd6.c. Save this in a file in your home directory called nd6.c.patch starting with the line that says "--- src/sys/netinet6/nd6.c 2006/10/07 18:31:27 1.48.2.15" (or if you save the whole thing, just delete the lines that precede this one).
Next,
cd /usr/src/sys/netinet6 . Run patch -R < ~/nd6.c.patch. This has the effect of reverse patching the differences between those two versions of the file, backing out the last change that broke IPv6. This will also re-break the bug that the commit was trying to fix, but since that fix also completely broke IPv6, that's probably okay for now.Finally, rebuild your kernel. Do a
make clean first. I went as far as doing an rm -rf on the compile/KERNELNAME directory too, just to make sure everything got cleaned out.Maybe the FreeBSD project can gets its head out of its collective ass and add documentation about this major malfunction to the errata, and then for an encore, perhaps someone can see fit to fix this longtime breakage. IMO, 6.2 should never have been released with major feature set breakage of this severity.
And why aren't there test suites catching this kind of crap?
This is so disheartening. If I wanted to suffer through major feature set breakage, I'd run Linux. I have used FreeBSD for a good 11 years because of its former dedication to stability and quality, not because I liked to spend my afternoons chasing problems.
Labels: software
Subscribe to Posts [Atom]
