The core state machine was broken - it didn't free resources
in START -> DOWN transition and might freed resources after
UP -> STOP transition before protocol turned down. It leads
to deadlock on olock acquisition when lock was not freed
during previous stop.
The current behavior is that resources, allocated during
DOWN -> * transition, are freed in * -> DOWN transition,
and flushing (scheduled in UP -> *) just counteract
feeding (scheduled in * -> UP). Protocol fell down
when both flushing is done (if needed) and protocol
reports DOWN.
BTW, is thera a reason why neighbour cache item acquired
by protocol is not tracked by resource mechanism?
When protocol started, feeding was scheduled. If protocol
got down before feeding was executed, then function
responsible for connecting protocol to kernel routing
tables was called after the function responsible for
disconnecting, then resource pool of protocol was freed,
but freed linked list structures remains in the list.
Please try compiling your code with --enable-warnings to see them. (The
unused parameter warnings are usually bogus, the unused variable ones
are very useful, but gcc is unable to control them separately.)
of calling the protocols manually.
Implemented printing of dynamic attributes in `show route all'.
Each protocol can now register its own attribute class (protocol->attr_class,
set to EAP_xxx) and also a callback for naming and formatting of attributes.
The callback can return one of the following results:
GA_UNKNOWN Attribute not recognized.
GA_NAME Attribute name recognized and put to the buffer,
generic code should format the value.
GA_FULL Both attribute name and value put to the buffer.
Please update protocols generating dynamic attributes to provide
the attr_class and formatting hook.
in configuration files and commands for manipulating them.
Current debug message policy:
o D_STATES, D_ROUTES and D_FILTERS are handled in generic code.
o Other debug flags should be handled in the protocols and whenever
the flag is set, the corresponding messages should be printed
using calls to log(L_TRACE, ...), each message prefixed with
the name of the protocol instance. These messages should cover
the whole normal operation of the protocol and should be useful
for an administrator trying to understand what does the protocol
behave on his network or who is attempting to diagnose network
problems. If your messages don't fit to the categories I've defined,
feel free to add your own ones (by adding them to protocol.h
and on two places in nest/config.Y), but please try to keep the
categories as general as possible (i.e., not tied to your protocol).
o Internal debug messages not interesting even to an experienced
user should be printed by calling DBG() which is either void or
a call to debug() depending on setting of the LOCAL_DEBUG symbol
at the top of your source.
o Dump functions (proto->dump etc.) should call debug() to print
their messages.
o If you are doing any internal consistency checks, use ASSERT
or bug().
o Nobody shall ever call printf() or any other stdio functions.
Also please try to log any protocol errors you encounter and tag them
with the appropriate message category (usually L_REMOTE or L_AUTH). Always
carefully check contents of any message field you receive and verify all
IP addresses you work with (by calling ipa_classify() or by using the
neighbour cache if you want to check direct connectedness as well).
