On Wed, 2007-24-10 at 12:30 +0900, Masahide NAKAMURA wrote: > At IPsec point of view, actually "SPI mismatch" caused by user configuration > cannot be identified easily since identify of SAD is consist of SPI, address > and > protocol(ESP/AH...) and linux SAD uses hash database. It is database identify > mismatch. Then, SPI mismatch goes "NoStates" at my patch. > OTOH Key mismatch goes "ProtoError" since esp[46]_input returns error.
Would be useful to just document what you said above so that user doesnt have to intepret it. > Thanks for pointing the RFC. I've read it, however, I cannot find them at the > RFC. My bad. > > In any case, it seems to me to be more accurate to not call them MIB > > stats if they are not. This doesnt qualify using the macros, utilities > > etc used for MIBs. > BTW, I meant "doesnt disqualify them" above;-> > How about assuming it as "private MIB" of linux? Ok, makes sense to me now - that would be a good choice (i dont see any confusion with enteprise mib). > Shouldn't we have something after XFRM_ to distinguish from other XFRM > macros? > It is not needed - I am sorry that i missed the "Linux MIB" part in your emails so far. That would be good enough. > > > > 2) Why /proc? Are you going to make these available also via netlink? > > > > > > Because /proc is easy to see it without any modified application. > > > If you want the netlink interface, I can do it as the next step. Do you > > > want it? > > > > Absolutely - it would be much appreciated. And if you dont have time, I > > will write and test the user space part extension. > > Thanks. After my first step is completed, could you write the netlink part? Thanks. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
