From bms@spc.org Thu Aug 5 05:20:08 2004 From: bms@spc.org (Bruce M Simpson) Date: Wed, 4 Aug 2004 21:20:08 -0700 Subject: [Xorp-hackers] First cut app-level tcp-md5 patch Message-ID: <20040805042008.GA796@empiric.icir.org> --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I just cut this patch to begin using the TCP-MD5 support in the BSDs. It is pretty much a straight port of the work I did on Zebra to the XORP codebase. I'm really looking for feedback here regarding: does this fit well with the rest of the code? Or does it need further changes? I haven't dealt with the PF_KEY stuff yet; that is perhaps more appropriate as an extension of the firewall work. Now I think this is sufficient to get things up and running in the quick and dirty. This compiles cleanly - but the comments/style probably need some attention. I haven't tested it in production. The changes to auto-generated files (i.e. XRL RPC glue) can be ignored; this is a quick diff of my dev tree on my desktop machine. BMS --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcpmd5-hilevel.diff" Index: bgp/bgp.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/bgp.cc,v retrieving revision 1.37 diff -u -p -r1.37 bgp.cc --- bgp/bgp.cc 10 Jun 2004 22:40:28 -0000 1.37 +++ bgp/bgp.cc 5 Aug 2004 04:11:48 -0000 @@ -471,6 +471,21 @@ BGPMain::set_peer_state(const Iptuple& i } bool +BGPMain::set_peer_md5_password(const Iptuple& iptuple, const string& password) +{ + BGPPeer *peer = find_peer(iptuple); + + if (peer == 0) { + XLOG_WARNING("Could not find peer: %s", iptuple.str().c_str()); + return false; + } + + peer->set_md5_password(password); + + return true; +} + +bool BGPMain::activate(const Iptuple& iptuple) { BGPPeer *peer = find_peer(iptuple); Index: bgp/bgp.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/bgp.hh,v retrieving revision 1.27 diff -u -p -r1.27 bgp.hh --- bgp/bgp.hh 10 Jun 2004 22:40:28 -0000 1.27 +++ bgp/bgp.hh 5 Aug 2004 04:11:48 -0000 @@ -125,6 +125,16 @@ public: bool set_peer_state(const Iptuple& iptuple, bool state); /** + * Set peer state. + * + * @param iptuple iptuple. + * @param state should the peering be enable or disabled. + * + * @ return true on success. + */ + bool set_peer_md5_password(const Iptuple& iptuple, const string& password); + + /** * Activate peer. * * Enable the peering based on the peer state. Index: bgp/peer.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/peer.cc,v retrieving revision 1.79 diff -u -p -r1.79 peer.cc --- bgp/peer.cc 10 Jun 2004 22:40:31 -0000 1.79 +++ bgp/peer.cc 5 Aug 2004 04:11:48 -0000 @@ -23,6 +23,7 @@ #include "libxorp/debug.h" #include "libxorp/xlog.h" #include "libxorp/timer.hh" +#include "libcomm/comm_api.h" #include "xrl/interfaces/bgp_mib_traps_xif.hh" #include "libxorp/timespent.hh" @@ -1702,3 +1703,15 @@ BGPPeer::remote_ip_ge_than(const BGPPeer const IPv4& other_remote_ip = peer.peerdata()->iptuple().get_peer_addr(); return (this_remote_ip >= other_remote_ip); } + +void +BGPPeer::set_md5_password(const string& password) +{ + /* XXX: No PF_KEY support yet. _md5_password is just a placeholder. */ + _md5_password = password; + + if ("" == _md5_password) + comm_set_tcpmd5(_SocketClient->get_sock(), false); + else + comm_set_tcpmd5(_SocketClient->get_sock(), true); +} Index: bgp/peer.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/peer.hh,v retrieving revision 1.17 diff -u -p -r1.17 peer.hh --- bgp/peer.hh 10 Jun 2004 22:40:32 -0000 1.17 +++ bgp/peer.hh 5 Aug 2004 04:11:48 -0000 @@ -229,6 +229,10 @@ private: void set_next_peer_state(bool state) {_next_state = state;} bool get_next_peer_state() {return _next_state;} + string _md5_password; + void set_md5_password(const string& password); + const string& get_md5_password() {return _md5_password;} + bool _activated; void set_activate_state(bool state) {_activated = state;} bool get_activate_state() {return _activated;} Index: bgp/xrl_target.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/xrl_target.cc,v retrieving revision 1.26 diff -u -p -r1.26 xrl_target.cc --- bgp/xrl_target.cc 10 Jun 2004 22:40:39 -0000 1.26 +++ bgp/xrl_target.cc 5 Aug 2004 04:11:48 -0000 @@ -286,6 +286,28 @@ XrlBgpTarget::bgp_0_2_set_peer_state( } XrlCmdError +XrlBgpTarget::bgp_0_2_set_peer_md5_password( + // Input values, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password) +{ + debug_msg("local ip %s local port %d peer ip %s peer port %d password %s\n", + local_ip.c_str(), local_port, peer_ip.c_str(), peer_port, + password.c_str()); + + Iptuple iptuple(local_ip.c_str(), local_port, peer_ip.c_str(), peer_port); + + if(!_bgp.set_peer_md5_password(iptuple, password)) + return XrlCmdError::COMMAND_FAILED(); + + return XrlCmdError::OKAY(); +} + + +XrlCmdError XrlBgpTarget::bgp_0_2_activate( // Input values, const string& local_ip, Index: bgp/xrl_target.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/xrl_target.hh,v retrieving revision 1.22 diff -u -p -r1.22 xrl_target.hh --- bgp/xrl_target.hh 10 Jun 2004 22:40:39 -0000 1.22 +++ bgp/xrl_target.hh 5 Aug 2004 04:11:48 -0000 @@ -106,6 +106,14 @@ public: const uint32_t& peer_port, const bool& state); + XrlCmdError bgp_0_2_set_peer_md5_password( + // Input values, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password); + XrlCmdError bgp_0_2_activate( // Input values, const string& local_ip, Index: etc/templates/bgp.tp =================================================================== RCS file: /usr/local/www/data/cvs/xorp/etc/templates/bgp.tp,v retrieving revision 1.32 diff -u -p -r1.32 bgp.tp --- etc/templates/bgp.tp 9 Jun 2004 22:40:49 -0000 1.32 +++ etc/templates/bgp.tp 5 Aug 2004 04:11:48 -0000 @@ -14,6 +14,7 @@ protocols { next-hop: ipv4; holdtime: u32 = 120; enabled: bool = true; + md5-password: txt = ""; } /* @@ -87,6 +88,10 @@ protocols { %set:; } + md5-password { + %set:; + } + as { %allow-range: $(@) "0" "65535"; %set:; @@ -210,6 +215,10 @@ protocols { %help: short "Enable this peering."; } + md5-password { + %help: short "Enable and set the password for TCP-MD5 authentication with this peer."; + } + set-parameter { } Index: xrl/interfaces/bgp.xif =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/bgp.xif,v retrieving revision 1.18 diff -u -p -r1.18 bgp.xif --- xrl/interfaces/bgp.xif 30 May 2004 23:17:33 -0000 1.18 +++ xrl/interfaces/bgp.xif 5 Aug 2004 04:11:49 -0000 @@ -131,6 +131,23 @@ interface bgp/0.2 { & toggle:bool /** + * Set the peer md5 password. + * + * @param local IP address. + * @param local server port. + * @param peer IP address. + * @param peer port. + * @param password the password to use for TCP-MD5 authentication. + */ + set_peer_md5_password \ + ? \ + local_ip:txt \ + & local_port:u32 \ + & peer_ip:txt \ + & peer_port:u32 \ + & password:txt + + /** * Enable or disable the peering based on the peer state. * * @param local IP address. Index: xrl/interfaces/bgp_xif.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/bgp_xif.cc,v retrieving revision 1.26 diff -u -p -r1.26 bgp_xif.cc --- xrl/interfaces/bgp_xif.cc 10 Jun 2004 22:41:58 -0000 1.26 +++ xrl/interfaces/bgp_xif.cc 5 Aug 2004 04:11:49 -0000 @@ -422,6 +422,46 @@ XrlBgpV0p2Client::unmarshall_set_peer_st } bool +XrlBgpV0p2Client::send_set_peer_md5_password( + const char* the_tgt, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password, + const SetPeerMd5PasswordCB& cb +) +{ + Xrl x(the_tgt, "bgp/0.2/set_peer_md5_password"); + x.args().add("local_ip", local_ip); + x.args().add("local_port", local_port); + x.args().add("peer_ip", peer_ip); + x.args().add("peer_port", peer_port); + x.args().add("password", password); + return _sender->send(x, callback(this, &XrlBgpV0p2Client::unmarshall_set_peer_md5_password, cb)); +} + + +/* Unmarshall set_peer_md5_password */ +void +XrlBgpV0p2Client::unmarshall_set_peer_md5_password( + const XrlError& e, + XrlArgs* a, + SetPeerMd5PasswordCB cb +) +{ + if (e != XrlError::OKAY()) { + cb->dispatch(e); + return; + } else if (a && a->size() != 0) { + XLOG_ERROR("Wrong number of arguments (%u != %u)", (uint32_t)a->size(), 0); + cb->dispatch(XrlError::BAD_ARGS()); + return; + } + cb->dispatch(e); +} + +bool XrlBgpV0p2Client::send_activate( const char* the_tgt, const string& local_ip, Index: xrl/interfaces/bgp_xif.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/bgp_xif.hh,v retrieving revision 1.26 diff -u -p -r1.26 bgp_xif.hh --- xrl/interfaces/bgp_xif.hh 10 Jun 2004 22:41:58 -0000 1.26 +++ xrl/interfaces/bgp_xif.hh 5 Aug 2004 04:11:49 -0000 @@ -213,6 +213,26 @@ public: const SetPeerStateCB& cb ); + typedef XorpCallback1::RefPtr SetPeerMd5PasswordCB; + /** + * Send Xrl intended to: + * + * Set the peer md5 password. + * + * @param tgt_name Xrl Target name + * + * @param password the password to use for TCP-MD5 authentication. + */ + bool send_set_peer_md5_password( + const char* target_name, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password, + const SetPeerMd5PasswordCB& cb + ); + typedef XorpCallback1::RefPtr ActivateCB; /** * Send Xrl intended to: @@ -626,6 +646,12 @@ private: SetPeerStateCB cb ); + void unmarshall_set_peer_md5_password( + const XrlError& e, + XrlArgs* a, + SetPeerMd5PasswordCB cb + ); + void unmarshall_activate( const XrlError& e, XrlArgs* a, Index: xrl/targets/bgp.xrls =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/targets/bgp.xrls,v retrieving revision 1.28 diff -u -p -r1.28 bgp.xrls --- xrl/targets/bgp.xrls 3 Aug 2004 05:21:28 -0000 1.28 +++ xrl/targets/bgp.xrls 5 Aug 2004 04:11:49 -0000 @@ -99,6 +99,13 @@ finder://bgp/bgp/0.2/disable_peer?local_ finder://bgp/bgp/0.2/set_peer_state?local_ip:txt&local_port:u32&peer_ip:txt&peer_port:u32&toggle:bool /** + * Set the peer md5 password. + * + * @param password the password to use for TCP-MD5 authentication. + */ +finder://bgp/bgp/0.2/set_peer_md5_password?local_ip:txt&local_port:u32&peer_ip:txt&peer_port:u32&password:txt + +/** * Enable or disable the peering based on the peer state. */ finder://bgp/bgp/0.2/activate?local_ip:txt&local_port:u32&peer_ip:txt&peer_port:u32 Index: xrl/targets/bgp_base.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/targets/bgp_base.cc,v retrieving revision 1.29 diff -u -p -r1.29 bgp_base.cc --- xrl/targets/bgp_base.cc 10 Jun 2004 22:42:08 -0000 1.29 +++ xrl/targets/bgp_base.cc 5 Aug 2004 04:11:49 -0000 @@ -518,6 +518,35 @@ XrlBgpTargetBase::handle_bgp_0_2_set_pee } const XrlCmdError +XrlBgpTargetBase::handle_bgp_0_2_set_peer_md5_password(const XrlArgs& xa_inputs, XrlArgs* /* pxa_outputs */) +{ + if (xa_inputs.size() != 5) { + XLOG_ERROR("Wrong number of arguments (%u != %u) handling %s", + 5, (uint32_t)xa_inputs.size(), "bgp/0.2/set_peer_md5_password"); + return XrlCmdError::BAD_ARGS(); + } + + /* Return value declarations */ + try { + XrlCmdError e = bgp_0_2_set_peer_md5_password( + xa_inputs.get_string("local_ip"), + xa_inputs.get_uint32("local_port"), + xa_inputs.get_string("peer_ip"), + xa_inputs.get_uint32("peer_port"), + xa_inputs.get_string("password")); + if (e != XrlCmdError::OKAY()) { + XLOG_WARNING("Handling method for %s failed: %s", + "bgp/0.2/set_peer_md5_password", e.str().c_str()); + return e; + } + } catch (const XrlArgs::XrlAtomNotFound& e) { + XLOG_ERROR("Argument not found"); + return XrlCmdError::BAD_ARGS(); + } + return XrlCmdError::OKAY(); +} + +const XrlCmdError XrlBgpTargetBase::handle_bgp_0_2_activate(const XrlArgs& xa_inputs, XrlArgs* /* pxa_outputs */) { if (xa_inputs.size() != 4) { @@ -1626,6 +1655,10 @@ XrlBgpTargetBase::add_handlers() callback(this, &XrlBgpTargetBase::handle_bgp_0_2_set_peer_state)) == false) { XLOG_ERROR("Failed to xrl handler finder://%s/%s", "bgp", "bgp/0.2/set_peer_state"); } + if (_cmds->add_handler("bgp/0.2/set_peer_md5_password", + callback(this, &XrlBgpTargetBase::handle_bgp_0_2_set_peer_md5_password)) == false) { + XLOG_ERROR("Failed to xrl handler finder://%s/%s", "bgp", "bgp/0.2/set_peer_md5_password"); + } if (_cmds->add_handler("bgp/0.2/activate", callback(this, &XrlBgpTargetBase::handle_bgp_0_2_activate)) == false) { XLOG_ERROR("Failed to xrl handler finder://%s/%s", "bgp", "bgp/0.2/activate"); @@ -1755,6 +1788,7 @@ XrlBgpTargetBase::remove_handlers() _cmds->remove_handler("bgp/0.2/enable_peer"); _cmds->remove_handler("bgp/0.2/disable_peer"); _cmds->remove_handler("bgp/0.2/set_peer_state"); + _cmds->remove_handler("bgp/0.2/set_peer_md5_password"); _cmds->remove_handler("bgp/0.2/activate"); _cmds->remove_handler("bgp/0.2/set_parameter"); _cmds->remove_handler("bgp/0.2/next_hop_rewrite_filter"); Index: xrl/targets/bgp_base.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/targets/bgp_base.hh,v retrieving revision 1.34 diff -u -p -r1.34 bgp_base.hh --- xrl/targets/bgp_base.hh 3 Aug 2004 05:21:28 -0000 1.34 +++ xrl/targets/bgp_base.hh 5 Aug 2004 04:11:49 -0000 @@ -235,6 +235,21 @@ protected: /** * Pure-virtual function that needs to be implemented to: * + * Set the peer md5 password. + * + * @param password the password to use for TCP-MD5 authentication. + */ + virtual XrlCmdError bgp_0_2_set_peer_md5_password( + // Input values, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password) = 0; + + /** + * Pure-virtual function that needs to be implemented to: + * * Enable or disable the peering based on the peer state. */ virtual XrlCmdError bgp_0_2_activate( @@ -671,6 +686,8 @@ private: const XrlCmdError handle_bgp_0_2_set_peer_state(const XrlArgs& in, XrlArgs* out); + const XrlCmdError handle_bgp_0_2_set_peer_md5_password(const XrlArgs& in, XrlArgs* out); + const XrlCmdError handle_bgp_0_2_activate(const XrlArgs& in, XrlArgs* out); const XrlCmdError handle_bgp_0_2_set_parameter(const XrlArgs& in, XrlArgs* out); --J2SCkAp4GZ/dPZZf-- From Prasanna.S@trilogy.com Thu Aug 5 05:37:28 2004 From: Prasanna.S@trilogy.com (Prasanna.S@trilogy.com) Date: Thu, 5 Aug 2004 11:07:28 +0630 Subject: [Xorp-hackers] intel ixp2400 Message-ID: This is a multipart message in MIME format. --=_alternative 0019E444E5256EE7_= Content-Type: text/plain; charset="us-ascii" What d u think will it take to port xorp to run over intel 2xxx network processor? --=_alternative 0019E444E5256EE7_= Content-Type: text/html; charset="us-ascii"
What d u think will it take to port xorp to run over intel 2xxx network processor?
--=_alternative 0019E444E5256EE7_=-- From atanu@ICSI.Berkeley.EDU Thu Aug 5 21:44:23 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 05 Aug 2004 13:44:23 -0700 Subject: [Xorp-hackers] First cut app-level tcp-md5 patch In-Reply-To: Message from Bruce M Simpson of "Wed, 04 Aug 2004 21:20:08 PDT." <20040805042008.GA796@empiric.icir.org> Message-ID: <33039.1091738663@tigger.icir.org> Hi, One minor point, all the user configurable peer specific state is normally stored in BGPPeerData, not BGPpeer. This is distinction is not very obvious, however, we should stick with it for consistency. Atanu. >>>>> "Bruce" == Bruce M Simpson writes: Bruce> Hi, I just cut this patch to begin using the TCP-MD5 support Bruce> in the BSDs. It is pretty much a straight port of the work I Bruce> did on Zebra to the XORP codebase. Bruce> I'm really looking for feedback here regarding: does this fit Bruce> well with the rest of the code? Or does it need further Bruce> changes? Bruce> I haven't dealt with the PF_KEY stuff yet; that is perhaps Bruce> more appropriate as an extension of the firewall work. Bruce> Now I think this is sufficient to get things up and running Bruce> in the quick and dirty. This compiles cleanly - but the Bruce> comments/style probably need some attention. I haven't tested Bruce> it in production. Bruce> The changes to auto-generated files (i.e. XRL RPC glue) can Bruce> be ignored; this is a quick diff of my dev tree on my desktop Bruce> machine. Bruce> BMS From atanu@ICSI.Berkeley.EDU Thu Aug 5 22:08:50 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 05 Aug 2004 14:08:50 -0700 Subject: [Xorp-hackers] intel ixp2400 In-Reply-To: Message from Prasanna.S@trilogy.com of "Thu, 05 Aug 2004 11:07:28 +0630." Message-ID: <38636.1091740130@tigger.icir.org> We have consider supporting the INTEL IXP2400. In order to support the IXP the XORP FEA (Forwarding Engine Abstraction) would need hooks to configure the IXP. The simplest way of doing this is to use the Network Process Forum API. I believe a Linux library exists that could be used. The IXP can therefore be therefore be treated as a black box and does not have to be explicitly programmed. The last time that I checked IPv6 and Multicast were not supported by the NPF API. It would take about a month to do this work. The other solution would be to write code to run on the IXP that the FEA would interact with. I would expect this effort to take many months. Atanu. >>>>> "Prasanna" == Prasanna S writes: Prasanna> What d u think will it take to port xorp to run over intel Prasanna> 2xxx network processor? From bms@spc.org Thu Aug 5 23:05:26 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 5 Aug 2004 15:05:26 -0700 Subject: [Xorp-hackers] First cut app-level tcp-md5 patch In-Reply-To: <33039.1091738663@tigger.icir.org> References: <20040805042008.GA796@empiric.icir.org> <33039.1091738663@tigger.icir.org> Message-ID: <20040805220526.GA810@empiric.icir.org> On Thu, Aug 05, 2004 at 01:44:23PM -0700, Atanu Ghosh wrote: > One minor point, all the user configurable peer specific state is > normally stored in BGPPeerData, not BGPpeer. This is distinction is not > very obvious, however, we should stick with it for consistency. It's just become apparent that the property needs to reside in BGPPeerData anyway, for reasons related to socket semantics. I'm going to post an updated patch here very shortly. Thanks, BMS From bms@spc.org Thu Aug 5 23:23:51 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 5 Aug 2004 15:23:51 -0700 Subject: [Xorp-hackers] First cut app-level tcp-md5 patch In-Reply-To: <20040805220526.GA810@empiric.icir.org> References: <20040805042008.GA796@empiric.icir.org> <33039.1091738663@tigger.icir.org> <20040805220526.GA810@empiric.icir.org> Message-ID: <20040805222351.GC810@empiric.icir.org> --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 05, 2004 at 03:05:26PM -0700, Bruce M Simpson wrote: > It's just become apparent that the property needs to reside in BGPPeerData > anyway, for reasons related to socket semantics. I'm going to post an > updated patch here very shortly. Here is an updated patch for tcp-md5 support. Both SocketClient::connect_socket() and SocketServer::listen() are the places where comm_set_tcpmd5() actually need to be called, for the correct semantics to take place. The TCP_MD5SIG socket option shouldn't be set in the middle of a TCP session; I should probably add anti-foot-shooting code to FreeBSD to make sure it can't be set for a socket in anything other than LISTEN or IDLE state. However, in BGPMain::create_peer(), which instantiates SocketClient, the SocketClient is instantiated before the BGPPeer. So, push md5 socket option switch down to SocketClient as a bool property, and add it to the constructor signature appropriately as an optional argument. Amend the BGPMain::set_peer_md5_password() method accordingly with a const_cast to obtain the BGPPeerData instance, and reference through that. Move the accessors/mutators for _md5_password into BGPPeerData instead. The XRL interface remains the same. -- There is a potential problem here. The code here isn't guaranteed to support tcp-md5 passive open properly with itojun's new iteration of the tcp-md5 code. There is no way of telling non-tcpmd5 peers apart on the listening socket until such time as they actually connect - and by that time it's too late; so until security policies a la PF_KEY SPD can be used, only active opens will have the correct semantics. --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="md5-cut2.diff" Index: bgp/bgp.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/bgp.cc,v retrieving revision 1.37 diff -u -p -r1.37 bgp.cc --- bgp/bgp.cc 10 Jun 2004 22:40:28 -0000 1.37 +++ bgp/bgp.cc 5 Aug 2004 22:14:20 -0000 @@ -387,7 +387,9 @@ BGPMain::create_peer(BGPPeerData *pd) return false; } - SocketClient *sock = new SocketClient(pd->iptuple(), eventloop()); + bool md5sig = ("" == pd->get_md5_password() ? false : true); + + SocketClient *sock = new SocketClient(pd->iptuple(), eventloop(), md5sig); BGPPeer *p = new BGPPeer(&_local_data, pd, sock, this); // sock->set_eventloop(eventloop()); @@ -471,6 +473,24 @@ BGPMain::set_peer_state(const Iptuple& i } bool +BGPMain::set_peer_md5_password(const Iptuple& iptuple, const string& password) +{ + BGPPeer *peer = find_peer(iptuple); + + if (peer == NULL) { + XLOG_WARNING("Could not find peer: %s", iptuple.str().c_str()); + return false; + } + + // The md5-password property has to belong to BGPPeerData, because + // it is instantiated before BGPPeer and before SocketClient. + BGPPeerData* pd = const_cast(peer->peerdata()); + pd->set_md5_password(password); + + return true; +} + +bool BGPMain::activate(const Iptuple& iptuple) { BGPPeer *peer = find_peer(iptuple); Index: bgp/bgp.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/bgp.hh,v retrieving revision 1.27 diff -u -p -r1.27 bgp.hh --- bgp/bgp.hh 10 Jun 2004 22:40:28 -0000 1.27 +++ bgp/bgp.hh 5 Aug 2004 22:14:20 -0000 @@ -125,6 +125,16 @@ public: bool set_peer_state(const Iptuple& iptuple, bool state); /** + * Set peer TCP-MD5 password. + * + * @param iptuple iptuple. + * @param password The password to use for TCP-MD5 authentication; if this is the empty string, then authentication will be disabled. + * + * @return true on success. + */ + bool set_peer_md5_password(const Iptuple& iptuple, const string& password); + + /** * Activate peer. * * Enable the peering based on the peer state. Index: bgp/peer_data.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/peer_data.hh,v retrieving revision 1.12 diff -u -p -r1.12 peer_data.hh --- bgp/peer_data.hh 10 Jun 2004 22:40:32 -0000 1.12 +++ bgp/peer_data.hh 5 Aug 2004 22:14:20 -0000 @@ -199,6 +199,9 @@ public: return _next_hop_rewrite; } + void set_md5_password(const string &password) { _md5_password = password; } + const string& get_md5_password() const { return _md5_password; } + /** * Dump the state of the peer data (debugging). */ @@ -272,6 +275,11 @@ private: ** temporary hack store the re-write value here. */ IPv4 _next_hop_rewrite; + + /** + * The password for TCP-MD5 authentication. + */ + string _md5_password; }; #endif // __BGP_PEER_DATA_HH__ Index: bgp/socket.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/socket.cc,v retrieving revision 1.15 diff -u -p -r1.15 socket.cc --- bgp/socket.cc 10 Jun 2004 22:40:36 -0000 1.15 +++ bgp/socket.cc 5 Aug 2004 22:14:20 -0000 @@ -27,6 +27,7 @@ #include "libxorp/xlog.h" #include "libxorp/exceptions.hh" #include "libxorp/callback.hh" +#include "libcomm/comm_api.h" #include "socket.hh" #include "packet.hh" @@ -111,8 +112,9 @@ Socket::init_sockaddr(struct sockaddr_in /* **************** BGPSocketClient - PUBLIC METHODS *********************** */ -SocketClient::SocketClient(const Iptuple& iptuple, EventLoop& e) - : Socket(iptuple, e) +SocketClient::SocketClient(const Iptuple& iptuple, EventLoop& e, + bool md5sig = false) + : Socket(iptuple, e), _md5sig(md5sig) { debug_msg("SocketClient constructor called\n"); _async_writer = 0; @@ -168,6 +170,10 @@ SocketClient::connect(ConnectCallback cb XLOG_ASSERT(UNCONNECTED == get_sock()); create_socket(); + + if (_md5sig) + comm_set_tcpmd5(get_sock(), _md5sig); + return connect_socket(get_sock(), get_remote_addr(), get_remote_port(), get_local_addr(), cb); } Index: bgp/socket.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/socket.hh,v retrieving revision 1.7 diff -u -p -r1.7 socket.hh --- bgp/socket.hh 10 Jun 2004 22:40:36 -0000 1.7 +++ bgp/socket.hh 5 Aug 2004 22:14:20 -0000 @@ -93,7 +93,7 @@ public: /** * @param iptuple specification of the connection endpoints. */ - SocketClient(const Iptuple& iptuple, EventLoop& e); + SocketClient(const Iptuple& iptuple, EventLoop& e, bool md5sig = false); ~SocketClient(); /** @@ -246,6 +246,7 @@ private: bool _disconnecting; bool _connecting; + bool _md5sig; uint8_t _read_buf[MAXPACKETSIZE]; // Maximum allowed BGP message }; Index: bgp/xrl_target.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/xrl_target.cc,v retrieving revision 1.26 diff -u -p -r1.26 xrl_target.cc --- bgp/xrl_target.cc 10 Jun 2004 22:40:39 -0000 1.26 +++ bgp/xrl_target.cc 5 Aug 2004 22:14:20 -0000 @@ -286,6 +286,28 @@ XrlBgpTarget::bgp_0_2_set_peer_state( } XrlCmdError +XrlBgpTarget::bgp_0_2_set_peer_md5_password( + // Input values, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password) +{ + debug_msg("local ip %s local port %d peer ip %s peer port %d password %s\n", + local_ip.c_str(), local_port, peer_ip.c_str(), peer_port, + password.c_str()); + + Iptuple iptuple(local_ip.c_str(), local_port, peer_ip.c_str(), peer_port); + + if(!_bgp.set_peer_md5_password(iptuple, password)) + return XrlCmdError::COMMAND_FAILED(); + + return XrlCmdError::OKAY(); +} + + +XrlCmdError XrlBgpTarget::bgp_0_2_activate( // Input values, const string& local_ip, Index: bgp/xrl_target.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/bgp/xrl_target.hh,v retrieving revision 1.22 diff -u -p -r1.22 xrl_target.hh --- bgp/xrl_target.hh 10 Jun 2004 22:40:39 -0000 1.22 +++ bgp/xrl_target.hh 5 Aug 2004 22:14:20 -0000 @@ -106,6 +106,14 @@ public: const uint32_t& peer_port, const bool& state); + XrlCmdError bgp_0_2_set_peer_md5_password( + // Input values, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password); + XrlCmdError bgp_0_2_activate( // Input values, const string& local_ip, Index: etc/templates/bgp.tp =================================================================== RCS file: /usr/local/www/data/cvs/xorp/etc/templates/bgp.tp,v retrieving revision 1.32 diff -u -p -r1.32 bgp.tp --- etc/templates/bgp.tp 9 Jun 2004 22:40:49 -0000 1.32 +++ etc/templates/bgp.tp 5 Aug 2004 22:14:25 -0000 @@ -14,6 +14,7 @@ protocols { next-hop: ipv4; holdtime: u32 = 120; enabled: bool = true; + md5-password: txt = ""; } /* @@ -87,6 +88,10 @@ protocols { %set:; } + md5-password { + %set:; + } + as { %allow-range: $(@) "0" "65535"; %set:; @@ -210,6 +215,10 @@ protocols { %help: short "Enable this peering."; } + md5-password { + %help: short "Enable and set the password for TCP-MD5 authentication with this peer."; + } + set-parameter { } Index: xrl/interfaces/bgp.xif =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/bgp.xif,v retrieving revision 1.18 diff -u -p -r1.18 bgp.xif --- xrl/interfaces/bgp.xif 30 May 2004 23:17:33 -0000 1.18 +++ xrl/interfaces/bgp.xif 5 Aug 2004 22:14:28 -0000 @@ -131,6 +131,23 @@ interface bgp/0.2 { & toggle:bool /** + * Set the peer md5 password. + * + * @param local IP address. + * @param local server port. + * @param peer IP address. + * @param peer port. + * @param password the password to use for TCP-MD5 authentication. + */ + set_peer_md5_password \ + ? \ + local_ip:txt \ + & local_port:u32 \ + & peer_ip:txt \ + & peer_port:u32 \ + & password:txt + + /** * Enable or disable the peering based on the peer state. * * @param local IP address. Index: xrl/interfaces/bgp_xif.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/bgp_xif.cc,v retrieving revision 1.26 diff -u -p -r1.26 bgp_xif.cc --- xrl/interfaces/bgp_xif.cc 10 Jun 2004 22:41:58 -0000 1.26 +++ xrl/interfaces/bgp_xif.cc 5 Aug 2004 22:14:28 -0000 @@ -422,6 +422,46 @@ XrlBgpV0p2Client::unmarshall_set_peer_st } bool +XrlBgpV0p2Client::send_set_peer_md5_password( + const char* the_tgt, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password, + const SetPeerMd5PasswordCB& cb +) +{ + Xrl x(the_tgt, "bgp/0.2/set_peer_md5_password"); + x.args().add("local_ip", local_ip); + x.args().add("local_port", local_port); + x.args().add("peer_ip", peer_ip); + x.args().add("peer_port", peer_port); + x.args().add("password", password); + return _sender->send(x, callback(this, &XrlBgpV0p2Client::unmarshall_set_peer_md5_password, cb)); +} + + +/* Unmarshall set_peer_md5_password */ +void +XrlBgpV0p2Client::unmarshall_set_peer_md5_password( + const XrlError& e, + XrlArgs* a, + SetPeerMd5PasswordCB cb +) +{ + if (e != XrlError::OKAY()) { + cb->dispatch(e); + return; + } else if (a && a->size() != 0) { + XLOG_ERROR("Wrong number of arguments (%u != %u)", (uint32_t)a->size(), 0); + cb->dispatch(XrlError::BAD_ARGS()); + return; + } + cb->dispatch(e); +} + +bool XrlBgpV0p2Client::send_activate( const char* the_tgt, const string& local_ip, Index: xrl/interfaces/bgp_xif.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/bgp_xif.hh,v retrieving revision 1.26 diff -u -p -r1.26 bgp_xif.hh --- xrl/interfaces/bgp_xif.hh 10 Jun 2004 22:41:58 -0000 1.26 +++ xrl/interfaces/bgp_xif.hh 5 Aug 2004 22:14:28 -0000 @@ -213,6 +213,26 @@ public: const SetPeerStateCB& cb ); + typedef XorpCallback1::RefPtr SetPeerMd5PasswordCB; + /** + * Send Xrl intended to: + * + * Set the peer md5 password. + * + * @param tgt_name Xrl Target name + * + * @param password the password to use for TCP-MD5 authentication. + */ + bool send_set_peer_md5_password( + const char* target_name, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password, + const SetPeerMd5PasswordCB& cb + ); + typedef XorpCallback1::RefPtr ActivateCB; /** * Send Xrl intended to: @@ -626,6 +646,12 @@ private: SetPeerStateCB cb ); + void unmarshall_set_peer_md5_password( + const XrlError& e, + XrlArgs* a, + SetPeerMd5PasswordCB cb + ); + void unmarshall_activate( const XrlError& e, XrlArgs* a, Index: xrl/targets/bgp.xrls =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/targets/bgp.xrls,v retrieving revision 1.28 diff -u -p -r1.28 bgp.xrls --- xrl/targets/bgp.xrls 3 Aug 2004 05:21:28 -0000 1.28 +++ xrl/targets/bgp.xrls 5 Aug 2004 22:14:28 -0000 @@ -99,6 +99,13 @@ finder://bgp/bgp/0.2/disable_peer?local_ finder://bgp/bgp/0.2/set_peer_state?local_ip:txt&local_port:u32&peer_ip:txt&peer_port:u32&toggle:bool /** + * Set the peer md5 password. + * + * @param password the password to use for TCP-MD5 authentication. + */ +finder://bgp/bgp/0.2/set_peer_md5_password?local_ip:txt&local_port:u32&peer_ip:txt&peer_port:u32&password:txt + +/** * Enable or disable the peering based on the peer state. */ finder://bgp/bgp/0.2/activate?local_ip:txt&local_port:u32&peer_ip:txt&peer_port:u32 Index: xrl/targets/bgp_base.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/targets/bgp_base.cc,v retrieving revision 1.29 diff -u -p -r1.29 bgp_base.cc --- xrl/targets/bgp_base.cc 10 Jun 2004 22:42:08 -0000 1.29 +++ xrl/targets/bgp_base.cc 5 Aug 2004 22:14:28 -0000 @@ -518,6 +518,35 @@ XrlBgpTargetBase::handle_bgp_0_2_set_pee } const XrlCmdError +XrlBgpTargetBase::handle_bgp_0_2_set_peer_md5_password(const XrlArgs& xa_inputs, XrlArgs* /* pxa_outputs */) +{ + if (xa_inputs.size() != 5) { + XLOG_ERROR("Wrong number of arguments (%u != %u) handling %s", + 5, (uint32_t)xa_inputs.size(), "bgp/0.2/set_peer_md5_password"); + return XrlCmdError::BAD_ARGS(); + } + + /* Return value declarations */ + try { + XrlCmdError e = bgp_0_2_set_peer_md5_password( + xa_inputs.get_string("local_ip"), + xa_inputs.get_uint32("local_port"), + xa_inputs.get_string("peer_ip"), + xa_inputs.get_uint32("peer_port"), + xa_inputs.get_string("password")); + if (e != XrlCmdError::OKAY()) { + XLOG_WARNING("Handling method for %s failed: %s", + "bgp/0.2/set_peer_md5_password", e.str().c_str()); + return e; + } + } catch (const XrlArgs::XrlAtomNotFound& e) { + XLOG_ERROR("Argument not found"); + return XrlCmdError::BAD_ARGS(); + } + return XrlCmdError::OKAY(); +} + +const XrlCmdError XrlBgpTargetBase::handle_bgp_0_2_activate(const XrlArgs& xa_inputs, XrlArgs* /* pxa_outputs */) { if (xa_inputs.size() != 4) { @@ -1626,6 +1655,10 @@ XrlBgpTargetBase::add_handlers() callback(this, &XrlBgpTargetBase::handle_bgp_0_2_set_peer_state)) == false) { XLOG_ERROR("Failed to xrl handler finder://%s/%s", "bgp", "bgp/0.2/set_peer_state"); } + if (_cmds->add_handler("bgp/0.2/set_peer_md5_password", + callback(this, &XrlBgpTargetBase::handle_bgp_0_2_set_peer_md5_password)) == false) { + XLOG_ERROR("Failed to xrl handler finder://%s/%s", "bgp", "bgp/0.2/set_peer_md5_password"); + } if (_cmds->add_handler("bgp/0.2/activate", callback(this, &XrlBgpTargetBase::handle_bgp_0_2_activate)) == false) { XLOG_ERROR("Failed to xrl handler finder://%s/%s", "bgp", "bgp/0.2/activate"); @@ -1755,6 +1788,7 @@ XrlBgpTargetBase::remove_handlers() _cmds->remove_handler("bgp/0.2/enable_peer"); _cmds->remove_handler("bgp/0.2/disable_peer"); _cmds->remove_handler("bgp/0.2/set_peer_state"); + _cmds->remove_handler("bgp/0.2/set_peer_md5_password"); _cmds->remove_handler("bgp/0.2/activate"); _cmds->remove_handler("bgp/0.2/set_parameter"); _cmds->remove_handler("bgp/0.2/next_hop_rewrite_filter"); Index: xrl/targets/bgp_base.hh =================================================================== RCS file: /usr/local/www/data/cvs/xorp/xrl/targets/bgp_base.hh,v retrieving revision 1.34 diff -u -p -r1.34 bgp_base.hh --- xrl/targets/bgp_base.hh 3 Aug 2004 05:21:28 -0000 1.34 +++ xrl/targets/bgp_base.hh 5 Aug 2004 22:14:28 -0000 @@ -235,6 +235,21 @@ protected: /** * Pure-virtual function that needs to be implemented to: * + * Set the peer md5 password. + * + * @param password the password to use for TCP-MD5 authentication. + */ + virtual XrlCmdError bgp_0_2_set_peer_md5_password( + // Input values, + const string& local_ip, + const uint32_t& local_port, + const string& peer_ip, + const uint32_t& peer_port, + const string& password) = 0; + + /** + * Pure-virtual function that needs to be implemented to: + * * Enable or disable the peering based on the peer state. */ virtual XrlCmdError bgp_0_2_activate( @@ -671,6 +686,8 @@ private: const XrlCmdError handle_bgp_0_2_set_peer_state(const XrlArgs& in, XrlArgs* out); + const XrlCmdError handle_bgp_0_2_set_peer_md5_password(const XrlArgs& in, XrlArgs* out); + const XrlCmdError handle_bgp_0_2_activate(const XrlArgs& in, XrlArgs* out); const XrlCmdError handle_bgp_0_2_set_parameter(const XrlArgs& in, XrlArgs* out); --xHFwDpU9dbj6ez1V-- From ray.qiu@gmail.com Fri Aug 6 07:18:10 2004 From: ray.qiu@gmail.com (Ray Qiu) Date: Thu, 5 Aug 2004 23:18:10 -0700 Subject: [Xorp-hackers] process auto restart Message-ID: Hi, I have one question. How is process auto restart addressed in XORP design? By process auto restart, I mean to automatically restart a process which exits abnormally, e.g. crash. How can the restarted process get its configuration information? Thanks. --Ray From pavlin@icir.org Mon Aug 9 19:12:06 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 09 Aug 2004 11:12:06 -0700 Subject: [Xorp-hackers] process auto restart In-Reply-To: Message from Ray Qiu of "Thu, 05 Aug 2004 23:18:10 PDT." Message-ID: <200408091812.i79IC6wK049833@possum.icir.org> > I have one question. How is process auto restart addressed in XORP design? > By process auto restart, I mean to automatically restart a process > which exits abnormally, e.g. crash. > > How can the restarted process get its configuration information? Ray, The restarting can be done as follows: 1. The rtrmgr detects that the process has exit abnormally by using one of the following mechanisms: (a) If the process is running on the same machine as the rtrmgr, then the rtrmgr can check the process' exit status after SIGCHLD. (b) The rtrmgr registers interest with the finder in that particular process' status. E.g., see the following XRL interfaces: finder_event_notifier/0.1 and finder_event_observer/0.1 (inside files xrl/interfaces/finder_event_notifier.xif and xrl/interfaces/finder_event_observer.xif). 2. Once the abnormal exit is detected, the rtrmgr can check its current configuration related to this particular process, and will execute only those tasks that are needed to start the process and configure it. Those tasks include the particular command to start the process, and the XRLs to configure it (remember that all configuration is done via XRLs sent by the rtrmgr to the process). In other words, the rtrmgr has all the responsibility for restarting and configuring the process, and the process itself does not need to do anything special. Note that currently the rtrmgr only detects (using 1(a)) that a process has exit abnormally, but it does not attempt to restart it. The restarting should be added in one of the future releases. Regards, Pavlin From M.Handley@cs.ucl.ac.uk Mon Aug 9 20:33:11 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 09 Aug 2004 20:33:11 +0100 Subject: [Xorp-hackers] process auto restart In-Reply-To: Your message of "Mon, 09 Aug 2004 11:12:06 PDT." <200408091812.i79IC6wK049833@possum.icir.org> Message-ID: <26151.1092079991@cs.ucl.ac.uk> >In other words, the rtrmgr has all the responsibility for restarting >and configuring the process, and the process itself does not need to >do anything special. > >Note that currently the rtrmgr only detects (using 1(a)) that a >process has exit abnormally, but it does not attempt to restart it. >The restarting should be added in one of the future releases. This is correct. There's one other question that would need to be resolved before this can be implemented. What should the rtrmgr do about processes that depend on the failed process? The rtrmgr knows about process startup dependencies from the dependency information in the process template files. But should it use this information? My feeling is no. Our error handling rules state that a process should terminate itself if a process it critically depends on fails. So in principle, the rtrmgr shouldn't do anything based on this dependency information - one process failure should cause all the critically dependent processes to terminate, and the rtrmgr should wait until all the processes that think they are dependent have terminated, and then restart everything that exited. But how does the rtrmgr know when it's safe to start the restart procedure? This isn't a showstopper, but needs to be decided globally, or we'll have inconsistent behaviour. - Mark From ray.qiu@gmail.com Tue Aug 10 18:32:09 2004 From: ray.qiu@gmail.com (Ray Qiu) Date: Tue, 10 Aug 2004 10:32:09 -0700 Subject: [Xorp-hackers] process auto restart In-Reply-To: <26151.1092079991@cs.ucl.ac.uk> References: <26151.1092079991@cs.ucl.ac.uk> Message-ID: On Mon, 09 Aug 2004 20:33:11 +0100, Mark Handley wrote: > > >In other words, the rtrmgr has all the responsibility for restarting > >and configuring the process, and the process itself does not need to > >do anything special. > > > >Note that currently the rtrmgr only detects (using 1(a)) that a > >process has exit abnormally, but it does not attempt to restart it. > >The restarting should be added in one of the future releases. > > This is correct. There's one other question that would need to be > resolved before this can be implemented. What should the rtrmgr do > about processes that depend on the failed process? The rtrmgr knows > about process startup dependencies from the dependency information in > the process template files. But should it use this information? > > My feeling is no. Our error handling rules state that a process > should terminate itself if a process it critically depends on fails. > So in principle, the rtrmgr shouldn't do anything based on this > dependency information - one process failure should cause all the > critically dependent processes to terminate, and the rtrmgr should > wait until all the processes that think they are dependent have > terminated, and then restart everything that exited. But how does the > rtrmgr know when it's safe to start the restart procedure? > > This isn't a showstopper, but needs to be decided globally, or we'll > have inconsistent behaviour. > > - Mark > It might be a good idea to define some processes as server components (e.g. RIB) and others as clients (e.g. BGP). If a server component dies, one easy thing to do is to simply restart the whole stack. If a client dies, it can be restarted immediatelly. Too complicated dependencies might be too hard to deal with. Just my 2 cents. --Ray From pavlin@icir.org Fri Aug 13 00:28:28 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 12 Aug 2004 16:28:28 -0700 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router Message-ID: <200408122328.i7CNSTwK007626@possum.icir.org> I have a question about the desired behavior of adding static routes to StaticRoute. Currently, if a static route is added to StaticRoutes, and if the next-hop router toward the destination is unresolvable (e.g., the network interface toward the destination is DOWN, or simply there is no network interface that connects us to that router), then the routing entry is saved internally (inside StaticRoutes), and the "add" operation returns OK. However, StaticRoutes does NOT send that route to the RIB. If the network interface toward that next-hop router comes up, then StaticRoutes will send that route to RIB. The reasoning behind the above behavior is that StaticRoutes can be configured on startup (or on the fly) with a number of routes, even though some of them may not be used because some of the network interfaces are intentionally down. Once a network interface becomes UP, then the corresponding static routes that use that interface are automatically installed. In addition, if we look into StaticRoutes as a simple routing protocol, then it should be taking into account the network interface status and should install routes into RIB only if those routes are valid. However, if there is an error in the configuration such as a typo in the IP address of a next-hop router, then such route will be installed in StaticRoutes (only), and no error will be returned to the user. Such behavior may be a source of a confusion, hence I'd like to ask for opinions what the right solution should be. Below are some suggestions: a) If the next-hop router toward the destination is not resolvable, then always return an error. Note that may not be a practical solution, because on startup we may have to wait until StaticRoutes receive all network interface information from the FEA before we can add any static routes to it. b) If the next-hop router toward the destination is not resolvable, then StaticRoutes should print a warning, but it should still return OK (if we don't return OK, then the rtrmgr will fail to start StaticRoutes). c) If the next-hop router toward the destination is not resolvable, then the StaticRoutes should still add the route to the RIB, and then let the RIB deal with resolving the next-hop router whenever the status of the related network interface changes. Doing something like this may require changes to the RIB. d) Don't change the current behavior, but document it. Comments? Pavlin From atanu@ICSI.Berkeley.EDU Fri Aug 13 00:58:22 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 12 Aug 2004 16:58:22 -0700 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Message from Pavlin Radoslavov of "Thu, 12 Aug 2004 16:28:28 PDT." <200408122328.i7CNSTwK007626@possum.icir.org> Message-ID: <44486.1092355102@tigger.icir.org> It is the job of the routing protocols to install or remove routes. All routing protocols are responsible for monitoring the status of the the next hops. If a next hop transitions between resolvable states the routing protocol should take the appropriate action (add/delete). I would say that option d) is the most consistent behaviour. If you really believe that a common mis-configuration is going to be assigning an invalid next-hop then b) works too. Atanu. >>>>> "Pavlin" == Pavlin Radoslavov writes: Pavlin> I have a question about the desired behavior of adding static routes Pavlin> to StaticRoute. Pavlin> Currently, if a static route is added to StaticRoutes, and if the Pavlin> next-hop router toward the destination is unresolvable (e.g., the Pavlin> network interface toward the destination is DOWN, or simply there is Pavlin> no network interface that connects us to that router), then the Pavlin> routing entry is saved internally (inside StaticRoutes), and the Pavlin> "add" operation returns OK. However, StaticRoutes does NOT send that Pavlin> route to the RIB. If the network interface toward that next-hop Pavlin> router comes up, then StaticRoutes will send that route to RIB. Pavlin> The reasoning behind the above behavior is that StaticRoutes can be Pavlin> configured on startup (or on the fly) with a number of routes, even Pavlin> though some of them may not be used because some of the network Pavlin> interfaces are intentionally down. Once a network interface becomes Pavlin> UP, then the corresponding static routes that use that interface are Pavlin> automatically installed. Pavlin> In addition, if we look into StaticRoutes as a simple routing Pavlin> protocol, then it should be taking into account the network Pavlin> interface status and should install routes into RIB only if those Pavlin> routes are valid. Pavlin> However, if there is an error in the configuration such as a typo in Pavlin> the IP address of a next-hop router, then such route will be Pavlin> installed in StaticRoutes (only), and no error will be returned to Pavlin> the user. Such behavior may be a source of a confusion, hence I'd Pavlin> like to ask for opinions what the right solution should be. Pavlin> Below are some suggestions: Pavlin> a) If the next-hop router toward the destination is not resolvable, Pavlin> then always return an error. Note that may not be a practical Pavlin> solution, because on startup we may have to wait until StaticRoutes Pavlin> receive all network interface information from the FEA before we Pavlin> can add any static routes to it. Pavlin> b) If the next-hop router toward the destination is not resolvable, Pavlin> then StaticRoutes should print a warning, but it should still Pavlin> return OK (if we don't return OK, then the rtrmgr will fail to Pavlin> start StaticRoutes). Pavlin> c) If the next-hop router toward the destination is not resolvable, Pavlin> then the StaticRoutes should still add the route to the RIB, and Pavlin> then let the RIB deal with resolving the next-hop router Pavlin> whenever the status of the related network interface changes. Pavlin> Doing something like this may require changes to the RIB. Pavlin> d) Don't change the current behavior, but document it. Pavlin> Comments? Pavlin> Pavlin Pavlin> _______________________________________________ Pavlin> Xorp-hackers mailing list Pavlin> Xorp-hackers@icir.org Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From M.Handley@cs.ucl.ac.uk Fri Aug 13 08:26:13 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 13 Aug 2004 08:26:13 +0100 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Your message of "Thu, 12 Aug 2004 16:28:28 PDT." <200408122328.i7CNSTwK007626@possum.icir.org> Message-ID: <6907.1092381973@vulture.xorp.org> >c) If the next-hop router toward the destination is not resolvable, > then the StaticRoutes should still add the route to the RIB, and > then let the RIB deal with resolving the next-hop router > whenever the status of the related network interface changes. > Doing something like this may require changes to the RIB. The RIB does actually contain code to do this - it's just not enabled for IGP routes. The code was originally there for BGP, before we realised that BGP routes where the BGP nexthop is unreachable shouldn't be considered for the BGP decision process. Currently I believe this code in the RIB is unused - you can find it in rib/rt_tab_extint.cc (look for anything to do with unresolved_nexthops). In any event, this opens up several more questions: - Should static_routes be able to specify a nexthop that isn't an immediate neighbour? (So long as the nexthop is reachable via another route). Retasking the code in ExtIntTable to do nexthop lookup for IGP routes would give us this. We'd need to be careful to check for mutual recursion though. - If we have a static_route for a destination, and a dynamic route (say from RIP) for the same destination, the static_route will normally win on admin distance. Now, say the interface for the static_route goes down. Should the route fall back to that from RIP? I can see both answers make sense: + It should not fall back because the network administrator really really wanted to NOT use the RIP route - that's why he configured the static route. + It should fall back because we really want to ensure reachability above all else. Anyway, the answer to the second question determines (or at least is closely related to) whether you want the resolvabilty test in the static_routes process, or in the RIB itself. This could of course be a policy question - if the RIB had the nexthop reachability code, we could configure the behaviour for each static route on a case-by-case basis. If static_routes does the reachability test, then the route would be withdrawn when the interface goes down, allowing the RIP route to take over. If static_routes always passes the route to the RIB , and the RIBdoes the reachability test, then it would be after the admin_distance test, and so the RIP route would not take over if the interface went down. In any event, there needs to be a way to should the routing table including the routes with unresolvable nexthops to see what the problem is. Currently the way to show static routes is to show the RIB's view of them, which only shows the routes with reachable nexthops. Cheers, Mark From M.Handley@cs.ucl.ac.uk Fri Aug 13 09:00:53 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 13 Aug 2004 09:00:53 +0100 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Your message of "Thu, 12 Aug 2004 16:58:22 PDT." <44486.1092355102@tigger.icir.org> Message-ID: <6949.1092384053@vulture.xorp.org> >It is the job of the routing protocols to install or remove routes. All >routing protocols are responsible for monitoring the status of the the >next hops. If a next hop transitions between resolvable states the >routing protocol should take the appropriate action (add/delete). Well, this is certainly true for all the normal dynamic routing protocols: - In BGP a route is not eligable for Decision unless the nexthop is resolvable. BGP has to explicitly monitor the RIB state to do this. - In RIP, if an interface goes down, the routes from neighbours on that interface will timeout without RIP needing to do anything special about nexthop reachability. - In OSPF/IS-IS, if an interface goes down, the link will be remove from the link state table, and the SPF calculation will remove any routes whose nexthop was over that interface. Again, no special monitoring of nexthop reachability needed beyond what OSPF does itself. The question is really one of whether static_routes behaves like a "normal" routing protocol (in which case it will need to monitor RIB or interface state in a similar way to BGP, because unlike RIP, OSPF or IS-IS, it doesn't have its own link state monitoring mechanism), or whether it's something different. Cheers, Mark From atanu@ICSI.Berkeley.EDU Fri Aug 13 20:01:39 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 13 Aug 2004 12:01:39 -0700 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Message from Mark Handley of "Fri, 13 Aug 2004 09:00:53 BST." <6949.1092384053@vulture.xorp.org> Message-ID: <76072.1092423699@tigger.icir.org> Mark> The question is really one of whether static_routes behaves Mark> like a "normal" routing protocol (in which case it will need Mark> to monitor RIB or interface state in a similar way to BGP, Mark> because unlike RIP, OSPF or IS-IS, it doesn't have its own Mark> link state monitoring mechanism), or whether it's something Mark> different. I think that the static route should be monitoring the interface states. It needs to do this anyway to determine if it can add a route in the first place. Atanu. From bms@spc.org Sun Aug 15 12:33:34 2004 From: bms@spc.org (Bruce M Simpson) Date: Sun, 15 Aug 2004 04:33:34 -0700 Subject: [Xorp-hackers] OSPF prep: SOCK_RAW per-OS dependencies. Message-ID: <20040815113334.GA3822@empiric.icir.org> --32u276st3Jlj2kUU Content-Type: multipart/mixed; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is an excerpt from a document I wrote 6 years ago. It points out the differences between SOCK_RAW support with respect to PF_INET across various operating systems. It may be somewhat out of date but it's a starting point; in particular I recently updated the FreeBSD ip(4) man page re header field byte ordering when IP_HDRINCL is in use. We might need this for hacking RawSocket4 appropriately in the run-up to portable OSPF implementation but I suspect much of the groundwork has been done for PIM. BMS --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="raw-socket-osdeps.txt" Content-Transfer-Encoding: quoted-printable -0x0A-------------------[ Appendix A: SOCK_RAW/IP_HDRINCL by Platform This appendix attempts to document the known issues with the use of IP_HDRI= NCL on commonly used platforms. One way of sidestepping/avoiding this issue is = to go straight to the link layer, and this is often used as the solution. Byte swapping to overcome the problem with traditional BSD IP_HDRINCL behav= ior is done when LIBNET_BSD_BYTE_SWAP is defined. The LIBNET_BSD_BYTE_SWAP defi= ne is generic by nature. It should no longer need to be used with FreeBSD or OpenBSD. BSD/OS will need it. NetBSD's status is not known - tell me. The libnet module responsible for opening raw sockets is libnet_socket.c, a= nd the writing code is in libnet_write_ip.c. Any changes made to the way we handle raw sockets will go there. ----[-------------- BSD Platforms Historic BSD IP_HDRINCL implementations specify that it's a raw IP packet, including header, with everything as it will go out onto the network _EXCEP= T_ the ip_len and ip_off fields in the header. This is in host order, as it is used to represent the length of the packet. The kernel will change these fields to network order using swab() when it sends the packet out on the network. However, each BSD variant appears to have its own quirks. I have attempted = to document these quirks here for future reference. ----[-------------- FreeBSD FreeBSD has now been fixed with regards to the treatment of ip_off/ip_len. According to /usr/src/sys/netinet/raw_ip.c in the 4.0-STABLE release of FreeBSD, FreeBSD should have no problem with the IP_HDRINCL option, and sho= uld pass the IPv4 header to the link layer verbatim with no changes. The only exception to this is the ip_id and ip_len fields; FreeBSD will overwrite the ip_id field if it is set to zero. It will also return EINVAL = if the specified IPv4 header length is greater than the length passed to the socket subsystem, or if the overall IP length is less than the length of the specified IP header, or if the IP header is not equal to the size of the IP= v4 header. FreeBSD also maintains statistics for IP datagrams output with the IP_HDRIN= CL option. This is maintained in the ipstat.ips_rawout member, and can be view= ed using 'netstat -p ip'. FreeBSD has BPF support for the link layer. ----[-------------- BSD/OS =46rom the BSD/OS 4.1 manual page for ip(4) which is current as of this wri= ting: Unlike previous BSD releases, the program must set all the fields of the IP header, including the following: ip->ip_v =3D IPVERSION; ip->ip_hl =3D hlen >> 2; ip->ip_id =3D 0; /* 0 means kernel set appropriate value */ ip->ip_off =3D offset; The ip_len and ip_off fields must be provided in host byte order. All other fields must be provided in network byte order. See byteorder(4) for more information on network byte order. If the header source addre= ss is set to INADDR_ANY, the kernel will choose an appropriate address. BSD/OS supports the BPF link-layer interface. ----[-------------- NetBSD According to a post dated October 1996 by Kurt J. Lidl to the tech- net@netbsd.org and freebsd-arch mailing lists: "So far, BSDi (which is the system where I first noticed this issue) has committed to fixing this interface if both the FreeBSD and NetBSD groups will commit to fixing it also." Make up your own mind about this. ----[-------------- OpenBSD My reading of CHANGELOG for OpenBSD 2.1 reveals that OpenBSD's behavior with regard to ip_len and ip_off has been fixed to require these fields to be in network byte order, that is, they are sent without modification. From CHANGELOG: "This is a compatibility/portability fix and we expect other BSD systems to eventually follow suit." As of OpenBSD 2.3, IP_HDRINCL is supported from within the Linux emulation subsystem, and its semantics should be similar to the real thing. OpenBSD, in common with other BSD variants, supports the BPF interface. ----[-------------- Solaris Solaris allows the use of the IPPROTO_RAW option when requesting a PF_INET, SOCK_RAW socket. This is somewhat analogous to IP_HDRINCL. It will *expect*= an IP header to be included in the data written to such a socket in this instance. It will compute the IP checksum on your behalf. Solaris (at least 2.5/2.6) and changes the ip_id field, and adds a Do Not Fragment flag to the IP header (IP_DF). It also expects the checksum to contain the length of the transport level header, and the data. Solaris uses the DLPI link layer interface. Libnet supports this link layer. This should yield the desired results. ----[-------------- IRIX =46rom the Raw IP Networking FAQ: "Further reports which I cannot verify (can't reproduce), consist of claims that Solaris 2.x and Irix 6.x will change the sequence and acknowledgment numbers. Irix 6.x is also believed to have the problem mentioned in the previous paragraph. If you experience these problems, double check with the example source code. " SGI: Patch 2673 [IRIX 6.2] - IRIX 6.2 Networking Kernel Rollup #6 Fixes: 473385 - IP_HDRINCL does not work on IP options and ip_id is bad SGI: Patch 3577 [IRIX 6.4] - IRIX 6.4 Networking Kernel Rollup #7 473385 - IP_HDRINCL does not work on IP options and ip_id is bad I think it's becoming something of a consensus within the industry that IRIX is 'swiss cheese' when it comes to security - it's full of holes. Regard th= is as an inane, 'smart-ass' comment at your own peril. I would be grateful to hear from anyone who has applied the above patches to production IRIX machi= nes which exercise this functionality. ----[-------------- Linux One bug reported in Linux in July 1998 involved Linux's sendto() over SOCK_= RAW code not taking IP_HDRINCL into account, when comparing the packet length w= ith the MTU for the underlying link layer interface. Linux uses the SOCK_PACKET link layer interface. This is currently supported by libpcap, in pcap-linux.c. ----[-------------- HPUX I don't have an HPUX host to test IP_HDRINCL functionality on, but based on what I've seen, I would wager that arbitrary IP packet injection requires t= hat one go directly to the link layer. HPUX is known to support the DLPI interf= ace for this. ----[-------------- Win32 IP_HDRINCL may not be supported by the underlying Winsock Service Provider under Win32. Recall that the Winsock family of libraries, under Windows platforms, define an interface for Winsock functionality; the implementation is provided by a 'Service Provider' set of DLLs. Microsoft's Winsock is known NOT to support IP_HDRINCL on any platform OTHER than Windows 2000. Details of this can be found in the Winsock Programmer's FAQ. Specifics of how IP_HDRINCL works under Windows 2000 are not known at this time. If you know of other Winsock 2 compatible SPs which grok IP_HDRINCL, let me know via email, and I will update this document. For the time being, you probably want to talk straight to NDIS, which is the link layer standard wh= ich Microsoft developed with 3Com and adopted for Windows NT. Windows 2000 makes use of the new NDIS 5.0 specification. ----[-------------- Amiga AmiTCP =46rom http://cloanto.com/kb/4-112.html: "Some versions of Windows TCP/IP do not support certain rarely-used TCP= /IP socket options which the original Amiga bsdsocket.library supports. For example, the "traceroute" command which comes with AmiTCP/IP may fail if Winsock does not support IP_HDRINCL/raw sockets." Sounds to me as though Amiga AmiTCP supports IP_HDRINCL. I'd love to hear m= ore about this from other Amigans. It's more than likely that SANA-2 compliant network drivers for the Amiga will do link-layer capture and injection. ----[-------------- Other platforms Information about other platforms is solicited from all readers, wherever possible. I'd be particularly interested in the behavior of QNX, AmiTCP, and any embedded system which offers BSD SOCK_RAW or link layer services. I will be cataloguing and publishing this information for use in future projects. --f2QGlHpHGjS2mn6Y-- --32u276st3Jlj2kUU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBH0oNueUpAYYNtTsRAvTFAJ9mRCiPz9RdrKVM+2uk7V/esMaSywCeOJN5 PiPmT8AFEk+90EKzCePtGAM= =CRad -----END PGP SIGNATURE----- --32u276st3Jlj2kUU-- From pavlin@icir.org Mon Aug 16 23:00:03 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 16 Aug 2004 15:00:03 -0700 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Message from Mark Handley of "Fri, 13 Aug 2004 08:26:13 BST." <6907.1092381973@vulture.xorp.org> Message-ID: <200408162200.i7GM03wK049321@possum.icir.org> > >c) If the next-hop router toward the destination is not resolvable, > > then the StaticRoutes should still add the route to the RIB, and > > then let the RIB deal with resolving the next-hop router > > whenever the status of the related network interface changes. > > Doing something like this may require changes to the RIB. > > The RIB does actually contain code to do this - it's just not enabled > for IGP routes. The code was originally there for BGP, before we > realised that BGP routes where the BGP nexthop is unreachable > shouldn't be considered for the BGP decision process. Currently I > believe this code in the RIB is unused - you can find it in > rib/rt_tab_extint.cc (look for anything to do with > unresolved_nexthops). > > In any event, this opens up several more questions: > > - Should static_routes be able to specify a nexthop that isn't an > immediate neighbour? (So long as the nexthop is reachable via > another route). Retasking the code in ExtIntTable to do nexthop > lookup for IGP routes would give us this. We'd need to be careful > to check for mutual recursion though. > > - If we have a static_route for a destination, and a dynamic route > (say from RIP) for the same destination, the static_route will > normally win on admin distance. Now, say the interface for the > static_route goes down. Should the route fall back to that from > RIP? I can see both answers make sense: > > + It should not fall back because the network administrator > really really wanted to NOT use the RIP route - that's why he > configured the static route. > > + It should fall back because we really want to ensure > reachability above all else. > > Anyway, the answer to the second question determines (or at least is > closely related to) whether you want the resolvabilty test in the > static_routes process, or in the RIB itself. I believe that both mechanisms can be implemented within StaticRoutes, but the final decision which one to use would be left to the netadmin. For example, if a network interfaces goes down and if the neadmin does NOT want to use the RIP routes for the same destination, then when configuring StaticRoutes, all he needs to do is to add the same route twice, but with different metric. E.g, the first route with the preferred metric will use the desired network interface. The second route with the less preferred metric will use a dummy /dev/null-like network interface toward the destination. If the desired network interface fails, then StaticRoutes itself will replace the first route with the second route inside the RIB (this operation can be atomic, because there is already a "replace_route" XRL). If the netadmin does want to ensure reachability, then he simply doesn't need to install the second route with the less preferred metric and the /dev/null next-hop network interface. The above logic is quite simple to implement inside StaticRoutes, and the only caveat to the end-user is that it will become legal to install inside StaticRoutes the same route more than once, but with different attributes. > > This could of course be a policy question - if the RIB had the nexthop > reachability code, we could configure the behaviour for each static > route on a case-by-case basis. If static_routes does the reachability > test, then the route would be withdrawn when the interface goes down, > allowing the RIP route to take over. If static_routes always passes > the route to the RIB , and the RIBdoes the reachability test, then it > would be after the admin_distance test, and so the RIP route would not > take over if the interface went down. > > > In any event, there needs to be a way to should the routing table > including the routes with unresolvable nexthops to see what the > problem is. Currently the way to show static routes is to show the > RIB's view of them, which only shows the routes with reachable > nexthops. Yes, StaticRoutes itself should support some xorpsh "show" commands, so we can look directly into its state. Currently, we can look only into what gets installed into the RIB. Regards, Pavlin From M.Handley@cs.ucl.ac.uk Mon Aug 16 23:13:52 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 16 Aug 2004 23:13:52 +0100 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Your message of "Mon, 16 Aug 2004 15:00:03 PDT." <200408162200.i7GM03wK049321@possum.icir.org> Message-ID: <1523.1092694432@cs.ucl.ac.uk> >I believe that both mechanisms can be implemented within >StaticRoutes, but the final decision which one to use would be left >to the netadmin. > >For example, if a network interfaces goes down and if the neadmin >does NOT want to use the RIP routes for the same destination, then >when configuring StaticRoutes, all he needs to do is to add the same >route twice, but with different metric. E.g, the first route with >the preferred metric will use the desired network interface. The >second route with the less preferred metric will use a dummy >/dev/null-like network interface toward the destination. If the >desired network interface fails, then StaticRoutes itself will >replace the first route with the second route inside the RIB (this >operation can be atomic, because there is already a "replace_route" >XRL). > >If the netadmin does want to ensure reachability, then he simply >doesn't need to install the second route with the less preferred >metric and the /dev/null next-hop network interface. There's a simpler solution than this. The XRL interface to the RIB should require the admin distance to be specified on a per-route basis. This would allow low-priority static routes - something I think is quite desirable, as a fallback in case a dynamic routing protocol loses all routes. Currently the RIB chooses the admin distance for each protocol. But this isn't a good idea - if a new protocol comes along it requires the RIB to be modified. The routing protocol should specify the admin distance. Once it's doing this, it can also do it on a per-route basis, so that the default admin distance for a protocol can be overridden if desired. Probably this would only be used for static routes, and as a result of policy filtering. - Mark From pavlin@icir.org Mon Aug 16 23:40:58 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 16 Aug 2004 15:40:58 -0700 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Message from Mark Handley of "Mon, 16 Aug 2004 23:13:52 BST." <1523.1092694432@cs.ucl.ac.uk> Message-ID: <200408162240.i7GMewwK049634@possum.icir.org> > >I believe that both mechanisms can be implemented within > >StaticRoutes, but the final decision which one to use would be left > >to the netadmin. > > > >For example, if a network interfaces goes down and if the neadmin > >does NOT want to use the RIP routes for the same destination, then > >when configuring StaticRoutes, all he needs to do is to add the same > >route twice, but with different metric. E.g, the first route with > >the preferred metric will use the desired network interface. The > >second route with the less preferred metric will use a dummy > >/dev/null-like network interface toward the destination. If the > >desired network interface fails, then StaticRoutes itself will > >replace the first route with the second route inside the RIB (this > >operation can be atomic, because there is already a "replace_route" > >XRL). > > > >If the netadmin does want to ensure reachability, then he simply > >doesn't need to install the second route with the less preferred > >metric and the /dev/null next-hop network interface. > > There's a simpler solution than this. The XRL interface to the RIB > should require the admin distance to be specified on a per-route > basis. This would allow low-priority static routes - something I > think is quite desirable, as a fallback in case a dynamic routing > protocol loses all routes. > > Currently the RIB chooses the admin distance for each protocol. But > this isn't a good idea - if a new protocol comes along it requires the > RIB to be modified. The routing protocol should specify the admin > distance. Once it's doing this, it can also do it on a per-route > basis, so that the default admin distance for a protocol can be > overridden if desired. Probably this would only be used for static > routes, and as a result of policy filtering. I think what you are proposing is kind of orthogonal. I was suggesting that we can use routes with different metrics to configure StaticRoutes such that if the original route fails, and if we don't want to use the RIP routes for a particular destination, then the second route (that points to /dev/null) will be used by StaticRoutes and installed into the RIB. Obviously, this can't be used to install fallback static routes if the dynamic routing fails, but can be used to keep _some_ high-priority static routes into the RIB. I agree with your suggestion to export the admin distance to the RIB XRL add/replace interface. Then, we can mediate between protocols and let static routes being used as backups. In other words, I think we want both solutions, because they are not mutually exclusive, but complementary. Regards, Pavlin From M.Handley@cs.ucl.ac.uk Mon Aug 16 23:54:49 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 16 Aug 2004 23:54:49 +0100 Subject: [Xorp-hackers] Adding static routes with unresolved next-hop router In-Reply-To: Your message of "Mon, 16 Aug 2004 15:40:58 PDT." <200408162240.i7GMewwK049634@possum.icir.org> Message-ID: <1555.1092696889@cs.ucl.ac.uk> >I was suggesting that we can use routes with different metrics to >configure StaticRoutes such that if the original route fails, and if >we don't want to use the RIP routes for a particular destination, >then the second route (that points to /dev/null) will be used by >StaticRoutes and installed into the RIB. Obviously, this can't be >used to install fallback static routes if the dynamic routing fails, >but can be used to keep _some_ high-priority static routes into the >RIB. Agreed - both capabilities are useful. But we need to be careful about feature interaction here. From BGP's point of view, is a static route for a BGP nexthop that points explicitly to the discard interface a resolvable nexthop, or an unresolvable one? Currently if there's a route in the RIB for a BGP nexthop, then BGP will consider it resolvable, even if it points to the discard interface. There may be other interactions that also need to be considered, but this is the obvious one that occurs to me. - Mark From Ray Qiu Tue Aug 17 06:10:42 2004 From: Ray Qiu (Ray Qiu) Date: Tue, 17 Aug 2004 05:10:42 +0000 Subject: [Xorp-hackers] Re: process auto restart In-Reply-To: References: Message-ID: ------=_Part_104_28907956.1092719442843 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I made a patch for process auto-restart. It kinda of works. fea restart is not supported. I want to post it here, so you guys can provide comments and better ideas. My idea is that if some critical processes can not support restart, the whole XORP stack should be restarted (e.g. killed and brought back by init) upon their failures. Thanks. --Ray Index: bgp/process_watch.cc =================================================================== RCS file: /cvs/xorp/bgp/process_watch.cc,v retrieving revision 1.13 diff -r1.13 process_watch.cc 80c80 < ::exit(-1); --- > //::exit(-1); 83,84c83,84 < start_kill_timer(); < _shutdown->dispatch(); --- > //start_kill_timer(); > //_shutdown->dispatch(); Index: rtrmgr/Makefile.am =================================================================== RCS file: /cvs/xorp/rtrmgr/Makefile.am,v retrieving revision 1.28 diff -r1.28 Makefile.am 180a181 > test_templates_SOURCES += master_conf_tree.cc 254a256 > test_module_manager_SOURCES += master_conf_tree.hh 268a271 > test_module_manager_SOURCES += master_conf_tree.cc 269a273 > test_module_manager_SOURCES += master_conf_tree.cc Index: rtrmgr/Makefile.in =================================================================== RCS file: /cvs/xorp/rtrmgr/Makefile.in,v retrieving revision 1.39 diff -r1.39 Makefile.in 170c170 < module_command.$(OBJEXT) module_manager.$(OBJEXT) \ --- > module_command.$(OBJEXT) module_manager.$(OBJEXT) master_conf_tree.$(OBJEXT) \ 200c200 < task.$(OBJEXT) template_commands.$(OBJEXT) \ --- > task.$(OBJEXT) template_commands.$(OBJEXT) master_conf_tree.$(OBJEXT) \ Index: rtrmgr/conf_tree_node.cc =================================================================== RCS file: /cvs/xorp/rtrmgr/conf_tree_node.cc,v retrieving revision 1.50 diff -r1.50 conf_tree_node.cc 17d16 < 1104a1104,1117 > ConfigTreeNode::mark_subtree_as_uncommitted() > { > _existence_committed = false; > _value_committed = false; > > list::iterator iter; > iter = _children.begin(); > while (iter != _children.end()) { > (*iter)->mark_subtree_as_uncommitted(); > ++iter; > } > } > > void Index: rtrmgr/conf_tree_node.hh =================================================================== RCS file: /cvs/xorp/rtrmgr/conf_tree_node.hh,v retrieving revision 1.24 diff -r1.24 conf_tree_node.hh 52a53 > void mark_subtree_as_uncommitted(); Index: rtrmgr/main_rtrmgr.cc =================================================================== RCS file: /cvs/xorp/rtrmgr/main_rtrmgr.cc,v retrieving revision 1.50 diff -r1.50 main_rtrmgr.cc 16a17,19 > //#define DEBUG_LOGGING > //#define DEBUG_PRINT_FUNCTION_NAME > 263d265 < 273a276 > mmgr.set_conf_tree(_mct); Index: rtrmgr/module_manager.cc =================================================================== RCS file: /cvs/xorp/rtrmgr/module_manager.cc,v retrieving revision 1.32 diff -r1.32 module_manager.cc 16a17,19 > //#define DEBUG_LOGGING > //#define DEBUG_PRINT_FUNCTION_NAME > 35a39,40 > #include "master_conf_tree.hh" > #include "conf_tree_node.hh" 86,88c91,122 < } < } < module_pids.erase(pid_iter); --- > // Restart the module because it exited abnormally. > // It probably crashed. > // > if (module->status() == Module::MODULE_FAILED) { > if ((!strcmp(module->name().c_str(), "fea")) || (!strcmp(module->name().c_str(), "interfaces"))) { > XLOG_ERROR("Fatal error: fea died, exit XORP.\n"); > kill(getpid(), SIGTERM); > return; > } > XLOG_INFO("Restarting module %s ...\n", module->name().c_str()); > XorpCallback1::RefPtr run_cb > = callback(module, &Module::module_run_done); > if (module->run(true, run_cb) < 0) { > XLOG_ERROR("Failed to restart module %s.\n", module->name().c_str()); > } > else { > XLOG_INFO("Module %s is successfully restarted.\n", > module->name().c_str()); > } > MasterConfigTree* mct; > ConfigTreeNode* ctn; > mct = module->module_manager().get_conf_tree(); > (const ConfigTreeNode*) ctn = mct->find_config_module(module->name()); > if (ctn != NULL){ > XLOG_INFO("Configure module %s.\n", module->name().c_str()); > ctn->mark_subtree_as_uncommitted(); > mct->execute(); > } > } > } > module_pids.erase(pid_iter); > } 106a141,166 > if (module->status() == Module::MODULE_FAILED) { > // fea restart is not supported. > if ((!strcmp(module->name().c_str(), "fea")) || (!strcmp(module->name().c_str(), "interfaces"))) { > XLOG_ERROR("Fatal error: fea died, exit XORP.\n"); > kill(getpid(), SIGTERM); > return; > } > XLOG_INFO("Restarting module %s ...\n", module->name().c_str()); > XorpCallback1::RefPtr run_cb > = callback(module, &Module::module_run_done); > if (module->run(true, run_cb) < 0) { > XLOG_ERROR("Failed to restart module %s.\n", module->name().c_str()); > } > else { > XLOG_INFO("Module %s is successfully restarted.\n", module->name().c_str()); > } > MasterConfigTree* mct; > ConfigTreeNode* ctn; > mct = module->module_manager().get_conf_tree(); > (const ConfigTreeNode*) ctn = mct->find_config_module(module->name()); > if (ctn != NULL){ > XLOG_INFO("Configure module %s.\n", module->name().c_str()); > ctn->mark_subtree_as_uncommitted(); > mct->execute(); > } > } 357c417 < --- > 535c595,596 < _xorp_root_dir(xorp_root_dir) --- > _xorp_root_dir(xorp_root_dir), > _master_conf_tree(NULL) Index: rtrmgr/module_manager.hh =================================================================== RCS file: /cvs/xorp/rtrmgr/module_manager.hh,v retrieving revision 1.22 diff -r1.22 module_manager.hh 27d26 < 29a29,30 > class MasterConfigTree; > 35a37 > 77a80,81 > ModuleManager& module_manager() const { return _mmgr; } > string const name() { return _name; } 95a100 > 138c143,145 < --- > void set_conf_tree(MasterConfigTree* v) { _master_conf_tree = v; } > MasterConfigTree* get_conf_tree() const { return _master_conf_tree; } > 146a154 > MasterConfigTree* _master_conf_tree; ------=_Part_104_28907956.1092719442843 Content-Type: application/octet-stream; name="rtrmgr-patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rtrmgr-patch" SW5kZXg6IGJncC9wcm9jZXNzX3dhdGNoLmNjCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMveG9y cC9iZ3AvcHJvY2Vzc193YXRjaC5jYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMwpkaWZmIC1y MS4xMyBwcm9jZXNzX3dhdGNoLmNjCjgwYzgwCjwgCTo6ZXhpdCgtMSk7Ci0tLQo+IAkvLzo6ZXhp dCgtMSk7CjgzLDg0YzgzLDg0CjwgCXN0YXJ0X2tpbGxfdGltZXIoKTsKPCAJX3NodXRkb3duLT5k aXNwYXRjaCgpOwotLS0KPiAJLy9zdGFydF9raWxsX3RpbWVyKCk7Cj4gCS8vX3NodXRkb3duLT5k aXNwYXRjaCgpOwpJbmRleDogcnRybWdyL01ha2VmaWxlLmFtCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6 IC9jdnMveG9ycC9ydHJtZ3IvTWFrZWZpbGUuYW0sdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjgK ZGlmZiAtcjEuMjggTWFrZWZpbGUuYW0KMTgwYTE4MQo+IHRlc3RfdGVtcGxhdGVzX1NPVVJDRVMJ Kz0gbWFzdGVyX2NvbmZfdHJlZS5jYwoyNTRhMjU2Cj4gdGVzdF9tb2R1bGVfbWFuYWdlcl9TT1VS Q0VTCSs9IG1hc3Rlcl9jb25mX3RyZWUuaGgKMjY4YTI3MQo+IHRlc3RfbW9kdWxlX21hbmFnZXJf U09VUkNFUwkrPSBtYXN0ZXJfY29uZl90cmVlLmNjCjI2OWEyNzMKPiB0ZXN0X21vZHVsZV9tYW5h Z2VyX1NPVVJDRVMJKz0gbWFzdGVyX2NvbmZfdHJlZS5jYwpJbmRleDogcnRybWdyL01ha2VmaWxl LmluCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMveG9ycC9ydHJtZ3IvTWFrZWZpbGUuaW4sdgpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMzkKZGlmZiAtcjEuMzkgTWFrZWZpbGUuaW4KMTcwYzE3MAo8 IAltb2R1bGVfY29tbWFuZC4kKE9CSkVYVCkgbW9kdWxlX21hbmFnZXIuJChPQkpFWFQpIFwKLS0t Cj4gCW1vZHVsZV9jb21tYW5kLiQoT0JKRVhUKSBtb2R1bGVfbWFuYWdlci4kKE9CSkVYVCkgbWFz dGVyX2NvbmZfdHJlZS4kKE9CSkVYVCkgXAoyMDBjMjAwCjwgCXRhc2suJChPQkpFWFQpIHRlbXBs YXRlX2NvbW1hbmRzLiQoT0JKRVhUKSBcCi0tLQo+IAl0YXNrLiQoT0JKRVhUKSB0ZW1wbGF0ZV9j b21tYW5kcy4kKE9CSkVYVCkgbWFzdGVyX2NvbmZfdHJlZS4kKE9CSkVYVCkgXApJbmRleDogcnRy bWdyL2NvbmZfdHJlZV9ub2RlLmNjCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMveG9ycC9ydHJt Z3IvY29uZl90cmVlX25vZGUuY2MsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNTAKZGlmZiAtcjEu NTAgY29uZl90cmVlX25vZGUuY2MKMTdkMTYKPCAKMTEwNGExMTA0LDExMTcKPiBDb25maWdUcmVl Tm9kZTo6bWFya19zdWJ0cmVlX2FzX3VuY29tbWl0dGVkKCkKPiB7Cj4gICAgIF9leGlzdGVuY2Vf Y29tbWl0dGVkID0gZmFsc2U7Cj4gICAgIF92YWx1ZV9jb21taXR0ZWQgPSBmYWxzZTsKPiAKPiAg ICAgbGlzdDxDb25maWdUcmVlTm9kZSo+OjppdGVyYXRvciBpdGVyOwo+ICAgICBpdGVyID0gX2No aWxkcmVuLmJlZ2luKCk7Cj4gICAgIHdoaWxlIChpdGVyICE9IF9jaGlsZHJlbi5lbmQoKSkgewo+ IAkoKml0ZXIpLT5tYXJrX3N1YnRyZWVfYXNfdW5jb21taXR0ZWQoKTsKPiAJKytpdGVyOwo+ICAg ICB9Cj4gfQo+IAo+IHZvaWQKSW5kZXg6IHJ0cm1nci9jb25mX3RyZWVfbm9kZS5oaAo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09ClJDUyBmaWxlOiAvY3ZzL3hvcnAvcnRybWdyL2NvbmZfdHJlZV9ub2RlLmhoLHYKcmV0cmll dmluZyByZXZpc2lvbiAxLjI0CmRpZmYgLXIxLjI0IGNvbmZfdHJlZV9ub2RlLmhoCjUyYTUzCj4g ICAgIHZvaWQgbWFya19zdWJ0cmVlX2FzX3VuY29tbWl0dGVkKCk7CkluZGV4OiBydHJtZ3IvbWFp bl9ydHJtZ3IuY2MKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy94b3JwL3J0cm1nci9tYWluX3J0 cm1nci5jYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS41MApkaWZmIC1yMS41MCBtYWluX3J0cm1n ci5jYwoxNmExNywxOQo+IC8vI2RlZmluZSBERUJVR19MT0dHSU5HCj4gLy8jZGVmaW5lIERFQlVH X1BSSU5UX0ZVTkNUSU9OX05BTUUKPiAKMjYzZDI2NQo8IAoyNzNhMjc2Cj4gCW1tZ3Iuc2V0X2Nv bmZfdHJlZShfbWN0KTsKSW5kZXg6IHJ0cm1nci9tb2R1bGVfbWFuYWdlci5jYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 ClJDUyBmaWxlOiAvY3ZzL3hvcnAvcnRybWdyL21vZHVsZV9tYW5hZ2VyLmNjLHYKcmV0cmlldmlu ZyByZXZpc2lvbiAxLjMyCmRpZmYgLXIxLjMyIG1vZHVsZV9tYW5hZ2VyLmNjCjE2YTE3LDE5Cj4g Ly8jZGVmaW5lIERFQlVHX0xPR0dJTkcKPiAvLyNkZWZpbmUgREVCVUdfUFJJTlRfRlVOQ1RJT05f TkFNRQo+IAozNWEzOSw0MAo+ICNpbmNsdWRlICJtYXN0ZXJfY29uZl90cmVlLmhoIgo+ICNpbmNs dWRlICJjb25mX3RyZWVfbm9kZS5oaCIKODYsODhjOTEsMTIyCjwgCSAgICB9CjwgCX0KPCAJbW9k dWxlX3BpZHMuZXJhc2UocGlkX2l0ZXIpOwotLS0KPiAJCS8vIFJlc3RhcnQgdGhlIG1vZHVsZSBi ZWNhdXNlIGl0IGV4aXRlZCBhYm5vcm1hbGx5LiAKPiAJICAgICAgICAvLyBJdCBwcm9iYWJseSBj cmFzaGVkLgo+IAkJLy8KPiAJICAgICAgICBpZiAobW9kdWxlLT5zdGF0dXMoKSA9PSBNb2R1bGU6 Ok1PRFVMRV9GQUlMRUQpIHsKPiAJCSAgICBpZiAoKCFzdHJjbXAobW9kdWxlLT5uYW1lKCkuY19z dHIoKSwgImZlYSIpKSB8fCAoIXN0cmNtcChtb2R1bGUtPm5hbWUoKS5jX3N0cigpLCAiaW50ZXJm YWNlcyIpKSkgewo+IAkJICAgICAgICBYTE9HX0VSUk9SKCJGYXRhbCBlcnJvcjogZmVhIGRpZWQs IGV4aXQgWE9SUC5cbiIpOwo+IAkJICAgICAgICBraWxsKGdldHBpZCgpLCBTSUdURVJNKTsKPiAJ CSAgICAgICAgcmV0dXJuOwo+IAkJICAgIH0KPiAJICAgICAgICAgICAgWExPR19JTkZPKCJSZXN0 YXJ0aW5nIG1vZHVsZSAlcyAuLi5cbiIsIG1vZHVsZS0+bmFtZSgpLmNfc3RyKCkpOwo+IAkgICAg ICAgICAgICBYb3JwQ2FsbGJhY2sxPHZvaWQsIGJvb2w+OjpSZWZQdHIgcnVuX2NiIAo+IAkJICAg ICAgICA9IGNhbGxiYWNrKG1vZHVsZSwgJk1vZHVsZTo6bW9kdWxlX3J1bl9kb25lKTsKPiAJICAg ICAgICAgICAgaWYgKG1vZHVsZS0+cnVuKHRydWUsIHJ1bl9jYikgPCAwKSB7Cj4gCQkgICAgICAg IFhMT0dfRVJST1IoIkZhaWxlZCB0byByZXN0YXJ0IG1vZHVsZSAlcy5cbiIsIG1vZHVsZS0+bmFt ZSgpLmNfc3RyKCkpOwo+IAkgICAgICAgICAgICB9ICAgIAkKPiAJCSAgICBlbHNlIHsKPiAJCSAg ICAgICAgWExPR19JTkZPKCJNb2R1bGUgJXMgaXMgc3VjY2Vzc2Z1bGx5IHJlc3RhcnRlZC5cbiIs Cj4gCQkJICAgIG1vZHVsZS0+bmFtZSgpLmNfc3RyKCkpOwo+IAkgICAgICAgICAgICB9Cj4gCQkg ICAgTWFzdGVyQ29uZmlnVHJlZSogbWN0Owo+IAkJICAgIENvbmZpZ1RyZWVOb2RlKiBjdG47Cj4g CQkgICAgbWN0ID0gbW9kdWxlLT5tb2R1bGVfbWFuYWdlcigpLmdldF9jb25mX3RyZWUoKTsKPiAJ CSAgICAoY29uc3QgQ29uZmlnVHJlZU5vZGUqKSBjdG4gPSBtY3QtPmZpbmRfY29uZmlnX21vZHVs ZShtb2R1bGUtPm5hbWUoKSk7Cj4gCQkgICAgaWYgKGN0biAhPSBOVUxMKXsKPiAJCSAgICAgICAg WExPR19JTkZPKCJDb25maWd1cmUgbW9kdWxlICVzLlxuIiwgbW9kdWxlLT5uYW1lKCkuY19zdHIo KSk7Cj4gCQkgICAgICAgIGN0bi0+bWFya19zdWJ0cmVlX2FzX3VuY29tbWl0dGVkKCk7Cj4gCQkg ICAgICAgIG1jdC0+ZXhlY3V0ZSgpOwo+IAkJICAgIH0KPiAJCX0KPiAgICAgICAgICAgICB9Cj4g CSAgICBtb2R1bGVfcGlkcy5lcmFzZShwaWRfaXRlcik7Cj4gCX0JCjEwNmExNDEsMTY2Cj4gCSAg ICBpZiAobW9kdWxlLT5zdGF0dXMoKSA9PSBNb2R1bGU6Ok1PRFVMRV9GQUlMRUQpIHsKPiAJICAg ICAgICAvLyBmZWEgcmVzdGFydCBpcyBub3Qgc3VwcG9ydGVkLgo+IAkJaWYgKCghc3RyY21wKG1v ZHVsZS0+bmFtZSgpLmNfc3RyKCksICJmZWEiKSkgfHwgKCFzdHJjbXAobW9kdWxlLT5uYW1lKCku Y19zdHIoKSwgImludGVyZmFjZXMiKSkpIHsKPiAJCSAgICBYTE9HX0VSUk9SKCJGYXRhbCBlcnJv cjogZmVhIGRpZWQsIGV4aXQgWE9SUC5cbiIpOwo+IAkJICAgIGtpbGwoZ2V0cGlkKCksIFNJR1RF Uk0pOwo+IAkJICAgIHJldHVybjsKPiAJCX0KPiAJICAgICAgICBYTE9HX0lORk8oIlJlc3RhcnRp bmcgbW9kdWxlICVzIC4uLlxuIiwgbW9kdWxlLT5uYW1lKCkuY19zdHIoKSk7Cj4gCSAgICAgICAg WG9ycENhbGxiYWNrMTx2b2lkLCBib29sPjo6UmVmUHRyIHJ1bl9jYiAKPiAJCSAgICA9IGNhbGxi YWNrKG1vZHVsZSwgJk1vZHVsZTo6bW9kdWxlX3J1bl9kb25lKTsKPiAJICAgICAgICBpZiAobW9k dWxlLT5ydW4odHJ1ZSwgcnVuX2NiKSA8IDApIHsKPiAJCSAgICBYTE9HX0VSUk9SKCJGYWlsZWQg dG8gcmVzdGFydCBtb2R1bGUgJXMuXG4iLCBtb2R1bGUtPm5hbWUoKS5jX3N0cigpKTsKPiAJICAg ICAgICB9ICAgIAkKPiAJCWVsc2Ugewo+IAkJICAgIFhMT0dfSU5GTygiTW9kdWxlICVzIGlzIHN1 Y2Nlc3NmdWxseSByZXN0YXJ0ZWQuXG4iLCBtb2R1bGUtPm5hbWUoKS5jX3N0cigpKTsKPiAJICAg ICAgICB9Cj4gCQlNYXN0ZXJDb25maWdUcmVlKiBtY3Q7Cj4gCQlDb25maWdUcmVlTm9kZSogY3Ru Owo+IAkJbWN0ID0gbW9kdWxlLT5tb2R1bGVfbWFuYWdlcigpLmdldF9jb25mX3RyZWUoKTsKPiAJ CShjb25zdCBDb25maWdUcmVlTm9kZSopIGN0biA9IG1jdC0+ZmluZF9jb25maWdfbW9kdWxlKG1v ZHVsZS0+bmFtZSgpKTsKPiAJCWlmIChjdG4gIT0gTlVMTCl7Cj4gCQkgICAgWExPR19JTkZPKCJD b25maWd1cmUgbW9kdWxlICVzLlxuIiwgbW9kdWxlLT5uYW1lKCkuY19zdHIoKSk7Cj4gCQkgICAg Y3RuLT5tYXJrX3N1YnRyZWVfYXNfdW5jb21taXR0ZWQoKTsKPiAJCSAgICBtY3QtPmV4ZWN1dGUo KTsKPiAJCX0KPiAJICAgIH0KMzU3YzQxNwo8IAotLS0KPiAgICAgCjUzNWM1OTUsNTk2CjwgICAg ICAgX3hvcnBfcm9vdF9kaXIoeG9ycF9yb290X2RpcikKLS0tCj4gICAgICAgX3hvcnBfcm9vdF9k aXIoeG9ycF9yb290X2RpciksCj4gICAgICAgX21hc3Rlcl9jb25mX3RyZWUoTlVMTCkKSW5kZXg6 IHJ0cm1nci9tb2R1bGVfbWFuYWdlci5oaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3ZzL3hvcnAv cnRybWdyL21vZHVsZV9tYW5hZ2VyLmhoLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjIyCmRpZmYg LXIxLjIyIG1vZHVsZV9tYW5hZ2VyLmhoCjI3ZDI2CjwgCjI5YTI5LDMwCj4gY2xhc3MgTWFzdGVy Q29uZmlnVHJlZTsKPiAKMzVhMzcKPiAKNzdhODAsODEKPiAgICAgTW9kdWxlTWFuYWdlciYgbW9k dWxlX21hbmFnZXIoKSBjb25zdCB7IHJldHVybiBfbW1ncjsgfQo+ICAgICBzdHJpbmcgY29uc3Qg bmFtZSgpIHsgcmV0dXJuIF9uYW1lOyB9Cjk1YTEwMAo+IAoxMzhjMTQzLDE0NQo8IAotLS0KPiAg ICAgdm9pZCBzZXRfY29uZl90cmVlKE1hc3RlckNvbmZpZ1RyZWUqIHYpIHsgX21hc3Rlcl9jb25m X3RyZWUgPSB2OyB9Cj4gICAgIE1hc3RlckNvbmZpZ1RyZWUqIGdldF9jb25mX3RyZWUoKSBjb25z dCB7IHJldHVybiBfbWFzdGVyX2NvbmZfdHJlZTsgfQo+ICAgICAKMTQ2YTE1NAo+ICAgICBNYXN0 ZXJDb25maWdUcmVlKglfbWFzdGVyX2NvbmZfdHJlZTsK ------=_Part_104_28907956.1092719442843-- From pavlin@icir.org Thu Aug 19 03:44:52 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 18 Aug 2004 19:44:52 -0700 Subject: [Xorp-hackers] Re: process auto restart In-Reply-To: Message from Ray Qiu of "Tue, 17 Aug 2004 05:10:42 -0000." Message-ID: <200408190244.i7J2iqwK052881@possum.icir.org> > I made a patch for process auto-restart. It kinda of works. fea > restart is not > supported. I want to post it here, so you guys can provide comments > and better ideas. > > My idea is that if some critical processes can not support restart, > the whole XORP > stack should be restarted (e.g. killed and brought back by init) upon > their failures. Ray, Thank you for your patch. I just commited it with some modifications. Below are my comments. * The rtrmgr should not use hard-coded names like "fea" and "interfaces" to figure-out whether a failed process can be restarted. Hence, I removed the string comparison against those particular strings and let the rtrmgr restart any process. If restarting the fea (or any other processes) is problematic, then this should be specified in the particular rtrmgr template file (though, for that we need to introduce some new keyword). * It appears that you have modified BGP NOT to exit if it discovers that a process like fea has disappeared. However, if the FEA really fails (and/or is restarted), then we need to restart BGP. If BGP itself doesn't exit, then the rtrmgr needs to track all dependencies between the proceses and it has to figure-out to explicitly kill BGP. For the time being, this is rather a complicated task, and it is much simpler if BGP itself exits once it detects that the FEA has failed. After it exits, the rtrmgr should be able to restart it as any other failed processes. Therefore, I haven't committed the BGP modification. * Currently, restarting a failed process doesn't work if the process failed while being reconfigured via xorpsh. The reason is if an XRL triggers a coredump in the target process, then the rtrmgr will detect the process failure and will attempt to restart it before the XRL's callback has been called to report a failure. The code for restarting a process assumes that the previous state has been clean (e.g., ConfigTreeNode::_actions_pending == 0). Cleaning-up the pending XRL events to fix the problem won't be trivial. Ideally, we would be using the finder to find-out that a process has died (rather than obtaining the child process status). When the code is refactored to include such solution, then it should address the pending XRL events as well. * If for whatever reason an user wants to kill a process, that process will be unconditionally restarted, which is not the desired behavior. Therefore, I modified the code NOT to restart a process, if it failed because of SIGTERM or SIGKILL (e.g., the signals that are typically sent by an user when he wants to kill a process). * The process restarting mechanism is disabled by default until we have a finder-based process observation that is robust and well-tested. For the time being there is a new "-r" rtrmgr command-line option to enable the existing mechanism for restarting failed processes. Though, once we have the finder-based solution, we may still keep "-r" if it proves to be useful. Thanks! Pavlin From Ray Qiu Thu Aug 19 21:36:52 2004 From: Ray Qiu (Ray Qiu) Date: Thu, 19 Aug 2004 13:36:52 -0700 Subject: [Xorp-hackers] Shell command suppport Message-ID: Hi, Is there any particular reason that XORP doesn't support executing shell commands from the CLI? Thanks. --Ray From atanu@ICSI.Berkeley.EDU Fri Aug 20 00:05:44 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 19 Aug 2004 16:05:44 -0700 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: Message from Ray Qiu of "Thu, 19 Aug 2004 13:36:52 PDT." Message-ID: <37323.1092956744@tigger.icir.org> If the xorpsh is installed as a login shell it may not be desirable to allow the execution of shell commands. Atanu. >>>>> "Ray" == Ray Qiu writes: Ray> Hi, Is there any particular reason that XORP doesn't support Ray> executing shell commands from the CLI? Ray> Thanks. Ray> --Ray _______________________________________________ Ray> Xorp-hackers mailing list Xorp-hackers@icir.org Ray> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From jonny@jonny.eng.br Fri Aug 20 02:17:31 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Thu, 19 Aug 2004 22:17:31 -0300 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: <37323.1092956744@tigger.icir.org> References: <37323.1092956744@tigger.icir.org> Message-ID: <4125512B.8050902@jonny.eng.br> In Unix, if it is a login shell, two conditions will occur: - $SHELL wil be set to /path/xorpsh - argv[0] of the runnig process will have a '-' as the first character Both of these, especially the last, could be checked to verify if it is a login shell, and decide to allow or not shell commands. Atanu Ghosh wrote: > If the xorpsh is installed as a login shell it may not be desirable > to allow the execution of shell commands. > > Atanu. > > >>>>>>"Ray" == Ray Qiu writes: > > > Ray> Hi, Is there any particular reason that XORP doesn't support > Ray> executing shell commands from the CLI? > > Ray> Thanks. > > Ray> --Ray _______________________________________________ > Ray> Xorp-hackers mailing list Xorp-hackers@icir.org > Ray> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Jonny -- João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br From bms@spc.org Fri Aug 20 03:15:28 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 19 Aug 2004 19:15:28 -0700 Subject: [Xorp-hackers] OSPF API (for future consideration) Message-ID: <20040820021528.GF4105@empiric.icir.org> --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Some brief notes... OSPF API - Application-layer access to OSPF Opaque-LSA - Could be implemented with XRL, or with a OSPF-API migration library in C. XRL was invented for this sort of thing, so implementing an OSPF API for XORP would be far less painful than for Quagga/Zebra. - Implemented for Quagga - Clients - SRRD - ANCS - Could be used to implement TE-LSAs for MPLS-TE I think SRRD is 'hella' cool. BMS --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBJV7AueUpAYYNtTsRAtBfAJ9afZdCbi0zpYW2dsiyhIlYCrNsfQCaAqKc 5n9lLis4S3dyrHOueQXoMy8= =nqfa -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From atanu@ICSI.Berkeley.EDU Fri Aug 20 07:03:51 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 19 Aug 2004 23:03:51 -0700 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: Message from Ray Qiu of "Thu, 19 Aug 2004 21:15:16 PDT." Message-ID: <22900.1092981831@tigger.icir.org> If you have installed xorpsh as a login shell then we do *not* want to allow shell commands to be executed. Which is why João explained how it is possible to distinguish a xorpsh login shell from a xorpsh started from the command line. Atanu. >>>>> "Ray" == Ray Qiu writes: Ray> I made a patch to add command "shell" to the operational mode. Ray> It uses system() call. It can be used to execute Unix shell Ray> commands. I didn't see any problems even when I configured to Ray> use xorpsh as the login shell. Screen capture is attached. Ray> Did I miss anything? Ray> --Ray Ray> On Thu, 19 Aug 2004 22:17:31 -0300, João Carlos Mendes Luís Ray> wrote: >> In Unix, if it is a login shell, two conditions will occur: >> >> - $SHELL wil be set to /path/xorpsh - argv[0] of the runnig >> process will have a '-' as the first character >> >> Both of these, especially the last, could be checked to verify if >> it is a login shell, and decide to allow or not shell commands. >> >> >> >> Atanu Ghosh wrote: > If the xorpsh is installed as a login shell >> it may not be desirable > to allow the execution of shell >> commands. >> > >> > Atanu. >> > >> > >> >>>>>>"Ray" == Ray Qiu writes: >> > >> > >> > Ray> Hi, Is there any particular reason that XORP doesn't >> support > Ray> executing shell commands from the CLI? >> > >> > Ray> Thanks. >> > >> > Ray> --Ray _______________________________________________ > >> Ray> Xorp-hackers mailing list Xorp-hackers@icir.org > Ray> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> _______________________________________________ > Xorp-hackers >> mailing list > Xorp-hackers@icir.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> >> -- >> >> Jonny >> >> -- >> João Carlos Mendes Luís - Networking Engineer - >> jonny@jonny.eng.br >> _______________________________________________ >> >> >> Xorp-hackers mailing list Xorp-hackers@icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> From Ray Qiu Fri Aug 20 08:03:25 2004 From: Ray Qiu (Ray Qiu) Date: Fri, 20 Aug 2004 00:03:25 -0700 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: <22900.1092981831@tigger.icir.org> References: <22900.1092981831@tigger.icir.org> Message-ID: I see. Is it because of the security concern? Thanks. --Ray On Thu, 19 Aug 2004 23:03:51 -0700, Atanu Ghosh wrote: > If you have installed xorpsh as a login shell then we do *not* want to > allow shell commands to be executed. Which is why João explained how it > is possible to distinguish a xorpsh login shell from a xorpsh started > from the command line. > > Atanu. > > >>>>> "Ray" == Ray Qiu writes: > > Ray> I made a patch to add command "shell" to the operational mode. > Ray> It uses system() call. It can be used to execute Unix shell > Ray> commands. I didn't see any problems even when I configured to > Ray> use xorpsh as the login shell. Screen capture is attached. > > Ray> Did I miss anything? > > Ray> --Ray > > Ray> On Thu, 19 Aug 2004 22:17:31 -0300, João Carlos Mendes Luís > > > Ray> wrote: > >> In Unix, if it is a login shell, two conditions will occur: > >> > >> - $SHELL wil be set to /path/xorpsh - argv[0] of the runnig > >> process will have a '-' as the first character > >> > >> Both of these, especially the last, could be checked to verify if > >> it is a login shell, and decide to allow or not shell commands. > >> > >> > >> > >> Atanu Ghosh wrote: > If the xorpsh is installed as a login shell > >> it may not be desirable > to allow the execution of shell > >> commands. > >> > > >> > Atanu. > >> > > >> > > >> >>>>>>"Ray" == Ray Qiu writes: > >> > > >> > > >> > Ray> Hi, Is there any particular reason that XORP doesn't > >> support > Ray> executing shell commands from the CLI? > >> > > >> > Ray> Thanks. > >> > > >> > Ray> --Ray _______________________________________________ > > >> Ray> Xorp-hackers mailing list Xorp-hackers@icir.org > Ray> > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > >> _______________________________________________ > Xorp-hackers > >> mailing list > Xorp-hackers@icir.org > > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> > >> -- > >> > >> Jonny > >> > >> -- > >> João Carlos Mendes Luís - Networking Engineer - > >> jonny@jonny.eng.br > >> _______________________________________________ > >> > >> > >> Xorp-hackers mailing list Xorp-hackers@icir.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > >> > From Ray Qiu Fri Aug 20 05:15:16 2004 From: Ray Qiu (Ray Qiu) Date: Thu, 19 Aug 2004 21:15:16 -0700 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: <4125512B.8050902@jonny.eng.br> References: <37323.1092956744@tigger.icir.org> <4125512B.8050902@jonny.eng.br> Message-ID: ------=_Part_101_21637727.1092975316512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I made a patch to add command "shell" to the operational mode. It uses system() call. It can be used to execute Unix shell commands. I didn't see any problems even when I configured to use xorpsh as the login shell. Screen capture is attached. Did I miss anything? --Ray On Thu, 19 Aug 2004 22:17:31 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > In Unix, if it is a login shell, two conditions will occur: >=20 > - $SHELL wil be set to /path/xorpsh > - argv[0] of the runnig process will have a '-' as the first character >=20 > Both of these, especially the last, could be checked to verify if it is a= login > shell, and decide to allow or not shell commands. >=20 >=20 >=20 > Atanu Ghosh wrote: > > If the xorpsh is installed as a login shell it may not be desirable > > to allow the execution of shell commands. > > > > Atanu. > > > > > >>>>>>"Ray" =3D=3D Ray Qiu writes: > > > > > > Ray> Hi, Is there any particular reason that XORP doesn't support > > Ray> executing shell commands from the CLI? > > > > Ray> Thanks. > > > > Ray> --Ray _______________________________________________ > > Ray> Xorp-hackers mailing list Xorp-hackers@icir.org > > Ray> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >=20 > -- >=20 > Jonny >=20 > -- > Jo=E3o Carlos Mendes Lu=EDs - Networking Engineer - jonny@jonny.eng.br > _______________________________________________ >=20 >=20 > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > ------=_Part_101_21637727.1092975316512 Content-Type: image/jpeg; name="screen.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="screen.jpg" /9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICAgMCAgMEAsLCxAUDg0NDhQYEhMTExIYFBIUFBQU EhQUGx4eHhsUJCcnJyckMjU1NTI7Ozs7Ozs7Ozs7AQ0LCw4LDhIPDxIUERERFBcUFBQUFx4XGBgY Fx4lHh4eHh4eJSMoKCgoKCMsMDAwMCw3Ozs7Nzs7Ozs7Ozs7Ozv/wAARCAGQAtADASIAAhEBAxEB /8QBQgAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUG BwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLR QwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZm doaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgI7AQACEQMhMRIEQVFhcSITBTKB kRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aU pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH1+f3/9oADAMBAAIRAxEAPwDypJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSU6eV0G7DYTdlYwtFDckU73AvrdB/R2OY2p51/MeZgxK0P+b7OpdJ6T b05lVOXlMyQ9rrHTc6g+0Na5z4JaxxJ0bPcSAqlnXcV3Tren14bxXaxoZVZebKKbG6m2hjmeowmX f4TvrIRsL6zswT0n08UuHSRfIdbracge4yKvaATpykpqdK+r2d1il1mHBLS5oY5tsOLW749UVGoE zpueELD6TZm4d2c2+qqnGe1t5s3zWLJ2PIZW+Q5w2+2TPIjVXum/Wf7BV08OxvVt6W+00OFm1pZk H9I17djiTE7SHCPA96eP1RmN0/qPTqqSWdQNWxznyaxS8vAMMG4mY7JKSv8Aq3nU351WU+rHZ03Z 9oueXOYPVIFW0Vse87pn6PxhXOj9Crp+s1HRer113m2sm6trng1ONZuaNzCz3CBMFzdfuM3rTes3 9XdbXVVV1BmOXY78ltFhNBY0eldbUau0uDgD4cJZ/XsPD+ueR1rHb9trrhtWx+xpd6TaXHcWPkfS 4+MwkpyL+iZWOcIufXYzqBLKbKibBva/03thjS4lrv3QQfzZS6r0TM6OKH5MFmSHGtwD2GWHa4Fl zK3giRy3vorWF9Zn4I6T6eOHHpJvkudpaMg+4QG+0gHTlVs/qtGX07F6dVQ+pmC+w0OdYHnZdDnt fFbJO8aERppHdJTLqODXjdI6XlMrrnKFxdcx73Gwsc0Q+t7GhhZO32zKzFo53VaMvpOD01lD63YG +LTYHB/qnfZ7PTbHu410Hjys5JTr9Pw8TI+r3Vsq2kHIwzjmm7c8EC2zY4Fu7aRDfDuh4nQMjJpx Ln30Y46hY6rEbb6hNha5rD/NVWBo3Oj3EKOD1WjE6TndNfQ+x2fsm0WBoZ6R31+z03T7uddR4co+ J16irH6dTlYr7XdKtddjuqtFQO97bYsDqrZ9zexGiSkVP1ez7WWPea6TXk/YWse4k2ZOv6JmxrxO nLiG+ajR0wV9fr6Te+q4tyG02e6xtb3B0Or3iveJPtnb58arZ6J1Nub7s52O1v7VZ1Bw9duM+t7p 3Pi9rm2Vj91rt33rIs6jj1fWS3qzGnIpbmPyaw13pl4FhsZq5joHE6JKV+x7s3reV0rDFdVrLLxV SXucCai4+kywt1MN0Lo80DP6Xdg042V6ld+Plh5puq3QTW7Y8bbGVuBB8lbxuvMxfrGev145IdZZ aaHWaza14d+kFY0l8j2/3qtl9T+1dLwOm+ls+wet+k3Tv9Z4f9HaIiPFJSDKpxafR+y5H2jfU19v sLPTsM7qvd9Lb+8EBHysr7V6P6Gqn0am0/oW7N+yf0lmpl5nUoCSnYt+q2dVQ+9t2Pbtx/trK2Pd vfjgMJua1zGwPfw6CYMAoWP9Xs7K6a/qdEOrqrfc5pba07K3bXkWOqFRIiYD5+eij1nqtHVPsno0 Po+yY7MUb7BZuZX9A6V1wdTP8Fdq+s7AysXYpe8YB6Xa5lu0Oo90FrTU/bZxqSR5a6JTRZ0TKfX0 20Prjq1jqqNTLSx7aj6nt0Eu7SqmXjPw8q7DtIL8ex9Ty3UEsJaYkDTRdF0bKptx+ljqIqro6XbZ fVeMuqtwaXi1wfjlttrzuZ7Q0CfxWD1LJZmdRysyoEMyL7LWB2hAe4uEwTrqkprJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKesz+mdDpwm3W0UYgu6WzLqey55uOW8jbW2p91hNZ8dn9pY2P9 Xs7K6a/qdEOrqrfc5pba07K3bXkWOqFRIiYD5+eij1nqtHVPsno0Po+yY7MUb7BZuZX9A6V1wdTP 8Fdq+s7AysXYpe8YB6Xa5lu0Oo90FrTU/bZxqSR5a6JTSxeiWZGHVnWZWPjU32mhjri8jeI0e6qu xrOfzyNNeNU2N0a6/HyMuy+iinFsbVa9znWAOdMH9XZd7dNHH2nsSj9I63j9MY0HGsc6Xet6d+yv IrOnp5FNldzXABzhpHPjqh9M6vT0977mUWVXGwPrtxL3VFrOTS4WNva+uQDBE6akpKYO6LkCnPyG 20WV9NNYsdW/eHi521hqc0EEeMkfei431bzsnFozWvqbRfVkZBe4u/R14pDbHPDWE8kRtlHwfrMz Ayc62jAqFOY9ltdAc5rarKX+pSdOQHaluk9oGiPb9cXXODXYbGUPx8mi9jLHBznZjhZdYx7w/b72 ggEOjX5JTn/sDIN2Cxl9D6uplzMbIHqemXtd6ZaQ6oWA7oH0Y1+KWb9Xs/CpZbNd5deMR7KHF7q8 gta/0XDaJdrHt3CdEUdeobZ0tleK8Y3SXutrrdaDY973+r7rBUGxuA02fPwq39T3dad1nGq9N32g ZTa7HeoA/d6hBLW1yN34JKdLqXRcfp/1cbda2o59WaMa59L3v2g1G01WSdm9pMHbp5zKxvRxfsPr /aP1n1dn2bYf5vbPq+p9H6Wm1aPUevUZ2Hk4bMV9TcnLOeHG0PLbn7m2D+abLC06DkHueFnfav1H 7D6NX8763r7f030dnp75+h3jxSUgSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSU7H1kxsLF/Z32PHZj/acKrKt2OsdL7ZkfpLH6DbohY/1ezsrpr+ p0Q6uqt9zmltrTsrdteRY6oVEiJgPn56Kzl9e6ZltYX9Oe6yjC+wUGy8OawBrmttLRQ2Xjd4x81K r6zsDKxdil7xgHpdrmW7Q6j3QWtNT9tnGpJHlrolNLF6JZkYdWdZlY+NTfaaGOuLyN4jR7qq7Gs5 /PI0141VnoXRsTOOf9svra7Exr7G1hz3AOYABaXVMe11bS7810mOCFDpHW8fpjGg41jnS71vTv2V 5FZ09PIpsrua4AOcNI58dUDpnVR0/IybPQDqcyi3GsqY4tLa7f8ARvf6kEQI3bklNCxoY9zGuFga SA9sw4DuNwaYPmEq3Bj2vc0WBpBLHTDgOx2lpg+RRMq2m7Istx6RjVOPspa5zw0dhueSSfFDrLA9 ptBcwEb2tO0kdwHEOg/IpKd3rHQg/wCtdnQ+kVisOLBW1zjDQam2PJc4uMDU/kVJ3Qsl1FOTh21Z lWRkDDa6kvbFzgHNYReyo6g88K3b9Z5+sjPrHRjbHiPUpfZvB9nou2uDGR7PI6/ch1dcqooxMHAp +z1UZrc42ZVhu/SNDWNn0qqjsAGoAJ8ElIs3oGRg49+VZfRZXj3/AGVxZ6km8bt9bQ6purQJJOng SUnYNbfq23qIrrc92Z6JuD3+o0emXekaiwMjTduDjzC1frDlYZ6Pbj1vrGRkdUsyzXVkMygWlhDr GuqYza0l2jXDcsj9q0fsD9i+g/f9o+1ev6gjft9OPT9PjZ/K518klJsb6s5mWzGfRdQ451b7MVkv BsdVu9WsTXAc3b+cQ3XQlZ+LTi3et9qyPs+ypz6vYX+pYI21e36O794rV6f9Z/sP7J/VvU/ZP2n/ AAm31PtM/wAg7ds+crKxcr7L636Gq71qnU/pm79m+P0leoh4jQpKQLT6JX020ZTMsVuyvTBw25L3 VY7nNO6wPex9ZDi0eyXBs89lmK5gZuLj05ONmYoyGZAZD2kMurLHbprsdXZAdw7TVJTezOjjJzci jCoODZg4ZyM2i8mBZUB6ooM2ktdILdztfGIVY9CyWZmBhWW1Mf1Kqq6lxLy0C6Qxr4YSCSI4jzVv /nP+tb/s36t+z/2X6XqfpPRj6Xq7Nu/d32R5d0K/rzLszpmY3HLT0sVVhpskProfvqB/RiHRo49+ YHCSkGb0TKwcX7ZY+uxjb3YtwYTNV7RudW/c1snzbI05WetXP679twcjC9DZ9o6g/qO/fO3e0t9O NomJ5/BZSSnqMz6pDHxcjHFd7cvAoOXbmOaRi3CA6ymsxywRtPc7pA0jM/5t5379X/J/7U5d/M/u /Q+n5ceaPd9Z/W6p1LqX2aP2liOxPT9SfT3MrZv3bPd9DiApVfWdgZWLsUveMA9Ltcy3aHUe6C1p qfts41JI8tdEprYP1bzs+rEsrfUx2e97cat5dueKiBa/2sc0BuvJB00B0nLsaGPcxrhYGkgPbMOA 7jcGmD5hdd9Wuo4tVPS7s+yhtfTTlw8XhllYtaXEWY9jN1hcT7fTPx1C5BJTodBx8DK6tjY/UvUN NtjWBlQEuc5wa1rnFzdrddSNfDxWhiYPSW9c6vi5TKvSxmZIw677TUw212BtTC82Vk6eLlk9Ly6M DOqzb6n3eg9ttbGPFfvY5rm7ia7JGnH4o+R1Hp2T1O/OtwnvqyfUdZU673NssLnb63srYBtJ0Dmu /uSluq491Aoe/CoxWWhzq7Max11doB2n3m+9stI4B+PZZ60Oo9UZmYmHgY9Jpx8EWenvf6ljjc/e 4ucGViOI9qz0lO11vB6Xj9I6TmdNbZOUL/Vsu0e81OY2SwPe1omYjtytC36qMwegZ9uVTbZ1KhlN u4NcKq2vd72McNLC1gJsOoHbglZWf1bBy+l4vTasW2r7D6noWOva/wDnnh797RQyeNIIQ8HqtGJ0 nO6a+h9js/ZNosDQz0jvr9npun3c66jw5SU1aacV+LkW25Hp317PQo2F3q7jD/eNG7RrrytPodOD khoyMKt1GMfV6hm5FtoayokBra20urhxgho9xc7yWZTleji5GL6NT/tGz9K9s2V7Du/ROn27uHLQ q6xgHpuJ03LwrLGYtj7Xiq8VNvc90za30XEkN9oO6YSU3um9GxMvpl2fhYwySc91DXZr3srpxmVm 31bTQ+uCJG4yR4BUevdMwun/AFju6dW80YjbK5e4Gw1ssax7jA1cG7tO6VfW8duBk9JfjWNwr8n7 Uyui/Y5oiBU9z67d7RDew1EoHUesP6j1l/WLKa5dYx4ocN9ZFYa1rHzG4EN93ikpHj/Yqc99bmDP ql9dBe849biTtrssmCG9yNzfiugxug9Nys/old1IqOcMh2VVjWOspIoLyzZbvt1O2HgP08lztWXi nMuyMzEZbVdvPo1ONIrL5INRG4DaeAQ4R2WlR9Z/sd/THYeNto6V6uxltm97/tBPqS9rKwND7fbp 5pKS9Y6NXi9Ap6lbjV4eY7JFT6KXvdtrfX6jRc219hbZpMTwddVzy083rDMjp37Nx6rGsdkuzLbc i31rH2Obs+kK6tOZkFZiSnXu+rOZQcmk3UOysOj7TkYrS/1GVwxzvcaxWS0PEw8+UpY31ZzMtmM+ i6hxzq32YrJeDY6rd6tYmuA5u384huuhKPkfWdl12bnNxS3N6hjfZLnm2aQHNrY9zKvSDgYZpLzH mo9P+s/2H9k/q3qfsn7T/hNvqfaZ/kHbtnzlJThq1+zb/wBlftfcz0PtH2XbJ379nqTEREeaqrQ6 Z1UYbH4mZQM3AtIe/Fe4sixv0bK3t1Y7sSORoUlJz9WcxlP2q66irHGNTlvucXkNbkOLKmFrK3O3 Eg8AjzWfmYv2S0Vi6rIa5jbG2UO3NIcJ1kNc0ju1wBWi36yW3MzaOoVerRnMqZ6dLhT6Lcd2+plM ssa1gkiNvz8QU9UxcPM+2YGEyt1dQZj+o82llo2/rDtwDXP5gbQ0GDGmqUwzOmfs77MzOt9O+733 47W7rKKzt2F4Lmje4EnZIjSYlWvrPg9Owr8H9mMeyjIwqsj9IZe4vL/c7UgEgCY0WV6nqX+tlF9u 9++07oe+TLve4O1PiQVodZ6ri9UZiirGsofiUV4rHOuFgNde6JaKa/d7uZ+SSnMSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJT13/ADcwv+en7P8Asj/2Xv8AT5s2b/s3rbfV 3TM6xuWbj/U7q+TRTdXs3ZNXr1VkWmWkFzQbW1GlpcBoHPHIlW/+fWbv9T0Gb/s+3dFc/a9vp/bJ 9HnZ7dvEaLPu61hZbMV2fgm+7DxhiMi4spcGb/Tc9jWb5G7WLBPkkpX1fw8TNZ1NmVSLDRgXZNL9 zwWWVxtja4Aj3dwVWxek2ZGC7qVt9WLjNtGOLLt53WFpftDaa7XaN8Qp9G6rR0v7X61D7/teO/FO ywV7WWfTOtdknQR/FLF6rQzpTukZtD7qDkDKY6mwVPD9hrIJdXaCI8gkpVfQ73uzCcjHbRgbPWyQ 82VH1Hba9hpbY47v6uneEen6rZ12Z9kF2OxpxBntyHvc2p1B2++SzcOfzmjhQo6zi0s6hiDD2YXU PT/Q1WkPr9F29kWWttn+VLfhHCO76z/pbS3Gio9MPSqmmyXNZAix7tgDjM8NakpR+pvW2vx6nNq9 TItNDmCxpNLw02xbtmJrG7SdPOAq3U/q9ndLxWZt0OpfYaZ221kPjcAWZFVLoInUAjRar/ry85X2 qvDDT9sGWWus3CPs4xHV6MbqRqHfgVg5V/Tn0NqwsV9Lw8ufddd6ryIADAGsqYB3+iT5pKaq2up9 HwcPoeBnU5Ndl2Qby8j1YtDHsraKg6psBms7o8p0WKtM9Ypt6RT0zJxBa/EFzca71HNDPXc17nOY 36ThB2+6PEFJSSn6s5l5xqRdQ3KzKPtOPiuL/UfXD3N9wrNYLgwxLx5wshb2P9Z2U3YWc7FLs3p+ N9kpeLYpIa2xjHPq9IuJh+sPE+SwUlOv0bp+J1ml3SqwKepvs9THveXmuytrffS4NnaRG4O2meNF cbjdCfhdSz8PH9dnTKsWlhtdY1l9llhZZkFjbGvbMe1u75eGZh9Xf0/Atx8Jpoy7rAX5rHxZ6IH8 y3SWjcNxIOvBVyz6yUXsyqr8P2dQqpbmGqwVvsvodv8AXH6JzG759zdvnKSnQxejdKs+sPS8V+MH Y/U8BmTZTvsiux1djz6bg/dE1/nE8nygF3TOn053Q6rsatl2cR9rxa7Hvp9Oy306bGWNteZc0k6W HgaeIKPrOynq+J1M4pczp+M3Ex6fVgw1rmbrH+kdx97uGt7fMFHXmV19Iqsxy8dIsstG2zabS94t bzW7aAW68z5JKbP1iwek4dFjaGVUZdebbTXVRabd2M0e19oNlu1+7SJb30XPqz1LKZnZ+Rm11moZ FjrSxzt5BedzvcGs0k6aKskp17vqzmUHJpN1DsrDo+05GK0v9RlcMc73GsVktDxMPPlKWN9WczLZ jPouocc6t9mKyXg2Oq3erWJrgObt/OIbroSj5H1nZddm5zcUtzeoY32S55tmkBza2Pcyr0g4GGaS 8x5qPT/rP9h/ZP6t6n7J+0/4Tb6n2mf5B27Z85SU4avYfSbMvDuz3X1UUY7212Os3uIL52y2mu1w Gn0nACdAqK0ek9Vq6ZLxVaLw8OZkY95pftHNb2uZcxzCQDG370lN3o3SMe7I6rgZTaMh+Ph23UXs u/Rixm0Mc2xtjWbTvk7uO8aqlZ0LLrz6MAuY45dTcii2ttljX1uaXhwYyt1v5p/M/DVGo65j4+R1 PIpwhWOo0W49dVb9tdLbeTBY7cdBwWjnTiCt+s/6WouxpqHTB0q1oshzmQZsY7YQ0zHLXJKa1/1f zMbqmP0rIfXXZlhjqbHbwwizRkj0/Uadw2w5og86apXfV7PqZW9hruNmT9hcxjiDXk6fon72sE68 tJb5ol/XmXZnTMxuOWnpYqrDTZIfXQ/fUD+jEOjRx78wOEX/AJyOs/RsqZS53Vf2oLbHOcxhOmxz WM3EDuRr5JKa2b0DIwce/Ksvosrx7/sriz1JN43b62h1TdWgSSdPAkrQ6t9X2WVUZfTGVUj9mV59 2OLHFx1PqvYLHPIDQ4fScJ7SQUX6w5WGej249b6xkZHVLMs11ZDMoFpYQ6xrqmM2tJdo1w3KrZ9Z 2F7jVilrD0s9JY11u4gdrS4VNk+UBJTUx/q9nZXTX9Toh1dVb7nNLbWnZW7a8ix1QqJETAfPz0S6 Jg15jOoPfXXccbDtuax731lpb/hWbGODi391xEyrdX1nYGVi7FL3jAPS7XMt2h1Hugtaan7bONSS PLXSl0bqtHS/tfrUPv8AteO/FOywV7WWfTOtdknQR/FJTnJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSno/sPQvT/AOcm z/Jn8z+zZs9T7Vs/mvVn6H5++fLb2VOn6s5l5xqRdQ3KzKPtOPiuL/UfXD3N9wrNYLgwxLx5wi/8 5/1rZ9m/yR6Xofsv1P0e2Od+z6fqe/fG7zUsf6zspuws52KXZvT8b7JS8WxSQ1tjGOfV6RcTD9Ye J8klNbp/1dyeo4tWZVkY9dVtv2Yeq57SLiWBlUCsklwfI2yImSEOroWS+rKtttqoGBaKcsWF5NRJ c1rj6bH7gXt2+2TPaNUv2rR+wP2L6D9/2j7V6/qCN+3049P0+Nn8rnXyV/oT8RnQOsMy3MIv9DZS L66bX+i42P2eoHnQEfm68DVJTQd02jp3Vremdcc+oMlhuoIeGOcA6u0tiXsgyW6GPPRV+odPyOm5 Bx8gAkgPrsYd1dlbvo2Vu/Oa7sVcyOt1ZvW7us5uIy4v1rxy4+mHNaGV+ppLwA3UaT8NFn5WVkZ2 RZl5dhtutO573ck/3eASUiSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklPR/Yehen/AM5Nn+TP5n9mzZ6n2rZ/NerP0Pz98+W3sqdP 1ZzLzjUi6huVmUfacfFcX+o+uHub7hWawXBhiXjzhF/5z/rWz7N/kj0vQ/Zfqfo9sc79n0/U9++N 3mpY/wBZ2U3YWc7FLs3p+N9kpeLYpIa2xjHPq9IuJh+sPE+SSmt0/wCruT1HFqzKsjHrqtt+zD1X PaRcSwMqgVkkuD5G2REyQh1dCyX1ZVtttVAwLRTliwvJqJLmtcfTY/cC9u32yZ7Rql+1aP2B+xfQ fv8AtH2r1/UEb9vpx6fp8bP5XOvkr/Qn4jOgdYZluYRf6GykX102v9Fxsfs9QPOgI/N14GqSmg7p tHTurW9M6459QZLDdQQ8Mc4B1dpbEvZBkt0Meeir9Q6fkdNyDj5ABJAfXYw7q7K3fRsrd+c13Yq5 kdbqzet3dZzcRlxfrXjlx9MOa0Mr9TSXgBuo0n4aLPysrIzsizLy7Dbdadz3u5J/u8AkpEkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKej+w9C9P/AJybP8mfzP7Nmz1PtWz+a9Wfofn758tvZU6fqzmXnGpF1DcrMo+04+K4v9R9cPc3 3Cs1guDDEvHnCL/zn/Wtn2b/ACR6Xofsv1P0e2Od+z6fqe/fG7zUsf6zspuws52KXZvT8b7JS8Wx SQ1tjGOfV6RcTD9YeJ8klNbp/wBXcnqOLVmVZGPXVbb9mHque0i4lgZVArJJcHyNsiJkhDq6Fkvq yrbbaqBgWinLFheTUSXNa4+mx+4F7dvtkz2jVL9q0fsD9i+g/f8AaPtXr+oI37fTj0/T42fyudfJ X+hPxGdA6wzLcwi/0NlIvrptf6LjY/Z6gedAR+brwNUlNB3TaOndWt6Z1xz6gyWG6gh4Y5wDq7S2 JeyDJboY89FX6h0/I6bkHHyACSA+uxh3V2Vu+jZW785ruxVzI63Vm9bu6zm4jLi/WvHLj6Yc1oZX 6mkvADdRpPw0WflZWRnZFmXl2G2607nvdyT/AHeASUywcO3qGZThUFjbL3hjTY4NaCfEn/ee2qPl dPHT9tzrsfKDLTXbQDYx7XMgltlVjaLYPEj7wVWxbaaciu3IpGTU0++lznMDh3G5hBB8FodS6zR1 GrGqtotsOO8l2RfcLMh1bjPpC0UsETJG5ronTTRJTc+sv1cGFl59/ThW3EwzQH0h5dZW25jQ153T oXg6bt3eNsFCyPqd1fGouus2bsar17awLRDQA5wFrqhS4tB1DXngwl1D6z/bv2t+ren+1vs3+E3e n9mj+QN26PKELqXWsLql1+dkYJObkVtYXm4+ix7WsZ6jKmsa6YboHPI8ZSUrp+HiZH1e6tlW0g5G Gcc03bnggW2bHAt3bSIb4d0vq/h4mazqbMqkWGjAuyaX7ngssrjbG1wBHu7goOD1WjE6TndNfQ+x 2fsm0WBoZ6R31+z03T7uddR4cpdG6rR0v7X61D7/ALXjvxTssFe1ln0zrXZJ0EfxSU5yudO6Xd1I ZBpsrYcWv17BZuB9IEB7xtY7RkyRz4Aqmt76pOx2P6kcmytjLcC2gNfdXSXvs27WMdaeTtOsEDuk prN+rec7PqwGvqJvxxl1WguLX1FpeCxmz1SdD7Qzd5RqqeZhDFFT2ZFGUy4Eh1DiSC07SHssax7T 8W69lev67TkZuPkW4p9HExmYuO1tzmXM9Iey0XMaB6gcZ+hHl3QOsdUZ1R9NgpLH1Vit91j/AFLr Y+ibXtZW0lrYAO2fElJTnpJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkp6fonTul5HRaM3KxscuHUG4t91976R6BaLHOE31t3idI7diqn1fwel5v1mHT3M+1YNr7m 1F5exxYwPfW/2GszDByPkqn7Vo/YH7F9B+/7R9q9f1BG/b6cen6fGz+Vzr5JuhdUZ0bqVfUX0m80 h2xgf6YlzSySdj9IcUlNr6v0YOa/qb8rErsFGHdl0s3WgMdXG1g22glvu7knzQOv9Px8HIx7MQFl OdjVZjKnHcahbP6Pf+cBGhS6T1XF6Y/NJxrLWZlD8VrfWDSyuz6Uu9F252g1gfBA6r1N/VMhtpYK aqa20Y9LTIrpr+gzcdXHXUlJTDp1uFTlst6jScnHaH7qWuLC47HbBuaQQN0St7qLfq7gDCbkdOj7 XiYmYX02Wkgvsm9m2y7h1bSG6yD945haPWeq0dU+yejQ+j7JjsxRvsFm5lf0DpXXB1M/wSU6ma3o FPSMPO/ZorPUa8wMLLbXGqyp2yg++yHDX3aefkpfsvon239u7Wf83tk+l6jvV9X09v2fbv3+pv8A dzt26zCyc7qtGX0nB6ayh9bsDfFpsDg/1Tvs9nptj3ca6Dx5S/atH7A/YvoP3/aPtXr+oI37fTj0 /T42fyudfJJTnJJJJKUkkkkpSSSSSlJJJJKUkkkkpS6D6q0dG6hl4/S83D9e++21z7nPe0NqbVuY 1ore3Xe0yT2/Dn1odC6ozo3Uq+ovpN5pDtjA/wBMS5pZJOx+kOKSk+M7pWf1jptVOEKqrTVRlUF9 hY6x7yxz2O9TeBtcCNdD499Dp3S+jZP1h6vi5tXo4WFVkOb6bnzWKXtZ6glz3E7ZOsie3ZYWDl0Y XU6c4VPfVRaLmVbwHew7mBz/AEyOQJ9uvkrrOvMqz+qZteOY6pRfSWOsk1nIIc524ViQCNBA+KSn aP1f6Bi42B6FjOqPs6nVh5N4c5rC21hOxnp2R7Q5pkE6/csz6yYvT+nl+HXiV0Xm9z6LabX2A4zX 307LA+x4Fm6sHT4aEQgdN68zBw8fDsxzaMfPb1AObZsJLGbGs1rfpIkn5eaH1PqmBnMvNGEacjJy TlWXvtFpg75qYBVXDZfP5Z0SU5i3usY3SOj5d/RbMY2upoAGa17ha69zBa1+wu9MVy7aWxMazKwV r5XXMfONmZl4Qt6hbR6D73P/AERdHp+t6Gz+c2aD3bZ1hJTvU/Vv6s2fsqzIyfs9tuPjWX4kknId f7WFhJkS+d23gfu8oLOk9F2PZZhAl3WbOlNe2y1r21u3bHiXubuYSOW6ga+Kxbuu+tndLzfQj9l1 Y9OzfPqfZ3bpnb7d3zVxn1qx2sfOCX2HPs6mwuu9jbnbhXLW1NJayRpuEkeGiSnFz8X7FnZGFu3/ AGe19O+I3bHFsxJiYQFO++3Jvsyb3brbnussdAEucdzjAgclQSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklO96PSn9LvzsjC GHQ+v0sB4tsfk3ZDNsu9zhWawQd52ACYGqPb0/EdThDpGDh5734dduQ05Lzd6waXWtFLMtjpAEwG qp1HrfS+pXW5NvT7A91HoY7PtP6Gja0NYa62Us0bE7ZjUqHTetYXS7qM7HwSM3HrcwPFx9F73Nez 1H1OY50w7UNeB4Qkps4/Q2u6JiZFFNWVl9TfY2v1720+kK3ek0VMNtXqPc4zOoGg2of1V6b07N62 On9YrtLzvY2gDYN7Gvc71Xbmvbt28Ac/iPE69RVj9OpysV9rulWuux3VWioHe9tsWB1Vs+5vYjRN 0zrzMLrNnXMjHN+Q6yy1rK7PSrBtDw+Q6u0ke/TUfNJSDoOPgZXVsbH6l6hptsawMqAlznODWtc4 ubtbrqRr4eKD1airG6rmY1DdtVORbXW2SYa17mtEmTwETCzcHC6nXnNx7XVUPZbVUbmhwewtcN7/ AEIIkHQNHxQ+qZdGfnW5tFT6fXe62xj3iz3vc5ztpFdcDXj8UlK6X02/q+fV0/Gcxtt27abCQ32t c8ztDjw3wROn9GzOp49+Ri7D9nfTWWOMOc7If6VYbpt+lzJCrYuVkYORXl4lhquqO5j28g/3eIWn b9Y3MdSemYlWAxtrMrIrrLi2+6twe3dqCKwR7awYCSmvm9IOEL/1zGusxbPSupY57bAZc07W3V17 wC3XbP3IeJ0x+Ri359rxj4uOCPVeJ33ESymsfnOd3/dGpReo9R6dmuyb6sJ9eTl2m51tt3qCvc5z 3CtjK6hqT+du0+9C6n1N/UHsa1gx8XHBZjYzDLKmHXv9JzuXOOpKSm9hYPS7/qz1LNLbH5+Kafc7 21sFlmwBm1/uJAM7h8PFYq1cDq2DidLyum24ttv270/Xsbe1n8y8vZsaaHxzrJKyklKSSSSUpJJJ JTZ6bjMzOo4uHaSGZF9dTy3QgPcGmJB11XR9W+r+NR0zquW7Frw3Yd7RiCt9hsfSbnU77WW2We13 5pETHguYxMl+HlU5lQBfj2MtYHaglhDhMEaaLVz/AKxMyqeoV00WMf1Wyt+Q+671toqcXtZWBVXA Egak6CElO3m/VbCpPVKvsrKaMPEdZiZBss+0XWVV12Pdtc8scwF0OIYOYHlyNNOK/FyLbcj0769n oUbC71dxh/vGjdo115WzlfWv7Tbl5hx3jLzcT7E9zrt1LGODQ/06vTDmztJA3nU91jU5Xo4uRi+j U/7Rs/SvbNlew7v0Tp9u7hySnpej/V/GyMHpOQcWu9uZZac2/IfYxtbGWspYys12Vjc+YaCCS7yU aPq7jtxsx+PjsyrKep2Ye/Le9lVOPSxz3XWOpfVH8on5CVn4f1iZTidPxMqiy0dMvORR6V3pNcS8 WD1WOqt3EGYIjQqI+sPr4eXg59L3VZmWc1/2a30Tvd9Jjt7Lg5kwQPEJKW690zC6f9Y7unVvNGI2 yuXuBsNbLGse4wNXBu7Tup9C6XiZufn1AHOZiY192M0B7Be6shtUsaQ+Hbp2ggqr1HrD+o9Zf1iy muXWMeKHDfWRWGtax8xuBDfd4qfTOuP6dn5OayoNGZXbU9lB9E1i07v0LofsLSBt0KSneH1YwHdR 6JTk1Mqdm/aBmU41jn1h2PLtgc91jgfzXw7tp4rP6x0avF6BT1K3Grw8x2SKn0Uve7bW+v1Gi5tr 7C2zSYng66oVH1n+x39Mdh422jpXq7GW2b3v+0E+pL2srA0Pt9unmq2b1hmR079m49VjWOyXZltu Rb61j7HN2fSFdWnMyCkpzFq/8287+e31fYvS9f7fLvs+3iN2zdv3e3Zt3T2WUtj9v0eh+zfsTP2X sj7PuHq+rH9I+0enPqT/ACdu32wkpan6s5l5xqRdQ3KzKPtOPiuL/UfXD3N9wrNYLgwxLx5wo9P+ ruT1HFqzKsjHrqtt+zD1XPaRcSwMqgVkkuD5G2REyQrOP9Z2U3YWc7FLs3p+N9kpeLYpIa2xjHPq 9IuJh+sPE+SpftWj9gfsX0H7/tH2r1/UEb9vpx6fp8bP5XOvkkpVXQsl9WVbbbVQMC0U5YsLyaiS 5rXH02P3Avbt9sme0aon/NvOZmZuHe+ql3T2epe5xc8bDthzW1MseRDpJ26D6UK30J+IzoHWGZbm EX+hspF9dNr/AEXGx+z1A86Aj83Xgaqvd9YGZXVsrquRjvbbkbfSfjXupto2gMG2yHg7mCHS34Qk pN0DpOJZ9Ycfpub6Gdj5NbnB9Nj4j03WAjY6tzXAtgtcPlwVm5/Ssjp9ONkWOrsqyw81vqduG6t2 yxk6atPcS09iVoUfWSinr7eu/Y/c1hHptsDS+xzdj7bHCraS7cSdrG6/OaOX1P7V0vA6b6Wz7B63 6TdO/wBZ4f8AR2iIjxSU0UkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklO96PSn9LvzsjCGHQ+v0sB4tsfk3ZDNsu9zhWawQd52ACYGqPb 0/EdThDpGDh5734dduQ05Lzd6waXWtFLMtjpAEwGqp1HrfS+pXW5NvT7A91HoY7PtP6Gja0NYa62 Us0bE7ZjUqHTetYXS7qM7HwSM3HrcwPFx9F73Nez1H1OY50w7UNeB4Qkps4/Q2u6JiZFFNWVl9Tf Y2v1720+kK3ek0VMNtXqPc4zOoGg2of1V6b07N62On9YrtLzvY2gDYN7Gvc71Xbmvbt28Ac/iPE6 9RVj9OpysV9rulWuux3VWioHe9tsWB1Vs+5vYjRN0zrzMLrNnXMjHN+Q6yy1rK7PSrBtDw+Q6u0k e/TUfNJS/Q8fp12B1CzJZj25dfo/ZK8m70Gu3OcLf8NTMN81T6rRdj5DWXYleGXVte1tLnPre13u bY17rbtwPiHQlVkdLY+5tmHZZTYG+l+ni6oiJIeKtjg7Xmv/AGy6t1P9p20FtXo1YuPXi1NLt7tl QMF7trQSSTw0JKR9L6bf1fPq6fjOY227dtNhIb7WueZ2hx4b4InT+jZnU8e/Ixdh+zvprLHGHOdk P9KsN02/S5khVsXKyMHIry8Sw1XVHcx7eQf7vELTt+sbmOpPTMSrAY21mVkV1lxbfdW4Pbu1BFYI 9tYMBJTXzekHCF/65jXWYtnpXUsc9tgMuadrbq694Bbrtn7kPE6Y/Ixb8+14x8XHBHqvE77iJZTW PznO7/ujUovUeo9OzXZN9WE+vJy7Tc62271BXuc57hWxldQ1J/O3afehdT6m/qD2NawY+LjgsxsZ hllTDr3+k53LnHUlJTewsHpd/wBWepZpbY/PxTT7ne2tgss2AM2v9xIBncPh4rFWrgdWwcTpeV02 3Ftt+3en69jb2s/mXl7NjTQ+OdZJWUkpSSSSSlJJJJKbPTcZmZ1HFw7SQzIvrqeW6EB7g0xIOuq6 Pq31fxqOmdVy3YteG7DvaMQVvsNj6Tc6nfay2yz2u/NIiY8FzGJkvw8qnMqAL8exlrA7UEsIcJgj TRauf9YmZVPUK6aLGP6rZW/Ifdd620VOL2srAqrgCQNSdBCSnbzfqthUnqlX2VlNGHiOsxMg2Wfa LrKq67Hu2ueWOYC6HEMHMDy5GmnFfi5FtuR6d9ez0KNhd6u4w/3jRu0a68rZyvrX9pty8w47xl5u J9ie5126ljHBof6dXphzZ2kgbzqe6xqcr0cXIxfRqf8AaNn6V7Zsr2Hd+idPt3cOSU9L0f6v42Rg 9JyDi13tzLLTm35D7GNrYy1lLGVmuysbnzDQQSXeSjR9XcduNmPx8dmVZT1OzD35b3sqpx6WOe66 x1L6o/lE/ISs/D+sTKcTp+JlUWWjpl5yKPSu9JriXiweqx1Vu4gzBEaFRH1h9fDy8HPpe6rMyzmv +zW+id7vpMdvZcHMmCB4hJS3XumYXT/rHd06t5oxG2Vy9wNhrZY1j3GBq4N3ad1PoXS8TNz8+oA5 zMTGvuxmgPYL3VkNqljSHw7dO0EFVeo9Yf1HrL+sWU1y6xjxQ4b6yKw1rWPmNwIb7vFT6Z1x/Ts/ JzWVBozK7ansoPomsWnd+hdD9haQNuhSU7w+rGA7qPRKcmplTs37QMynGsc+sOx5dsDnuscD+a+H dtPFZ/WOjV4vQKepW41eHmOyRU+il73ba31+o0XNtfYW2aTE8HXVCo+s/wBjv6Y7DxttHSvV2Mts 3vf9oJ9SXtZWBofb7dPNVs3rDMjp37Nx6rGsdkuzLbci31rH2Obs+kK6tOZkFJTmLXt+rOZWyx7L qLSzGGc1jC8GzGO39K3fW0QJ4cQ7TjichdZ1fquP0/Hxm44ryMi7pDOm2WV5FdldfHqtNdQcdw7O 3x8YSU4zeg3fZ8fItysak5dbraGWPc0ODN0t9XYaQ7TgvESJhZi2MPruLiYZxRhve2yp1d1JvJxr Xni59LmOcHiG6se3jSFjpKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKej+w9C9P/nJs/wAmfzP7Nmz1PtWz+a9Wfofn 758tvZU6fqzmXnGpF1DcrMo+04+K4v8AUfXD3N9wrNYLgwxLx5wi/wDOf9a2fZv8kel6H7L9T9Ht jnfs+n6nv3xu81LH+s7KbsLOdil2b0/G+yUvFsUkNbYxjn1ekXEw/WHifJJTW6f9XcnqOLVmVZGP XVbb9mHque0i4lgZVArJJcHyNsiJkhDq6FkvqyrbbaqBgWinLFheTUSXNa4+mx+4F7dvtkz2jVL9 q0fsD9i+g/f9o+1ev6gjft9OPT9PjZ/K518lf6E/EZ0DrDMtzCL/AENlIvrptf6LjY/Z6gedAR+b rwNUlNB3TaOndWt6Z1xz6gyWG6gh4Y5wDq7S2JeyDJboY89FX6h0/I6bkHHyACSA+uxh3V2Vu+jZ W785ruxVzI63Vm9bu6zm4jLi/WvHLj6Yc1oZX6mkvADdRpPw0WflZWRnZFmXl2G2607nvdyT/d4B JSJJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJ SkkkklKSSSSU9H9h6F6f/OTZ/kz+Z/Zs2ep9q2fzXqz9D8/fPlt7KnT9Wcy841IuoblZlH2nHxXF /qPrh7m+4VmsFwYYl484Rf8AnP8ArWz7N/kj0vQ/Zfqfo9sc79n0/U9++N3mpY/1nZTdhZzsUuze n432Sl4tikhrbGMc+r0i4mH6w8T5JKa3T/q7k9RxasyrIx66rbfsw9Vz2kXEsDKoFZJLg+RtkRMk IdXQsl9WVbbbVQMC0U5YsLyaiS5rXH02P3Avbt9sme0apftWj9gfsX0H7/tH2r1/UEb9vpx6fp8b P5XOvkr/AEJ+IzoHWGZbmEX+hspF9dNr/RcbH7PUDzoCPzdeBqkpoO6bR07q1vTOuOfUGSw3UEPD HOAdXaWxL2QZLdDHnoq/UOn5HTcg4+QASQH12MO6uyt30bK3fnNd2KuZHW6s3rd3Wc3EZcX6145c fTDmtDK/U0l4AbqNJ+Giz8rKyM7Isy8uw23Wnc97uSf7vAJKRJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSno/sPQvT/5ybP8mfzP 7Nmz1PtWz+a9Wfofn758tvZU6fqzmXnGpF1DcrMo+04+K4v9R9cPc33Cs1guDDEvHnCL/wA5/wBa 2fZv8kel6H7L9T9Htjnfs+n6nv3xu81LH+s7KbsLOdil2b0/G+yUvFsUkNbYxjn1ekXEw/WHifJJ TW6f9XcnqOLVmVZGPXVbb9mHque0i4lgZVArJJcHyNsiJkhDq6FkvqyrbbaqBgWinLFheTUSXNa4 +mx+4F7dvtkz2jVL9q0fsD9i+g/f9o+1ev6gjft9OPT9PjZ/K518lf6E/EZ0DrDMtzCL/Q2Ui+um 1/ouNj9nqB50BH5uvA1SU0HdNo6d1a3pnXHPqDJYbqCHhjnAOrtLYl7IMluhjz0VfqHT8jpuQcfI AJID67GHdXZW76Nlbvzmu7FXMjrdWb1u7rObiMuL9a8cuPphzWhlfqaS8AN1Gk/DRZ+VlZGdkWZe XYbbrTue93JP93gElMsHDt6hmU4VBY2y94Y02ODWgnxJ/wB57ao+V08dP23Oux8oMtNdtANjHtcy CW2VWNotg8SPvBVbFtppyK7cikZNTT76XOcwOHcbmEEHwWh1LrNHUasaq2i2w47yXZF9wsyHVuM+ kLRSwRMkbmuidNNElNz6y/VwYWXn39OFbcTDNAfSHl1lbbmNDXndOheDpu3d42wULI+p3V8ai66z ZuxqvXtrAtENADnAWuqFLi0HUNeeDCXUPrP9u/a36t6f7W+zf4Td6f2aP5A3bo8oQupdawuqXX52 Rgk5uRW1hebj6LHtaxnqMqaxrphugc8jxlJSun4eJkfV7q2VbSDkYZxzTdueCBbZscC3dtIhvh3S +r+HiZrOpsyqRYaMC7JpfueCyyuNsbXAEe7uCg4PVaMTpOd019D7HZ+ybRYGhnpHfX7PTdPu511H hyl0bqtHS/tfrUPv+1478U7LBXtZZ9M612SdBH8UlOcrnTul3dSGQabK2HFr9ewWbgfSBAe8bWO0 ZMkc+AKpre+qTsdj+pHJsrYy3AtoDX3V0l77Nu1jHWnk7TrBA7pKazvq3nC22sPqc2vCPUm2Au22 UQDLJYHTrw4BCxeh5+dh15mI0Wi3J+xsqbPqGzZ6s8bdu3kyr1f1pDM1trsQWYjcAdMOO6w73Ugd 7Wtb7ie4bx96sn69ZJux8j7HU22vIOTkFrnxa70jjDaCTs/RGO+uvkUpqdf6ZhYPS+l3Y3pPtu+0 Mvux3WPrsNL21hzfV+fAg9tIWGtHP6rRl9OxenVUPqZgvsNDnWB52XQ57XxWyTvGhEaaR3WckpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpuYnTH5GLfn2vGPi44I9V4nfcRL Kax+c53f90ala/8AzfZ1LpPSbenMqpy8pmSHtdY6bnUH2hrXOfBLWOJOjZ7iQFkdT6m/qD2NawY+ LjgsxsZhllTDr3+k53LnHUlaWF9Z2YJ6T6eKXDpIvkOt1tOQPcZFXtAJ05SU1MToGRk04lz76Mcd QsdViNt9Qmwtc1h/mqrA0bnR7iEXF+qnVsyi62n0vVoyHYhx3WBtjrawHPayfYYEn6XYpYnXqKsf p1OVivtd0q112O6q0VA73ttiwOqtn3N7EaKz0/63vw3epbii15z7eoPLX7ATdU+ksALXwBvmZSUi /wCZ/VTfbUHVPrqqrvF9Rfcx7LiW1mttNb7HTtd+b2niFn9V6VldHyG42XE2VtuY5sgOY/g7XtY5 pkEEOAK0n/Wdl+IcDIxScd+HjYlmy3bYTivc9tjXGp4AO4y3afiqVPVMXDzPtmBhMrdXUGY/qPNp ZaNv6w7cA1z+YG0NBgxpqlMj0G5mRh4F11dObmGDRYHTSH7fRFpY10OfP0Y00mJ0j1DoOZ03GGVa +qxgt+zWip+41XBgsNT9ACQDrtJEiJQMHO+zdTp6lktfkOqtF7hv2ue9p3gue5r/AM7nREv6nu60 7rONV6bvtAym12O9QB+71CCWtrkbvwSUl6n9Xs7peKzNuh1L7DTO22sh8bgCzIqpdBE6gEaKVv1b zqs/O6e59Rt6djuyrSC7aWNax5DPZMw8cgKfUevUZ2Hk4bMV9TcnLOeHG0PLbn7m2D+abLC06DkH ueFr3dTxQOqdWz211ZmdhnD2UZVWQH2PY1ksqqDixo9OSXWeWpSU8gkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp6P7D0L0/+cmz/Jn8z+zZs9T7 Vs/mvVn6H5++fLb2VOn6s5l5xqRdQ3KzKPtOPiuL/UfXD3N9wrNYLgwxLx5wi/8AOf8AWtn2b/JH peh+y/U/R7Y537Pp+p798bvNSx/rOym7CznYpdm9PxvslLxbFJDW2MY59XpFxMP1h4nySU1un/V3 J6ji1ZlWRj11W2/Zh6rntIuJYGVQKySXB8jbIiZIQ6uhZL6sq222qgYFopyxYXk1ElzWuPpsfuBe 3b7ZM9o1S/atH7A/YvoP3/aPtXr+oI37fTj0/T42fyudfJX+hPxGdA6wzLcwi/0NlIvrptf6LjY/ Z6gedAR+brwNUlNB3TaOndWt6Z1xz6gyWG6gh4Y5wDq7S2JeyDJboY89FX6h0/I6bkHHyACSA+ux h3V2Vu+jZW785ruxVzI63Vm9bu6zm4jLi/WvHLj6Yc1oZX6mkvADdRpPw0WflZWRnZFmXl2G2607 nvdyT/d4BJTLBw7eoZlOFQWNsveGNNjg1oJ8Sf8Aee2qPldPHT9tzrsfKDLTXbQDYx7XMgltlVja LYPEj7wVWxbaaciu3IpGTU0++lznMDh3G5hBB8FodS6zR1GrGqtotsOO8l2RfcLMh1bjPpC0UsET JG5ronTTRJTc+sv1cGFl59/ThW3EwzQH0h5dZW25jQ153ToXg6bt3eNsFCyPqd1fGouus2bsar17 awLRDQA5wFrqhS4tB1DXngwl1D6z/bv2t+ren+1vs3+E3en9mj+QN26PKELqXWsLql1+dkYJObkV tYXm4+ix7WsZ6jKmsa6YboHPI8ZSUrp+HiZH1e6tlW0g5GGcc03bnggW2bHAt3bSIb4d0vq/h4ma zqbMqkWGjAuyaX7ngssrjbG1wBHu7goOD1WjE6TndNfQ+x2fsm0WBoZ6R31+z03T7uddR4cpdG6r R0v7X61D7/teO/FOywV7WWfTOtdknQR/FJTnK507pd3UhkGmythxa/XsFm4H0gQHvG1jtGTJHPgC qa3vqk7HY/qRybK2MtwLaA191dJe+zbtYx1p5O06wQO6Sms36t5zs+rAa+om/HGXVaC4tfUWl4LG bPVJ0PtDN3lGqp5mEMUVPZkUZTLgSHUOJILTtIeyxrHtPxbr2V6/rtORm4+Rbin0cTGZi47W3OZc z0h7LRcxoHqBxn6EeXdA6x1RnVH02CksfVWK33WP9S62Pom17WVtJa2ADtnxJSU560+p/V7O6Xis zbodS+w0zttrIfG4AsyKqXQROoBGio4mS/DyqcyoAvx7GWsDtQSwhwmCNNFp9R69RnYeThsxX1Ny cs54cbQ8tufubYP5pssLToOQe54SUw/5t5389vq+xel6/wBvl32fbxG7Zu37vbs27p7LKWx+36PQ /Zv2Jn7L2R9n3D1fVj+kfaPTn1J/k7dvthY6SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSnp+idO6XkdFozcrGxy4dQbi33X3vpHoFosc4TfW3eJ0jt2KqfV/B6Xm/WYdPcz7 Vg2vubUXl7HFjA99b/YazMMHI+SqftWj9gfsX0H7/tH2r1/UEb9vpx6fp8bP5XOvkm6F1RnRupV9 RfSbzSHbGB/piXNLJJ2P0hxSU2vq/Rg5r+pvysSuwUYd2XSzdaAx1cbWDbaCW+7uSfNA6/0/Hwcj HsxAWU52NVmMqcdxqFs/o9/5wEaFLpPVcXpj80nGstZmUPxWt9YNLK7PpS70XbnaDWB8EDqvU39U yG2lgpqprbRj0tMiumv6DNx1cddSUlMOnW4VOWy3qNJycdofupa4sLjsdsG5pBA3RK3uot+ruAMJ uR06PteJiZhfTZaSC+yb2bbLuHVtIbrIP3jmFo9Z6rR1T7J6ND6PsmOzFG+wWbmV/QOldcHUz/BJ TqZregU9Iw879mis9RrzAwsttcarKnbKD77IcNfdp5+Sl+y+ifbf27tZ/wA3tk+l6jvV9X09v2fb v3+pv93O3brMLJzuq0ZfScHprKH1uwN8WmwOD/VO+z2em2PdxroPHlL9q0fsD9i+g/f9o+1ev6gj ft9OPT9PjZ/K518klOckkkkpSSSSSlJJJJKZ0eh69f2rf6G9vq+nG/ZPu27tJjiVu9Xxel1YeRfj 4rBS+1o6dmYlj7GEfTdXk+rc8sfscNNrTI8FhUW+hfXfsZZ6b2v9OwbmO2mdrm9we61MjreL9kz8 TAwzjDqVjH3brA9rBW91jWVMZTVtEu7zokp0/wDsY/Zv7Y/ZX6t+0Psmz1rfU9H0t+/+e2792scd v5Sjh/VIZGLj45rvdl59Ay6sxrScWkQXV02GOXidx7HbAOs5H7Vo/YH7F9B+/wC0favX9QRv2+nH p+nxs/lc6+St0/Wf0eqdN6l9mn9m4jcT0/Uj1NrLGb92z2/T4gpKS9Dq6LmYl9VmCLcjCwMjLtus stAfYx/6NobXa0bQ06+P5cfqNuFdlvt6dScbHcGbaXOLy07G7xucSSN0wrHRuq0dL+1+tQ+/7Xjv xTssFe1ln0zrXZJ0EfxWckpSSSSSmz063Cpy2W9RpOTjtD91LXFhcdjtg3NIIG6JWx1yrouHiUVV 4IqyM3Ax8uq6uy0hlj3/AKRpbZa4bS0aeH5OeWj1nqtHVPsno0Po+yY7MUb7BZuZX9A6V1wdTP8A BJSfqeNhVdA6Tl0Y7K78z1/WsDrCT6DhWNHWOaN0ydOeIXT/APNT6qft30PX/wCD/Zu5271PT9Xd v3b9mzX4/nfmrkc7qtGX0nB6ayh9bsDfFpsDg/1Tvs9nptj3ca6Dx5Vv/nP/ANk//OT7N/6D+p/w XofT2fP6KSm9Rg9Iq6J0/q+T0+q6pzLXZ0XWttLWXMx2upb60TL5dpH9WQuVW5T17pgxenY2V05+ S3pnqFrXXgMsdaQ929voHTcNBPkZWGkp18PDxMfoVvW8ikZb3ZIw6qXueyth2eq6x3puY5xjQCR4 6o+NjdIuxOr9Xpxi6vEGN6GNe9xa03v22AuqdW5waQQ3XjnVUcPqjKsC3pWbScjEssF7Ax/pWV3A bd7X7LAQW6EFp8oR6+uY7R1DGOEK8LqApb6ND9jqxjkGuLHsskmPcS3U66JKdjG6F0OzPacus1Yt 3Rm9RsDHPIpsJaHOr1c4gCSA7creD9Vvq4W4dTLR1MvzH0ZF7HOawj7PbcGN9N8QIaZBOvfssF31 n/S2luNFR6YelVNNkuayBFj3bAHGZ4a1Lon1n/Y2PTR9m9b0ct+Xu9TZO+h2PsjY796ZSU6Z+rHQ bOmZR6XljOyn2Ywx7HEtFDMm5tbGvDPzud0if5I70+r/AFbqxcDIyMarIpPTHtqusyWlrMoPds9a nwh+kcbdpmZmj0Xrv7Hpvq9D1vXtxbp37Y+y2+tH0XfS48kn9d309Yq9CP2vay6d/wDNbLXXR9H3 fSjskp6XqH1T6HVZ1TIxCHMw8Ozfil791ORsbbVYDMua5s8kifHgUcDo3SuoYXSMc4wqyOq15TTl MfYSyzGPsfsc9zSHBp3CBzpCz7vrP63VOpdS+zR+0sR2J6fqT6e5lbN+7Z7vocQFKj6zsxMLDpxc Utyun13Mx8h9u4NfkEGyz0xU2TyGgmBOspKcFJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTodBx8DK6tjY/UvUNNtjWBlQEuc5wa1rnF zdrddSNfDxQerUVY3VczGobtqpyLa62yTDWvc1okyeAl0vLowM6rNvqfd6D221sY8V+9jmubuJrs kacfil1TLoz863NoqfT673W2Me8We97nOdtIrrga8fikpbpzsBmbU/qjbLMRpm1lMb3AAwBJboTE 68K/1fGwsfpmHY/HZi5+V+sNrodY6v7K8RW6z1bLPeXAxtPHOqx1a6hmszfs2yt9f2fHroO+11u4 sn3N3/QBn6I0CSmqkkkkpSSSSSlJJJJKUkkkkpnR6Hr1/at/ob2+r6cb9k+7bu0mOJW71fF6XVh5 F+PisFL7Wjp2ZiWPsYR9N1eT6tzyx+xw02tMjwWFRb6F9d+xlnpva/07BuY7aZ2ub3B7rUyOt4v2 TPxMDDOMOpWMfdusD2sFb3WNZUxlNW0S7vOiSnISSSSUpJJJJSkkkklOn9Wen4/VOuYuDlgmmwuL w0wSGMdZE+B26q91jo1eL0CnqVuNXh5jskVPope922t9fqNFzbX2FtmkxPB11WV0fqb+j9So6jWw WmkmWOMBwc0scJHBh2iPm9YZkdO/ZuPVY1jsl2ZbbkW+tY+xzdn0hXVpzMgpKad1OKzFx7asj1L7 N/r0bC30tphnvOjtw104XXZv1WwqT1Sr7KymjDxHWYmQbLPtF1lVddj3bXPLHMBdDiGDmB5cjdle ti4+L6NTPs+/9KxsWWbzu/Sun3beGrZyvrX9pty8w47xl5uJ9ie5126ljHBof6dXphzZ2kgbzqe6 Sl8roBrwMOjBx68rKy8ZuY+11wbcA4b/AE6Mb1Wlwa1h12umTEQueW9j/WdlN2FnOxS7N6fjfZKX i2KSGtsYxz6vSLiYfrDxPksFJTp/VvBr6j1enFtrruDg8+ja99QsIaTHqVMeQR9L5IHTul3dSGQa bK2HFr9ewWbgfSBAe8bWO0ZMkc+AKJ0LqjOjdSr6i+k3mkO2MD/TEuaWSTsfpDil07qjOmvzjVSX szMa7EY1z9WC2IcXBnuIjwE+SSked0u7p+RTRkWV7Mmuu+q9u41mq3h8bN8cyNs+Ss9b6fTi9duw IqwK2bNN9t1bJra/6fpmwzP7v4IXUeqM6k/BNtJYzDxqcR7Wv1eKplwcWe0mfAx5pdd6ozrPUrOo spNBuDd7C/1BLWhkg7GaQ0JKT/WjpeJ0jqtmJh2BzGBg9P3mxp9Osk2FzGtl5JPtJ+XCyFp9a6xT 1iz7UcQU5dpa6+71HODtrGVhtbNA1vtnXcfNZiSnYzsbCxvq70zJrx2HJzvtHq3udZuHo2hrdrRY GcGD7VZ6Dh9N6pZTjW4dbafTsbff9oc7LNjWPs300NsbI4gCp3zWfkdVoyejYfTLKHi3B9X0rm2D afWf6jt1ZrJ4ED3I3TetYXS7qM7HwSM3HrcwPFx9F73Nez1H1OY50w7UNeB4Qkpf6p42Fn9Zp6fn Y7L6sjdJc6xrm7GPf7fTsYNSNZBWOtHoPVaOjZ7OoWUPyLap9INsFbRua5jt012E6O01CzklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklN7p LGXXnFbg/tDJvhmPW57msaZlznNrLHH2j98AclS64zpteaK+mQWsrY281lzqfWAiz0HPJca54J/J CfpfVaMDFzcW6h9n21jKzbVYKrGMaS57Q412aP0Dgq+ddhXvrODjHFYytrHtdYbS94mbC4tbBPgB CSldOdgMzan9UbZZiNM2spje4AGAJLdCYnXhX+r42Fj9Mw7H47MXPyv1htdDrHV/ZXiK3WerZZ7y 4GNp451WOrXUM1mb9m2Vvr+z49dB32ut3Fk+5u/6AM/RGgSU1UkkklKSSSSUpJJJJSkkkklM6PQ9 ev7Vv9De31fTjfsn3bd2kxxK3er4vS6sPIvx8Vgpfa0dOzMSx9jCPpuryfVueWP2OGm1pkeCwqLf Qvrv2Ms9N7X+nYNzHbTO1ze4PdamR1vF+yZ+JgYZxh1Kxj7t1ge1gre6xrKmMpq2iXd50SU6/wDz cwv+en7P+yP/AGXv9PmzZv8As3rbfV3TM6xuXIrp/wDn1m7/AFPQZv8As+3dFc/a9vp/bJ9HnZ7d vEaLmElKSSSSUpJJJJTp/Vnp+P1TrmLg5YJpsLi8NMEhjHWRPgduqvdY6NXi9Ap6lbjV4eY7JFT6 KXvdtrfX6jRc219hbZpMTwddVldH6m/o/UqOo1sFppJljjAcHNLHCRwYdoj5vWGZHTv2bj1WNY7J dmW25FvrWPsc3Z9IV1aczIKSmndTisxce2rI9S+zf69Gwt9LaYZ7zo7cNdOF12b9VsKk9Uq+yspo w8R1mJkGyz7RdZVXXY921zyxzAXQ4hg5geXI3ZXrYuPi+jUz7Pv/AErGxZZvO79K6fdt4atnK+tf 2m3LzDjvGXm4n2J7nXbqWMcGh/p1emHNnaSBvOp7pKdXp/1Wwsh/T6X4rPs2VhMuuzLLLG2m+5tr xXRDxWS3bMbDDRr58Uugo+tfpPwMl+O9+T0zHOPj/poo+i6sPdT6ZdO0jdDxMdlz6SnX+rmHiZT+ oPzKReMXAuya2Oc9o9SvZtn03MMa+Kn9X8LG6q/qdT8UWPbh3ZGMys2SyxsBjWAPO4e/h08BVejd UZ0t+UbaTezLxrMR7Wv9MgWbZcHFlmvt8FPpPWGdIfm241Vm/Kofj0P9XaaQ/XcS2v3OEDUbf7kp lV9W86/qL+mVPqffTUbsjYXPFW36VbtjHFzwSBDA7X5op+qXUxm4eFurBzxYabHiysTUCXhzbKmW NMD93uk36xsGbbmHEAOZhuxM4MftNr7B+kvaQzaxziAY2kfeqZ6jVjX4+R0ep+FbjSfVdabbHuJP 0jtYyI0gM+MpKV0/o2Z1PHvyMXYfs76ayxxhznZD/SrDdNv0uZIVrqP1V6l07Fvy7Sx9eM9rLdrb WRuJYHNN1VTXjdp7SefBK36xuY6k9MxKsBjbWZWRXWXFt91bg9u7UEVgj21gwEDqPUenZrsm+rCf Xk5dpudbbd6gr3Oc9wrYyuoak/nbtPvSUmt+rOZWyx7LqLSzGGc1jC8GzGO39K3fW0QJ4cQ7TjiZ jo+CPqyeq/aazkHJFYP6WABUbDSB6X84Sefo6fSUv+c//db/ALyv2T/Of+C/Q/6P4qthdYpo6Y/p eXiDKq9c5Vf6R1YFhrdV+k2aubqDALfikpvfVToVedl0W9TrrOJkmyqpljnsstcxjnudSKyJDNsO LvbrHKzOiMx7eq4uNlUMyKsi2ulzXl7YD3taXNNb2GY8dPJXum/Wf7BV08OxvVt6W+00OFm1pZkH 9I17djiTE7SHCPA98/p+Zi4PUWZzqbLGUWC2msWhpBY4OZvf6Ttw01ho+SSmPVqKsbquZjUN21U5 FtdbZJhrXua0SZPAVVHz8r7bnZGbt2faLX3bJnbvcXRMCYlASUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklNzphx9767cavJtsAFPr3ehSwj3OLzuq kwIHvHzVn6xYOLg5WM3FZ6XrYlN9rGkvrbY8e70nuLtzNOQ53xVPDuwqhazNxjkCwDY9lhqsrIMy 07bGkEaGWnyhF6t1P9p20FtXo1YuPXi1NLt7tlQMF7trQSSTw0JKRdOdgMzan9UbZZiNM2spje4A GAJLdCYnXhX+r42Fj9Mw7H47MXPyv1htdDrHV/ZXiK3WerZZ7y4GNp451WOrXUM1mb9m2Vvr+z49 dB32ut3Fk+5u/wCgDP0RoElNVJJJJSkkkklKSSSSUpJJJJTOj0PXr+1b/Q3t9X0437J923dpMcSt 3q+L0urDyL8fFYKX2tHTszEsfYwj6bq8n1bnlj9jhptaZHgsKi30L679jLPTe1/p2Dcx20ztc3uD 3WpkdbxfsmfiYGGcYdSsY+7dYHtYK3usaypjKatol3edElOv/wA3ML/np+z/ALI/9l7/AE+bNm/7 N6231d0zOsblc6f9U+h5lnS3gje7DryM3Ec94NjbWODbWEGZ9TkAx8Pzsz/n1m7/AFPQZv8As+3d Fc/a9vp/bJ9HnZ7dvEaKpT9Z/R6p03qX2af2biNxPT9SPU2ssZv3bPb9PiCkpw0kkklKSSSSU6f1 Z6fj9U65i4OWCabC4vDTBIYx1kT4Hbqr3WOjV4vQKepW41eHmOyRU+il73ba31+o0XNtfYW2aTE8 HXVZXR+pv6P1KjqNbBaaSZY4wHBzSxwkcGHaI+b1hmR079m49VjWOyXZltuRb61j7HN2fSFdWnMy Ckpp3U4rMXHtqyPUvs3+vRsLfS2mGe86O3DXThddm/VbCpPVKvsrKaMPEdZiZBss+0XWVV12Pdtc 8scwF0OIYOYHlyN2V62Lj4vo1M+z7/0rGxZZvO79K6fdt4atnK+tf2m3LzDjvGXm4n2J7nXbqWMc Gh/p1emHNnaSBvOp7pKQ4WD0u/6s9SzS2x+fimn3O9tbBZZsAZtf7iQDO4fDxWKtXA6tg4nS8rpt uLbb9u9P17G3tZ/MvL2bGmh8c6ySspJTr/VzDxMp/UH5lIvGLgXZNbHOe0epXs2z6bmGNfFT+r+F jdVf1Op+KLHtw7sjGZWbJZY2AxrAHncPfw6eAqvRuqM6W/KNtJvZl41mI9rX+mQLNsuDiyzX2+Cn 0nrDOkPzbcaqzflUPx6H+rtNIfruJbX7nCBqNv8AclKZ9X8qzqX7KbdQchlZstDXFwrLGlz6vYxx fY2NW1h34GI09DvyszFw8HIx8p2Zu2OqeQG7J3+o2xrHtgCdW6jiUS3rOLkdRZ1G7D/SGoC51Vpq e7IH/aqt1bQ1j90GNpHz1R/+c/p9Wwuq04024jPTsfdZvtvBDmfpLGMrEhhgO2z47klNO7o1zMWv Oovoyce2/wCy+oxzmBtsB4a/7QymAQeePFXvrTg9L6Xkv6bi0Gu6g1llws3+rW6sb/WaXHbYHjSA NDxxNS7quK7p1fScfGsZijJ+1277g+xx2ivax4pY1o2zy0qHXeqM6z1KzqLKTQbg3ewv9QS1oZIO xmkNCSm11Po+Dh9DwM6nJrsuyDeXkerFoY9lbRUHVNgM1ndHlOiBhYNd3Q+pZxrrsfjmkBxe9tlQ e/bIYGbHh/GrtISPWKbekU9MycQWvxBc3Gu9RzQz13Ne5zmN+k4QdvujxBUcHqtGJ0nO6a+h9js/ ZNosDQz0jvr9npun3c66jw5SUk6f9XcnqOLVmVZGPXVbb9mHque0i4lgZVArJJcHyNsiJkhRp+r2 fayx7zXSa8n7C1j3EmzJ1/RM2NeJ05cQ3zUf2rR+wP2L6D9/2j7V6/qCN+3049P0+Nn8rnXyV36u dVpYcXpWWwei3Przm3+q2kVuYNrjYbGua5u0TGh89UlNSvomQ3PyaHPofV04zl3vNjcdu0xsc4Nb YS5w2gNEk8eKl9acHF6d13KwsJnp0V+nsZJdG6tjjq4k8lWczqtOLndaw7WDKxOpX7y+i1oMNtN1 bmWBtzYIdqI+5VOo5tfX+pPzr314L7K2eqbC99brGNbX7BVU9zQQODPxSUw6B0xnWOr4/TrXmtlx dvc0SYY1zyBPc7YSyczpVzA+jAGNbXfuaxtlj630mfZbvfu3AgatImTxonx7T0TKp6lgZuPkX0v0 Yxt3BBDt3q01CCNNDOuibJzel2MFOLgGhjr/AFrXOu9SzYJApqeaxsb7jyHE6Twkp2vrL0ronT29 QqrrqxraH44wRXc6y2ze3dcLa3W2FoAMg7W9tSlldE6XX13reEymKMLp78jHZvf7LG10uDp3SdXH lYvXeqM6z1KzqLKTQbg3ewv9QS1oZIOxmkNCvZH1nZddm5zcUtzeoY32S55tmkBza2Pcyr0g4GGa S8x5pKdfp/1Wwsh/T6X4rPs2VhMuuzLLLG2m+5trxXRDxWS3bMbDDRr54X1TxsLP6zT0/Ox2X1ZG 6S51jXN2Me/2+nYwakayCrFH1r9J+Bkvx3vyemY5x8f9NFH0XVh7qfTLp2kboeJjsqHQeq0dGz2d QsofkW1T6QbYK2jc1zHbprsJ0dpqElOckkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSnT6H0V/Vn22uFhxcQB+R6DfUudunbXUwTLnRzwOSifWvp1PS+uX4mLUaccCt1LTuIIL G7iHPJJG6Vk1lge02guYCN7WnaSO4DiHQfkVf671RnWepWdRZSaDcG72F/qCWtDJB2M0hoSUg6c7 AZm1P6o2yzEaZtZTG9wAMASW6ExOvCv9XxsLH6Zh2Px2YuflfrDa6HWOr+yvEVus9Wyz3lwMbTxz qsdWuoZrM37NsrfX9nx66DvtdbuLJ9zd/wBAGfojQJKaqSSSSlJJJJKUkkkkpSSSSSmdHoevX9q3 +hvb6vpxv2T7tu7SY4lbvV8XpdWHkX4+KwUvtaOnZmJY+xhH03V5Pq3PLH7HDTa0yPBYVFvoX137 GWem9r/TsG5jtpna5vcHutTI63i/ZM/EwMM4w6lYx926wPawVvdY1lTGU1bRLu86JKdf/m5hf89P 2f8AZH/svf6fNmzf9m9bb6u6ZnWNy5FdP/z6zd/qegzf9n27orn7Xt9P7ZPo87Pbt4jRcwkpSSSS SlJJJJKdP6s9Px+qdcxcHLBNNhcXhpgkMY6yJ8Dt1V7rHRq8XoFPUrcavDzHZIqfRS97ttb6/UaL m2vsLbNJieDrqsro/U39H6lR1GtgtNJMscYDg5pY4SODDtEfN6wzI6d+zceqxrHZLsy23It9ax9j m7PpCurTmZBSU07qcVmLj21ZHqX2b/Xo2FvpbTDPedHbhrpwtO/B6WPqpV1HFbY7L+2Ci+2z2j+a dYWMa17htGmp1+HCzLsr1sXHxfRqZ9n3/pWNiyzed36V0+7bw1Xv2tg/sP8AY32W3+d+0+r67f57 0/S+j6H0O+2Z80lNnpdPSrsU5OdhCnAx6zXkZbrbDfZkODi1uOA5le6SPaWEACXFYK2n9b6XkMwq 8zp9lrMGgUilmT6dLzrvsLG07g5zjJh3xWKkp1/q5h4mU/qD8ykXjFwLsmtjnPaPUr2bZ9NzDGvi p/V/Cxuqv6nU/FFj24d2RjMrNkssbAY1gDzuHv4dPAVXo3VGdLflG2k3sy8azEe1r/TIFm2XBxZZ r7fBT6T1hnSH5tuNVZvyqH49D/V2mkP13Etr9zhA1G3+5KUz6v5VnUv2U26g5DKzZaGuLhWWNLn1 exji+xsatrDvwMLG6DdmZuNhYeVjXnLDyyxj3Q01hxcLGuYLGmG6S3XspW9ZxcjqLOo3Yf6Q1AXO qtNT3ZA/7VVuraGsfugxtI+eqP8A85/T6thdVpxptxGenY+6zfbeCHM/SWMZWJDDAdtnx3JKc3H6 bfk4GZ1CtzBVg+l6ocTuPrO2N2wCORrqrPU/q9ndLxWZt0OpfYaZ221kPjcAWZFVLoInUAjRaFn1 zs+zinGwqqXMfjit297wKMR/q0VOBdqQ7l0iR2VTqPXqM7DycNmK+puTlnPDjaHltz9zbB/NNlha dByD3PCSlrfqzmVssey6i0sxhnNYwvBsxjt/St31tECeHEO044m10foVbsDMyOpV17nYF2XiVuc9 twFQG27awhvpuLtN3MaaSrfV+q4/T8fGbjivIyLukM6bZZXkV2V18eq011Bx3Ds7fHxhUavrOwMr F2KXvGAel2uZbtDqPdBa01P22cakkeWuiUh+qeNhZ/Waen52Oy+rI3SXOsa5uxj3+307GDUjWQVj rR6D1Wjo2ezqFlD8i2qfSDbBW0bmuY7dNdhOjtNQs5JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTsdDx+nXYHULMlmPbl1+j9krybvQa7c5 wt/w1Mw3zVPqtF2PkNZdiV4ZdW17W0uc+t7Xe5tjXutu3A+IdChh3YVQtZm4xyBYBseyw1WVkGZa dtjSCNDLT5Qi9W6n+07aC2r0asXHrxaml292yoGC921oJJJ4aElIunOwGZtT+qNssxGmbWUxvcAD AEluhMTrwr/V8bCx+mYdj8dmLn5X6w2uh1jq/srxFbrPVss95cDG08c6rHVrqGazN+zbK31/Z8eu g77XW7iyfc3f9AGfojQJKaqSSSSlJJJJKUkkkkpSSSSSmdHoevX9q3+hvb6vpxv2T7tu7SY4lbvV 8XpdWHkX4+KwUvtaOnZmJY+xhH03V5Pq3PLH7HDTa0yPBYVFvoX137GWem9r/TsG5jtpna5vcHut TI63i/ZM/EwMM4w6lYx926wPawVvdY1lTGU1bRLu86JKdf8A5uYX/PT9n/ZH/svf6fNmzf8AZvW2 +rumZ1jcuRXT/wDPrN3+p6DN/wBn27orn7Xt9P7ZPo87Pbt4jRcwkpSSSSSlJJJJKdP6s9Px+qdc xcHLBNNhcXhpgkMY6yJ8Dt1V7rHRq8XoFPUrcavDzHZIqfRS97ttb6/UaLm2vsLbNJieDrqsro/U 39H6lR1GtgtNJMscYDg5pY4SODDtEfN6wzI6d+zceqxrHZLsy23It9ax9jm7PpCurTmZBSU07qcV mLj21ZHqX2b/AF6Nhb6W0wz3nR24a6cLrs36rYVJ6pV9lZTRh4jrMTINln2i6yquux7trnljmAuh xDBzA8uRuyvWxcfF9Gpn2ff+lY2LLN53fpXT7tvDVs5X1r+025eYcd4y83E+xPc67dSxjg0P9Or0 w5s7SQN51PdJTq9P+q2FkP6fS/FZ9mysJl12ZZZY2033NteK6IeKyW7ZjYYaNfPil0FH1r9J+Bkv x3vyemY5x8f9NFH0XVh7qfTLp2kboeJjsufSU6/1cw8TKf1B+ZSLxi4F2TWxzntHqV7Ns+m5hjXx U/q/h4PU39TZlU1sDMO7JpfutAocyNsbXOJaN/cOOn31ejdUZ0t+UbaTezLxrMR7Wv8ATIFm2XBx ZZr7fBP0rqtHTL8x3oPtozMe3F2eoGvay0t13+m4EgD91JSv2B1H9o/s6GTs9b7Ru/Qehz9o9Xj0 47/LnRaXUei4D+tdIwsVrKqs/Hx7LjU9waTa5291ZySXCWj2g6+UoH/Of9a3/Zv1b9n/ALL9L1P0 nox9L1dm3fu77I8u6HZ16i3O6bmuxX/5MYyprBaPeyhxdRJ9LQj88/ndg1JTD6xVdOx86zEwqPs9 mPbbVYGWerW9gd+ieC5z3B+0w8T27GQpdUw8SrofR86ikVXZQyBeWueQ80vbW0w9zoPjCo9SymZ2 fkZtdZqGRY60sc7eQXnc73BrNJOmisZ3VaMvpOD01lD63YG+LTYHB/qnfZ7PTbHu410HjykpJmfV vOwv2h6r6j+y/Q9faXHd9ojZslgmJ1mFFvQbvs+PkW5WNScut1tDLHuaHBm6W+rsNIdpwXiJEwre b9Z2ZzM8WYpa/qddQyHNt0FmPt9N9bTUYbodzSTPiEHD67i4mGcUYb3tsqdXdSbyca154ufS5jnB 4hurHt40hJTYwei4/U/q9TdU2qjMd1AYnr2PeA5rmbmtLZfJL3ge1vGp0kqh0vGZX1yrpvUMdlu/ Ibi3Vvc4bCbGscWupsbqNe5CNhdeZhYGJhMxy442ezqD3mzR5YNuwN9P2iANZKDV1Wgdcf1m+h75 yDlV1MsDIf6nqtDnGt8jtwElIOrUVY3VczGobtqpyLa62yTDWvc1okyeAqqPn5X23OyM3bs+0Wvu 2TO3e4uiYExKAkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKdjoPS6MvFz+oXtZd9hZWK6LbBRW99xcxrrLS9kBsTEieJVDqGHkYeQWZFIoNgFtbWO 31mt/uaa37n7m+B3FH6d1RmHiZmBkUm7HzhX6mx/p2NNL97S1xZYI5n2qPVup/tO2gtq9GrFx68W ppdvdsqBgvdtaCSSeGhJSLpzsBmbU/qjbLMRpm1lMb3AAwBJboTE68K/1fGwsfpmHY/HZi5+V+sN rodY6v7K8RW6z1bLPeXAxtPHOqx1a6hmszfs2yt9f2fHroO+11u4sn3N3/QBn6I0CSmqkkkkpSSS SSlJJJJKUkkkkpnR6Hr1/at/ob2+r6cb9k+7bu0mOJW71fF6XVh5F+PisFL7Wjp2ZiWPsYR9N1eT 6tzyx+xw02tMjwWFRb6F9d+xlnpva/07BuY7aZ2ub3B7rUyOt4v2TPxMDDOMOpWMfdusD2sFb3WN ZUxlNW0S7vOiSnX/AObmF/z0/Z/2R/7L3+nzZs3/AGb1tvq7pmdY3LkV0/8Az6zd/qegzf8AZ9u6 K5+17fT+2T6POz27eI0XMJKUkkkkpSSSSSnT+rPT8fqnXMXBywTTYXF4aYJDGOsifA7dVe6x0avF 6BT1K3Grw8x2SKn0Uve7bW+v1Gi5tr7C2zSYng66rK6P1N/R+pUdRrYLTSTLHGA4OaWOEjgw7RHz esMyOnfs3Hqsax2S7MttyLfWsfY5uz6Qrq05mQUlNO6nFZi49tWR6l9m/wBejYW+ltMM950duGun C3utdPxGXZY6Jg4eTh01h4uqyX3XNbtaH2em3LJhrnclkeOiwbsr1sXHxfRqZ9n3/pWNiyzed36V 0+7bw1aFPWsLEZlOwME0XZmMcR83F9LQ/Z6jmMczfJ26TYY80lN63p+I6nCHSMHDz3vw67chpyXm 71g0utaKWZbHSAJgNXNLX6b1rC6XdRnY+CRm49bmB4uPove5r2eo+pzHOmHahrwPCFkJKdf6uYeJ lP6g/MpF4xcC7JrY5z2j1K9m2fTcwxr4qf1fwsbqr+p1PxRY9uHdkYzKzZLLGwGNYA87h7+HTwFV 6N1RnS35RtpN7MvGsxHta/0yBZtlwcWWa+3wU+k9YZ0h+bbjVWb8qh+PQ/1dppD9dxLa/c4QNRt/ uSlf838r7RlYguodbhYz8rIa1xcGenG+rcGEGwTrGnmonoWSzMwMKy2pj+pVVXUuJeWgXSGNfDCQ SRHEeast+sbBm25hxADmYbsTODH7Ta+wfpL2kM2sc4gGNpH3olHVaepdY6M8sGMMA00l9trQz0aH 72Fxc2sBwbMmfceAOElNLK6DnY1DbwWXzkHCfXTuc9mQAD6JaWt3HzZuHmr/AFLouP0/6uNutbUc +rNGNc+l737QajaarJOze0mDt085lT6x11uNmWY3T62OZV1N3U/Vda29tlmmzaagwBkctkntOiqd R69RnYeThsxX1Nycs54cbQ8tufubYP5pssLToOQe54SUiu+r2dV0v9r6OoaK3PG21haLfokG2qtr xOnsLvuRx0fBH1ZPVftNZyDkisH9LAAqNhpA9L+cJPP0dPpImb9Z2ZzM8WYpa/qddQyHNt0FmPt9 N9bTUYbodzSTPiFUwusU0dMf0vLxBlVeucqv9I6sCw1uq/SbNXN1BgFvxSUl6d9VepdRxaMuosZX kvcyrc2187SGFzjTVa1g3ae4jjwUui9Cut6iB1GutmNRktxLxc5wD7XO9M01mky6zWdDA5OiFX1j DswMLA6jiPyGdPfY6r0rvRD22ua9zbJqsJ1HLSNPvUsLr4xMX7KcYEVZjeoY2x5aGWtG0NeHiwvr 40kH+UkprZ7MfA61l1MoZZRRkXVspsL9u1rnNaCWPa/T+sj/AFpwcXp3XcrCwmenRX6exkl0bq2O OriTyVWy8zFzOqXZ1tNgpyLH2vpbaA8F8uMWGoiNx/c4081LrfU/2z1S7qXpej62z9Hu3xsY1n0t rf3fBJTRSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJTc6fdjMFlNmAM7IuLG4+59gDTJkbKXMLy6YGqs/WPHwMXMpx8KtlNjMesZlVbnPazJ9xtYHPe/ 6Og0cfvQOidT/Y3VKepel63o7/0e7ZO9jmfS2u/e8FRSU2enOwGZtT+qNssxGmbWUxvcADAEluhM Trwr/V8bCx+mYdj8dmLn5X6w2uh1jq/srxFbrPVss95cDG08c6rHVrqGazN+zbK31/Z8eug77XW7 iyfc3f8AQBn6I0CSmqkkkkpSSSSSlJJJJKUkkkkpnR6Hr1/at/ob2+r6cb9k+7bu0mOJW71fF6XV h5F+PisFL7Wjp2ZiWPsYR9N1eT6tzyx+xw02tMjwWFRb6F9d+xlnpva/07BuY7aZ2ub3B7rUyOt4 v2TPxMDDOMOpWMfdusD2sFb3WNZUxlNW0S7vOiSnX/5uYX/PT9n/AGR/7L3+nzZs3/ZvW2+rumZ1 jcuRXT/8+s3f6noM3/Z9u6K5+17fT+2T6POz27eI0XMJKUkkkkpSSSSSnT+rPT8fqnXMXBywTTYX F4aYJDGOsifA7dVe6x0avF6BT1K3Grw8x2SKn0Uve7bW+v1Gi5tr7C2zSYng66rK6P1N/R+pUdRr YLTSTLHGA4OaWOEjgw7RHzesMyOnfs3Hqsax2S7MttyLfWsfY5uz6Qrq05mQUlNO6nFZi49tWR6l 9m/16Nhb6W0wz3nR24a6cLrs36rYVJ6pV9lZTRh4jrMTINln2i6yquux7trnljmAuhxDBzA8uRuy vWxcfF9Gpn2ff+lY2LLN53fpXT7tvDVs5X1r+025eYcd4y83E+xPc67dSxjg0P8ATq9MObO0kDed T3SU6vT/AKrYWQ/p9L8Vn2bKwmXXZllljbTfc214roh4rJbtmNhho18+KXQUfWv0n4GS/He/J6Zj nHx/00UfRdWHup9MunaRuh4mOy59JTr/AFcw8TKf1B+ZSLxi4F2TWxzntHqV7Ns+m5hjXxU/q/hY 3VX9Tqfiix7cO7IxmVmyWWNgMawB53D38OngKr0bqjOlvyjbSb2ZeNZiPa1/pkCzbLg4ss19vgp9 J6wzpD823Gqs35VD8eh/q7TSH67iW1+5wgajb/clN3onRccfWSno/U21ZQsY8XMre/8ARPDHWbN9 ZYN7S2HQSPnxWp+rGffkYWPVZQ4dQFpptDyaw6jd6rCWtOrdvIBaexKLj/WSijrdPXHYc311bbQy wMFt7mlj73RUQNwd9EDnWVHC+sz8EdJ9PHDj0k3yXO0tGQfcIDfaQDpykpo29Puw8TB6ncK7acw2 GuuXSRS8McLI2wD5O+5an1p6Azp+blXdNDDh0PrrsqY5zn0F9bHN9XfrDyTtdJHbnRUM/qtGX07F 6dVQ+pmC+w0OdYHnZdDntfFbJO8aERppHdXeq/WdnUGZ4pxTS/qho+0Ofb6gAx/oitoqrgmBMkpK ZjoVeL9XuoX59dYz6Bj2saHP9alt9m3bcyRWCWiQPpCdeyrdAxsLNo6lVlY7Hvx8K/Kqu3WB7XsD Q0Q2wMIEzq1GzfrOzOZnizFLX9TrqGQ5tugsx9vpvraajDdDuaSZ8QqXSuq0dMozG+g+2/Mx7cXf 6gaxrLQ3XZ6biSCP3klOckkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUtr6o4PS+pdXZh9TbZYLA70q2aMcQ1zibHh7XAAN0jk/jirR6D1Wjo2 ezqFlD8i2qfSDbBW0bmuY7dNdhOjtNQkpt/V7pLOoYXUMhuN9tycf7OzHocXBhN1m1znem+t2jW/ vQO6H9aOmYvTMzGZi7A3IxKr3ipxfVvdua41OfLiw7ZEkqGD1mjBqzsOqi37J1BjGOaLg25vpmf5 0U7SHbnAjZwfvB1bqf7TtoLavRqxcevFqaXb3bKgYL3bWgkknhoSUi6c7AZm1P6o2yzEaZtZTG9w AMASW6ExOvCv9XxsLH6Zh2Px2YuflfrDa6HWOr+yvEVus9Wyz3lwMbTxzqsdWuoZrM37NsrfX9nx 66DvtdbuLJ9zd/0AZ+iNAkpqpJJJKUkkkkpSSSSSlJJJJKZ0eh69f2rf6G9vq+nG/ZPu27tJjiVu 9Xxel1YeRfj4rBS+1o6dmYlj7GEfTdXk+rc8sfscNNrTI8FhUW+hfXfsZZ6b2v8ATsG5jtpna5vc HutTI63i/ZM/EwMM4w6lYx926wPawVvdY1lTGU1bRLu86JKdf/m5hf8APT9n/ZH/ALL3+nzZs3/Z vW2+rumZ1jcuRXT/APPrN3+p6DN/2fbuiufte30/tk+jzs9u3iNFzCSlJJJJKUkkkkp0/qz0/H6p 1zFwcsE02FxeGmCQxjrInwO3VXusdGrxegU9Stxq8PMdkip9FL3u21vr9Rouba+wts0mJ4Ouqyuj 9Tf0fqVHUa2C00kyxxgODmljhI4MO0R83rDMjp37Nx6rGsdkuzLbci31rH2Obs+kK6tOZkFJTTup xWYuPbVkepfZv9ejYW+ltMM950duGunC67N+q2FSeqVfZWU0YeI6zEyDZZ9ousqrrse7a55Y5gLo cQwcwPLkbsr1sXHxfRqZ9n3/AKVjYss3nd+ldPu28NWzlfWv7Tbl5hx3jLzcT7E9zrt1LGODQ/06 vTDmztJA3nU90lOr0/6rYWQ/p9L8Vn2bKwmXXZllljbTfc214roh4rJbtmNhho18+KXQUfWv0n4G S/He/J6ZjnHx/wBNFH0XVh7qfTLp2kboeJjsufSU6/1cw8TKf1B+ZSLxi4F2TWxzntHqV7Ns+m5h jXxU/q/hY3VX9Tqfiix7cO7IxmVmyWWNgMawB53D38OngKr0bqjOlvyjbSb2ZeNZiPa1/pkCzbLg 4ss19vgp9J6wzpD823Gqs35VD8eh/q7TSH67iW1+5wgajb/clKZ9X8qzqX7IruofmCsvNbXEj1Gt LnUbwzb6gA1129t0oh+rGe7Kw8XHsoyRnmxtF9TyayaSW26ua0w2JkDXtKLj/WSijrdPXHYc311b bQywMFt7mlj73RUQNwd9EDnWVR6X1P8AZHVqupY1W5tL3FtVjpOxwcwtL2tbrtdzHPbskpL1P6vZ 3S8VmbdDqX2GmdttZD43AFmRVS6CJ1AI0S6jg143SOl5TK65yhcXXMe9xsLHNEPrexoYWTt9syq2 Vf059DasLFfS8PLn3XXeq8iAAwBrKmAd/ok+aPndVoy+k4PTWUPrdgb4tNgcH+qd9ns9Nse7jXQe PKSmWV0G7DYTdlYwtFDckU73AvrdB/R2OY2p51/MeZgxKs4/1O6vk0U3V7N2TV69VZFplpBc0G1t RpaXAaBzxyJQ7Ou4runW9Prw3iu1jQyqy82UU2N1NtDHM9RhMu/wnfWQmu61hZbMV2fgm+7DxhiM i4spcGb/AE3PY1m+Ru1iwT5JKY9P+ruT1HFqzKsjHrqtt+zD1XPaRcSwMqgVkkuD5G2REyQrfSej 0VYXVc7qeOy+zpj66jjvuFYn1IukseHTtEMPBPAcVQ/atH7A/YvoP3/aPtXr+oI37fTj0/T42fyu dfJLB6rRidJzumvofY7P2TaLA0M9I76/Z6bp93Ouo8OUlLYvSx1K7MfhWCrFxQ63dkSbBVu2tJZQ yxxIB9xDYHdKvouRfmtw8a2i8OrF7sit/wChZVEufa4gFgb+cHAHy4Q+mZ1OC99llVjnkD0rqLnU XVHuWPAe2HNJBlp+Svf842ftLKzRiBtebjPxchjX7bH+o0B9u8MDBYXCTFceU6pKY/WfBwsK/B+w sYxmRhVZD/TNhY57y+XN9Yl4BjSUusY2E3o3SuoY2OzGtzPtPrCt1jmn0ntYyPVssI081X6t1RnU xibaTScSgYoJfvDq6yfSkbG+4A+49/AJ+pdVozMDB6fjUPpqwPW2mywWud6zg8ztrqGhHgkpzkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//9k= ------=_Part_101_21637727.1092975316512-- From adam@hiddennet.net Fri Aug 20 09:43:42 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Fri, 20 Aug 2004 09:43:42 +0100 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: References: <37323.1092956744@tigger.icir.org> <4125512B.8050902@jonny.eng.br> Message-ID: <1092991422.13524.54.camel@cellini.cs.ucl.ac.uk> What permissions are you able to execute commands as ? I'd assume it was as a normal user "ray" ? Much of the idea about not having the ability to access the underlying os is that you are using a router and not a unix box. This may seem like a dumb question, but what are you wanting shell access to the router when in xorpsh mode ? What is the set of tasks you are wanting to do ? From this it maybe possible to code in the specific functionality into xorpsh. Adam On Thu, 2004-08-19 at 21:15 -0700, Ray Qiu wrote: > I made a patch to add command "shell" to the operational mode. It > uses system() call. > It can be used to execute Unix shell commands. I didn't see any > problems even when I configured to use xorpsh as the login shell. > Screen capture is attached. > > Did I miss anything? > > --Ray > > On Thu, 19 Aug 2004 22:17:31 -0300, João Carlos Mendes Luís > wrote: > > In Unix, if it is a login shell, two conditions will occur: > > > > - $SHELL wil be set to /path/xorpsh > > - argv[0] of the runnig process will have a '-' as the first character > > > > Both of these, especially the last, could be checked to verify if it is a login > > shell, and decide to allow or not shell commands. > > > > > > > > Atanu Ghosh wrote: > > > If the xorpsh is installed as a login shell it may not be desirable > > > to allow the execution of shell commands. > > > > > > Atanu. > > > > > > > > >>>>>>"Ray" == Ray Qiu writes: > > > > > > > > > Ray> Hi, Is there any particular reason that XORP doesn't support > > > Ray> executing shell commands from the CLI? > > > > > > Ray> Thanks. > > > > > > Ray> --Ray _______________________________________________ > > > Ray> Xorp-hackers mailing list Xorp-hackers@icir.org > > > Ray> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > _______________________________________________ > > > Xorp-hackers mailing list > > > Xorp-hackers@icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > -- > > > > Jonny > > > > -- > > João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br > > _______________________________________________ > > > > > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From jonny@jonny.eng.br Fri Aug 20 15:02:57 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Fri, 20 Aug 2004 11:02:57 -0300 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: <1092991422.13524.54.camel@cellini.cs.ucl.ac.uk> References: <37323.1092956744@tigger.icir.org> <4125512B.8050902@jonny.eng.br> <1092991422.13524.54.camel@cellini.cs.ucl.ac.uk> Message-ID: <41260491.20005@jonny.eng.br> Adam Greenhalgh wrote: > What permissions are you able to execute commands as ? I'd assume it was > as a normal user "ray" ? > > Much of the idea about not having the ability to access the underlying > os is that you are using a router and not a unix box. > > This may seem like a dumb question, but what are you wanting shell > access to the router when in xorpsh mode ? What is the set of tasks you > are wanting to do ? From this it maybe possible to code in the specific > functionality into xorpsh. In a real router, this command may be indeeed useless. That's why it should be possible to disable it by configuration, compilation, etc. In a unix box, though, this may save you time wasted openning another terminal. But you gave me an interesting idea that could be put in the long term TODO list: Expandable, loadable or configurable internal commands that map to the external operating system. Thus, commands that do not exist or belongs in XORP would then be "created" externally. This could, for example, include some kind of kernel loading or unloading for device drivers. Just an idea, though... From Ray Qiu Fri Aug 20 18:45:42 2004 From: Ray Qiu (Ray Qiu) Date: Fri, 20 Aug 2004 10:45:42 -0700 Subject: [Xorp-hackers] Shell command suppport In-Reply-To: <1092991422.13524.54.camel@cellini.cs.ucl.ac.uk> References: <37323.1092956744@tigger.icir.org> <4125512B.8050902@jonny.eng.br> <1092991422.13524.54.camel@cellini.cs.ucl.ac.uk> Message-ID: It saves me time, because I don't need to open another terminal. BTW, Juniper routers allow you to do this. --Ray On Fri, 20 Aug 2004 09:43:42 +0100, Adam Greenhalgh wrote: > What permissions are you able to execute commands as ? I'd assume it was > as a normal user "ray" ? > > Much of the idea about not having the ability to access the underlying > os is that you are using a router and not a unix box. > > This may seem like a dumb question, but what are you wanting shell > access to the router when in xorpsh mode ? What is the set of tasks you > are wanting to do ? From this it maybe possible to code in the specific > functionality into xorpsh. > > Adam > > > On Thu, 2004-08-19 at 21:15 -0700, Ray Qiu wrote: > > I made a patch to add command "shell" to the operational mode. It > > uses system() call. > > It can be used to execute Unix shell commands. I didn't see any > > problems even when I configured to use xorpsh as the login shell. > > Screen capture is attached. > > > > Did I miss anything? > > > > --Ray > > > > On Thu, 19 Aug 2004 22:17:31 -0300, João Carlos Mendes Luís > > wrote: > > > In Unix, if it is a login shell, two conditions will occur: > > > > > > - $SHELL wil be set to /path/xorpsh > > > - argv[0] of the runnig process will have a '-' as the first character > > > > > > Both of these, especially the last, could be checked to verify if it is a login > > > shell, and decide to allow or not shell commands. > > > > > > > > > > > > Atanu Ghosh wrote: > > > > If the xorpsh is installed as a login shell it may not be desirable > > > > to allow the execution of shell commands. > > > > > > > > Atanu. > > > > > > > > > > > >>>>>>"Ray" == Ray Qiu writes: > > > > > > > > > > > > Ray> Hi, Is there any particular reason that XORP doesn't support > > > > Ray> executing shell commands from the CLI? > > > > > > > > Ray> Thanks. > > > > > > > > Ray> --Ray _______________________________________________ > > > > Ray> Xorp-hackers mailing list Xorp-hackers@icir.org > > > > Ray> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > _______________________________________________ > > > > Xorp-hackers mailing list > > > > Xorp-hackers@icir.org > > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > -- > > > > > > Jonny > > > > > > -- > > > João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br > > > _______________________________________________ > > > > > > > > > Xorp-hackers mailing list > > > Xorp-hackers@icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > From bms@spc.org Sun Aug 22 12:30:57 2004 From: bms@spc.org (Bruce M Simpson) Date: Sun, 22 Aug 2004 04:30:57 -0700 Subject: [Xorp-hackers] First-cut IP filtering XIF. Message-ID: <20040822113056.GA798@empiric.icir.org> --/WwmFnJnmDyWGHa4 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Here's a first cut at a simple XRL interface to a firewall abstraction layer (as yet to be coded) in the FEA. I have chosen to treat IPv4 and IPv6 as separate families, with separate tables, etc. This may be an appropriate tactic as some of the filtering providers out there may support IPv4 but not IPv6; those that do support both generally implement them in separate tables. (As an aside, I have also begun hacking code for a PF_KEY interface.) Looking at the Juniper filtering story it appears they *don't* use a numbered-table method; this does limit flexibility at the expense of keeping the interface simple. Also Juniper filters have to be tied to particular interfaces, presumably this is so that they can be readily adapt to whatever filtering features exist on their hardware. All of ipfw, ipf, iptables and pf implement a numbered-table scheme to some degree. Juniper, however, do specify that rules are evaluated in the order in which they are defined. More about how Juniper do filtering can be found here: http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-policy/html/policy-framework-overview4.html#1030422 Questions/comments/flames... BMS --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fea_filter.xif" /* $XORP$ */ /* ** IP filtering XRL interface. */ interface fea_filter/0.1 { /** * Get global IP filter enable status. */ get_fw_enabled -> enabled:bool /** * Set global IP filter enable status. * * @param enabled Enable or disable IP filtering. */ set_fw_enabled ? enabled:bool /** * Get global IP filter default-to-discard status. */ get_fw_default_discard -> discard:bool /** * Set global IP filter default-to-discard status. * * @param accept Discard all datagrams by default if true; * otherwise, accept them. */ set_fw_default_discard ? discard:bool /** * Get the underlying IP filter provider type in use. */ get_fw_provider -> provider:txt /** * Set the underlying IP filter provider type in use. * @param provider Name of an IP firewall provider to use on * systems which have multiple IP filtering providers. */ set_fw_provider ? provider:txt /** * Get the underlying IP filter provider version in use. */ get_fw_version -> version:txt /** * Add an IPv4 family filter rule. * * @param iface Name of the interface where this filter is to be applied. * @param src Source IPv4 address with network prefix. * @param dst Destination IPv4 address with network prefix. * @param proto IP protocol number for match (actually u8). * @param sport Source TCP/UDP port (actually u16). * @param dport Destination TCP/UDP port (actually u16). * @param action Action to take when this filter is matched. */ add_filter_4 \ ? \ iface:txt & \ src:ipv4net & \ dst:ipv4net & \ proto:u32 & \ sport:u32 & \ dport:u32 & \ action:txt /** * Add an IPv6 family filter rule. * * @param iface Name of the interface where this filter is to be applied. * @param src Source IPv6 address with network prefix. * @param dst Destination IPv6 address with network prefix. * @param proto IP protocol number for match (actually u8). * @param sport Source TCP/UDP port (actually u16). * @param dport Destination TCP/UDP port (actually u16). * @param action Action to take when this filter is matched. */ add_filter_6 \ ? \ iface:txt & \ src:ipv6net & \ dst:ipv6net & \ proto:u32 & \ sport:u32 & \ dport:u32 & \ action:txt /** * Delete an IPv4 family filter rule. * * @param iface Name of the interface where this filter is to be deleted. * @param src Source IPv4 address with network prefix. * @param dst Destination IPv4 address with network prefix. * @param proto IP protocol number for match (actually u8). * @param sport Source TCP/UDP port (actually u16). * @param dport Destination TCP/UDP port (actually u16). */ delete_filter_4 \ ? \ iface:txt & \ src:ipv4net & \ dst:ipv4net & \ proto:u32 & \ sport:u32 & \ dport:u32 /** * Delete an IPv6 family filter rule. * * @param iface Name of the interface where this filter is to * be deleted. * @param src Source IPv6 address with network prefix. * @param dst Destination IPv6 address with network prefix. * @param proto IP protocol number for match (actually u8). * @param sport Source TCP/UDP port (actually u16). * @param dport Destination TCP/UDP port (actually u16). */ delete_filter_6 \ ? \ iface:txt & \ src:ipv6net & \ dst:ipv6net & \ proto:u32 & \ sport:u32 & \ dport:u32 /** * Get the first IPv4 family filter rule configured in the system. * * @param token returned token to be provided when calling * get_filter_list_next_4. * @param more returned to indicate whether there are more * list items remaining. */ get_filter_list_start_4 \ -> \ token:u32 \ & more:bool /** * Get the next IPv4 family filter rule configured in the system. * * @param token token from prior call to get_filter_list_start_4. * @param more returned to indicate whether there are more list items * remaining. */ get_filter_list_next_4 \ ? \ token:u32 \ -> \ more:bool & \ src:ipv4net & \ dst:ipv4net & \ proto:u32 & \ sport:u32 & \ dport:u32 & \ action:txt /** * Get the first IPv6 family filter rule configured in the system. * * @param token returned token to be provided when calling * get_filter_list_next_6. * @param more returned to indicate whether there are more * list items remaining. */ get_filter_list_start_6 \ -> \ token:u32 \ & more:bool /** * Get the next IPv6 family filter rule configured in the system. * * @param token token from prior call to get_filter_list_start_6. * @param more returned to indicate whether there are more list items * remaining. */ get_filter_list_next_6 \ ? \ token:u32 \ -> \ more:bool & \ src:ipv6net & \ dst:ipv6net & \ proto:u32 & \ sport:u32 & \ dport:u32 & \ action:txt } --J2SCkAp4GZ/dPZZf-- --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBKIPwueUpAYYNtTsRAuF/AKCHR5z0hNymPteU4E63INsS2mToiACfcVu4 toiEcBpOeEiMiOFd24a0CWc= =n+Yf -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From pavlin@icir.org Mon Aug 23 23:44:37 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 23 Aug 2004 15:44:37 -0700 Subject: [Xorp-hackers] First-cut IP filtering XIF. In-Reply-To: Message from Bruce M Simpson of "Sun, 22 Aug 2004 04:30:57 PDT." <20040822113056.GA798@empiric.icir.org> Message-ID: <200408232244.i7NMibwK014326@possum.icir.org> > Questions/comments/flames... Few minor editorial suggestions/nits/comments. > BMS > > --J2SCkAp4GZ/dPZZf > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="fea_filter.xif" > > /* $XORP$ */ > > /* > ** IP filtering XRL interface. > */ > interface fea_filter/0.1 { > /** > * Get global IP filter enable status. > */ > get_fw_enabled -> enabled:bool > > /** > * Set global IP filter enable status. > * > * @param enabled Enable or disable IP filtering. > */ > set_fw_enabled ? enabled:bool > > /** > * Get global IP filter default-to-discard status. > */ > get_fw_default_discard -> discard:bool > > /** > * Set global IP filter default-to-discard status. > * > * @param accept Discard all datagrams by default if true; > * otherwise, accept them. > */ > set_fw_default_discard ? discard:bool > > /** > * Get the underlying IP filter provider type in use. > */ > get_fw_provider -> provider:txt > > /** > * Set the underlying IP filter provider type in use. > * @param provider Name of an IP firewall provider to use on > * systems which have multiple IP filtering providers. > */ > set_fw_provider ? provider:txt > > /** > * Get the underlying IP filter provider version in use. > */ > get_fw_version -> version:txt > > /** > * Add an IPv4 family filter rule. > * > * @param iface Name of the interface where this filter is to be applied. You may want to split the line. > * @param src Source IPv4 address with network prefix. > * @param dst Destination IPv4 address with network prefix. > * @param proto IP protocol number for match (actually u8). > * @param sport Source TCP/UDP port (actually u16). > * @param dport Destination TCP/UDP port (actually u16). The name "sport" may be a bit confusing due to the fact there is already a word spelled exactly same way :) I'd recommend the following renaming: sport -> src_port dport -> dst_port Also, in the comments about "proto", "sport" and "dport" you may want to replace "(actually u8)" with something like "(0-255)", because when the kdoc comments gets picked-up from the auto-generated *.hh file, the "u32", etc, XRL-specific keywords are lost. > * @param action Action to take when this filter is matched. > */ > add_filter_4 \ > ? \ > iface:txt & \ > src:ipv4net & \ > dst:ipv4net & \ > proto:u32 & \ > sport:u32 & \ > dport:u32 & \ > action:txt The convention so far we have been following is to use "foo4" and "foo6" (instead of "foo_4" and "foo_6") as the names of the XRLs that are IPv4 and IPv6 specific, hence for consistency I'd recommend that you use same convention. Also, alignment-wise, even though there are no strict guidelines, many of the *.xif files use slightly different alignment. E.g., the '\' is -ed to the end of the line, '&' goes first on a line, etc. Example: add_filter4 ? iface:txt \ & src:ipv4net \ & dst:ipv4net \ & proto:u32 \ & sport:u32 \ & dport:u32 \ & action:txt Regards, Pavlin From kohler@CS.UCLA.EDU Tue Aug 24 00:42:57 2004 From: kohler@CS.UCLA.EDU (Eddie Kohler) Date: Mon, 23 Aug 2004 16:42:57 -0700 Subject: [Xorp-hackers] First-cut IP filtering XIF. In-Reply-To: <200408232244.i7NMibwK014326@possum.icir.org> References: <200408232244.i7NMibwK014326@possum.icir.org> Message-ID: <291B8D21-F55E-11D8-BF26-000A95A6D9BC@cs.ucla.edu> >> * @param src Source IPv4 address with network prefix. >> * @param dst Destination IPv4 address with network prefix. >> * @param proto IP protocol number for match (actually u8). >> * @param sport Source TCP/UDP port (actually u16). >> * @param dport Destination TCP/UDP port (actually u16). > > The name "sport" may be a bit confusing due to the fact there is > already a word spelled exactly same way :) > I'd recommend the following renaming: > > sport -> src_port > dport -> dst_port "sport" and "dport" are well-known actually.. Minor, but whatever :) E From zec@icir.org Tue Aug 24 15:10:17 2004 From: zec@icir.org (Marko Zec) Date: Tue, 24 Aug 2004 16:10:17 +0200 Subject: [Xorp-hackers] First-cut IP filtering XIF. In-Reply-To: <20040822113056.GA798@empiric.icir.org> References: <20040822113056.GA798@empiric.icir.org> Message-ID: <200408241610.17649.zec@icir.org> On Sunday 22 August 2004 13:30, Bruce M Simpson wrote: > Here's a first cut at a simple XRL interface to a firewall abstraction > layer (as yet to be coded) in the FEA. ... > iface:txt & \ > src:ipv4net & \ > dst:ipv4net & \ > proto:u32 & \ > sport:u32 & \ > dport:u32 & \ > action:txt ... > * @param sport Source TCP/UDP port (actually u16). > * @param dport Destination TCP/UDP port (actually u16). Perhaps it would make sense to allow for some kind of wildcarding on TCP/UDP ports. The proposed model with strict 1:1 port matching will not allow catching ephemeral ports etc. On the other hand, different firewalling providers / implementations can have quite incompatible semantics in this matter, which might be a problem if we wish to have an uniform XRL firewall interface across all platforms. So maybe we should begin with supportting something really simple, like a single sport/dport range per firewall rule, since such semantics seems to be supported by most UNIX firewalls (I guess?). IMO, the "action" field should probably also be uniformly defined across all underlying platforms (i.e. to avoid having random aliases for the same action, like permit/allow/pass/accept, deny/drop/block etc.). Or maybe not? Marko From zec@icir.org Tue Aug 24 19:47:26 2004 From: zec@icir.org (Marko Zec) Date: Tue, 24 Aug 2004 20:47:26 +0200 Subject: [Xorp-hackers] Small bug in RIP code Message-ID: <200408242047.26794.zec@icir.org> Hi all, While running multiple xorps in imunes, I've just bumped into a small bug / typo in the RIP code, which leads to incorrect route metric calculation. See the patch bellow... Cheers, Marko --- port.cc.org Tue Aug 24 20:40:31 2004 +++ port.cc Tue Aug 24 20:40:38 2004 @@ -918,7 +918,7 @@ nh = src_addr; } - metric += metric + cost(); + metric += cost(); if (metric > RIP_INFINITY) { metric = RIP_INFINITY; } From lqin@sce.carleton.ca Tue Aug 24 20:16:27 2004 From: lqin@sce.carleton.ca (Liang Qin) Date: Tue, 24 Aug 2004 15:16:27 -0400 Subject: [Xorp-hackers] compiling error in Fedora 2 Message-ID: <412B940B.7070405@sce.carleton.ca> This is a multi-part message in MIME format. --------------080704030502030207070706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi XORP users, I got an error when I compile XORP 1.0 in Fedora core 2 (kernel 2.6.5-1.358) I attach part of message here. Thanks! Liang Qin --------------080704030502030207070706 Content-Type: text/plain; name="gmakeError" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gmakeError" /bin/sh: line 1: net-snmp-config: command not found bgp4_mib_1657.cc:18:38: net-snmp/net-snmp-config.h: No such file or directory bgp4_mib_1657.cc:19:40: net-snmp/net-snmp-includes.h: No such file or directory bgp4_mib_1657.cc:20:52: net-snmp/agent/net-snmp-agent-includes.h: No such file or directory In file included from bgp4_mib_1657.cc:28: bgp4_mib_1657_bgpversion.hh:27: error: 'Netsnmp_Node_Handler' is used as a type, but is not defined as a type. In file included from bgp4_mib_1657.cc:29: bgp4_mib_1657_bgplocalas.hh:27: error: 'Netsnmp_Node_Handler' is used as a type, but is not defined as a type. In file included from bgp4_mib_1657.cc:30: bgp4_mib_1657_bgpidentifier.hh:25: error: 'Netsnmp_Node_Handler' is used as a type, but is not defined as a type. In file included from bgp4_mib_1657.cc:31: bgp4_mib_1657_bgppeertable.hh:22: error: 'Netsnmp_Node_Handler' is used as a type, but is not defined as a type. bgp4_mib_1657_bgppeertable.hh:24: error: 'Netsnmp_First_Data_Point' is used as a type, but is not defined as a type. bgp4_mib_1657_bgppeertable.hh:25: error: 'Netsnmp_Next_Data_Point' is used as a type, but is not defined as a type. In file included from bgp4_mib_1657.cc:32: bgp4_mib_1657_bgp4pathattrtable.hh:26:38: net-snmp/net-snmp-config.h: No such file or directory In file included from bgp4_mib_1657_bgp4pathattrtable.hh:31, from bgp4_mib_1657.cc:32: patched_container.h:12:2: #error "Please include before this file" patched_container.h:15:28: net-snmp/types.h: No such file or directory patched_container.h:16:38: net-snmp/library/factory.h: No such file or directory In file included from bgp4_mib_1657_bgp4pathattrtable.hh:31, from bgp4_mib_1657.cc:32: patched_container.h:76: error: syntax error before `*' token patched_container.h:149: error: syntax error before `*' token patched_container.h:193: error: type specifier omitted for parameter ` netsnmp_factory' patched_container.h:193: error: syntax error before `*' token patched_container.h:382: error: syntax error before `*' token patched_container.h:391: error: type specifier omitted for parameter ` netsnmp_container_set' patched_container.h:391: error: syntax error before `*' token In file included from bgp4_mib_1657.cc:32: bgp4_mib_1657_bgp4pathattrtable.hh:34:40: net-snmp/agent/table_array.h: No such file or directory In file included from bgp4_mib_1657.cc:32: bgp4_mib_1657_bgp4pathattrtable.hh:51: error: syntax error before `[' token bgp4_mib_1657.cc: In function `void init_bgp4_mib_1657()': bgp4_mib_1657.cc:42: error: `DEBUGMSGTL' undeclared (first use this function) bgp4_mib_1657.cc:42: error: (Each undeclared identifier is reported only once for each function it appears in.) bgp4_mib_1657.cc: In function `void deinit_bgp4_mib_1657()': bgp4_mib_1657.cc:67: error: `DEBUGMSGTL' undeclared (first use this function) bgp4_mib_1657.cc: In constructor `BgpMib::BgpMib()': bgp4_mib_1657.cc:83: warning: left-hand operand of comma expression has no effect bgp4_mib_1657.cc:83: error: `DEBUGMSGTL' undeclared (first use this function) bgp4_mib_1657.cc: In destructor `virtual BgpMib::~BgpMib()': bgp4_mib_1657.cc:88: warning: left-hand operand of comma expression has no effect bgp4_mib_1657.cc:88: error: `DEBUGMSGTL' undeclared (first use this function) gmake[3]: *** [bgp4_mib_1657.o] Error 1 gmake[3]: Leaving directory `/home/lqin/xorp-1.0/mibs' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/lqin/xorp-1.0/mibs' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/lqin/xorp-1.0' gmake: *** [all] Error 2 You have new mail in /var/spool/mail/root [root@localhost xorp-1.0]# --------------080704030502030207070706-- From dchuang@juniper.net Wed Aug 25 02:29:48 2004 From: dchuang@juniper.net (Daniel Chuang) Date: Tue, 24 Aug 2004 18:29:48 -0700 Subject: [Xorp-hackers] compiling error in Fedora 2 References: <412B940B.7070405@sce.carleton.ca> Message-ID: <412BEB8C.7080901@juniper.net> Add the net-snmp source code directory into your search path so that you can run net-snmp-config. Also the where-is-your-net-snmp/include is not in the -I... list during compilation. thanks, Daniel Liang Qin wrote: > Hi XORP users, > > I got an error when I compile XORP 1.0 in Fedora core 2 (kernel > 2.6.5-1.358) > > I attach part of message here. > > Thanks! > > Liang Qin > > >------------------------------------------------------------------------ > >/bin/sh: line 1: net-snmp-config: command not found >bgp4_mib_1657.cc:18:38: net-snmp/net-snmp-config.h: No such file or directory >bgp4_mib_1657.cc:19:40: net-snmp/net-snmp-includes.h: No such file or directory >bgp4_mib_1657.cc:20:52: net-snmp/agent/net-snmp-agent-includes.h: No such file or directory >In file included from bgp4_mib_1657.cc:28: >bgp4_mib_1657_bgpversion.hh:27: error: 'Netsnmp_Node_Handler' is used as a > type, but is not defined as a type. >In file included from bgp4_mib_1657.cc:29: >bgp4_mib_1657_bgplocalas.hh:27: error: 'Netsnmp_Node_Handler' is used as a > type, but is not defined as a type. >In file included from bgp4_mib_1657.cc:30: >bgp4_mib_1657_bgpidentifier.hh:25: error: 'Netsnmp_Node_Handler' is used as a > type, but is not defined as a type. >In file included from bgp4_mib_1657.cc:31: >bgp4_mib_1657_bgppeertable.hh:22: error: 'Netsnmp_Node_Handler' is used as a > type, but is not defined as a type. >bgp4_mib_1657_bgppeertable.hh:24: error: 'Netsnmp_First_Data_Point' is used as > a type, but is not defined as a type. >bgp4_mib_1657_bgppeertable.hh:25: error: 'Netsnmp_Next_Data_Point' is used as a > type, but is not defined as a type. >In file included from bgp4_mib_1657.cc:32: >bgp4_mib_1657_bgp4pathattrtable.hh:26:38: net-snmp/net-snmp-config.h: No such file or directory >In file included from bgp4_mib_1657_bgp4pathattrtable.hh:31, > from bgp4_mib_1657.cc:32: >patched_container.h:12:2: #error "Please include before this file" >patched_container.h:15:28: net-snmp/types.h: No such file or directory >patched_container.h:16:38: net-snmp/library/factory.h: No such file or directory >In file included from bgp4_mib_1657_bgp4pathattrtable.hh:31, > from bgp4_mib_1657.cc:32: >patched_container.h:76: error: syntax error before `*' token >patched_container.h:149: error: syntax error before `*' token >patched_container.h:193: error: type specifier omitted for parameter ` > netsnmp_factory' >patched_container.h:193: error: syntax error before `*' token >patched_container.h:382: error: syntax error before `*' token >patched_container.h:391: error: type specifier omitted for parameter ` > netsnmp_container_set' >patched_container.h:391: error: syntax error before `*' token >In file included from bgp4_mib_1657.cc:32: >bgp4_mib_1657_bgp4pathattrtable.hh:34:40: net-snmp/agent/table_array.h: No such file or directory >In file included from bgp4_mib_1657.cc:32: >bgp4_mib_1657_bgp4pathattrtable.hh:51: error: syntax error before `[' token >bgp4_mib_1657.cc: In function `void init_bgp4_mib_1657()': >bgp4_mib_1657.cc:42: error: `DEBUGMSGTL' undeclared (first use this function) >bgp4_mib_1657.cc:42: error: (Each undeclared identifier is reported only once > for each function it appears in.) >bgp4_mib_1657.cc: In function `void deinit_bgp4_mib_1657()': >bgp4_mib_1657.cc:67: error: `DEBUGMSGTL' undeclared (first use this function) >bgp4_mib_1657.cc: In constructor `BgpMib::BgpMib()': >bgp4_mib_1657.cc:83: warning: left-hand operand of comma expression has no > effect >bgp4_mib_1657.cc:83: error: `DEBUGMSGTL' undeclared (first use this function) >bgp4_mib_1657.cc: In destructor `virtual BgpMib::~BgpMib()': >bgp4_mib_1657.cc:88: warning: left-hand operand of comma expression has no > effect >bgp4_mib_1657.cc:88: error: `DEBUGMSGTL' undeclared (first use this function) >gmake[3]: *** [bgp4_mib_1657.o] Error 1 >gmake[3]: Leaving directory `/home/lqin/xorp-1.0/mibs' >gmake[2]: *** [all-recursive] Error 1 >gmake[2]: Leaving directory `/home/lqin/xorp-1.0/mibs' >gmake[1]: *** [all-recursive] Error 1 >gmake[1]: Leaving directory `/home/lqin/xorp-1.0' >gmake: *** [all] Error 2 >You have new mail in /var/spool/mail/root >[root@localhost xorp-1.0]# > From pavlin@icir.org Wed Aug 25 22:09:58 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 25 Aug 2004 14:09:58 -0700 Subject: [Xorp-hackers] compiling error in Fedora 2 In-Reply-To: Message from Daniel Chuang of "Tue, 24 Aug 2004 18:29:48 PDT." <412BEB8C.7080901@juniper.net> Message-ID: <200408252109.i7PL9wwK035204@possum.icir.org> > Add the net-snmp source code directory into your search path so that > you can run net-snmp-config. > > Also the where-is-your-net-snmp/include is not in the -I... > list during compilation. It appears that the net-snmp pre-compiled distribution on Fedora doesn't contain net-snmp-config nor any .h header files. Hence, for the time being you have the following three options: (1) Install net-snmp from source rather than from RPM. (2) Run "./configure --without-snmp" to disable the SNMP compilation. (3) Do nothing :) The "mibs" directory is the last in the list of directories to compile, hence even if the compilation in that directory fails, the rest of the system is not affected. Regards, Pavlin > > thanks, > Daniel > > Liang Qin wrote: > > > Hi XORP users, > > > > I got an error when I compile XORP 1.0 in Fedora core 2 (kernel > > 2.6.5-1.358) > > > > I attach part of message here. > > > > Thanks! > > > > Liang Qin > > > > > >------------------------------------------------------------------------ > > > >/bin/sh: line 1: net-snmp-config: command not found > >bgp4_mib_1657.cc:18:38: net-snmp/net-snmp-config.h: No such file or directory > >bgp4_mib_1657.cc:19:40: net-snmp/net-snmp-includes.h: No such file or directory > >bgp4_mib_1657.cc:20:52: net-snmp/agent/net-snmp-agent-includes.h: No such file or directory > >In file included from bgp4_mib_1657.cc:28: > >bgp4_mib_1657_bgpversion.hh:27: error: 'Netsnmp_Node_Handler' is used as a > > type, but is not defined as a type. > >In file included from bgp4_mib_1657.cc:29: > >bgp4_mib_1657_bgplocalas.hh:27: error: 'Netsnmp_Node_Handler' is used as a > > type, but is not defined as a type. > >In file included from bgp4_mib_1657.cc:30: > >bgp4_mib_1657_bgpidentifier.hh:25: error: 'Netsnmp_Node_Handler' is used as a > > type, but is not defined as a type. > >In file included from bgp4_mib_1657.cc:31: > >bgp4_mib_1657_bgppeertable.hh:22: error: 'Netsnmp_Node_Handler' is used as a > > type, but is not defined as a type. > >bgp4_mib_1657_bgppeertable.hh:24: error: 'Netsnmp_First_Data_Point' is used as > > a type, but is not defined as a type. > >bgp4_mib_1657_bgppeertable.hh:25: error: 'Netsnmp_Next_Data_Point' is used as a > > type, but is not defined as a type. > >In file included from bgp4_mib_1657.cc:32: > >bgp4_mib_1657_bgp4pathattrtable.hh:26:38: net-snmp/net-snmp-config.h: No such file or directory > >In file included from bgp4_mib_1657_bgp4pathattrtable.hh:31, > > from bgp4_mib_1657.cc:32: > >patched_container.h:12:2: #error "Please include before this file" > >patched_container.h:15:28: net-snmp/types.h: No such file or directory > >patched_container.h:16:38: net-snmp/library/factory.h: No such file or directory > >In file included from bgp4_mib_1657_bgp4pathattrtable.hh:31, > > from bgp4_mib_1657.cc:32: > >patched_container.h:76: error: syntax error before `*' token > >patched_container.h:149: error: syntax error before `*' token > >patched_container.h:193: error: type specifier omitted for parameter ` > > netsnmp_factory' > >patched_container.h:193: error: syntax error before `*' token > >patched_container.h:382: error: syntax error before `*' token > >patched_container.h:391: error: type specifier omitted for parameter ` > > netsnmp_container_set' > >patched_container.h:391: error: syntax error before `*' token > >In file included from bgp4_mib_1657.cc:32: > >bgp4_mib_1657_bgp4pathattrtable.hh:34:40: net-snmp/agent/table_array.h: No such file or directory > >In file included from bgp4_mib_1657.cc:32: > >bgp4_mib_1657_bgp4pathattrtable.hh:51: error: syntax error before `[' token > >bgp4_mib_1657.cc: In function `void init_bgp4_mib_1657()': > >bgp4_mib_1657.cc:42: error: `DEBUGMSGTL' undeclared (first use this function) > >bgp4_mib_1657.cc:42: error: (Each undeclared identifier is reported only once > > for each function it appears in.) > >bgp4_mib_1657.cc: In function `void deinit_bgp4_mib_1657()': > >bgp4_mib_1657.cc:67: error: `DEBUGMSGTL' undeclared (first use this function) > >bgp4_mib_1657.cc: In constructor `BgpMib::BgpMib()': > >bgp4_mib_1657.cc:83: warning: left-hand operand of comma expression has no > > effect > >bgp4_mib_1657.cc:83: error: `DEBUGMSGTL' undeclared (first use this function) > >bgp4_mib_1657.cc: In destructor `virtual BgpMib::~BgpMib()': > >bgp4_mib_1657.cc:88: warning: left-hand operand of comma expression has no > > effect > >bgp4_mib_1657.cc:88: error: `DEBUGMSGTL' undeclared (first use this function) > >gmake[3]: *** [bgp4_mib_1657.o] Error 1 > >gmake[3]: Leaving directory `/home/lqin/xorp-1.0/mibs' > >gmake[2]: *** [all-recursive] Error 1 > >gmake[2]: Leaving directory `/home/lqin/xorp-1.0/mibs' > >gmake[1]: *** [all-recursive] Error 1 > >gmake[1]: Leaving directory `/home/lqin/xorp-1.0' > >gmake: *** [all] Error 2 > >You have new mail in /var/spool/mail/root > >[root@localhost xorp-1.0]# > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Wed Aug 25 22:38:43 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 25 Aug 2004 14:38:43 -0700 Subject: [Xorp-hackers] compiling error in Fedora 2 In-Reply-To: Message from Pavlin Radoslavov of "Wed, 25 Aug 2004 14:09:58 PDT." <200408252109.i7PL9wwK035204@possum.icir.org> Message-ID: <200408252138.i7PLchwK036672@possum.icir.org> > > Add the net-snmp source code directory into your search path so that > > you can run net-snmp-config. > > > > Also the where-is-your-net-snmp/include is not in the -I... > > list during compilation. > > It appears that the net-snmp pre-compiled distribution on Fedora > doesn't contain net-snmp-config nor any .h header files. > Hence, for the time being you have the following three options: > > (1) Install net-snmp from source rather than from RPM. > (2) Run "./configure --without-snmp" to disable the SNMP compilation. > (3) Do nothing :) > The "mibs" directory is the last in the list of directories to > compile, hence even if the compilation in that directory fails, > the rest of the system is not affected. FYI, I just commited a better check to the "./configure" script, hence if you use XORP-current the SNMP compilation should be automatically disabled if net-snmp-config is missing. Regards, Pavlin