bird/nest/config.Y

336 lines
8 KiB
Text
Raw Normal View History

/*
* BIRD -- Core Configuration
*
* (c) 1998--2000 Martin Mares <mj@ucw.cz>
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
CF_HDR
static struct proto_config *this_proto;
static struct iface_patt *this_ipatt;
#include "nest/rt-dev.h"
#include "nest/password.h"
#include "nest/cmds.h"
CF_DECLS
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)
2000-03-13 04:50:35 +08:00
CF_KEYWORDS(PASSWORD, FROM, PASSIVE, TO, ID, EVENTS, PACKETS, PROTOCOLS, INTERFACES)
1999-11-15 19:36:22 +08:00
CF_ENUM(T_ENUM_RTS, RTS_, DUMMY, STATIC, INHERIT, DEVICE, STATIC_DEVICE, REDIRECT,
RIP, RIP_EXT, OSPF, OSPF_EXT, OSPF_IA, OSPF_BOUNDARY, BGP, PIPE)
%type <i32> idval
%type <f> imexport
%type <r> rtable
%type <p> password_list password_begin
%type <s> optsym
%type <ra> r_args
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
%type <i> echo_mask echo_size debug_mask debug_list debug_flag
%type <t> proto_patt
CF_GRAMMAR
/* Setting of router ID */
CF_ADDTO(conf, rtrid)
rtrid: ROUTER ID idval ';' {
new_config->router_id = $3;
}
;
idval:
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
}
;
/* Creation of routing tables */
CF_ADDTO(conf, newtab)
newtab: TABLE SYM {
rt_new_table($2);
}
;
/* Definition of protocols */
CF_ADDTO(conf, proto)
proto_start: PROTOCOL
proto_name:
/* EMPTY */ {
struct symbol *s = cf_default_name(this_proto->protocol->template, &this_proto->protocol->name_counter);
s->class = SYM_PROTO;
s->def = this_proto;
this_proto->name = s->name;
}
| SYM {
cf_define_symbol($1, SYM_PROTO, this_proto);
this_proto->name = $1->name;
}
;
proto_item:
/* EMPTY */
| PREFERENCE expr {
if ($2 < 0 || $2 > 255) cf_error("Invalid preference");
this_proto->preference = $2;
}
| 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; }
| IMPORT imexport { this_proto->in_filter = $2; }
| EXPORT imexport { this_proto->out_filter = $2; }
| TABLE rtable { this_proto->table = $2; }
;
imexport:
FILTER filter { $$ = $2; }
| where_filter
| ALL { $$ = FILTER_ACCEPT; }
| NONE { $$ = FILTER_REJECT; }
;
rtable:
SYM {
if ($1->class != SYM_TABLE) cf_error("Table name expected");
$$ = $1->def;
}
;
CF_ADDTO(conf, debug_default)
debug_default:
DEBUG PROTOCOLS debug_mask { new_config->proto_default_debug = $3; }
;
/* Interface patterns */
iface_patt:
TEXT { this_ipatt->pattern = $1; this_ipatt->prefix = IPA_NONE; this_ipatt->pxlen = 0; }
| IPA pxlen { this_ipatt->pattern = NULL; this_ipatt->prefix = $1; this_ipatt->pxlen = $2; }
| TEXT IPA pxlen { this_ipatt->pattern = $1; this_ipatt->prefix = $2; this_ipatt->pxlen = $3; }
;
/* Direct device route protocol */
CF_ADDTO(proto, dev_proto '}')
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);
}
;
dev_proto:
dev_proto_start proto_name '{'
| dev_proto proto_item ';'
| dev_proto dev_iface_list ';'
;
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;
}
;
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; }
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; }
;
/* Password lists */
password_begin:
PASSWORD TEXT {
last_password_item = cfg_alloc(sizeof (struct password_item));
last_password_item->password = $2;
last_password_item->from = 0;
last_password_item->to = TIME_INFINITY;
last_password_item->id = 0;
last_password_item->next = NULL;
$$=last_password_item;
}
;
password_items:
/* empty */ { }
| FROM datetime password_items { last_password_item->from = $2; }
| TO datetime password_items { last_password_item->to = $2; }
1999-06-01 01:12:00 +08:00
| PASSIVE datetime password_items { last_password_item->passive = $2; }
| ID NUM password_items { last_password_item->id = $2; }
;
password_list:
/* empty */ { $$ = NULL; }
| password_begin password_items ';' password_list {
1999-10-02 18:44:48 +08:00
$1->next = $4;
$$ = $1;
}
;
/* Core commands */
CF_CLI_HELP(SHOW, ..., [[Show status information]])
CF_CLI(SHOW STATUS,,, [[Show router status]])
{ cmd_show_status(); }
CF_CLI(SHOW PROTOCOLS, optsym, [<name>], [[Show routing protocols]])
{ proto_show($3, 0); } ;
CF_CLI(SHOW PROTOCOLS ALL, optsym, [<name>], [[Show routing protocol details]])
{ proto_show($4, 1); } ;
optsym:
SYM
| /* empty */ { $$ = NULL; }
;
CF_CLI(SHOW INTERFACES,,, [[Show network interfaces]])
{ if_show(); } ;
CF_CLI(SHOW INTERFACES SUMMARY,,, [[Show summary of network interfaces]])
{ if_show_summary(); } ;
CF_CLI(SHOW ROUTE, r_args, [<prefix>] [table <t>] [filter <f>] [all], [[Show routing table]])
{ rt_show($3); } ;
r_args:
/* empty */ {
$$ = cfg_allocz(sizeof(struct rt_show_data));
$$->pxlen = 256;
$$->filter = FILTER_ACCEPT;
$$->table = config->master_rtc->table;
}
| r_args IPA pxlen {
$$ = $1;
if ($$->pxlen != 256) cf_error("Only one prefix expected");
if (!ip_is_prefix($2, $3)) cf_error("Invalid prefix");
$$->prefix = $2;
$$->pxlen = $3;
}
| 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;
if ($$->filter != FILTER_ACCEPT) cf_error("Filter specified twice");
$$->filter = $3;
}
| r_args where_filter {
$$ = $1;
if ($$->filter != FILTER_ACCEPT) cf_error("Filter specified twice");
$$->filter = $2;
}
| r_args ALL {
$$ = $1;
$$->verbose = 1;
}
;
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]])
{ 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]])
{ 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]])
{ 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]])
{ 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]])
{ 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]])
{ 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]])
{ 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;
}
;
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); }
proto_patt:
SYM { $$ = $1->name; }
| ALL { $$ = "*"; }
| TEXT
;
CF_CODE
CF_END