| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
by `debug commands <level>' in the configuration. Level 0 means
no tracing, 1 means connections only, 2 includes all commands.
|
|
|
|
o Use `expr' instead of `NUM' and `ipa' instead of `IPA',
so that defined symbols work everywhere.
o `define' now accepts both numbers and IP addresses.
o Renamed `ipa' in filters to `fipa'.
Pavel, please update filters to accept define'd symbols as well.
|
|
given network.
|
|
Had to rename `prefix' in filters to `fprefix'.
|
|
exception that it doesn't print the routes themselves.
|
|
|
|
show the routing table as exported to the protocol given resp. as returned
from its import control hook.
To get handling of filtered extended attributes right (even in the old
`show route where <filter>' command), the get_route_info hook gets an
attribute list and all protocol specific rte attributes are contained
there as temporary ones. Updated RIP to do that.
Added ea_append() which joins two ea_list's.
|
|
|
|
C declarations etc.).
|
|
|
|
|
|
|
|
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).
|
|
they can be made configurable if it turns out to be useful.
|
|
symbols of libreadline :-(
|
|
Added `show symbols' command which dumps whole symbol table together
with symbol types etc.
|
|
used for automatic generation of instance names.
protocol->name is the official name
protocol->template is the name template (usually "name%d"),
should be all lowercase.
Updated all protocols to define the templates, checked that their configuration
grammar includes proto_name which generates the name and interns it in the
symbol table.
|
|
(proto_list) and per-type one (original lists). A lot of things simplified.
Implemented `disable', `enable' and `restart' CLI commands.
|
|
|
|
|
|
Removed CLI tests, real commands now serve as much better examples.
|
|
with the other commands.
|
|
Pavel, please check my addition to filter/config.Y.
|
|
|
|
of 2000000000 (BTW who wrote that???)
|
|
|
|
show protocols (incomplete).
|
|
To define a new command, just add a new rule to the gramar:
CF_CLI(COMMAND NAME, arguments, help-args, help-text) {
what-should-the-command-do
} ;
where <arguments> are appended to the RHS of the rule, <help-args> is the
argument list as shown in the help and <help-text> is description of the
command for the help.
<what-should-the-command-do> is a C code snippet to be executed. It should
not take too much time to execute. If you want to print out a lot of
information, you can schedule a routine to be called after the current
buffer is flushed by making cli->cont point to the routine (see the
TEST LONG command definition for an example); if the connection is closed
in the meantime, cli->cleanup gets called.
You can access `struct cli' belonging to the connection you're currently
servicing as this_cli, but only during parse time, not from routines scheduled
for deferred execution.
Functions to call inside command handlers:
cli_printf(cli, code, printf-args) -- print text to CLI connection,
<code> is message code as assigned in doc/reply_codes or a negative
one if it's a continuation line.
cli_msg(code, printf-args) -- the same for this_cli.
Use 'sock -x bird.ctl' for connecting to the CLI until a client is written.
|
|
|
|
we want to allow filter and similar complex constructs to be used in commands
and we should avoid code duplication), only with CLI_MARKER token prepended
before the whole input.
Defined macro CF_CLI(cmd, args, help) for defining CLI commands in .Y files.
The first argument specifies the command itself, the remaining two arguments
are copied to the help file (er, will be copied after the help file starts
to exist). This macro automatically creates a skeleton rule for the command,
you only need to append arguments as in:
CF_CLI(STEAL MONEY, <$>, [[Steal <$> US dollars or equivalent in any other currency]]): NUM {
cli_msg(0, "%d$ stolen", $3);
} ;
Also don't forget to reset lexer state between inputs.
|
|
|
|
but the core routines are there and seem to be working.
o lib/ipv6.[ch] written
o Lexical analyser recognizes IPv6 addresses and when in IPv6
mode, treats pure IPv4 addresses as router IDs.
o Router ID must be configured manually on IPv6 systems.
o Added SCOPE_ORGANIZATION for org-scoped IPv6 multicasts.
o Fixed few places where ipa_(hton|ntoh) was called as a function
returning converted address.
|
|
o Parsing of interface patterns moved to generic code,
introduced this_ipatt which works similarly to this_iface.
o Interface patterns now support selection by both interface
names and primary IP addresses.
o Proto `direct' updated.
o RIP updated as well, it also seems the memory corruption
bug there is gone.
|
|
|
|
multiple inclusions.
|
|
do nothing more advanced for them
|
|
definitely gone. Both rte_update() and rte_discard() have an additional
argument telling which table should they modify.
Also, rte_update() no longer walks the whole protocol list -- each table
has a list of all protocols connected to this table and having the
rt_notify hook set. Each protocol can also freely decide (by calling
proto_add_announce_hook) to connect to any other table, but it will
be probably used only by the table-to-table protocol.
The default debugging dumps now include all routing tables and also
all their connections.
|
|
version:
EXPORT <filter-spec> for outbound routes (i.e., those announced
by BIRD to the rest of the world).
IMPORT <filter-spec> for inbound routes (i.e., those imported
by BIRD from the rest of the world).
where <filter-spec> is one of:
ALL pass all routes
NONE drop all routes
FILTER <name> use named filter
FILTER { <filter> } use explicitly defined filter
For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes
the kernel protocol, so that you need to add EXPORT ALL to get the previous
configuration of kernel syncer (as usually, see doc/bird.conf.example for
a bird.conf example :)).
|
|
whitespace/semicolon rules for whole config file:
o All non-zero amounts of whitespace are equivalent to single space
(aka `all the whitespace has been born equal' ;-)).
o Comments count as whitespace.
o Whitespace has no syntactic signifance (it can only separate lexical
elements).
o Consequence: line ends are no longer treated as `;'s.
o Every declaration must be terminated by an explicit `;' unless
or by a group enclosed in `{' and `}'.
|
|
o Nothing is configured automatically. You _need_ to specify
the kernel syncer in config file in order to get it started.
o Syncing has been split to route syncer (protocol "Kernel") and
interface syncer (protocol "Device"), device routes are generated
by protocol "Direct" (now can exist in multiple instances, so that
it will be possible to feed different device routes to different
routing tables once multiple tables get supported).
See doc/bird.conf.example for a living example of these shiny features.
|
|
modifying filters yet) to be attached to protocol instances.
|
|
state machines. Full explanation will follow soon.
|
