If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: >>> and later I found out it was caused by commit 1.48.2.16: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html >> This isn't consistent with what I'm finding. For one thing, rev. >> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there >> anyways. Also, that's not the change I made to my local sources to get >> my gif(4) tunnel working. Are you sure about this? :-) > > I'm following -STABLE, and 1.48.2.16 is in there. Since it was > committed on 29 Nov, I suspected it would end up in -RELEASE, but > apparently not. :) > > I explicitly tried reverting just this one commit, and for me it solved > the problem (i.e. the automagical addition of needed routing entries).
I tried this too and it didn't help. :-( Just to confirm, you're dealing with a gif(4) interface with an explicitly-configured destination address and a 128-bit prefixlen, yes? > So for you, reverting the combination of 1.48.2.14 and .15 works? Yep. BTW these two changes really go together, so it doesn't really make sense to revert just one of them (the commit logs implied that this would be fairly broken in other ways). > Maybe > there is something else involved too, for example the route command > itself? Not sure what you mean by this exactly...???... Here's what I've tested so far...in the table below, "work" means that the host route to the destination got installed correctly and "no work" means that it didn't. Base Local Patch Result ---- ----------- ------ 6.2-RELEASE Unmodified No work 6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work 6.2-STABLE Unmodified No work 6.2-STABLE Revert nd6.c 1.48.2.{14,15} Work 6.2-STABLE Revert nd6.c 1.48.2.16 No work I'm going to write up an entry for the 6.2-RELEASE errata notes documenting the existence of a problem and a workaround. We still need to figure out exactly what the right fix is. Testing results from other users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome. Bruce.
signature.asc
Description: OpenPGP digital signature