Jerry/bird
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
bird/nest/config.Y

365 lines
8.7 KiB
Plaintext
Raw Normal View History

Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
/*
* BIRD -- Core Configuration
*
Split off general commands to cmds.c. Added `show symbols' command which dumps whole symbol table together with symbol types etc.
2000-01-19 20:30:19 +08:00
* (c) 1998--2000 Martin Mares <mj@ucw.cz>
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
CF_HDR
Added configuration of the device internal protocol. This is primarily intended to serve as an example of interface pattern list use. As a side effect, you can disable generating of device routes by disabling this protocol.
1998-11-30 06:03:58 +08:00
#include "nest/rt-dev.h"
Skeleton for password handling, currently I only build structures and do nothing more advanced for them
1999-05-26 22:24:57 +08:00
#include "nest/password.h"
Split off general commands to cmds.c. Added `show symbols' command which dumps whole symbol table together with symbol types etc.
2000-01-19 20:30:19 +08:00
#include "nest/cmds.h"
Added configuration of the device internal protocol. This is primarily intended to serve as an example of interface pattern list use. As a side effect, you can disable generating of device routes by disabling this protocol.
1998-11-30 06:03:58 +08:00
Split CF_HDR section to CF_HDR (only includes) and CF_DEFINES (defines, C declarations etc.).
2000-04-28 23:11:10 +08:00
CF_DEFINES
static struct proto_config *this_proto;
static struct iface_patt *this_ipatt;
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
CF_DECLS
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-27 05:44:38 +08:00
CF_KEYWORDS(ROUTER, ID, PROTOCOL, PREFERENCE, DISABLED, DEBUG, ALL, OFF, DIRECT)
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_KEYWORDS(INTERFACE, IMPORT, EXPORT, FILTER, NONE, TABLE, STATES, ROUTES, FILTERS)
Added tracing of interface events.
2000-03-13 04:50:35 +08:00
CF_KEYWORDS(PASSWORD, FROM, PASSIVE, TO, ID, EVENTS, PACKETS, PROTOCOLS, INTERFACES)
Implemented `show route count' which is `show route stats' with exception that it doesn't print the routes themselves.
2000-05-08 22:58:00 +08:00
CF_KEYWORDS(PRIMARY, STATS, COUNT)
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
An example of how to define enums.
1999-11-15 19:36:22 +08:00
CF_ENUM(T_ENUM_RTS, RTS_, DUMMY, STATIC, INHERIT, DEVICE, STATIC_DEVICE, REDIRECT,
Removed RTS_RIP_EXT.
2000-05-05 05:23:10 +08:00
RIP, OSPF, OSPF_EXT, OSPF_IA, OSPF_BOUNDARY, BGP, PIPE)
An example of how to define enums.
1999-11-15 19:36:22 +08:00
Basic support for IPv6. The system-dependent part doesn't work yet, 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.
1999-08-04 03:36:06 +08:00
%type <i32> idval
Changed syntax of attaching filters to protocols to hopefully the final 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 :)).
1999-04-06 04:15:31 +08:00
%type <f> imexport
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
%type <r> rtable
Skeleton for password handling, currently I only build structures and do nothing more advanced for them
1999-05-26 22:24:57 +08:00
%type <p> password_list password_begin
Added few basic commands: show status, show interfaces [summary], show protocols (incomplete).
1999-11-25 23:35:30 +08:00
%type <s> optsym
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
%type <ra> r_args
Added commands `show route protocol <p>' and `show route import <p>' which 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.
2000-05-07 06:57:39 +08:00
%type <i> echo_mask echo_size debug_mask debug_list debug_flag import_or_proto
Reworked proto lists -- each proto is now in two lists: the global one (proto_list) and per-type one (original lists). A lot of things simplified. Implemented `disable', `enable' and `restart' CLI commands.
2000-01-17 07:30:06 +08:00
%type <t> proto_patt
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
CF_GRAMMAR
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
/* Setting of router ID */
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
CF_ADDTO(conf, rtrid)
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
After today's lengthy discussions about filter syntax, let's clean up 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 `}'.
1999-03-30 03:04:14 +08:00
rtrid: ROUTER ID idval ';' {
Implemented new configuration/reconfiguration interface and defined protocol state machines. Full explanation will follow soon.
1999-02-06 05:37:34 +08:00
new_config->router_id = $3;
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
}
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
;
idval:
Basic support for IPv6. The system-dependent part doesn't work yet, 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.
1999-08-04 03:36:06 +08:00
NUM { $$ = $1; }
| RTRID
| IPA {
#ifndef IPV6
$$ = ipa_to_u32($1);
#else
cf_error("Router IDs must be entered as hexadecimal numbers in IPv6 version");
#endif
}
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
;
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
/* Creation of routing tables */
CF_ADDTO(conf, newtab)
newtab: TABLE SYM {
Garbage collector events and counters are now per table and one day they can be made configurable if it turns out to be useful.
2000-03-05 06:21:06 +08:00
rt_new_table($2);
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
}
;
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
/* Definition of protocols */
CF_ADDTO(conf, proto)
proto_start: PROTOCOL
proto_name:
/* EMPTY */ {
Separated `official protocol names' used in status dumps from name templates 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.
2000-01-17 19:52:50 +08:00
struct symbol *s = cf_default_name(this_proto->protocol->template, &this_proto->protocol->name_counter);
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
s->class = SYM_PROTO;
s->def = this_proto;
this_proto->name = s->name;
}
| SYM {
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
cf_define_symbol($1, SYM_PROTO, this_proto);
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
this_proto->name = $1->name;
}
;
proto_item:
/* EMPTY */
Trivial 15-line bison excercise: Implemented expressions including user-defined numeric symbols. Whenever possible, use `expr' instead of `NUM' to get full express ion power :-)
1998-11-28 05:32:45 +08:00
| PREFERENCE expr {
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
if ($2 < 0 || $2 > 255) cf_error("Invalid preference");
this_proto->preference = $2;
}
Allow setting debug value and `disabled' flag in protocol definition.
1998-11-29 22:40:39 +08:00
| DISABLED { this_proto->disabled = 1; }
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
| DEBUG debug_mask { this_proto->debug = $2; }
Changed syntax of attaching filters to protocols to hopefully the final 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 :)).
1999-04-06 04:15:31 +08:00
| IMPORT imexport { this_proto->in_filter = $2; }
| EXPORT imexport { this_proto->out_filter = $2; }
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
| TABLE rtable { this_proto->table = $2; }
Changed syntax of attaching filters to protocols to hopefully the final 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 :)).
1999-04-06 04:15:31 +08:00
;
imexport:
FILTER filter { $$ = $2; }
BGP now handles incoming routes (IPv4 only).
2000-04-01 17:17:33 +08:00
| where_filter
Changed syntax of attaching filters to protocols to hopefully the final 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 :)).
1999-04-06 04:15:31 +08:00
| ALL { $$ = FILTER_ACCEPT; }
| NONE { $$ = FILTER_REJECT; }
First attempt at protocol configuration (now done only for RIP).
1998-11-28 05:09:57 +08:00
;
From now we support multiple tables. The master_table variable is 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.
1999-05-18 04:14:52 +08:00
rtable:
SYM {
if ($1->class != SYM_TABLE) cf_error("Table name expected");
$$ = $1->def;
}
;
Added configuration of default protocol debugging flags.
2000-03-08 05:50:03 +08:00
CF_ADDTO(conf, debug_default)
debug_default:
DEBUG PROTOCOLS debug_mask { new_config->proto_default_debug = $3; }
;
Cleaned up handling of interface patterns: 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.
1999-08-04 03:30:49 +08:00
/* Interface patterns */
iface_patt:
TEXT { this_ipatt->pattern = $1; this_ipatt->prefix = IPA_NONE; this_ipatt->pxlen = 0; }
Unified parsing of prefixes. Had to rename `prefix' in filters to `fprefix'.
2000-05-13 19:17:49 +08:00
| prefix { this_ipatt->pattern = NULL; this_ipatt->prefix = $1.addr; this_ipatt->pxlen = $1.len; }
| TEXT prefix { this_ipatt->pattern = $1; this_ipatt->prefix = $2.addr; this_ipatt->pxlen = $2.len; }
Cleaned up handling of interface patterns: 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.
1999-08-04 03:30:49 +08:00
;
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-27 05:44:38 +08:00
/* Direct device route protocol */
Added configuration of the device internal protocol. This is primarily intended to serve as an example of interface pattern list use. As a side effect, you can disable generating of device routes by disabling this protocol.
1998-11-30 06:03:58 +08:00
CF_ADDTO(proto, dev_proto '}')
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-27 05:44:38 +08:00
dev_proto_start: proto_start DIRECT {
struct rt_dev_config *p = proto_config_new(&proto_device, sizeof(struct rt_dev_config));
this_proto = &p->c;
p->c.preference = DEF_PREF_DIRECT;
init_list(&p->iface_list);
Added configuration of the device internal protocol. This is primarily intended to serve as an example of interface pattern list use. As a side effect, you can disable generating of device routes by disabling this protocol.
1998-11-30 06:03:58 +08:00
}
;
dev_proto:
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-27 05:44:38 +08:00
dev_proto_start proto_name '{'
Added configuration of the device internal protocol. This is primarily intended to serve as an example of interface pattern list use. As a side effect, you can disable generating of device routes by disabling this protocol.
1998-11-30 06:03:58 +08:00
| dev_proto proto_item ';'
| dev_proto dev_iface_list ';'
;
Cleaned up handling of interface patterns: 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.
1999-08-04 03:30:49 +08:00
dev_iface_entry_init:
/* EMPTY */ {
struct rt_dev_config *p = (void *) this_proto;
struct iface_patt *k = cfg_allocz(sizeof(struct iface_patt));
add_tail(&p->iface_list, &k->n);
this_ipatt = k;
Added configuration of the device internal protocol. This is primarily intended to serve as an example of interface pattern list use. As a side effect, you can disable generating of device routes by disabling this protocol.
1998-11-30 06:03:58 +08:00
}
;
Cleaned up handling of interface patterns: 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.
1999-08-04 03:30:49 +08:00
dev_iface_entry:
dev_iface_entry_init iface_patt
;
dev_iface_list:
INTERFACE dev_iface_entry
| dev_iface_list ',' dev_iface_entry
;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
/* Debug flags */
debug_mask:
ALL { $$ = ~0; }
| OFF { $$ = 0; }
| '{' debug_list '}' { $$ = $2; }
;
debug_list:
debug_flag
| debug_list ',' debug_flag { $$ = $1 | $3; }
;
debug_flag:
STATES { $$ = D_STATES; }
| ROUTES { $$ = D_ROUTES; }
| FILTERS { $$ = D_FILTERS; }
Added tracing of interface events.
2000-03-13 04:50:35 +08:00
| INTERFACES { $$ = D_IFACES; }
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
| EVENTS { $$ = D_EVENTS; }
| PACKETS { $$ = D_PACKETS; }
;
Cleaned up handling of interface patterns: 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.
1999-08-04 03:30:49 +08:00
/* Password lists */
Skeleton for password handling, currently I only build structures and do nothing more advanced for them
1999-05-26 22:24:57 +08:00
password_begin:
PASSWORD TEXT {
last_password_item = cfg_alloc(sizeof (struct password_item));
last_password_item->password = $2;
last_password_item->from = 0;
Use TIME_INFINITY for initialization of password entries instead of 2000000000 (BTW who wrote that???)
1999-11-30 22:02:27 +08:00
last_password_item->to = TIME_INFINITY;
Skeleton for password handling, currently I only build structures and do nothing more advanced for them
1999-05-26 22:24:57 +08:00
last_password_item->id = 0;
last_password_item->next = NULL;
$$=last_password_item;
}
;
password_items:
/* empty */ { }
Change format of passwords (less ;'s) and fix password.h to allow multiple inclusions.
1999-05-26 22:37:07 +08:00
| FROM datetime password_items { last_password_item->from = $2; }
| TO datetime password_items { last_password_item->to = $2; }
Added PASSIVE option to paswwords.
1999-06-01 01:12:00 +08:00
| PASSIVE datetime password_items { last_password_item->passive = $2; }
Change format of passwords (less ;'s) and fix password.h to allow multiple inclusions.
1999-05-26 22:37:07 +08:00
| ID NUM password_items { last_password_item->id = $2; }
Skeleton for password handling, currently I only build structures and do nothing more advanced for them
1999-05-26 22:24:57 +08:00
;
password_list:
/* empty */ { $$ = NULL; }
Change format of passwords (less ;'s) and fix password.h to allow multiple inclusions.
1999-05-26 22:37:07 +08:00
| password_begin password_items ';' password_list {
Obvious bugs in authentication fixed.
1999-10-02 18:44:48 +08:00
$1->next = $4;
$$ = $1;
Skeleton for password handling, currently I only build structures and do nothing more advanced for them
1999-05-26 22:24:57 +08:00
}
;
Parse CLI commands. We use the same parser as for configuration files (because 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.
1999-11-01 01:47:47 +08:00
/* Core commands */
Completion works. Unfortunately, we have to access a couple of internal symbols of libreadline :-(
2000-02-18 07:37:16 +08:00
CF_CLI_HELP(SHOW, ..., [[Show status information]])
Added few basic commands: show status, show interfaces [summary], show protocols (incomplete).
1999-11-25 23:35:30 +08:00
Split off general commands to cmds.c. Added `show symbols' command which dumps whole symbol table together with symbol types etc.
2000-01-19 20:30:19 +08:00
CF_CLI(SHOW STATUS,,, [[Show router status]])
{ cmd_show_status(); }
Added few basic commands: show status, show interfaces [summary], show protocols (incomplete).
1999-11-25 23:35:30 +08:00
CF_CLI(SHOW PROTOCOLS, optsym, [<name>], [[Show routing protocols]])
`show interfaces' and `show protocols' works.
1999-11-30 20:57:14 +08:00
{ proto_show($3, 0); } ;
Renamed SHOW PROTOCOLS VERBOSE to SHOW PROTOCOLS ALL to be consistent with the other commands.
1999-12-03 19:10:50 +08:00
CF_CLI(SHOW PROTOCOLS ALL, optsym, [<name>], [[Show routing protocol details]])
`show interfaces' and `show protocols' works.
1999-11-30 20:57:14 +08:00
{ proto_show($4, 1); } ;
Added few basic commands: show status, show interfaces [summary], show protocols (incomplete).
1999-11-25 23:35:30 +08:00
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
optsym:
SYM
| /* empty */ { $$ = NULL; }
;
Added few basic commands: show status, show interfaces [summary], show protocols (incomplete).
1999-11-25 23:35:30 +08:00
CF_CLI(SHOW INTERFACES,,, [[Show network interfaces]])
{ if_show(); } ;
CF_CLI(SHOW INTERFACES SUMMARY,,, [[Show summary of network interfaces]])
{ if_show_summary(); } ;
Implemented `show route <...> stats'.
2000-05-07 19:28:59 +08:00
CF_CLI(SHOW ROUTE, r_args, [<prefix>] [table <t>] [filter <f>] [all] [primary] [(import|protocol) <p>] [stats], [[Show routing table]])
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
{ rt_show($3); } ;
r_args:
/* empty */ {
$$ = cfg_allocz(sizeof(struct rt_show_data));
$$->pxlen = 256;
$$->filter = FILTER_ACCEPT;
$$->table = config->master_rtc->table;
}
Unified parsing of prefixes. Had to rename `prefix' in filters to `fprefix'.
2000-05-13 19:17:49 +08:00
| r_args prefix {
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
$$ = $1;
if ($$->pxlen != 256) cf_error("Only one prefix expected");
Unified parsing of prefixes. Had to rename `prefix' in filters to `fprefix'.
2000-05-13 19:17:49 +08:00
$$->prefix = $2.addr;
$$->pxlen = $2.len;
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
}
| r_args TABLE SYM {
$$ = $1;
if ($3->class != SYM_TABLE) cf_error("%s is not a table", $3->name);
$$->table = ((struct rtable_config *)$3->def)->table;
}
| r_args FILTER filter {
$$ = $1;
Implemented `show route where <condition>' command. Pavel, please check my addition to filter/config.Y.
1999-12-02 22:04:44 +08:00
if ($$->filter != FILTER_ACCEPT) cf_error("Filter specified twice");
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
$$->filter = $3;
}
Implemented `show route where <condition>' command. Pavel, please check my addition to filter/config.Y.
1999-12-02 22:04:44 +08:00
| r_args where_filter {
$$ = $1;
if ($$->filter != FILTER_ACCEPT) cf_error("Filter specified twice");
$$->filter = $2;
}
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
| r_args ALL {
$$ = $1;
$$->verbose = 1;
}
Added commands `show route protocol <p>' and `show route import <p>' which 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.
2000-05-07 06:57:39 +08:00
| r_args PRIMARY {
$$ = $1;
$$->primary_only = 1;
}
| r_args import_or_proto SYM {
struct proto_config *c = (struct proto_config *) $3->def;
$$ = $1;
if ($$->import_mode) cf_error("Protocol specified twice");
if ($3->class != SYM_PROTO || !c->proto) cf_error("%s is not a protocol", $3->name);
$$->import_mode = $2;
$$->primary_only = 1;
$$->import_protocol = c->proto;
$$->running_on_config = c->proto->cf->global;
}
Implemented `show route <...> stats'.
2000-05-07 19:28:59 +08:00
| r_args STATS {
$$ = $1;
$$->stats = 1;
}
Implemented `show route count' which is `show route stats' with exception that it doesn't print the routes themselves.
2000-05-08 22:58:00 +08:00
| r_args COUNT {
$$ = $1;
$$->stats = 2;
}
Added commands `show route protocol <p>' and `show route import <p>' which 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.
2000-05-07 06:57:39 +08:00
;
import_or_proto:
IMPORT { $$ = 1; }
| PROTOCOL { $$ = 2; }
Added dumping of routing tables (`show route'). This includes filtering.
1999-12-01 23:10:21 +08:00
;
Split off general commands to cmds.c. Added `show symbols' command which dumps whole symbol table together with symbol types etc.
2000-01-19 20:30:19 +08:00
CF_CLI(SHOW SYMBOLS, optsym, [<symbol>], [[Show all known symbolic names]])
{ cmd_show_symbols($3); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI_HELP(DUMP, ..., [[Dump debugging information]])
CF_CLI(DUMP RESOURCES,,, [[Dump all allocated resource]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ rdump(&root_pool); cli_msg(0, ""); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI(DUMP SOCKETS,,, [[Dump open sockets]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ sk_dump_all(); cli_msg(0, ""); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI(DUMP INTERFACES,,, [[Dump interface information]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ if_dump_all(); cli_msg(0, ""); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI(DUMP NEIGHBORS,,, [[Dump neighbor cache]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ neigh_dump_all(); cli_msg(0, ""); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI(DUMP ATTRIBUTES,,, [[Dump attribute cache]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ rta_dump_all(); cli_msg(0, ""); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI(DUMP ROUTES,,, [[Dump routing table]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ rt_dump_all(); cli_msg(0, ""); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI(DUMP PROTOCOLS,,, [[Dump protocol information]])
Implemented echoing of log messages to CLI connections. Just try `echo all'.
1999-12-06 20:34:45 +08:00
{ protos_dump_all(); cli_msg(0, ""); } ;
CF_CLI(ECHO, echo_mask echo_size, [all | off | <mask>] [<buffer-size>], [[Configure echoing of log messages]]) {
cli_set_log_echo(this_cli, $2, $3);
cli_msg(0, "");
} ;
echo_mask:
ALL { $$ = ~0; }
| OFF { $$ = 0; }
| NUM
;
echo_size:
/* empty */ { $$ = 4096; }
| NUM {
if ($1 < 256 || $1 > 65536) cf_error("Invalid log buffer size");
$$ = $1;
}
;
Parse CLI commands. We use the same parser as for configuration files (because 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.
1999-11-01 01:47:47 +08:00
Reworked proto lists -- each proto is now in two lists: the global one (proto_list) and per-type one (original lists). A lot of things simplified. Implemented `disable', `enable' and `restart' CLI commands.
2000-01-17 07:30:06 +08:00
CF_CLI(DISABLE, proto_patt, <protocol> | <pattern> | all, [[Disable protocol]])
{ proto_xxable($2, 0); } ;
CF_CLI(ENABLE, proto_patt, <protocol> | <pattern> | all, [[Enable protocol]])
{ proto_xxable($2, 1); } ;
CF_CLI(RESTART, proto_patt, <protocol> | <pattern> | all, [[Restart protocol]])
{ proto_xxable($2, 2); } ;
Added protocol debugging flags (protocol.h: D_xxx), parsing of them 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).
2000-03-08 04:49:48 +08:00
CF_CLI_HELP(DEBUG, ..., [[Control protocol debugging]])
CF_CLI(DEBUG, proto_patt debug_mask, (<protocol> | <pattern> | all) (all | off | { states | routes | filters | events | packets }), [[Control protocol debugging]])
{ proto_debug($2, $3); }
Reworked proto lists -- each proto is now in two lists: the global one (proto_list) and per-type one (original lists). A lot of things simplified. Implemented `disable', `enable' and `restart' CLI commands.
2000-01-17 07:30:06 +08:00
proto_patt:
SYM { $$ = $1->name; }
| ALL { $$ = "*"; }
| TEXT
;
Parser fragment for the core. Now handles only router ID setting.
1998-11-28 03:37:57 +08:00
CF_CODE
CF_END
Reference in a new issue Copy permalink