On Thu, Apr 24, 2014 at 01:43:16PM +0200, Henning Brauer wrote: > * Martin Pieuchot <mpieuc...@nolizard.org> [2014-04-24 13:24]: > > This ifp pointer is only needed by rt_getifa() to find an address, so > > make it a local variable. > > > > The rtrequest1(9) change might introduce a negligible slowdown since > > I remove the already known ifp pointer. But this only happens in the > > case described in the comment just before and I would bet because of > > carp_setroute(), still nobody to fix this? It's not better than > > OpenSSL... > > > > In the rtsock chunk, the two pointers are equivalent. > > > > Ok? > > yup. > > the carp route fiddling is pretty damn mad, and with the route > priorities and the ability to mark routes as down there should be a > much cleaner way to do this these days. > heck, the entire carp route fiddling needs to be reassesed. things > changed, i can\t even fully remeber why it is there (i think it was > about backup nodes still being able to reach a network only present on > the carp if or the like), and i seem to remember it doesn't quite work > as expected anyway, but don't take my word for it, memory REALLY fuzzy > on that front.
Years ago mpf@ told me, that the purpose of this function is to ssh from a carp master to a carp slave via the carp address. Or was it the other way around? The carp_setroute() function starts with the encouraging comment /* XXX this mess needs fixing */. When switching carp states fast, the routing table gets messed up. In our product we removed all calls to carp_setroute(sc, RTM_DELETE). There is one carp_setroute(sc, RTM_ADD) left. I don't know wether it is needed. I would recommend to try to delete the whole function and fix fallout if any. bluhm
