From eshe168 at gmail.com Sat Jan 3 23:32:24 2009 From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=) Date: Sun, 4 Jan 2009 15:32:24 +0800 Subject: [Xorp-hackers] About inheriting from XrlStdRouter. Message-ID: <56f9e0990901032332s146d124cw97157dc50e93896f@mail.gmail.com> Hi, I wrote a new class, whose base class is XrlStdRouter. The following is my simple source code. But, when I use make to build, there are something wrong. I can not find reason. Moreover, if the IpcSVR do not inherit from XrlStdRouter, the build is right. PS: My OS is debian, 2.6.24 kernel. class IpcSVR : public XrlStdRouter { public: IpcSVR(EventLoop& eventloop, const string& targetname, const string& finder_hostname, uint16_t finder_port); ~IpcSVR(void); protected: private: EventLoop& _eventloop; // The event loop to use XrlStdRouter _xrl_router; // The standard XRL send/recv point }; Error information: /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o svr_main svr-main.o ../lib/libfinder.la ../lib/libxipc.la ../lib/libcomm.la ../lib/libxorp.la ../lib/libcpl_ifmgrxif.la g++ -g -O2 -o svr_main svr-main.o ../lib/libfinder.a ../lib/libxipc.a ../lib/libcomm.a ../lib/libxorp.a ../lib/libcpl_ifmgrxif.a -lcrypto -lrt svr-main.o: In function `XrlDispatcher': /home/yxs/ipc-xorp/svr-main/../libxipc/xrl_dispatcher.hh:22: undefined reference to `XrlCmdMap::XrlCmdMap(XrlCmdMap const&)' /home/yxs/ipc-xorp/svr-main/../libxipc/xrl_dispatcher.hh:22: undefined reference to `XrlCmdMap::XrlCmdMap(XrlCmdMap const&)' -- Best Regard Xiaoshuai Yang From syed.khalid at xorp.net Thu Jan 8 19:35:08 2009 From: syed.khalid at xorp.net (Syed Khalid) Date: Thu, 8 Jan 2009 19:35:08 -0800 Subject: [Xorp-hackers] XORP announces Release 1.6 Message-ID: Dear XORP community members, We are pleased to announce release 1.6 of the XORP codebase to the world! The XORP team and contributors have worked very hard over the last 6 months and 1.6 is a huge milestone in the history of the XORP project. As many of you know, XORP is now commercially backed by two well-known and highly-respected venture capitalists, and one of the benefits for the XORP community is the additional amount of resources we have been able to bring to the project. These increased resources have resulted in our ability to release 1.6 just months after our announcement of XORP, Inc and release 1.5. In terms of project milestones, 1.6 marks the first time we have put the codebase through a comprehensive and rigorous QA process, using some of the leading test tools in the market for layer 3 testing. Furthermore, here are some of the key improvements in the 1.6 codebase, based on your contributions and user feedback: - Significantly improved memory performance on the BGP code (especially in scenarios with many peers) - XRL performance improvements - Improved policy code - RIP tracing capabilities - *NEW* VRRP support - Numerous bug fixes (entire list is in 1.6 Release Notes available at http://www.xorp.org/releases/1.6/docs/RELEASE_NOTES Of late, we have noticed more users incorporating XORP into their projects, both non-profit and commercial and want to continue to encourage the community to do so. With the recent world financial crisis, organizations will be looking more to open-source as a cost-effective alternative to the high premiums other networking vendors charge, so help us spread the word about XORP.org and help all of us build the momentum behind open-source networking! Thank you very much for your interest and continued participation in the XORP open networking platform project. We appreciate the help and support the community has shown us over the years and hope that you will enjoy this latest release. If you have any questions, please feel free to contact us at info at xorp.net. --The XORP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090108/34191ca6/attachment.html From aleksandar.cvjetic at gmail.com Fri Jan 9 11:44:51 2009 From: aleksandar.cvjetic at gmail.com (Aleksandar Cvjetic) Date: Fri, 9 Jan 2009 20:44:51 +0100 Subject: [Xorp-hackers] bgp development Message-ID: <249ccfe90901091144s4c17c2a7n3bbc48ffb295ecb9@mail.gmail.com> Hello everyone, As a beginner in open source development, I need some instructions in order to start implementation of a new BGP feature. That one should be an academic project in order to test possibility of BGP to announce more than one route for a destination network. So, if a BGP router receives two (or more) routes for a destination prefix, it should announce all of them through iBGP, if those are received from different AS with MED attributes. Because I'm also new in C++ programming (but experienced in networking:-)), can somebody help me with following question: - How and where to start reading bgp code in order to find out which class(es) and objects in the code I need to reference to and compile with my future code? This would be very helpful to me because it's difficult to read and understand entire code. I suppose, this is first step after clear formulation of idea:). Thanks a lot! Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090109/296559e2/attachment.html From bms at incunabulum.net Fri Jan 9 18:50:10 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 10 Jan 2009 02:50:10 +0000 Subject: [Xorp-hackers] bgp development In-Reply-To: <249ccfe90901091144s4c17c2a7n3bbc48ffb295ecb9@mail.gmail.com> References: <249ccfe90901091144s4c17c2a7n3bbc48ffb295ecb9@mail.gmail.com> Message-ID: <49680CE2.2090300@incunabulum.net> Aleksandar Cvjetic wrote: > ... > - How and where to start reading bgp code in order to find out which > class(es) and objects in the code I need to reference to and compile > with my future code? This would be very helpful to me because it's > difficult to read and understand entire code. I suppose, this is first > step after clear formulation of idea:). Warning: BGP is Big. My advice would be to get to grips with tools such as KScope, which is an extremely good C/C++ code browser for the KDE desktop environment, which wraps the popular CScope tool -- one of the few good things to come out of SCO before they got a bit nasty towards Linux. It is intended for dealing with large codebases on a purely C metasyntactic basis, i.e. lookups by module reference -- it doesn't know anything about classes. KScope also gives good GraphViz action for call graphs, essential for understanding code flow in large projects. Also consider tossing the code into BOUML, which has a strong C++ reverse engineering plugout now which can (mostly) spot and deal with templatization. I leveraged the design of OLSR off OSPF mostly by doing this. Have the XORP kdoc documentation for the BGP module to hand in a web browser. You can generate it yourself from within doc/, but it may be easier just for you to mirror the web hosted copy. Also read the design doc (PDF) for BGP. Good luck. BMS From amatin at cox.net Tue Jan 13 16:21:03 2009 From: amatin at cox.net (amatin at cox.net) Date: Tue, 13 Jan 2009 16:21:03 -0800 Subject: [Xorp-hackers] building xorp Message-ID: <20090113192103.6F432.599785.imail@fed1rmwml32> Hi, I am new to XORP and would like to build it on Windows. Could anybody tell me what do I need for building (compile and link) everything on windows platform and what steps I should take. I appreciate any help I can get. Ali From bms at incunabulum.net Wed Jan 14 05:11:35 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 14 Jan 2009 13:11:35 +0000 Subject: [Xorp-hackers] building xorp In-Reply-To: <20090113192103.6F432.599785.imail@fed1rmwml32> References: <20090113192103.6F432.599785.imail@fed1rmwml32> Message-ID: <496DE487.909@incunabulum.net> Ali, amatin at cox.net wrote: > Hi, > > I am new to XORP and would like to build it on Windows. Could anybody tell me what do I need for building (compile and link) everything on windows platform and what steps I should take. I appreciate any help I can get. > Everything you need to know should be under BUILD_NOTES in the top level directory of the XORP source code. There are a bunch of packages which are needed and they need to be installed in just the right order. After that, you may need to patch the MinGW w32api headers. I hope you can appreciate it wasn't easy getting XORP to build with a free compiler under Windows :-) If there are any problems, send email to the list. thanks BMS From MHNews at rodalenews.com Sun Jan 18 00:52:54 2009 From: MHNews at rodalenews.com (Men's Health) Date: Sun, 18 Jan 2009 00:52:54 -0800 Subject: [Xorp-hackers] Message id0242 Message-ID: <20090118125253.2169.qmail@rustem-0zw0zugd> Dear xorp-hackers at icir.org! Learn how to be really inside her DOCTOR.Stanton Charles Honig, MD. Discount price store:(http://www.fatlydoybu.com ) We do guarantee high-quality medications, instant worldwide delivery and friendly support! From vfaion at gmail.com Sun Jan 18 13:34:15 2009 From: vfaion at gmail.com (Victor Faion) Date: Sun, 18 Jan 2009 21:34:15 +0000 Subject: [Xorp-hackers] non-virtual thunk Message-ID: <38f1dbe80901181334ob02658awac40078aa0be5da2@mail.gmail.com> Hello, I was trying to create a simple XORP process by following the xorpdev_101 document but I ran into this error when running make, something about a ``non-virtual thunk''. /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT xrl_bpsf_node.lo -MD -MP -MF .deps/xrl_bpsf_node.Tpo -c -o xrl_bpsf_node.lo xrl_bpsf_node.cc g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT xrl_bpsf_node.lo -MD -MP -MF .deps/xrl_bpsf_node.Tpo -c xrl_bpsf_node.cc -o xrl_bpsf_node.o mv -f .deps/xrl_bpsf_node.Tpo .deps/xrl_bpsf_node.Plo /bin/sh ../libtool --tag=CXX --mode=link g++ -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o libbpsf.la xrl_bpsf_node.lo -lpcap -lcrypto -lrt rm -fr .libs/libbpsf.a .libs/libbpsf.la ar cru .libs/libbpsf.a xrl_bpsf_node.o ranlib .libs/libbpsf.a creating libbpsf.la (cd .libs && rm -f libbpsf.la && ln -s ../libbpsf.la libbpsf.la) g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT xorp_bpsf.o -MD -MP -MF .deps/xorp_bpsf.Tpo -c -o xorp_bpsf.o xorp_bpsf.cc mv -f .deps/xorp_bpsf.Tpo .deps/xorp_bpsf.Po /bin/sh ../libtool --tag=CXX --mode=link g++ -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o xorp_bpsf xorp_bpsf.o libbpsf.la ../xrl/targets/libbpsfbase.la ../libxipc/libxipc.la ../libcomm/libcomm.la ../libxorp/libxorp.la -lpcap -lcrypto -lrt g++ -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o xorp_bpsf xorp_bpsf.o ./.libs/libbpsf.a ../xrl/targets/.libs/libbpsfbase.a ../libxipc/.libs/libxipc.a ../libcomm/.libs/libcomm.a ../libxorp/.libs/libxorp.a -lpcap -lcrypto -lrt ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable for XrlBpsfNode]+0xa8): undefined reference to `XrlBpsfNode::bpsf_0_1_set_nexthop4(std::basic_string, std::allocator > const&, unsigned int const&, std::basic_string, std::allocator > const&, unsigned int const&, IPv4 const&)' ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable for XrlBpsfNode]+0xb0): undefined reference to `XrlBpsfNode::bpsf_0_1_print_hello_world_and_msg(std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&)' ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable for XrlBpsfNode]+0x180): undefined reference to `non-virtual thunk to XrlBpsfNode::bpsf_0_1_set_nexthop4(std::basic_string, std::allocator > const&, unsigned int const&, std::basic_string, std::allocator > const&, unsigned int const&, IPv4 const&)' ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable for XrlBpsfNode]+0x188): undefined reference to `non-virtual thunk to XrlBpsfNode::bpsf_0_1_print_hello_world_and_msg(std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&)' collect2: ld returned 1 exit status make: *** [xorp_bpsf] Error 1 I'm not sure what is causing this. Here are the xrl_bpsf_node.{hh,cc} files: #ifndef __BPSF_XRL_BPSF_NODE_HH__ #define __BPSF_XRL_BPSF_NODE_HH__ #include "libxipc/xrl_std_router.hh" #include "xrl/targets/bpsf_base.hh" class XrlBpsfNode : public XrlStdRouter, public XrlBpsfTargetBase { public: XrlBpsfNode(EventLoop& eventloop, const string& class_name, const string& finder_hostname, uint16_t finder_port); ~XrlBpsfNode(); /** * Get a reference to the XrlRouter instance. * * @return a reference to the XrlRouter (@ref XrlRouter) instance. */ XrlRouter& xrl_router() { return *this; } /** * Startup the node operation. * * @return XORP_OK on success, otherwise XORP_ERROR. */ int startup(); int shutdown(); /** * Test if the node processing is done. * * @return true if the node processing is done, otherwise false. */ bool is_done() const { return true; } protected: // // XRL target methods // /** * Get name of Xrl Target */ XrlCmdError common_0_1_get_target_name( // Output values, string& name); /** * Get version string from Xrl Target */ XrlCmdError common_0_1_get_version( // Output values, string& version); /** * Get status of Xrl Target */ XrlCmdError common_0_1_get_status( // Output values, uint32_t& status, string& reason); /** * Request clean shutdown of Xrl Target */ XrlCmdError common_0_1_shutdown(); /** * Enable/disable/start/stop Bpsf. * * @param enable if true, then enable Bpsf, otherwise disable it. */ XrlCmdError bpsf_0_1_enable_bpsf( // Input values, const bool& enable); XrlCmdError bpsf_0_1_start_bpsf(); XrlCmdError bpsf_0_1_stop_bpsf(); /** * Set the peer's AS number. * * @param next_hop IPv4 nexthop. */ XrlCmdError bpsf_0_1_set_nexthop4( // Input values, const string& local_ip, const uint32_t& local_port, const string& peer_ip, const uint32_t& peer_port, const IPv4& next_hop); XrlCmdError bpsf_0_1_print_hello_world_and_msg( // Input values, const string& msg, // Output values, string& num); /** * Enable/disable the Bpsf trace log for all operations. * * @param enable if true, then enable the trace log, otherwise disable it. */ XrlCmdError bpsf_0_1_enable_log_trace_all( // Input values, const bool& enable); }; #endif // __BPSF_XRL_BPSF_NODE_HH__ ----------------- #include "bpsf_module.h" #include "libxorp/xorp.h" //#include "libxorp/xlog.h" //#include "libxorp/debug.h" //#include "libxorp/ipvx.hh" #include "libxorp/status_codes.h" #include "xrl_bpsf_node.hh" XrlBpsfNode::XrlBpsfNode(EventLoop& eventloop, const string& class_name, const string& finder_hostname, uint16_t finder_port) : XrlStdRouter(eventloop, class_name.c_str(), finder_hostname.c_str(), finder_port), XrlBpsfTargetBase(&xrl_router()) { printf("%s\n", "creating XrlBpsfNode"); } XrlBpsfNode::~XrlBpsfNode() { printf("%s\n", "deleting XrlBpsfNode"); } int XrlBpsfNode::shutdown() { printf("%s\n", "shutting down XrlBpsfNode"); return (XORP_OK); } int XrlBpsfNode::startup() { printf("%s\n", "starting up XrlBpsfNode"); return (XORP_OK); } // // XRL target methods // /** * Get name of Xrl Target */ XrlCmdError XrlBpsfNode::common_0_1_get_target_name( // Output values, string& name) { name = xrl_router().class_name(); return XrlCmdError::OKAY(); } /** * Get version string from Xrl Target */ XrlCmdError XrlBpsfNode::common_0_1_get_version( // Output values, string& version) { version = XORP_MODULE_VERSION; return XrlCmdError::OKAY(); } /** * Get status of Xrl Target */ XrlCmdError XrlBpsfNode::common_0_1_get_status( // Output values, uint32_t& status, string& reason) { status = NULL; reason = "testing protocol"; return XrlCmdError::OKAY(); } /** * Request clean shutdown of Xrl Target */ XrlCmdError XrlBpsfNode::common_0_1_shutdown() { string error_msg; if (shutdown() != XORP_OK) { error_msg = c_format("Failed to shutdown Bpsf"); return XrlCmdError::COMMAND_FAILED(error_msg); } return XrlCmdError::OKAY(); } /** * Enable/disable/start/stop Bpsf. * * @param enable if true, then enable Bpsf, otherwise disable it. */ XrlCmdError XrlBpsfNode::bpsf_0_1_enable_bpsf( // Input values, const bool& enable) { printf("%s\n", enable ? "enabling bpsf" : "disabling bpsf"); return XrlCmdError::OKAY(); } XrlCmdError XrlBpsfNode::bpsf_0_1_start_bpsf() { // XLOG_UNFINISHED(); printf("%s\n", "starting up XrlBpsfNode xrl"); return XrlCmdError::OKAY(); } XrlCmdError XrlBpsfNode::bpsf_0_1_stop_bpsf() { // XLOG_UNFINISHED(); printf("%s\n", "stopping XrlBpsfNode"); return XrlCmdError::OKAY(); } /** * Pure-virtual function that needs to be implemented to: * * Set the peer's AS number. * * @param next_hop IPv4 nexthop. */ XrlCmdError bpsf_0_1_set_nexthop4( // Input values, const string& local_ip, const uint32_t& local_port, const string& peer_ip, const uint32_t& peer_port, const IPv4& next_hop) { printf("%s: %s %d %s %d %s \n", "setting nexthop now...", local_ip.c_str(), local_port, peer_ip.c_str(), peer_port, next_hop.str().c_str()); return XrlCmdError::OKAY(); } XrlCmdError bpsf_0_1_print_hello_world_and_msg( // Input values, const string& msg, // Output values, string& num) { printf("%s: %s\n", "hello world", msg.c_str()); num = "return message from bpsf_0_1_print_hello_world_and_msg"; return XrlCmdError::OKAY(); } /** * Enable/disable the Bpsf trace log for all operations. * * @param enable if true, then enable the trace log, otherwise disable it. */ XrlCmdError XrlBpsfNode::bpsf_0_1_enable_log_trace_all( // Input values, const bool& enable) { printf("%s\n", enable ? "enabling bpsf logging" : "disabling bpsf logging"); return XrlCmdError::OKAY(); } I am using xorp-1.6 compiled from source on Linux kernel 2.6.20.3-ubuntu1 x86_64, but I think I'm just making a stupid mistake somewhere, has anyone had this problem or know how to fix it? Cheers, Victor From eshe168 at gmail.com Sun Jan 18 22:08:17 2009 From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=) Date: Mon, 19 Jan 2009 14:08:17 +0800 Subject: [Xorp-hackers] About STCPRequestHandler Message-ID: <56f9e0990901182208t7c76c9c8ge9862ddf3260583c@mail.gmail.com> Hi, When I have not entered anything in the xorpsh for a little long time(about 3 minutes), xorpsh and xorp_rtrmgr will give me a error message, like following. But I can still use xorpsh, and it works very good. I found a timeout timer in the STCPRequestHandler class, in xrl_pf_stcp.cc/hh, the timer is set as 3 minutes. That is reason? My OS is debian, linux 2.6.26, the version of Xorp is 1.6. [ 2009/01/19 14:05:14 ERROR xorpsh:12519 XRL +373 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired -- Best Regard Xiaoshuai Yang From vfaion at gmail.com Thu Jan 22 09:56:59 2009 From: vfaion at gmail.com (Victor Faion) Date: Thu, 22 Jan 2009 17:56:59 +0000 Subject: [Xorp-hackers] Template files Message-ID: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> Hello, Just wanted some help regarding template files. I was trying to write a simple template file for a process that has a function that just takes in an input message (string), modifies it and gives it back to the callback function, but I didn't know how. Or are the template files supposed to be automatically generated? Victor From r.harbird at cs.ucl.ac.uk Fri Jan 23 02:48:57 2009 From: r.harbird at cs.ucl.ac.uk (Rae Harbird) Date: Fri, 23 Jan 2009 10:48:57 +0000 Subject: [Xorp-hackers] Elementary test harness for XORP module Message-ID: Dear All I am writing a XORP module which sends and receives messages via the XORP OLSR module. I would like to write a simple test harness so that I can check message parsing etc but because each test instance will incorporate two XORP modules (an OLSR and a Rubi) I cannot think how to get started. Do I need to create an instance of both modules for each test node? Can someone give me a hint or let me know if there is an example I could look at? Regards Rae From pavlin at ICSI.Berkeley.EDU Mon Jan 26 10:30:45 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 26 Jan 2009 10:30:45 -0800 Subject: [Xorp-hackers] About inheriting from XrlStdRouter. In-Reply-To: <56f9e0990901032332s146d124cw97157dc50e93896f@mail.gmail.com> References: <56f9e0990901032332s146d124cw97157dc50e93896f@mail.gmail.com> Message-ID: <200901261830.n0QIUjBA021872@fruitcake.ICSI.Berkeley.EDU> [Reply to an old email that seems wasn't answered on the list] Did you resolve the issue? I had a look in file libxipc/xrl_dispatcher.hh (in XORP-1.6 and CVS), but line number 22 is a comment. It looks like the version you are using has been modified which makes it more difficult for us to resolve it. Pavlin ??? wrote: > Hi, > > I wrote a new class, whose base class is XrlStdRouter. The following > is my simple source code. But, when I use make to build, there are > something wrong. I can not find reason. > Moreover, if the IpcSVR do not inherit from XrlStdRouter, the build is right. > > PS: My OS is debian, 2.6.24 kernel. > > class IpcSVR : public XrlStdRouter > { > public: > IpcSVR(EventLoop& eventloop, const string& targetname, > const string& finder_hostname, uint16_t finder_port); > ~IpcSVR(void); > > protected: > private: > EventLoop& _eventloop; // The event loop to use > XrlStdRouter _xrl_router; // The standard XRL send/recv point > }; > > Error information: > /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o svr_main > svr-main.o ../lib/libfinder.la ../lib/libxipc.la ../lib/libcomm.la > ../lib/libxorp.la ../lib/libcpl_ifmgrxif.la > g++ -g -O2 -o svr_main svr-main.o ../lib/libfinder.a ../lib/libxipc.a > ../lib/libcomm.a ../lib/libxorp.a ../lib/libcpl_ifmgrxif.a -lcrypto > -lrt > svr-main.o: In function `XrlDispatcher': > /home/yxs/ipc-xorp/svr-main/../libxipc/xrl_dispatcher.hh:22: undefined > reference to `XrlCmdMap::XrlCmdMap(XrlCmdMap const&)' > /home/yxs/ipc-xorp/svr-main/../libxipc/xrl_dispatcher.hh:22: undefined > reference to `XrlCmdMap::XrlCmdMap(XrlCmdMap const&)' > -- > Best Regard > Xiaoshuai Yang > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at ICSI.Berkeley.EDU Mon Jan 26 11:48:32 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 26 Jan 2009 11:48:32 -0800 Subject: [Xorp-hackers] non-virtual thunk In-Reply-To: <38f1dbe80901181334ob02658awac40078aa0be5da2@mail.gmail.com> References: <38f1dbe80901181334ob02658awac40078aa0be5da2@mail.gmail.com> Message-ID: <200901261948.n0QJmWZ8029143@fruitcake.ICSI.Berkeley.EDU> The implementation of bpsf_0_1_set_nexthop4() is missing the class name: XrlCmdError bpsf_0_1_set_nexthop4( ... It should be: XrlCmdError XrlBpsfNode::bpsf_0_1_set_nexthop4( ... The same issues seems to apply for the other methods as well. A hint: if the return type is on separate line, then it will be easier to spot such omissions: XrlCmdError XrlBpsfNode::bpsf_0_1_set_nexthop4( ... Pavlin Victor Faion wrote: > Hello, > > I was trying to create a simple XORP process by following the > xorpdev_101 document but I ran into this error when running make, > something about a ``non-virtual thunk''. > > /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual > -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 > -pipe -MT xrl_bpsf_node.lo -MD -MP -MF .deps/xrl_bpsf_node.Tpo -c -o > xrl_bpsf_node.lo xrl_bpsf_node.cc > g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings > -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-25 -pipe -MT xrl_bpsf_node.lo -MD -MP -MF > .deps/xrl_bpsf_node.Tpo -c xrl_bpsf_node.cc -o xrl_bpsf_node.o > mv -f .deps/xrl_bpsf_node.Tpo .deps/xrl_bpsf_node.Plo > /bin/sh ../libtool --tag=CXX --mode=link g++ -g -Werror -W -Wall > -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align > -Woverloaded-virtual -ftemplate-depth-25 -pipe -o libbpsf.la > xrl_bpsf_node.lo -lpcap -lcrypto -lrt > rm -fr .libs/libbpsf.a .libs/libbpsf.la > ar cru .libs/libbpsf.a xrl_bpsf_node.o > ranlib .libs/libbpsf.a > creating libbpsf.la > (cd .libs && rm -f libbpsf.la && ln -s ../libbpsf.la libbpsf.la) > g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall > -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align > -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT xorp_bpsf.o -MD -MP > -MF .deps/xorp_bpsf.Tpo -c -o xorp_bpsf.o xorp_bpsf.cc > mv -f .deps/xorp_bpsf.Tpo .deps/xorp_bpsf.Po > /bin/sh ../libtool --tag=CXX --mode=link g++ -g -Werror -W -Wall > -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align > -Woverloaded-virtual -ftemplate-depth-25 -pipe -o xorp_bpsf > xorp_bpsf.o libbpsf.la ../xrl/targets/libbpsfbase.la > ../libxipc/libxipc.la ../libcomm/libcomm.la ../libxorp/libxorp.la > -lpcap -lcrypto -lrt > g++ -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o > xorp_bpsf xorp_bpsf.o ./.libs/libbpsf.a > ../xrl/targets/.libs/libbpsfbase.a ../libxipc/.libs/libxipc.a > ../libcomm/.libs/libcomm.a ../libxorp/.libs/libxorp.a -lpcap -lcrypto > -lrt > ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable > for XrlBpsfNode]+0xa8): undefined reference to > `XrlBpsfNode::bpsf_0_1_set_nexthop4(std::basic_string std::char_traits, std::allocator > const&, unsigned int > const&, std::basic_string, > std::allocator > const&, unsigned int const&, IPv4 const&)' > ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable > for XrlBpsfNode]+0xb0): undefined reference to > `XrlBpsfNode::bpsf_0_1_print_hello_world_and_msg(std::basic_string std::char_traits, std::allocator > const&, > std::basic_string, std::allocator > >&)' > ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable > for XrlBpsfNode]+0x180): undefined reference to `non-virtual thunk to > XrlBpsfNode::bpsf_0_1_set_nexthop4(std::basic_string std::char_traits, std::allocator > const&, unsigned int > const&, std::basic_string, > std::allocator > const&, unsigned int const&, IPv4 const&)' > ./.libs/libbpsf.a(xrl_bpsf_node.o):(.rodata._ZTV11XrlBpsfNode[vtable > for XrlBpsfNode]+0x188): undefined reference to `non-virtual thunk to > XrlBpsfNode::bpsf_0_1_print_hello_world_and_msg(std::basic_string std::char_traits, std::allocator > const&, > std::basic_string, std::allocator > >&)' > collect2: ld returned 1 exit status > make: *** [xorp_bpsf] Error 1 > > > I'm not sure what is causing this. Here are the xrl_bpsf_node.{hh,cc} files: > > #ifndef __BPSF_XRL_BPSF_NODE_HH__ > #define __BPSF_XRL_BPSF_NODE_HH__ > > #include "libxipc/xrl_std_router.hh" > #include "xrl/targets/bpsf_base.hh" > > class XrlBpsfNode : public XrlStdRouter, > public XrlBpsfTargetBase { > public: > XrlBpsfNode(EventLoop& eventloop, > const string& class_name, > const string& finder_hostname, > uint16_t finder_port); > ~XrlBpsfNode(); > /** > * Get a reference to the XrlRouter instance. > * > * @return a reference to the XrlRouter (@ref XrlRouter) instance. > */ > XrlRouter& xrl_router() { return *this; } > /** > * Startup the node operation. > * > * @return XORP_OK on success, otherwise XORP_ERROR. > */ > int startup(); > > int shutdown(); > > /** > * Test if the node processing is done. > * > * @return true if the node processing is done, otherwise false. > */ > bool is_done() const { return true; } > > > protected: > // > // XRL target methods > // > > /** > * Get name of Xrl Target > */ > XrlCmdError common_0_1_get_target_name( > // Output values, > string& name); > > /** > * Get version string from Xrl Target > */ > XrlCmdError common_0_1_get_version( > // Output values, > string& version); > > /** > * Get status of Xrl Target > */ > XrlCmdError common_0_1_get_status( > // Output values, > uint32_t& status, > string& reason); > > /** > * Request clean shutdown of Xrl Target > */ > XrlCmdError common_0_1_shutdown(); > > /** > * Enable/disable/start/stop Bpsf. > * > * @param enable if true, then enable Bpsf, otherwise disable it. > */ > XrlCmdError bpsf_0_1_enable_bpsf( > // Input values, > const bool& enable); > > XrlCmdError bpsf_0_1_start_bpsf(); > > XrlCmdError bpsf_0_1_stop_bpsf(); > > /** > * Set the peer's AS number. > * > * @param next_hop IPv4 nexthop. > */ > XrlCmdError bpsf_0_1_set_nexthop4( > // Input values, > const string& local_ip, > const uint32_t& local_port, > const string& peer_ip, > const uint32_t& peer_port, > const IPv4& next_hop); > > XrlCmdError bpsf_0_1_print_hello_world_and_msg( > // Input values, > const string& msg, > // Output values, > string& num); > > /** > * Enable/disable the Bpsf trace log for all operations. > * > * @param enable if true, then enable the trace log, otherwise disable it. > */ > XrlCmdError bpsf_0_1_enable_log_trace_all( > // Input values, > const bool& enable); > > }; > > #endif // __BPSF_XRL_BPSF_NODE_HH__ > > > ----------------- > > > > #include "bpsf_module.h" > > #include "libxorp/xorp.h" > //#include "libxorp/xlog.h" > //#include "libxorp/debug.h" > //#include "libxorp/ipvx.hh" > #include "libxorp/status_codes.h" > > #include "xrl_bpsf_node.hh" > > XrlBpsfNode::XrlBpsfNode(EventLoop& eventloop, > const string& class_name, > const string& finder_hostname, > uint16_t finder_port) > : XrlStdRouter(eventloop, class_name.c_str(), finder_hostname.c_str(), > finder_port), > XrlBpsfTargetBase(&xrl_router()) > { > printf("%s\n", "creating XrlBpsfNode"); > } > > XrlBpsfNode::~XrlBpsfNode() { > printf("%s\n", "deleting XrlBpsfNode"); > } > > int XrlBpsfNode::shutdown() { > printf("%s\n", "shutting down XrlBpsfNode"); > return (XORP_OK); > } > > int XrlBpsfNode::startup() { > printf("%s\n", "starting up XrlBpsfNode"); > return (XORP_OK); > } > > // > // XRL target methods > // > > /** > * Get name of Xrl Target > */ > XrlCmdError XrlBpsfNode::common_0_1_get_target_name( > // Output values, > string& name) > { > name = xrl_router().class_name(); > > return XrlCmdError::OKAY(); > } > > /** > * Get version string from Xrl Target > */ > XrlCmdError XrlBpsfNode::common_0_1_get_version( > // Output values, > string& version) > { > version = XORP_MODULE_VERSION; > > return XrlCmdError::OKAY(); > } > > /** > * Get status of Xrl Target > */ > XrlCmdError XrlBpsfNode::common_0_1_get_status( > // Output values, > uint32_t& status, > string& reason) > { > status = NULL; > reason = "testing protocol"; > > return XrlCmdError::OKAY(); > } > > /** > * Request clean shutdown of Xrl Target > */ > XrlCmdError XrlBpsfNode::common_0_1_shutdown() > { > string error_msg; > > if (shutdown() != XORP_OK) { > error_msg = c_format("Failed to shutdown Bpsf"); > return XrlCmdError::COMMAND_FAILED(error_msg); > } > > return XrlCmdError::OKAY(); > } > > /** > * Enable/disable/start/stop Bpsf. > * > * @param enable if true, then enable Bpsf, otherwise disable it. > */ > XrlCmdError XrlBpsfNode::bpsf_0_1_enable_bpsf( > // Input values, > const bool& enable) > { > printf("%s\n", enable ? "enabling bpsf" : "disabling bpsf"); > return XrlCmdError::OKAY(); > } > > XrlCmdError XrlBpsfNode::bpsf_0_1_start_bpsf() > { > // XLOG_UNFINISHED(); > printf("%s\n", "starting up XrlBpsfNode xrl"); > > return XrlCmdError::OKAY(); > } > > XrlCmdError XrlBpsfNode::bpsf_0_1_stop_bpsf() { > // XLOG_UNFINISHED(); > > printf("%s\n", "stopping XrlBpsfNode"); > return XrlCmdError::OKAY(); > } > > /** > * Pure-virtual function that needs to be implemented to: > * > * Set the peer's AS number. > * > * @param next_hop IPv4 nexthop. > */ > XrlCmdError bpsf_0_1_set_nexthop4( > // Input values, > const string& local_ip, > const uint32_t& local_port, > const string& peer_ip, > const uint32_t& peer_port, > const IPv4& next_hop) { > printf("%s: %s %d %s %d %s \n", "setting nexthop now...", > local_ip.c_str(), local_port, peer_ip.c_str(), > peer_port, next_hop.str().c_str()); > return XrlCmdError::OKAY(); > } > > XrlCmdError bpsf_0_1_print_hello_world_and_msg( > // Input values, > const string& msg, > // Output values, > string& num) { > printf("%s: %s\n", "hello world", msg.c_str()); > num = "return message from bpsf_0_1_print_hello_world_and_msg"; > return XrlCmdError::OKAY(); > } > > /** > * Enable/disable the Bpsf trace log for all operations. > * > * @param enable if true, then enable the trace log, otherwise disable it. > */ > XrlCmdError XrlBpsfNode::bpsf_0_1_enable_log_trace_all( > // Input values, > const bool& enable) > { > printf("%s\n", enable ? "enabling bpsf logging" : "disabling bpsf logging"); > > return XrlCmdError::OKAY(); > } > > > I am using xorp-1.6 compiled from source on Linux kernel > 2.6.20.3-ubuntu1 x86_64, but I think I'm just making a stupid mistake > somewhere, has anyone had this problem or know how to fix it? > > Cheers, > Victor > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at ICSI.Berkeley.EDU Tue Jan 27 02:56:26 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 27 Jan 2009 02:56:26 -0800 Subject: [Xorp-hackers] About STCPRequestHandler In-Reply-To: <56f9e0990901182208t7c76c9c8ge9862ddf3260583c@mail.gmail.com> References: <56f9e0990901182208t7c76c9c8ge9862ddf3260583c@mail.gmail.com> Message-ID: <200901271056.n0RAuQms000879@fruitcake.ICSI.Berkeley.EDU> ??? wrote: > Hi, > > When I have not entered anything in the xorpsh for a little long > time(about 3 minutes), xorpsh and xorp_rtrmgr will give me a error > message, like following. > But I can still use xorpsh, and it works very good. I found a timeout > timer in the STCPRequestHandler class, in xrl_pf_stcp.cc/hh, the timer > is set as 3 minutes. > That is reason? > > My OS is debian, linux 2.6.26, the version of Xorp is 1.6. > > [ 2009/01/19 14:05:14 ERROR xorpsh:12519 XRL +373 xrl_pf_stcp.cc die > ] STCPRequestHandler died: life timer expired This timeout shouldn't happen under normal circumstances. Please provide your XORP config and the rest of the log output. Pavlin > > -- > Best Regard > Xiaoshuai Yang > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at ICSI.Berkeley.EDU Tue Jan 27 03:10:01 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 27 Jan 2009 03:10:01 -0800 Subject: [Xorp-hackers] Template files In-Reply-To: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> References: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> Message-ID: <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> Victor Faion wrote: > Hello, > > Just wanted some help regarding template files. I was trying to write > a simple template file for a process that has a function that just > takes in an input message (string), modifies it and gives it back to > the callback function, but I didn't know how. Or are the template > files supposed to be automatically generated? You need to write them by hand. Your template file should look like the following. The string to be set in the user config is "my-string", and the XRL itself is "myproto/myproto/0.1/set_mystring?mystring:txt=$(@)" Hope that helps, Pavlin protocols { myproto { targetname: txt = "myproto"; my-string: txt; } } protocols { myproto { %help: short "Configure myproto"; %modinfo: provides myproto; /* XXX: uncomment if the FEA must be started first %modinfo: depends fea; */ %modinfo: path "myproto/xorp_myproto"; %modinfo: default_targetname "myproto"; %modinfo: status_method xrl "$(myproto.targetname)/common/0.1/get_status->status:u32&reason:txt"; %modinfo: shutdown_method xrl "$(myproto.targetname)/common/0.1/shutdown"; %mandatory: $(@.targetname); /* XXX: The optional XRL that will be called on startup %activate: xrl "$(myproto.targetname)/myproto/0.1/start_myproto"; */ targetname { %user-hidden: "XRL target name"; %help: short "XRL target name"; %set:; } my-string { %help: short "Set my string"; %set: xrl "$(myproto.targetname)/myproto/0.1/set_mystring?mystring:txt=$(@)"; } } } From vfaion at gmail.com Tue Jan 27 11:23:07 2009 From: vfaion at gmail.com (Victor Faion) Date: Tue, 27 Jan 2009 19:23:07 +0000 Subject: [Xorp-hackers] Template files In-Reply-To: <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> References: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> Message-ID: <38f1dbe80901271123h749ce9a7of0b1716824ee102@mail.gmail.com> Thank you, this has made it work. I think I misunderstood the point of the template files, I thought all the functions in the protocol had to be described in the template, but it's just the ones that are used for configuration when you start rtrmgr (I think). On Tue, Jan 27, 2009 at 11:10, Pavlin Radoslavov wrote: > Victor Faion wrote: > >> Hello, >> >> Just wanted some help regarding template files. I was trying to write >> a simple template file for a process that has a function that just >> takes in an input message (string), modifies it and gives it back to >> the callback function, but I didn't know how. Or are the template >> files supposed to be automatically generated? > > You need to write them by hand. > > Your template file should look like the following. The string to be > set in the user config is "my-string", and the XRL itself is > "myproto/myproto/0.1/set_mystring?mystring:txt=$(@)" > > Hope that helps, > Pavlin > > protocols { > myproto { > targetname: txt = "myproto"; > my-string: txt; > } > } > > protocols { > myproto { > %help: short "Configure myproto"; > %modinfo: provides myproto; > /* XXX: uncomment if the FEA must be started first > %modinfo: depends fea; > */ > %modinfo: path "myproto/xorp_myproto"; > %modinfo: default_targetname "myproto"; > %modinfo: status_method xrl "$(myproto.targetname)/common/0.1/get_status->status:u32&reason:txt"; > %modinfo: shutdown_method xrl "$(myproto.targetname)/common/0.1/shutdown"; > > %mandatory: $(@.targetname); > > /* XXX: The optional XRL that will be called on startup > %activate: xrl "$(myproto.targetname)/myproto/0.1/start_myproto"; > */ > > targetname { > %user-hidden: "XRL target name"; > %help: short "XRL target name"; > %set:; > } > > my-string { > %help: short "Set my string"; > %set: xrl "$(myproto.targetname)/myproto/0.1/set_mystring?mystring:txt=$(@)"; > } > } > } > From pavlin at ICSI.Berkeley.EDU Tue Jan 27 12:31:05 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 27 Jan 2009 12:31:05 -0800 Subject: [Xorp-hackers] Template files In-Reply-To: <38f1dbe80901271123h749ce9a7of0b1716824ee102@mail.gmail.com> References: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80901271123h749ce9a7of0b1716824ee102@mail.gmail.com> Message-ID: <200901272031.n0RKV5Mv007280@fruitcake.ICSI.Berkeley.EDU> > Thank you, this has made it work. I think I misunderstood the point of > the template files, I thought all the functions in the protocol had to > be described in the template, but it's just the ones that are used for > configuration when you start rtrmgr (I think). The template files are the glue between user config and the particular XRLs used to change the config. state in the protocol. Hence only the XRLs used to (re)configure the protocol need to be exposed in the *.tp file. Regards, Pavlin From vfaion at gmail.com Tue Jan 27 12:49:04 2009 From: vfaion at gmail.com (Victor Faion) Date: Tue, 27 Jan 2009 20:49:04 +0000 Subject: [Xorp-hackers] Template files In-Reply-To: <200901272031.n0RKV5Mv007280@fruitcake.ICSI.Berkeley.EDU> References: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80901271123h749ce9a7of0b1716824ee102@mail.gmail.com> <200901272031.n0RKV5Mv007280@fruitcake.ICSI.Berkeley.EDU> Message-ID: <38f1dbe80901271249u73077e6w21644a23e7ed5268@mail.gmail.com> OK, I understood it correctly then. If a process relies on another process for all of its configuration and has no state itself, could you have an empty template file? Maybe something like this: protocols { empty-protocol { %help: short "No configurable options"; } } Victor On Tue, Jan 27, 2009 at 20:31, Pavlin Radoslavov wrote: >> Thank you, this has made it work. I think I misunderstood the point of >> the template files, I thought all the functions in the protocol had to >> be described in the template, but it's just the ones that are used for >> configuration when you start rtrmgr (I think). > > The template files are the glue between user config and the > particular XRLs used to change the config. state in the protocol. > Hence only the XRLs used to (re)configure the protocol need to be > exposed in the *.tp file. > > Regards, > Pavlin > From pavlin at ICSI.Berkeley.EDU Tue Jan 27 13:03:42 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 27 Jan 2009 13:03:42 -0800 Subject: [Xorp-hackers] Template files In-Reply-To: <38f1dbe80901271249u73077e6w21644a23e7ed5268@mail.gmail.com> References: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80901271123h749ce9a7of0b1716824ee102@mail.gmail.com> <200901272031.n0RKV5Mv007280@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80901271249u73077e6w21644a23e7ed5268@mail.gmail.com> Message-ID: <200901272103.n0RL3gFZ011776@fruitcake.ICSI.Berkeley.EDU> Victor Faion wrote: > OK, I understood it correctly then. If a process relies on another > process for all of its configuration and has no state itself, could > you have an empty template file? Maybe something like this: > > protocols { > empty-protocol { > %help: short "No configurable options"; > } > } Yes, but in practice the "empty" template file is slightly more complex, because it needs to include info how the rtrmgr will start "empty-protocol", etc (assuming the startup/shutdown is managed by the rtrmgr). See etc/templates/rib.tp for such "almost empty" template file (you need ignore the "policy {} section there). Pavlin > Victor > > > On Tue, Jan 27, 2009 at 20:31, Pavlin Radoslavov > wrote: > >> Thank you, this has made it work. I think I misunderstood the point of > >> the template files, I thought all the functions in the protocol had to > >> be described in the template, but it's just the ones that are used for > >> configuration when you start rtrmgr (I think). > > > > The template files are the glue between user config and the > > particular XRLs used to change the config. state in the protocol. > > Hence only the XRLs used to (re)configure the protocol need to be > > exposed in the *.tp file. > > > > Regards, > > Pavlin > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From vfaion at gmail.com Tue Jan 27 13:18:30 2009 From: vfaion at gmail.com (Victor Faion) Date: Tue, 27 Jan 2009 21:18:30 +0000 Subject: [Xorp-hackers] Template files In-Reply-To: <200901272103.n0RL3gFZ011776@fruitcake.ICSI.Berkeley.EDU> References: <38f1dbe80901220956q1aeecfe5t5f2248b8baeeedb0@mail.gmail.com> <200901271110.n0RBA1W7001948@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80901271123h749ce9a7of0b1716824ee102@mail.gmail.com> <200901272031.n0RKV5Mv007280@fruitcake.ICSI.Berkeley.EDU> <38f1dbe80901271249u73077e6w21644a23e7ed5268@mail.gmail.com> <200901272103.n0RL3gFZ011776@fruitcake.ICSI.Berkeley.EDU> Message-ID: <38f1dbe80901271318h3735760bva9aca2735fa81935@mail.gmail.com> Oops forgot about that, basically I took out the my-string section from the template you gave me originally. It all makes sense now :-) On Tue, Jan 27, 2009 at 21:03, Pavlin Radoslavov wrote: > Victor Faion wrote: > >> OK, I understood it correctly then. If a process relies on another >> process for all of its configuration and has no state itself, could >> you have an empty template file? Maybe something like this: >> >> protocols { >> empty-protocol { >> %help: short "No configurable options"; >> } >> } > > Yes, but in practice the "empty" template file is slightly more > complex, because it needs to include info how the rtrmgr will start > "empty-protocol", etc (assuming the startup/shutdown is managed by > the rtrmgr). > > See etc/templates/rib.tp for such "almost empty" template file (you > need ignore the "policy {} section there). > > Pavlin > >> Victor >> >> >> On Tue, Jan 27, 2009 at 20:31, Pavlin Radoslavov >> wrote: >> >> Thank you, this has made it work. I think I misunderstood the point of >> >> the template files, I thought all the functions in the protocol had to >> >> be described in the template, but it's just the ones that are used for >> >> configuration when you start rtrmgr (I think). >> > >> > The template files are the glue between user config and the >> > particular XRLs used to change the config. state in the protocol. >> > Hence only the XRLs used to (re)configure the protocol need to be >> > exposed in the *.tp file. >> > >> > Regards, >> > Pavlin >> > >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From vfaion at gmail.com Fri Jan 30 09:24:37 2009 From: vfaion at gmail.com (Victor Faion) Date: Fri, 30 Jan 2009 17:24:37 +0000 Subject: [Xorp-hackers] Events and sockets in XORP Message-ID: <38f1dbe80901300924i20661ac3uf649aa66af8b2267@mail.gmail.com> Hello, I was trying to use XORP to create an application layer protocol with the routers sending messages to each other over TCP sockets. I created a XORP process following the guide about static routes, but I still don't understand some things such as when functions of the process get called. For example in the main function of the process there is an event loop. How do the events correspond to functions called, and how do you generate events? For example how would you trigger a function call on receipt of a message? Also a more general question, I am trying to use the socket library provided by XORP and run this code on top of XORP, but I'm not sure if I should be making a XORP process to do this or is there another way of using the XORP socket library? (I also wanted to extract the shortest paths calculated by OSPF and use these to open socket connections instead of sending packets.) Victor From pavlin at ICSI.Berkeley.EDU Sat Jan 31 04:58:26 2009 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sat, 31 Jan 2009 04:58:26 -0800 Subject: [Xorp-hackers] Events and sockets in XORP In-Reply-To: <38f1dbe80901300924i20661ac3uf649aa66af8b2267@mail.gmail.com> References: <38f1dbe80901300924i20661ac3uf649aa66af8b2267@mail.gmail.com> Message-ID: <200901311258.n0VCwQ9a025468@fruitcake.ICSI.Berkeley.EDU> > I was trying to use XORP to create an application layer protocol with > the routers sending messages to each other over TCP sockets. I created > a XORP process following the guide about static routes, but I still > don't understand some things such as when functions of the process get > called. For example in the main function of the process there is an > event loop. How do the events correspond to functions called, and how > do you generate events? For example how would you trigger a function > call on receipt of a message? Also a more general question, I am > trying to use the socket library provided by XORP and run this code on > top of XORP, but I'm not sure if I should be making a XORP process to > do this or is there another way of using the XORP socket library? (I > also wanted to extract the shortest paths calculated by OSPF and use > these to open socket connections instead of sending packets.) XORP processes are event-driven: you use the eventloop to register callbacks for various events: timer expires, socket ready for I/O, etc. In other words, the functions/methods in your process are event handlers. It is very important that those handlers return promptly to the eventloop, otherwise the process operation will be disturbed (background XRL timers might timeout, etc). Unlike other routing processes, the static routes process just pushes the user configured routes, and doesn't send/receive any control traffic. You might want to have a look at RIP/RIPng for example which uses UDP control packets. To send/receive TCP you can do it via the FEA so you don't have to deal with sockets, etc. Basically, you need to use the xrl/interfaces/socket4.xif XRL API to register with the FEA to send/receive TCP. Then in your protocol you need to implement the receiving (target) side of socket4_user.xif . The XRL library itself will take care of the rest: on reception it will call the appropriate socket4_user.xif method. Once you process the event, just return back to the eventloop. If you have transmission timers that are triggered periodically, just call the "send" XRL (socket4.xif) and return back to the eventloop. The handlers for those timers are scheduled by using the EventLoop API (e.g., new_oneoff_after(), etc). If you need to use raw IP packets, then you can use the fea_rawpkt4.xif / fea_rawpkt4_client.xif API. Of course, you can create and use your own sockets, but then it is up to you to deal with the extra details: add the socket file descriptor to the eventoop (EventLoop::add_ioevent_cb()), buffer the received data, etc. Hope that helps, Pavlin P.S. I cannot answer the OSPF-related question because I am not familiar with the OSPF implementation details.