From FoObArf00@netscape.net Thu Dec 2 17:42:47 2004 From: FoObArf00@netscape.net (FoObArf00@netscape.net) Date: Thu, 02 Dec 2004 12:42:47 -0500 Subject: [Xorp-users] Multicast advice Message-ID: <10116D53.1F65FB78.023DF18B@netscape.net> Hello, I have a linux PPP server with multiple clients connecting to it. I have a multicast application sending data on client A and I have a receiving multicast application on clients B and C. The ppp server receives the multicast traffic from client A but doesnt forward it to client B or C. Can anyone point me on the right direction on how to accomplish this? I have tried xorp (pim-sm) on the PPP server but no luck. ip_forward is on and rp_filter is off on all interfaces. When I ran xorp mc_forwarding was on all interfaces. A---->PPP SERVER<-----B /\ | C Thanks in advanced. __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp From pavlin@icir.org Fri Dec 3 22:35:12 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Dec 2004 14:35:12 -0800 Subject: [Xorp-users] Multicast advice In-Reply-To: Message from FoObArf00@netscape.net of "Thu, 02 Dec 2004 12:42:47 EST." <10116D53.1F65FB78.023DF18B@netscape.net> Message-ID: <200412032235.iB3MZCWw006848@possum.icir.org> > I have a linux PPP server with multiple clients connecting to it. > I have a multicast application sending data on client A and I have > a receiving multicast application on clients B and C. The ppp > server receives the multicast traffic from client A but doesnt > forward it to client B or C. Can anyone point me on the right > direction on how to accomplish this? I have tried xorp (pim-sm) > on the PPP server but no luck. ip_forward is on and rp_filter is > off on all interfaces. When I ran xorp mc_forwarding was on all > interfaces. > > > A---->PPP SERVER<-----B > /\ > | > C A quick suggestion, because it is often a source of an error: can you verify that the multicast packets originated by A have TTL > 1. If the TTL is not the problem, then make sure that: 1. Your PIM-SM router has the RP info. In your setup, the PPP SERVER probably should be the RP itself, so make sure that the "show pim rps" CLI command contains that info. The simplest way to do this is to use a static RP. Otherwise, if you use the Bootstrap mechanism, on startup you may have to wait on the order of 1-2 minutes until the BSR election happens and the Cand-RP set is distributed. Of course, in your setup you would have to configure the PPP Server as both a Cand-BSR and Cand-RP. 2. The PIM-SM router has the Join info from B and C. Use command "show pim join" to verify that. In particular, look for the "WC" entry for the (*,G) group, and for the "SG" entry for source A. 3. If the above info is correct, then make sure that "show pim mfc" shows the multicast-forwarding entry that PIM-SM has installed in the kernel. That entry should have iif = the interface toward A, and oifs set toward B and C. 4. Finally, if the "show pim mfc" output is correct, verify that the kernel itself contains that info. On Linux, the command is: cat /proc/net/ip_mr_cache If the above info doesn't help, then please run XORP with all traceoptions enabled, and send me your XORP configuration file and the XORP log message. You don't have to CC the list, especially if that information may be sensitive. Regards, Pavlin From berni@birkenwald.de Sat Dec 4 00:37:03 2004 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sat, 04 Dec 2004 01:37:03 +0100 Subject: [Xorp-users] MLD on FreeBSD Message-ID: <1102120623.11075.15.camel@cholera> Hi, I'm desperately trying to have my gateway IPv6 multicast forwarding enabled having tested ecmh, pim6sd and now xorp (which seems to be the best approach) It is a FreeBSD 5.3-STABLE box (CVSUPed Nov 24) with the current xorp CVS (Nov 29) with the following interfaces vr0: Ethernet to clients tun0: PPPoE to DSL provider gif0: IPv6-in-IPv4 unicast tunnel gif1: IPv6-in-IPv4 multicast tunnel xorp itself and PIM seems to work quite fine, I can see the neighborship on the Cisco on the other side of gif1. My problems are concerning MLD. I can see MLDv1 listener queries sent by xorp on the wire (and they are nicely recorded in the trace) [ 2004/12/04 01:31:14 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY from fe80::240:63ff:fed3:e0f0 to ff02::1 [ 2004/12/04 01:31:14 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY from fe80::240:63ff:fed3:e0f0 to ff02::1 but when I'm subscribing a multicast group on a client directly connected on vr0 nothing happens. I can see the MLDv1 listener report in tcpdump on the xorp-host, but there is no logmessage and no group is visible in xorpsh. Setting the interface to promisc mode did not help. Any tricks I missed? I've saved the configuration at http://www.birkenwald.de/~berni/tmp/xorp.txt Thanks in advance Bernhard From hozer@hozed.org Sat Dec 4 01:15:48 2004 From: hozer@hozed.org (Troy Benjegerdes) Date: Fri, 3 Dec 2004 19:15:48 -0600 Subject: [Xorp-users] OpenBSD-3.6 segfaults Message-ID: <20041204011548.GG17697@kalmia.hozed.org> I am attempting to build xorp-1.0 on openbsd-3.6. I had some build failures in bgp/harness, but I'm failing some 'make test' tests with segfaults, and xorp_rtrmgr is segfaulting on startup. Any ideas? I just want to run PIM-SM.. can I do that without xorp_rtrmgr? bash-3.00# gdb bin/xorp_rtrmgr xorp_rtrmgr.core GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd3.6"... Core was generated by `xorp_rtrmgr'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libcrypto.so.11.0...done. Loaded symbols for /usr/lib/libcrypto.so.11.0 Reading symbols from /usr/lib/libstdc++.so.33.0...done. Loaded symbols for /usr/lib/libstdc++.so.33.0 Reading symbols from /usr/lib/libm.so.2.0...done. Loaded symbols for /usr/lib/libm.so.2.0 Reading symbols from /usr/lib/libc.so.34.1...done. Loaded symbols for /usr/lib/libc.so.34.1 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x1c10a1d9 in XrlError::error_code (this=0x4d) at xrl_error.cc:107 107 return _errlet->error_code(); (gdb) bt #0 0x1c10a1d9 in XrlError::error_code (this=0x4d) at xrl_error.cc:107 #1 0x1c0395ad in operator!= (e1=@0x4d, e2=@0x3c037648) at ../libxipc/xrl_error.hh:239 #2 0x1c13ddba in XrlFinderV0p2Client::unmarshall_register_finder_client ( this=0xcfbe2820, e=@0x4d, a=0x3c1566d0, cb= {_M_ptr = 0x3c1566c0, _M_counter = 77}) at finder_xif.cc:41 #3 0x1c14463f in XorpMemberCallback2B1, __default_alloc_template > const *> > >::dispatch (this=0x3c15e3e0, a1=@0xcfbe2654, a2=0x3c1566d0) at ../libxorp/callback_nodebug.hh:4930 #4 0x1c0cf248 in FinderMessengerBase::dispatch_xrl_response (this=0x3c144e00, seqno=1001, xe=@0xcfbe2654, args=0x3c1566d0) at finder_messenger.cc:51 #5 0x1c0d5caf in FinderTcpMessenger::read_event (this=0x3c144e00, errval=0, data=0x3c152f10 "Finder 0.2\nMsgType r\nSeqNo 1001\nMsgData 100 / \nout_cookie:txt=3b1ef21747f8a238", data_bytes=78) at finder_tcp_messenger.cc:69 #6 0x1c0d20d1 in FinderTcpBase::read_callback (this=0x3c144e1c, ev=DATA, buffer=0x3c152f10 "Finder 0.2\nMsgType r\nSeqNo 1001\nMsgData 100 / \nout_cookie:txt=3b1ef21747f8a238", buffer_bytes=78, offset=78) at finder_tcp.cc:168 #7 0x1c0d3f2c in XorpMemberCallback4B0::dispatch ( this=0x3c1566b0, a1=DATA, a2=0x3c152f10 "Finder 0.2\nMsgType r\nSeqNo 1001\nMsgData 100 / \nout_cookie:txt=3b1ef21747f8a238", a3=78, a4=78) at ../libxorp/callback_nodebug.hh:8968 ---Type to continue, or q to quit--- #8 0x1c14d30e in AsyncFileReader::BufferInfo::dispatch_callback ( this=0xcfbe66fc, e=DATA) at asyncio.hh:183 #9 0x1c14b9a6 in AsyncFileReader::complete_transfer (this=0x3c144e2c, err=0, done=78) at asyncio.cc:107 #10 0x1c14b88c in AsyncFileReader::read (this=0x3c144e2c, fd=6, m=SEL_RD) at asyncio.cc:88 #11 0x1c14ca40 in XorpMemberCallback2B0::dispatch (this=0x3c1566d0, a1=6, a2=SEL_RD) at ../libxorp/callback_nodebug.hh:4638 #12 0x1c162582 in SelectorList::Node::run_hooks (this=0x3c09d0d8, m=SEL_RD, fd=6) at selector.cc:98 #13 0x1c160ed2 in SelectorList::select (this=0xcfbde4b0, timeout=0xcfbe899c) at selector.cc:254 #14 0x1c14f225 in EventLoop::run (this=0xcfbde4b0) at eventloop.cc:66 #15 0x1c1069df in wait_until_xrl_router_is_ready (eventloop=@0xcfbecb58, xrl_router=@0xcfbeec50) at xrl_router.cc:547 #16 0x1c025e0e in Rtrmgr::run (this=0xcfbf0bf4) at main_rtrmgr.cc:264 #17 0x1c0278d0 in main (argc=2, argv=0xcfbf0cf4) at main_rtrmgr.cc:490 (gdb) (gdb) From pavlin@icir.org Sat Dec 4 01:23:30 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Dec 2004 17:23:30 -0800 Subject: [Xorp-users] MLD on FreeBSD In-Reply-To: Message from Bernhard Schmidt of "Sat, 04 Dec 2004 01:37:03 +0100." <1102120623.11075.15.camel@cholera> Message-ID: <200412040123.iB41NUVV008134@possum.icir.org> > Hi, > > I'm desperately trying to have my gateway IPv6 multicast forwarding > enabled having tested ecmh, pim6sd and now xorp (which seems to be the > best approach) > > It is a FreeBSD 5.3-STABLE box (CVSUPed Nov 24) with the current xorp > CVS (Nov 29) with the following interfaces > > vr0: Ethernet to clients > tun0: PPPoE to DSL provider > gif0: IPv6-in-IPv4 unicast tunnel > gif1: IPv6-in-IPv4 multicast tunnel > > xorp itself and PIM seems to work quite fine, I can see the neighborship > on the Cisco on the other side of gif1. My problems are concerning MLD. > I can see MLDv1 listener queries sent by xorp on the wire (and they are > nicely recorded in the trace) > > [ 2004/12/04 01:31:14 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY > from fe80::240:63ff:fed3:e0f0 to ff02::1 > [ 2004/12/04 01:31:14 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY > from fe80::240:63ff:fed3:e0f0 to ff02::1 > > but when I'm subscribing a multicast group on a client directly > connected on vr0 nothing happens. I can see the MLDv1 listener report in > tcpdump on the xorp-host, but there is no logmessage and no group is > visible in xorpsh. Setting the interface to promisc mode did not help. > > Any tricks I missed? I've saved the configuration at > > http://www.birkenwald.de/~berni/tmp/xorp.txt Bernhard, Your config file seems fine. Could you confirm that if you run pim6sd, then pim6sd is able to see the MLDv1 listener reports on vr0. This test can be used to narrow the problem: if pim6sd is fine, then the problem is definitely in XORP. Further, can you run a MLDv1 receiver on the other side of the gif1 tunnel with XORP running on the router, and check if XORP can see the MLD messages. This test can be used to narrow the problem whether it is specific to the vr0 interface only. Thanks, Pavlin From pavlin@icir.org Sat Dec 4 01:34:03 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Dec 2004 17:34:03 -0800 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: Message from Troy Benjegerdes of "Fri, 03 Dec 2004 19:15:48 CST." <20041204011548.GG17697@kalmia.hozed.org> Message-ID: <200412040134.iB41Y371008227@possum.icir.org> > I am attempting to build xorp-1.0 on openbsd-3.6. I had some build > failures in bgp/harness, but I'm failing some 'make test' tests with > segfaults, and xorp_rtrmgr is segfaulting on startup. > > Any ideas? I just want to run PIM-SM.. can I do that without > xorp_rtrmgr? Troy, If you want to run PIM-SM on OpenBSD-3.6, currently you cannot do it, because the vanilla 3.6 kernel doesn't have the PIM-SM support. You can try some of the patches available from http://www.icir.org/pavlin/.private/openbsd/ or http://www.icir.org/pavlin/.private/openbsd/patches/ but those are against OpenBSD-current, so there is no guarantee they will even apply cleanly for 3.6. FYI, most of stuff in the incremental patches from the second URL has been applied to the OpenBSD-current source tree. The last (most important) patch is pending review from the OpenBSD folks. Hopefully, sometime soon it will be applied to the source tree, and will be part of the next OpenBSD release. Nevertheless, we will look into the coredump trace below. Thanks, Pavlin > bash-3.00# gdb bin/xorp_rtrmgr xorp_rtrmgr.core > GNU gdb 6.1 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-unknown-openbsd3.6"... > Core was generated by `xorp_rtrmgr'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/lib/libcrypto.so.11.0...done. > Loaded symbols for /usr/lib/libcrypto.so.11.0 > Reading symbols from /usr/lib/libstdc++.so.33.0...done. > Loaded symbols for /usr/lib/libstdc++.so.33.0 > Reading symbols from /usr/lib/libm.so.2.0...done. > Loaded symbols for /usr/lib/libm.so.2.0 > Reading symbols from /usr/lib/libc.so.34.1...done. > Loaded symbols for /usr/lib/libc.so.34.1 > Reading symbols from /usr/libexec/ld.so...done. > Loaded symbols for /usr/libexec/ld.so > #0 0x1c10a1d9 in XrlError::error_code (this=0x4d) at xrl_error.cc:107 > 107 return _errlet->error_code(); > (gdb) bt > #0 0x1c10a1d9 in XrlError::error_code (this=0x4d) at xrl_error.cc:107 > #1 0x1c0395ad in operator!= (e1=@0x4d, e2=@0x3c037648) > at ../libxipc/xrl_error.hh:239 > #2 0x1c13ddba in XrlFinderV0p2Client::unmarshall_register_finder_client > ( > this=0xcfbe2820, e=@0x4d, a=0x3c1566d0, cb= > {_M_ptr = 0x3c1566c0, _M_counter = 77}) at finder_xif.cc:41 > #3 0x1c14463f in XorpMemberCallback2B1 XrlError const &, XrlArgs *, ref_ptr &, basic_string, > __default_alloc_template > const *> > >::dispatch > (this=0x3c15e3e0, a1=@0xcfbe2654, a2=0x3c1566d0) > at ../libxorp/callback_nodebug.hh:4930 > #4 0x1c0cf248 in FinderMessengerBase::dispatch_xrl_response > (this=0x3c144e00, > seqno=1001, xe=@0xcfbe2654, args=0x3c1566d0) at > finder_messenger.cc:51 > #5 0x1c0d5caf in FinderTcpMessenger::read_event (this=0x3c144e00, > errval=0, > data=0x3c152f10 "Finder 0.2\nMsgType r\nSeqNo 1001\nMsgData 100 / > \nout_cookie:txt=3b1ef21747f8a238", data_bytes=78) at > finder_tcp_messenger.cc:69 > #6 0x1c0d20d1 in FinderTcpBase::read_callback (this=0x3c144e1c, > ev=DATA, > buffer=0x3c152f10 "Finder 0.2\nMsgType r\nSeqNo 1001\nMsgData 100 / > \nout_cookie:txt=3b1ef21747f8a238", buffer_bytes=78, offset=78) at > finder_tcp.cc:168 > #7 0x1c0d3f2c in XorpMemberCallback4B0 AsyncFileOperator::Event, unsigned char const *, unsigned int, unsigned > int>::dispatch ( > this=0x3c1566b0, a1=DATA, > a2=0x3c152f10 "Finder 0.2\nMsgType r\nSeqNo 1001\nMsgData 100 / > \nout_cookie:txt=3b1ef21747f8a238", a3=78, a4=78) at > ../libxorp/callback_nodebug.hh:8968 > ---Type to continue, or q to quit--- > #8 0x1c14d30e in AsyncFileReader::BufferInfo::dispatch_callback ( > this=0xcfbe66fc, e=DATA) at asyncio.hh:183 > #9 0x1c14b9a6 in AsyncFileReader::complete_transfer (this=0x3c144e2c, > err=0, > done=78) at asyncio.cc:107 > #10 0x1c14b88c in AsyncFileReader::read (this=0x3c144e2c, fd=6, > m=SEL_RD) > at asyncio.cc:88 > #11 0x1c14ca40 in XorpMemberCallback2B0 SelectorMask>::dispatch (this=0x3c1566d0, a1=6, a2=SEL_RD) > at ../libxorp/callback_nodebug.hh:4638 > #12 0x1c162582 in SelectorList::Node::run_hooks (this=0x3c09d0d8, > m=SEL_RD, > fd=6) at selector.cc:98 > #13 0x1c160ed2 in SelectorList::select (this=0xcfbde4b0, > timeout=0xcfbe899c) > at selector.cc:254 > #14 0x1c14f225 in EventLoop::run (this=0xcfbde4b0) at eventloop.cc:66 > #15 0x1c1069df in wait_until_xrl_router_is_ready (eventloop=@0xcfbecb58, > xrl_router=@0xcfbeec50) at xrl_router.cc:547 > #16 0x1c025e0e in Rtrmgr::run (this=0xcfbf0bf4) at main_rtrmgr.cc:264 > #17 0x1c0278d0 in main (argc=2, argv=0xcfbf0cf4) at main_rtrmgr.cc:490 > (gdb) > (gdb) > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From berni@birkenwald.de Sat Dec 4 01:55:27 2004 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sat, 04 Dec 2004 02:55:27 +0100 Subject: [Xorp-users] MLD on FreeBSD In-Reply-To: <200412040123.iB41NUVV008134@possum.icir.org> References: <200412040123.iB41NUVV008134@possum.icir.org> Message-ID: <1102125327.11075.33.camel@cholera> Hi, > > xorp itself and PIM seems to work quite fine, I can see the neighborship > > on the Cisco on the other side of gif1. My problems are concerning MLD. > > I can see MLDv1 listener queries sent by xorp on the wire (and they are > > nicely recorded in the trace) > > > > [ 2004/12/04 01:31:14 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY > > from fe80::240:63ff:fed3:e0f0 to ff02::1 > > [ 2004/12/04 01:31:14 TRACE xorp_mld MLD6IGMP ] TX MLD_LISTENER_QUERY > > from fe80::240:63ff:fed3:e0f0 to ff02::1 > > > > but when I'm subscribing a multicast group on a client directly > > connected on vr0 nothing happens. I can see the MLDv1 listener report in > > tcpdump on the xorp-host, but there is no logmessage and no group is > > visible in xorpsh. Setting the interface to promisc mode did not help. > > > > Any tricks I missed? I've saved the configuration at > > > > http://www.birkenwald.de/~berni/tmp/xorp.txt > Your config file seems fine. Could you confirm that if you run > pim6sd, then pim6sd is able to see the MLDv1 listener reports on > vr0. This test can be used to narrow the problem: if pim6sd is fine, > then the problem is definitely in XORP. Suck suck suck, I always find problems shortly after posting to mailing lists. Sorry for that :-) The problem seems to be the firewall... I'm using pf, when I disable it mld is able to catch up the requests. But, the only block rules in the configuration are associated to tun0, and all block rules have logging enabled. There is no drop recorded though, so this seems to be a side effect. And guess what, I can receive multicast. But due to disabled NAT no IPv4, so I think this needs more work :-) Only problem is, connection is lousy. I have ADSL with 3Mbps downstream, listening to some french radio at ff1e::8888 with about 300kbps... hickups constantly. Free bandwidth from the DSL termination equipment to the Cisco with the tunnel is more than 50Mbps. Yesterday I hooked up with the notebook directly on the Cisco and the audio was sane, so I guess the connection there should be good as well. CPU load on the router is good... any ideas or experiences? Bernhard From berni@birkenwald.de Sat Dec 4 02:24:41 2004 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sat, 04 Dec 2004 03:24:41 +0100 Subject: [Xorp-users] MLD on FreeBSD In-Reply-To: <1102125327.11075.33.camel@cholera> References: <200412040123.iB41NUVV008134@possum.icir.org> <1102125327.11075.33.camel@cholera> Message-ID: <1102127082.11075.35.camel@cholera> Hi, > The problem seems to be the firewall... I'm using pf, when I disable it > mld is able to catch up the requests. But, the only block rules in the > configuration are associated to tun0, and all block rules have logging > enabled. There is no drop recorded though, so this seems to be a side > effect. Just enabling the firewall (without any ruleset, so "pass all") also causes this behaviour, so this is most probably a bug in the pf-implementation. I'll post something on the appropriate FreeBSD mailinglist tomorrow, perhaps someone there has a clue. Bernhard From hozer@hozed.org Sat Dec 4 04:06:48 2004 From: hozer@hozed.org (Troy Benjegerdes) Date: Fri, 3 Dec 2004 22:06:48 -0600 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: <200412040134.iB41Y371008227@possum.icir.org> References: <20041204011548.GG17697@kalmia.hozed.org> <200412040134.iB41Y371008227@possum.icir.org> Message-ID: <20041204040648.GH17697@kalmia.hozed.org> On Fri, Dec 03, 2004 at 05:34:03PM -0800, Pavlin Radoslavov wrote: > > I am attempting to build xorp-1.0 on openbsd-3.6. I had some build > > failures in bgp/harness, but I'm failing some 'make test' tests with > > segfaults, and xorp_rtrmgr is segfaulting on startup. > > > > Any ideas? I just want to run PIM-SM.. can I do that without > > xorp_rtrmgr? > > Troy, > > If you want to run PIM-SM on OpenBSD-3.6, currently you cannot do > it, because the vanilla 3.6 kernel doesn't have the PIM-SM support. > You can try some of the patches available from > http://www.icir.org/pavlin/.private/openbsd/ > or > http://www.icir.org/pavlin/.private/openbsd/patches/ > My next thought was to try the livecd... which I do have booted on my router machine now, but it seems like xorpsh is somewhat unhappy... I get errors like: Xorp> show ERROR: Command is not executable I seem to have some functionality in "configure" mode. Is there some quick way I can bring up PIM-SM, and see if it works? Thanks. From pavlin@icir.org Sat Dec 4 10:08:59 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 04 Dec 2004 02:08:59 -0800 Subject: [Xorp-users] MLD on FreeBSD In-Reply-To: Message from Bernhard Schmidt of "Sat, 04 Dec 2004 02:55:27 +0100." <1102125327.11075.33.camel@cholera> Message-ID: <200412041009.iB4A8xcI011143@possum.icir.org> > Only problem is, connection is lousy. I have ADSL with 3Mbps downstream, > listening to some french radio at ff1e::8888 with about 300kbps... > hickups constantly. Free bandwidth from the DSL termination equipment to > the Cisco with the tunnel is more than 50Mbps. Yesterday I hooked up > with the notebook directly on the Cisco and the audio was sane, so I > guess the connection there should be good as well. > > CPU load on the router is good... any ideas or experiences? Do you have the option to attach a receiver right before the XORP router? If yes, this can help you in finding-out whether the loss happens before the traffic reaches the XORP router, or whether the XORP router is lossy. Regards, Pavlin From pavlin@icir.org Sat Dec 4 10:24:48 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 04 Dec 2004 02:24:48 -0800 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: Message from Troy Benjegerdes of "Fri, 03 Dec 2004 22:06:48 CST." <20041204040648.GH17697@kalmia.hozed.org> Message-ID: <200412041024.iB4AOmE3011256@possum.icir.org> > My next thought was to try the livecd... which I do have booted on my > router machine now, but it seems like xorpsh is somewhat unhappy... > > I get errors like: > > Xorp> show > ERROR: > Command is not executable In operational mode, the command "show" itself is incomplete hence you get the above error. If you press or '?' after a command, you may be able to see the list of sub-commands that can be used. In general, is pretty useful for completing a partial command, and for listing the sub-commands. > I seem to have some functionality in "configure" mode. > > Is there some quick way I can bring up PIM-SM, and see if it works? If you are going to use the LiveCD, I believe by default it comes with minimalistic configuration (if any) which doesn't include PIM-SM. Hence, you would have to add your own PIM-SM XORP configuration. To do so you can use the xorpsh configuration mode. Alternatively, you can just configure one of the network interfaces, and then you can use it to download a config file you have created previously and stored on some other machine. In both cases, you can use the following Web page for info how to configure XORP: http://www.xorp.org/getting_started.html Regards, Pavlin From berni@birkenwald.de Sat Dec 4 15:51:46 2004 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sat, 04 Dec 2004 16:51:46 +0100 Subject: [Xorp-users] MLD on FreeBSD In-Reply-To: <200412041009.iB4A8xcI011143@possum.icir.org> References: <200412041009.iB4A8xcI011143@possum.icir.org> Message-ID: <1102175506.12613.8.camel@cholera> Hi, > Do you have the option to attach a receiver right before the XORP > router? If yes, this can help you in finding-out whether the loss > happens before the traffic reaches the XORP router, or whether the > XORP router is lossy. Hm, I'll have to look for a simple test software since the gateway itself isn't Audio- or Video-equipped. But the problem is gone now (perhaps a temporary problem yesterday), I can now listen to IPv6 multicast radio in perfect quality. Only the pf problem remains, I hope the pf-developers can say something about that. Thanks for your support Bernhard From avinash_aithal@infosys.com Mon Dec 6 04:16:44 2004 From: avinash_aithal@infosys.com (Avinash Aithal) Date: Mon, 06 Dec 2004 09:46:44 +0530 Subject: [Xorp-users] user group problem to run xorpsh In-Reply-To: <200411292134.iATLYXbC086518@possum.icir.org> References: <200411292134.iATLYXbC086518@possum.icir.org> Message-ID: <1102306604.6371.17.camel@quapaw> On Tue, 2004-11-30 at 03:04, Pavlin Radoslavov wrote: > > OK, the above output seems fine. Then, I guess the problem is with > building the UserDB from the system password and group > files/databases. To trace the problem further, could you apply the > following patch to rtrmgr/userdb.cc (the patch below is against the > lastest userdb.cc: rev 1.7): > When you run the rtrmgr, on startup you should see output like: > > FOO3: UserDB::add_user(): user_id = 511, username = xorpuser > FOO5: found user xorpuser in group xorp > FOO5: found user <...> in group xorp > FOO5: found user <...> in group xorp > FOO6: add config capability for user xorpuser > > If you don't see the FOO3 line for user xorpuser, then getpwent(3) > somehow doesn't find a password file entry for user xorpuser. > For example, could be that inside your /etc/passwd you don't have > entry for xorpuser (e.g., if you use NIS, etc). > > If you don't see the FOO5 line for user xorpuser, then the result > returned by getgrnam(3) for group "xorp" somehow didn't contain > entry for user xorpuser. In that case, could you verify that your > /etc/group file contains a line for group "xorp", and that line > lists "xorpuser". > Here is a guess about the problem: because your xorpuser belongs to > only one group ("xorp"), this has been recorded in the /etc/passwd > file so "id xorpuser" shows that xorpuser belongs to group > xorp. However, inside /etc/group there is no entry like > xorp:x:511:xorpuser > Apparently, the UserDB::add_user() implementation uses only > getgrnam() to load the user->group mapping (when it should consider > the /etc/passwd database as well). To verify that, could you use > "vigr" and add "xorpuser" to the xorp group/line. > E.g.: "xorp:x:511:xorpuser" > > Please let me know the result. Your observations were on target. The problem got solved after I added 'xorpuser' in the /etc/group file. Thanks for the support. Cheers!!, Avinash. From pavlin@icir.org Mon Dec 6 06:20:43 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 05 Dec 2004 22:20:43 -0800 Subject: [Xorp-users] user group problem to run xorpsh In-Reply-To: Message from Avinash Aithal of "Mon, 06 Dec 2004 09:46:44 +0530." <1102306604.6371.17.camel@quapaw> Message-ID: <200412060620.iB66Khsi028086@possum.icir.org> > > Here is a guess about the problem: because your xorpuser belongs to > > only one group ("xorp"), this has been recorded in the /etc/passwd > > file so "id xorpuser" shows that xorpuser belongs to group > > xorp. However, inside /etc/group there is no entry like > > xorp:x:511:xorpuser > > Apparently, the UserDB::add_user() implementation uses only > > getgrnam() to load the user->group mapping (when it should consider > > the /etc/passwd database as well). To verify that, could you use > > "vigr" and add "xorpuser" to the xorp group/line. > > E.g.: "xorp:x:511:xorpuser" > > > > Please let me know the result. > > Your observations were on target. The problem got solved after I added > 'xorpuser' in the /etc/group file. Thanks for the support. Actually, few days ago Mark committed a fix to the CVS repository so with his fix you don't need to add such line to /etc/group (see his follow-up emails on the subject). Regards, Pavlin From hozer@hozed.org Tue Dec 7 02:42:46 2004 From: hozer@hozed.org (Troy Benjegerdes) Date: Mon, 6 Dec 2004 20:42:46 -0600 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: <200412040134.iB41Y371008227@possum.icir.org> References: <20041204011548.GG17697@kalmia.hozed.org> <200412040134.iB41Y371008227@possum.icir.org> Message-ID: <20041207024246.GK17697@kalmia.hozed.org> On Fri, Dec 03, 2004 at 05:34:03PM -0800, Pavlin Radoslavov wrote: > > I am attempting to build xorp-1.0 on openbsd-3.6. I had some build > > failures in bgp/harness, but I'm failing some 'make test' tests with > > segfaults, and xorp_rtrmgr is segfaulting on startup. > > > > Any ideas? I just want to run PIM-SM.. can I do that without > > xorp_rtrmgr? > > Troy, > > If you want to run PIM-SM on OpenBSD-3.6, currently you cannot do > it, because the vanilla 3.6 kernel doesn't have the PIM-SM support. > You can try some of the patches available from > http://www.icir.org/pavlin/.private/openbsd/ > or > http://www.icir.org/pavlin/.private/openbsd/patches/ > > but those are against OpenBSD-current, so there is no guarantee they > will even apply cleanly for 3.6. > > FYI, most of stuff in the incremental patches from the second URL > has been applied to the OpenBSD-current source tree. The last (most > important) patch is pending review from the OpenBSD folks. > Hopefully, sometime soon it will be applied to the source tree, and > will be part of the next OpenBSD release. I applied the patches to the latest OPENBSD_3_6 cvs (stable branch), and after fixing up a few things, got a kernel out. Some of the things have already been applied to the 3.6 stable branch. If you are interested, I have a patch against 3.6 at http://scl.ameslab.gov/~troy/obsd-3.6-pim.patch Any ideas on the segfault? I'm waiting for a complete rebuild at the moment on the off chance the PIM headers changing caused something goofy. What should I start looking at? (FYI, I used the stock openbsd gcc-2.95 compiler) From pavlin@icir.org Tue Dec 7 03:39:41 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 06 Dec 2004 19:39:41 -0800 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: Message from Troy Benjegerdes of "Mon, 06 Dec 2004 20:42:46 CST." <20041207024246.GK17697@kalmia.hozed.org> Message-ID: <200412070339.iB73dft4026386@possum.icir.org> > I applied the patches to the latest OPENBSD_3_6 cvs (stable branch), and > after fixing up a few things, got a kernel out. Some of the things > have already been applied to the 3.6 stable branch. > > If you are interested, I have a patch against 3.6 at > http://scl.ameslab.gov/~troy/obsd-3.6-pim.patch Thanks! > Any ideas on the segfault? I'm waiting for a complete rebuild at the > moment on the off chance the PIM headers changing caused something > goofy. What should I start looking at? > > (FYI, I used the stock openbsd gcc-2.95 compiler) You may want to look into file xorp/BUILD_NOTES which contains some notes about OpenBSD as well. E.g., on OpenBSD-3.5 you may have to use the egcc/eg++ compiler. I doubt you will see any PIM header related problems, but let me know if you run into such problem. BTW, what XORP version are you using? XORP-1.0 or XORP-CVS? The reason I ask you is because I just tried few days old XORP from CVS and I am getting the following errors on startup: [ 2004/12/06 19:14:47 ERROR xorp_rtrmgr:10094 LIBCOMM +499 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 0.0.0.0, remote_port = 19999): Invalid argument I've tracked the problem to a startup-time initialization problem that seems to exist on OpenBSD only. I vaguely remember that I had seen similar initialization OpenBSD-specific problem with some of the test programs for XORP-1.0, but that looked to me more like compiler/linker problem. I will keep investigating... Pavlin From Vlad GALU Tue Dec 7 19:56:15 2004 From: Vlad GALU (Vlad GALU) Date: Tue, 7 Dec 2004 21:56:15 +0200 Subject: [Xorp-users] Injecting BGP routes to the kernel Message-ID: <79722fad0412071156159054eb@mail.gmail.com> Hi guys. I've only started playing with XORP a couple of hours ago. It compiled almost smoothly on my FreeBSD 4.10-STABLE. After setting up the right interface address/aliases and static routes, I can see the BGP session I have configured as running. XORP sees the routes that it gets from its peer, and the peer sees the routes announced by XORP. However, I can't see the ones that XORP receives in my kernel routing table, using netstat. 'route get' always returns the default route of that machine for any given IP in the subnets received from the peer. Is this a bug or a lack of feature ? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From atanu@ICSI.Berkeley.EDU Tue Dec 7 22:00:24 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 07 Dec 2004 14:00:24 -0800 Subject: [Xorp-users] Injecting BGP routes to the kernel In-Reply-To: Message from Vlad GALU of "Tue, 07 Dec 2004 21:56:15 +0200." <79722fad0412071156159054eb@mail.gmail.com> Message-ID: <77643.1102456824@tigger.icir.org> The routes should appear in the Kernel if firstly they win the BGP decision process and no other protocol has a lower administrative distance. If you have a static default this will beat any BGP routes. The first thing to check is that BGP has the route. From within the xorpsh: Xorp> show bgp routes Should show the routes. Try this first. Atanu. >>>>> "Vlad" == Vlad GALU writes: Vlad> Hi guys. I've only started playing with XORP a couple of Vlad> hours ago. It compiled almost smoothly on my FreeBSD Vlad> 4.10-STABLE. After setting up the right interface Vlad> address/aliases and static routes, I can see the BGP session I Vlad> have configured as running. XORP sees the routes that it gets Vlad> from its peer, and the peer sees the routes announced by Vlad> XORP. However, I can't see the ones that XORP receives in my Vlad> kernel routing table, using netstat. 'route get' always Vlad> returns the default route of that machine for any given IP in Vlad> the subnets received from the peer. Is this a bug or a lack Vlad> of feature ? Vlad> -- If it's there, and you can see it, it's real. If it's not Vlad> there, and you can see it, it's virtual. If it's there, and Vlad> you can't see it, it's transparent. If it's not there, and Vlad> you can't see it, you erased it. Vlad> _______________________________________________ Xorp-users Vlad> mailing list Xorp-users@xorp.org Vlad> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From M.Handley@cs.ucl.ac.uk Wed Dec 8 01:58:18 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Wed, 08 Dec 2004 01:58:18 +0000 Subject: [Xorp-users] Injecting BGP routes to the kernel In-Reply-To: Your message of "Tue, 07 Dec 2004 14:00:24 PST." <77643.1102456824@tigger.icir.org> Message-ID: <2711.1102471098@cs.ucl.ac.uk> >The routes should appear in the Kernel if firstly they win the BGP decision >process and no other protocol has a lower administrative distance. If >you have a static default this will beat any BGP routes. This isn't quite correct. A static default would only beat a BGP *default*. More specific BGP routes would still be used. The admin distance test is only for routes that have both the same prefix and prefix length. - Mark From hozer@hozed.org Wed Dec 8 02:19:06 2004 From: hozer@hozed.org (Troy Benjegerdes) Date: Tue, 7 Dec 2004 20:19:06 -0600 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: <200412070339.iB73dft4026386@possum.icir.org> References: <20041207024246.GK17697@kalmia.hozed.org> <200412070339.iB73dft4026386@possum.icir.org> Message-ID: <20041208021906.GQ17697@kalmia.hozed.org> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_kalmia.hozed.org-4945-1102472346-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 06, 2004 at 07:39:41PM -0800, Pavlin Radoslavov wrote: > > I applied the patches to the latest OPENBSD_3_6 cvs (stable branch), and > > after fixing up a few things, got a kernel out. Some of the things > > have already been applied to the 3.6 stable branch. > > > > If you are interested, I have a patch against 3.6 at > > http://scl.ameslab.gov/~troy/obsd-3.6-pim.patch > > Thanks! > > > Any ideas on the segfault? I'm waiting for a complete rebuild at the > > moment on the off chance the PIM headers changing caused something > > goofy. What should I start looking at? > > > > (FYI, I used the stock openbsd gcc-2.95 compiler) > > You may want to look into file xorp/BUILD_NOTES which contains some > notes about OpenBSD as well. E.g., on OpenBSD-3.5 you may have to > use the egcc/eg++ compiler. > I doubt you will see any PIM header related problems, but let me > know if you run into such problem. > > BTW, what XORP version are you using? XORP-1.0 or XORP-CVS? > The reason I ask you is because I just tried few days old XORP from > CVS and I am getting the following errors on startup: I am running XORP-1.0. OpenBSD-3.6 also has the compiler bug. I build gcc-3.3.2 from ports, and it is much happier now. Some fo the bgp/harness tests seem to fail, but a lot more works than with gcc-2.95. Can you take a look at the included config file and tell me if this looks right? The vlan127 interface is statically configured, and connected to a Cisco router running PIM-SM. I want multicast traffic on em1 to get propagated back up to the multicast RP. --=_kalmia.hozed.org-4945-1102472346-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config.boot" /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.16 2004/06/21 18:06:05 hodson Exp $ */ interfaces { interface vlan127 { description: "Router 127 interface" enabled: true default-system-config } interface em1 { description: "Subnet 137 interface" enabled: true default-system-config } } fea { /* enable-unicast-forwarding4: true */ /* enable-unicast-forwarding6: true */ } protocols { static { route4 147.155.128.0/19 { nexthop: 147.155.127.1 metric: 1 } mrib-route4 147.155.128.0/19 { nexthop: 147.155.127.1 metric: 1 } } } plumbing { mfea4 { enabled: true interface vlan127 { vif vlan127 { enabled: true } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ enabled: true } } traceoptions { flag all { enabled: true } } } /* mfea6 { enabled: true interface dc0 { vif dc0 { enabled: true } } interface register_vif { vif register_vif { enabled: true } } traceoptions { flag all { enabled: true } } } */ } protocols { igmp { enabled: true interface vlan127 { vif vlan127 { enabled: true } } traceoptions { flag all { enabled: true } } } /* mld { enabled: true interface dc0 { vif dc0 { enabled: true } } traceoptions { flag all { enabled: true } } } */ } protocols { pimsm4 { enabled: true interface vlan127 { vif vlan127 { enabled: true /* dr-priority: 1 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ enabled: true } } bootstrap { enabled: true cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ cand-bsr-by-vif-name: "vlan127" /* bsr-priority: 1 */ /* hash-mask-len: 30 */ } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ cand-rp-by-vif-name: "vlan127" /* rp-priority: 192 */ /* rp-holdtime: 150 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ enabled: true interval-sec: 100 bytes: 102400 } traceoptions { flag all { enabled: true } } } /* pimsm6 { enabled: true interface dc0 { vif dc0 { enabled: true dr-priority: 1 alternative-subnet 40:40:40:40::/64 } } interface register_vif { vif register_vif { enabled: true } } static-rps { rp 50:50:50:50:50:50:50:50 { group-prefix ff00::/8 { rp-priority: 192 hash-mask-len: 126 } } } bootstrap { enabled: true cand-bsr { scope-zone ff00::/8 { is-scope-zone: false cand-bsr-by-vif-name: "dc0" bsr-priority: 1 hash-mask-len: 30 } } cand-rp { group-prefix ff00::/8 { is-scope-zone: false cand-rp-by-vif-name: "dc0" rp-priority: 192 rp-holdtime: 150 } } } switch-to-spt-threshold { enabled: true interval-sec: 100 bytes: 102400 } traceoptions { flag all { enabled: true } } } */ } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { enabled: true } } /* * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host * before uncommenting the snmp section below. * Also check that the "bgp4_mib_1657.so" exists in the correct location. */ /* protocols { snmp { mib-module bgp4_mib_1657 { abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" } } } */ --=_kalmia.hozed.org-4945-1102472346-0001-2-- From pavlin@icir.org Wed Dec 8 02:38:18 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 07 Dec 2004 18:38:18 -0800 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: Message from Troy Benjegerdes of "Tue, 07 Dec 2004 20:19:06 CST." <20041208021906.GQ17697@kalmia.hozed.org> Message-ID: <200412080238.iB82cI2i087153@possum.icir.org> > > You may want to look into file xorp/BUILD_NOTES which contains some > > notes about OpenBSD as well. E.g., on OpenBSD-3.5 you may have to > > use the egcc/eg++ compiler. > > I doubt you will see any PIM header related problems, but let me > > know if you run into such problem. > > > > BTW, what XORP version are you using? XORP-1.0 or XORP-CVS? > > The reason I ask you is because I just tried few days old XORP from > > CVS and I am getting the following errors on startup: > > I am running XORP-1.0. > OpenBSD-3.6 also has the compiler bug. I build gcc-3.3.2 from ports, and > it is much happier now. Some fo the bgp/harness tests seem to fail, but > a lot more works than with gcc-2.95. Do you still get the rtrmgr coredump? I couldn't replicate the problem on my OpenBSD-current (as of July 2004 or so), but actually I have been using XORP-cvs and it was triggering some other compiler/linker-related errors. > Can you take a look at the included config file and tell me if this > looks right? The vlan127 interface is statically configured, and > connected to a Cisco router running PIM-SM. I want multicast traffic on > em1 to get propagated back up to the multicast RP. Your configuration seems fine. Two comments though: 1. You have enabled your XORP router as a Cand-BSR and Cand-RP. This makes the assumption that (a) Your Cisco is also running the Bootstrap mechanism, and (b) You don't mind your XORP router being the BSR and/or the RP. If only (a) is true, then you may want to comment-out the cand-bsr and cand-rp statements. If (a) is false, then you should comment-out the "bootstrap" statement, and use static-rps to point to your RP (the cisco router?). 2. On some OS-es, you may have to enable the unicast forwarding if you want the multicast forwarding to work. Hence, if the multicast forwarding doesn't work, one of the things to try is to set enable-unicast-forwarding4: to true. Regards, Pavlin > > > > --=_kalmia.hozed.org-4945-1102472346-0001-2 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; filename="config.boot" > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.16 2004/06/21 18:06:05 hodson Exp $ */ > > > interfaces { > interface vlan127 { > description: "Router 127 interface" > enabled: true > default-system-config > } > interface em1 { > description: "Subnet 137 interface" > enabled: true > default-system-config > } > } > > fea { > /* enable-unicast-forwarding4: true */ > /* enable-unicast-forwarding6: true */ > } > > protocols { > static { > route4 147.155.128.0/19 { > nexthop: 147.155.127.1 > metric: 1 > } > mrib-route4 147.155.128.0/19 { > nexthop: 147.155.127.1 > metric: 1 > } > } > } > > plumbing { > mfea4 { > enabled: true > interface vlan127 { > vif vlan127 { > enabled: true > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > enabled: true > } > } > traceoptions { > flag all { > enabled: true > } > } > } > > /* > mfea6 { > enabled: true > interface dc0 { > vif dc0 { > enabled: true > } > } > interface register_vif { > vif register_vif { > enabled: true > } > } > traceoptions { > flag all { > enabled: true > } > } > } > */ > } > > protocols { > igmp { > enabled: true > interface vlan127 { > vif vlan127 { > enabled: true > } > } > traceoptions { > flag all { > enabled: true > } > } > } > /* > mld { > enabled: true > interface dc0 { > vif dc0 { > enabled: true > } > } > traceoptions { > flag all { > enabled: true > } > } > } > */ > } > > protocols { > pimsm4 { > enabled: true > interface vlan127 { > vif vlan127 { > enabled: true > /* dr-priority: 1 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > enabled: true > } > } > > bootstrap { > enabled: true > cand-bsr { > scope-zone 224.0.0.0/4 { > /* is-scope-zone: false */ > cand-bsr-by-vif-name: "vlan127" > /* bsr-priority: 1 */ > /* hash-mask-len: 30 */ > } > } > > cand-rp { > group-prefix 224.0.0.0/4 { > /* is-scope-zone: false */ > cand-rp-by-vif-name: "vlan127" > /* rp-priority: 192 */ > /* rp-holdtime: 150 */ > } > } > } > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > enabled: true > interval-sec: 100 > bytes: 102400 > } > > traceoptions { > flag all { > enabled: true > } > } > } > > /* > pimsm6 { > enabled: true > interface dc0 { > vif dc0 { > enabled: true > dr-priority: 1 > alternative-subnet 40:40:40:40::/64 > } > } > interface register_vif { > vif register_vif { > enabled: true > } > } > > static-rps { > rp 50:50:50:50:50:50:50:50 { > group-prefix ff00::/8 { > rp-priority: 192 > hash-mask-len: 126 > } > } > } > > bootstrap { > enabled: true > cand-bsr { > scope-zone ff00::/8 { > is-scope-zone: false > cand-bsr-by-vif-name: "dc0" > bsr-priority: 1 > hash-mask-len: 30 > } > } > > cand-rp { > group-prefix ff00::/8 { > is-scope-zone: false > cand-rp-by-vif-name: "dc0" > rp-priority: 192 > rp-holdtime: 150 > } > } > } > > switch-to-spt-threshold { > enabled: true > interval-sec: 100 > bytes: 102400 > } > > traceoptions { > flag all { > enabled: true > } > } > } > */ > } > > /* > * Note: fib2mrib is needed for multicast only if the unicast protocols > * don't populate the MRIB with multicast-specific routes. > */ > protocols { > fib2mrib { > enabled: true > } > } > > > > /* > * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host > * before uncommenting the snmp section below. > * Also check that the "bgp4_mib_1657.so" exists in the correct location. > */ > > /* > protocols { > snmp { > mib-module bgp4_mib_1657 { > abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" > } > } > } > */ > > --=_kalmia.hozed.org-4945-1102472346-0001-2-- > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hozer@hozed.org Wed Dec 8 05:58:55 2004 From: hozer@hozed.org (Troy Benjegerdes) Date: Tue, 7 Dec 2004 23:58:55 -0600 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: <200412080238.iB82cI2i087153@possum.icir.org> References: <20041208021906.GQ17697@kalmia.hozed.org> <200412080238.iB82cI2i087153@possum.icir.org> Message-ID: <20041208055855.GR17697@kalmia.hozed.org> > > I am running XORP-1.0. > > OpenBSD-3.6 also has the compiler bug. I build gcc-3.3.2 from ports, and > > it is much happier now. Some fo the bgp/harness tests seem to fail, but > > a lot more works than with gcc-2.95. > > Do you still get the rtrmgr coredump? > I couldn't replicate the problem on my OpenBSD-current (as of July > 2004 or so), but actually I have been using XORP-cvs and it was > triggering some other compiler/linker-related errors. > No more coredumps, at least on xorp_rtrmgr. I changed the RP to the cisco router, but I have a xorp_rib.core file now. I also get 3 failures on 'make check'.. (one of which is in the rib dir) bash-3.00# grep FAIL checklog FAIL: test_routing1.sh FAIL: test_rib1.sh FAIL: test_rib_fea1.sh What should I be looking for in the make check log? From russ@madhaus.cns.utoronto.ca Wed Dec 8 15:24:27 2004 From: russ@madhaus.cns.utoronto.ca (Russell Sutherland) Date: Wed, 8 Dec 2004 10:24:27 -0500 Subject: [Xorp-users] Supported Multicast Protocols Message-ID: <20041208152427.GA22002@madhaus.cns.utoronto.ca> Does the current version of XORP support: MSDP [ Multicast Source Discovery Protocol RFC 3618 ] MBGP [ Multicast Border Gateway Protocol RFC 2858 ] -- Russell P. Sutherland Email: russ @ madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Voice: +1.416.978.0470 University of Toronto Fax: +1.416.978.6620 Toronto, ON M5S 1C1 WWW: http://madhaus.cns.utoronto.ca/~russ CANADA From pavlin@icir.org Wed Dec 8 20:22:58 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 08 Dec 2004 12:22:58 -0800 Subject: [Xorp-users] Supported Multicast Protocols In-Reply-To: Message from Russell Sutherland of "Wed, 08 Dec 2004 10:24:27 EST." <20041208152427.GA22002@madhaus.cns.utoronto.ca> Message-ID: <200412082022.iB8KMw0Y072624@possum.icir.org> > Does the current version of XORP support: > > MSDP [ Multicast Source Discovery Protocol RFC 3618 ] No. > MBGP [ Multicast Border Gateway Protocol RFC 2858 ] XORP implements draft-ietf-idr-rfc2858bis-* which I believe is suppose to obsolete RFC 2858 in the future (BGP folks, please correct me if I am wrong). Regards, Pavlin From pavlin@icir.org Thu Dec 9 08:32:32 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Dec 2004 00:32:32 -0800 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: Message from Troy Benjegerdes of "Tue, 07 Dec 2004 23:58:55 CST." <20041208055855.GR17697@kalmia.hozed.org> Message-ID: <200412090832.iB98WWRW025725@possum.icir.org> > > > I am running XORP-1.0. > > > OpenBSD-3.6 also has the compiler bug. I build gcc-3.3.2 from ports, and > > > it is much happier now. Some fo the bgp/harness tests seem to fail, but > > > a lot more works than with gcc-2.95. > > > > Do you still get the rtrmgr coredump? > > I couldn't replicate the problem on my OpenBSD-current (as of July > > 2004 or so), but actually I have been using XORP-cvs and it was > > triggering some other compiler/linker-related errors. > > > > No more coredumps, at least on xorp_rtrmgr. > > I changed the RP to the cisco router, but I have a xorp_rib.core file now. > > I also get 3 failures on 'make check'.. (one of which is in the rib dir) > bash-3.00# grep FAIL checklog > FAIL: test_routing1.sh > FAIL: test_rib1.sh > FAIL: test_rib_fea1.sh > > What should I be looking for in the make check log? Troy, I just committed an OpenBSD-related fix to the CVS repository. This fix addresses the problem I mentioned in one of my earlier emails. Furthermore, all "gmake check" succeed, and I don't see any coredumps. Hence, could you get the lastest code from the CVS repository and give it a try. Thanks, Pavlin From tm021090@fh-stpoelten.ac.at Thu Dec 9 13:36:00 2004 From: tm021090@fh-stpoelten.ac.at (Michael Prochaska) Date: Thu, 9 Dec 2004 14:36:00 +0100 (CET) Subject: [Xorp-users] compile error, killed cc1plus Message-ID: <1090.195.202.148.12.1102599360.squirrel@mail.fh-stpoelten.ac.at> hi, i've problems to compile xorp-1.0. here are the last lines of my compile trial: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-20 -c -o finder_client.o `test -f finder_client.cc || echo './'`finder_client.cc g++: Internal error: Getötet (program cc1plus) Please submit a full bug report. See for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make[3]: *** [finder_client.o] Fehler 1 make[3]: Leaving directory `/home/mc/xorp-1.0/libxipc' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/home/mc/xorp-1.0/libxipc' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/mc/xorp-1.0' make: *** [all] Fehler 2 it's a debian box with g++ 3.3.4. any ideas? best regards, michael PS.: "Getötet" (german) means killed and "Fehler " means error From pavlin@icir.org Thu Dec 9 19:06:50 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Dec 2004 11:06:50 -0800 Subject: [Xorp-users] compile error, killed cc1plus In-Reply-To: Message from "Michael Prochaska" of "Thu, 09 Dec 2004 14:36:00 +0100." <1090.195.202.148.12.1102599360.squirrel@mail.fh-stpoelten.ac.at> Message-ID: <200412091906.iB9J6oK1030914@possum.icir.org> > hi, > i've problems to compile xorp-1.0. > > here are the last lines of my compile trial: > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes > -Woverloaded-virtual -ftemplate-depth-20 -c -o finder_client.o `test -f > finder_client.cc || echo './'`finder_client.cc > g++: Internal error: Getötet (program cc1plus) > Please submit a full bug report. > See for instructions. > For Debian GNU/Linux specific bug reporting instructions, > see . > > make[3]: *** [finder_client.o] Fehler 1 > make[3]: Leaving directory `/home/mc/xorp-1.0/libxipc' > make[2]: *** [all] Fehler 2 > make[2]: Leaving directory `/home/mc/xorp-1.0/libxipc' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Leaving directory `/home/mc/xorp-1.0' > make: *** [all] Fehler 2 > > > it's a debian box with g++ 3.3.4. > > any ideas? Hmmm, looks like a compiler bug. Can you try to compile the lastest XORP code from the anon-CVS repository and see if you still trigger the same bug? If this doesn't help, can you try a different gcc compiler? It seems that the gcc-3.3.4 compiler is marked as "testing" in the Debian packages, hence you may want to try some of the gcc-2.9x "stable" compilers (or the gcc-3.3.5 "unstable" if you feel more adventurous). FYI, on FreeBSD we don't have a problem with gcc-3.3.4. Regards, Pavlin From tm021090@fh-stpoelten.ac.at Thu Dec 9 23:21:22 2004 From: tm021090@fh-stpoelten.ac.at (Michael Prochaska (FH)) Date: Fri, 10 Dec 2004 00:21:22 +0100 Subject: [Xorp-users] compile error, killed cc1plus In-Reply-To: <200412091906.iB9J6oK1030914@possum.icir.org> Message-ID: <20041209232056.612ACA3124@sv3.isp4p.net> > Hmmm, looks like a compiler bug. > Can you try to compile the lastest XORP code from the anon-CVS > repository and see if you still trigger the same bug? i'll try it tomorrow! > If this doesn't help, can you try a different gcc compiler? > It seems that the gcc-3.3.4 compiler is marked as "testing" in the > Debian packages, hence you may want to try some of the gcc-2.9x > "stable" compilers (or the gcc-3.3.5 "unstable" if you feel more > adventurous). that was my first idea after mailing to the list....i've installed g++ 2.9.4 (debian stable) => same error by the way, it's a knoppix harddisk install, no idea if this could be a problem (in principle it's a stable-testing-unstable mixed debian) > Regards, > Pavlin best regards, michael From hozer@hozed.org Fri Dec 10 00:00:01 2004 From: hozer@hozed.org (Troy Benjegerdes) Date: Thu, 9 Dec 2004 18:00:01 -0600 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: <200412090832.iB98WWRW025725@possum.icir.org> References: <20041208055855.GR17697@kalmia.hozed.org> <200412090832.iB98WWRW025725@possum.icir.org> Message-ID: <20041210000001.GE17697@kalmia.hozed.org> > Troy, > > I just committed an OpenBSD-related fix to the CVS repository. > This fix addresses the problem I mentioned in one of my earlier > emails. Furthermore, all "gmake check" succeed, and I don't see any > coredumps. > Hence, could you get the lastest code from the CVS repository and > give it a try. 'gmake check' passes here as well now. Thanks! Now I'm getting the following errors: [ 2004/12/09 17:43:58 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 147.155.127.1 to 224.0.0.1 on vif vlan127 [ 2004/12/09 17:44:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 147.155.127.4 to 224.0.0.13 on vif vlan127 [ 2004/12/09 17:44:03 ERROR xorp_fea:18238 MFEA +1758 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 from 147.155.127.4 to 224.0.0.13 on vif vlan127) failed: No route to host [ 2004/12/09 17:44:03 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 147.155.127.4 to 224.0.0.13 on vif vlan127 [ 2004/12/09 17:44:03 ERROR xorp_pimsm4:2687 PIM +1746 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Failed to send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 147.155.127.4 to 224.0.0.13 on vif vlan127 Is this a config thing? Do you need more of the log? From pavlin@icir.org Fri Dec 10 01:59:07 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Dec 2004 17:59:07 -0800 Subject: [Xorp-users] OpenBSD-3.6 segfaults In-Reply-To: Message from Troy Benjegerdes of "Thu, 09 Dec 2004 18:00:01 CST." <20041210000001.GE17697@kalmia.hozed.org> Message-ID: <200412100159.iBA1x7p3040155@possum.icir.org> > Now I'm getting the following errors: > > [ 2004/12/09 17:43:58 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_MEMBERSHIP_QUERY from 147.155.127.1 to 224.0.0.1 on vif vlan127 > [ 2004/12/09 17:44:03 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from > 147.155.127.4 to 224.0.0.13 on vif vlan127 > [ 2004/12/09 17:44:03 ERROR xorp_fea:18238 MFEA +1758 > mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 from > 147.155.127.4 to 224.0.0.13 on vif vlan127) failed: No route to host > [ 2004/12/09 17:44:03 WARNING xorp_fea XrlMfeaTarget ] Handling method > for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command > failed Cannot send PIMSM_4 protocol message from 147.155.127.4 to > 224.0.0.13 on vif vlan127 > [ 2004/12/09 17:44:03 ERROR xorp_pimsm4:2687 PIM +1746 xrl_pim_node.cc > mfea_client_send_protocol_message_cb ] Failed to send a protocol > message: 102 Command failed Cannot send PIMSM_4 protocol message from > 147.155.127.4 to 224.0.0.13 on vif vlan127 > > Is this a config thing? Do you need more of the log? That is odd. For whatever reason the MFEA cannot transmit PIM control packets as link-local multicast on the vlan127 interface. Do you get similar errors for the IGMP messages? Off the top of my head, I don't see any particular reason why the link-local multicast should fail, unless there is something special about vlan. Ah, here is a thought. How did you create the vlan? Did you use openvpn or something like this? Can you verify by running "ifconfig -a" that vlan127 has the MULTICAST flag set. I think that on some OS older versions of openvpn don't set the MULTICAST flag properly, but this should be fixed in later versions. Anyway, I looked again into your config file you sent previously, and it seems fine. Hence, if the MULTICAST flag on vlan127 is set, please send your complete log message. Thanks, Pavlin From gernot.schmied@chello.at Mon Dec 13 10:51:32 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Mon, 13 Dec 2004 11:51:32 +0100 Subject: [Xorp-users] XORP on NetBSD 2.0 Message-ID: <41BD7434.2040402@chello.at> Just wanted to report that XORP-1.0 compiled like a charm on shiny new NetBSD 2.0. Is anybody aware of PIM support under NetBSD 2.0? Regards, Gernot From gernot.schmied@chello.at Mon Dec 13 15:26:30 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Mon, 13 Dec 2004 16:26:30 +0100 Subject: [Xorp-users] XORP and OSPFv2 Message-ID: <41BDB4A6.2060702@chello.at> I'm not sure how the OSPF integration of XORP-1.0 works. John Moy's code plus ??? is located in the contrib directory. How do I compile a xorp_ospf binary (xorp_rtmgr obviously complains about its absence)? Thanks, Gernot From adam@hiddennet.net Mon Dec 13 15:51:05 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Mon, 13 Dec 2004 15:51:05 +0000 Subject: [Xorp-users] XORP and OSPFv2 In-Reply-To: <41BDB4A6.2060702@chello.at> References: <41BDB4A6.2060702@chello.at> Message-ID: <1102953065.24370.15.camel@localhost> Hi I suspect this post by Atanu (2004/12/02) to the xorp-hackers list answers your question. " Ghazan> I started compiling it on an Ultra5 (debian linux). Seems Ghazan> to be going well, but it wont do OSPFD, I'll try to force Ghazan> that somehow. Wont need the multicast protocols nor ipv6, Ghazan> only RIP2, OSPF and BGP4. We have never tried building on an Ultra5 (debian linux) system. XORP does build on Redhat Linux. We have never tried building on an Ultra5, we don't expect any byte order problems as we have run our regression tests on a PowerPC running Mac OS X. I wouldn't expect the OSPF to build; the OSPF is a port of John Moy's OSPF and only builds on FreeBSD. We are in the process of writing our own OSPF that we expect to have available 1st Quarter next year. " Adam On Mon, 2004-12-13 at 16:26 +0100, Gernot W. Schmied wrote: > I'm not sure how the OSPF integration of XORP-1.0 works. > John Moy's code plus ??? is located in the contrib directory. How do I > compile a xorp_ospf binary (xorp_rtmgr obviously complains about its > absence)? > > Thanks, > Gernot > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Mon Dec 13 19:08:04 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 13 Dec 2004 11:08:04 -0800 Subject: [Xorp-users] XORP on NetBSD 2.0 In-Reply-To: Message from "Gernot W. Schmied" of "Mon, 13 Dec 2004 11:51:32 +0100." <41BD7434.2040402@chello.at> Message-ID: <200412131908.iBDJ84IS048503@possum.icir.org> > Just wanted to report that XORP-1.0 compiled like a charm on > shiny new NetBSD 2.0. Great! > Is anybody aware of PIM support under NetBSD 2.0? In the beginning of September, the PIM support was commited to the NetBSD cvs repository, but unfortunately it didn't make the cut to be included in the NetBSD-2.0 release. Unfortunately, I am not aware of a PIM patch for 2.0. You can try the following patch that was applied to NetBSD-current, but there is no guarantee it will even apply cleanly to 2.0: http://www.icir.org/pavlin/.private/netbsd/README http://www.icir.org/pavlin/.private/netbsd/sys.20040826.patch http://www.icir.org/pavlin/.private/netbsd/netstat.20040826.patch http://www.icir.org/pavlin/.private/netbsd/pim.h.20040826 http://www.icir.org/pavlin/.private/netbsd/pim_var.h.20040826 Though, I don't expect to see huge difference in the relevant code, so you may be able to correct the errors (if any) by hand. Regards, Pavlin From dikshie@lapi.itb.ac.id Thu Dec 16 05:41:50 2004 From: dikshie@lapi.itb.ac.id (Dikshie) Date: Thu, 16 Dec 2004 12:41:50 +0700 Subject: [Xorp-users] error compile xorp from cvs Message-ID: <20041216054150.GA27119@lapi.itb.ac.id> cvs-ed few hours ago: -------------------------- /bin/sh ../libtool --mode=link g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o demo_fea_ifmgr_client demo_fea_ifmgr_client.o ../xrl/targets/libdemofeaifmgrclientbase.la ../xrl/interfaces/libfeaifmgrxif.la ../libxipc/libxipc.la ../libcomm/libcomm.la ../libxorp/libxorp.la -lcrypto g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o demo_fea_ifmgr_client demo_fea_ifmgr_client.o ../xrl/targets/.libs/libdemofeaifmgrclientbase.a ../xrl/interfaces/.libs/libfeaifmgrxif.a ../libxipc/.libs/libxipc.a ../libcomm/.libs/libcomm.a ../libxorp/.libs/libxorp.a -lcrypto gmake[3]: *** No rule to make target `xorp_fea_click_config_generator', needed by `all-am'. Stop. gmake[3]: Leaving directory `/usr/local/src/xorp/xorp/fea' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/local/src/xorp/xorp/fea' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/xorp/xorp' gmake: *** [all] Error 2 ipv6# ipv6# uname -a FreeBSD ipv6.ppk.itb.ac.id 5.3-STABLE FreeBSD 5.3-STABLE #71: Mon Dec 13 17:47:18 WIT 2004 dikshie@ipv6.ppk.itb.ac.id:/usr/obj/usr/src/sys/PPK i386 --------------------------------- could someone check this ? thanks ! -dikshie- From pavlin@icir.org Thu Dec 16 05:52:11 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 15 Dec 2004 21:52:11 -0800 Subject: [Xorp-users] error compile xorp from cvs In-Reply-To: Message from Dikshie of "Thu, 16 Dec 2004 12:41:50 +0700." <20041216054150.GA27119@lapi.itb.ac.id> Message-ID: <200412160552.iBG5qBpA067080@possum.icir.org> > cvs-ed few hours ago: > -------------------------- > /bin/sh ../libtool --mode=link g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o demo_fea_ifmgr_client demo_fea_ifmgr_client.o ../xrl/targets/libdemofeaifmgrclientbase.la ../xrl/interfaces/libfeaifmgrxif.la ../libxipc/libxipc.la ../libcomm/libcomm.la ../libxorp/libxorp.la -lcrypto > g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o demo_fea_ifmgr_client demo_fea_ifmgr_client.o ../xrl/targets/.libs/libdemofeaifmgrclientbase.a ../xrl/interfaces/.libs/libfeaifmgrxif.a ../libxipc/.libs/libxipc.a ../libcomm/.libs/libcomm.a ../libxorp/.libs/libxorp.a -lcrypto > gmake[3]: *** No rule to make target `xorp_fea_click_config_generator', needed by `all-am'. Stop. > gmake[3]: Leaving directory `/usr/local/src/xorp/xorp/fea' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/usr/local/src/xorp/xorp/fea' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/usr/local/src/xorp/xorp' > gmake: *** [all] Error 2 > ipv6# > ipv6# uname -a > FreeBSD ipv6.ppk.itb.ac.id 5.3-STABLE FreeBSD 5.3-STABLE #71: Mon Dec 13 17:47:18 WIT 2004 dikshie@ipv6.ppk.itb.ac.id:/usr/obj/usr/src/sys/PPK i386 > --------------------------------- Could you confirm that you executed ./configure before "gmake". Thanks, Pavlin From Neto Thu Dec 16 14:09:31 2004 From: Neto (Neto) Date: Thu, 16 Dec 2004 12:09:31 -0200 Subject: [Xorp-users] XRL Message-ID: <2c6b709604121606096dbf1958@mail.gmail.com> I have a doubt, the tests of XRL target (i think) was failed. The Xorp need some packages of linux to manipulate the XRL? And which is? -- " uma coisa eh uma coisa, outra coisa ja eh outra coisa" From atanu@ICSI.Berkeley.EDU Fri Dec 17 01:50:52 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 16 Dec 2004 17:50:52 -0800 Subject: [Xorp-users] XRL In-Reply-To: Message from Neto of "Thu, 16 Dec 2004 12:09:31 -0200." <2c6b709604121606096dbf1958@mail.gmail.com> Message-ID: <14619.1103248252@tigger.icir.org> Could you send the output of the failed tests please. Atanu. >>>>> "Neto" == Neto writes: Neto> I have a doubt, the tests of XRL target (i think) was Neto> failed. The Xorp need some packages of linux to manipulate Neto> the XRL? And which is? Neto> -- " uma coisa eh uma coisa, outra coisa ja eh outra coisa" Neto> _______________________________________________ Xorp-users Neto> mailing list Xorp-users@xorp.org Neto> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From gernot.schmied@chello.at Mon Dec 20 20:34:56 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Mon, 20 Dec 2004 21:34:56 +0100 Subject: [Xorp-users] Compile failure on FreeBSD 5.3 Message-ID: <41C73770.5090308@chello.at> Just want to report this compile failure on FreeBSD 5.3/Intel P4. g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qua l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-20 -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo './'`mfea_proto_comm .cc mfea_proto_comm.cc: In member function `int ProtoComm::proto_socket_write(uint16 _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)': mfea_proto_comm.cc:1521: error: cannot bind packed field `ip->ip::ip_src' to `in _addr&' mfea_proto_comm.cc:1522: error: cannot bind packed field `ip->ip::ip_dst' to `in _addr&' gmake[3]: *** [mfea_proto_comm.o] Error 1 gmake[3]: Leaving directory `/usr/local/src/xorp-1.0/fea' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/local/src/xorp-1.0/fea' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/xorp-1.0' gmake: *** [all] Error 2 Regards, Gernot From Vlad GALU Tue Dec 21 15:54:56 2004 From: Vlad GALU (Vlad GALU) Date: Tue, 21 Dec 2004 17:54:56 +0200 Subject: [Xorp-users] Compile failure on FreeBSD 5.3 In-Reply-To: <41C8068C.8000004@chello.at> References: <41C73770.5090308@chello.at> <79722fad0412202125519552a4@mail.gmail.com> <41C8068C.8000004@chello.at> Message-ID: <79722fad041221075417967c26@mail.gmail.com> ------=_Part_121_5100559.1103644496086 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline > Hi, > > I'm not sure what you mean by "Do a cast". > See the attached patch. > Thanks, > Gernot > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ------=_Part_121_5100559.1103644496086 Content-Type: text/x-diff; name="xorp.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xorp.diff" diff -Nrau ./xorp-1.0/fea/mfea_proto_comm.cc ./xorp-1.0.bak/fea/mfea_proto_= comm.cc --- ./xorp-1.0/fea/mfea_proto_comm.cc=09Fri Jun 11 01:40:55 2004 +++ ./xorp-1.0.bak/fea/mfea_proto_comm.cc=09Tue Dec 21 17:53:05 2004 @@ -1518,8 +1518,8 @@ =09ip->ip_ttl=09=3D ip_ttl; =09ip->ip_tos=09=3D ip_tos; =09 -=09src.copy_out(ip->ip_src); -=09dst.copy_out(ip->ip_dst); +=09src.copy_out((in_addr&)ip->ip_src); +=09dst.copy_out((in_addr&)ip->ip_dst); =09ip->ip_len =3D (ip->ip_hl << 2) + datalen; #ifdef IPV4_RAW_OUTPUT_IS_RAW =09ip->ip_len =3D htons(ip->ip_len); ------=_Part_121_5100559.1103644496086-- From ongbh@ispworkshop.com Wed Dec 29 01:45:32 2004 From: ongbh@ispworkshop.com (Ong Beng Hui) Date: Wed, 29 Dec 2004 09:45:32 +0800 Subject: [Xorp-users] [Fwd: xorp on FreeBSD 5.3 on Sparc64] Message-ID: <41D20C3C.4050504@ispworkshop.com> -------- Original Message -------- Subject: xorp on FreeBSD 5.3 on Sparc64 Date: Tue, 28 Dec 2004 16:00:36 +0800 From: Ong Beng Hui To: xorp-hackers@xorp.org Hi, Has anyone tried to compile xorp on FreeBSD 5.3 on Sparc64 ? Got this error... make[3]: Entering directory `/usr/local/src/xorp/libxorp' source='asyncio.cc' object='asyncio.lo' libtool=yes \ depfile='.deps/asyncio.Plo' tmpdepfile='.deps/asyncio.TPlo' \ depmode=gcc3 /usr/local/bin/bash ../config/depcomp \ /usr/local/bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o asyncio.lo `test -f asyncio.cc || echo './'`asyncio.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c asyncio.cc -MT asyncio.lo -MD -MP -MF .deps/asyncio.TPlo -o asyncio.o asyncio.cc: In member function `void AsyncFileWriter::write(int, SelectorMask)': asyncio.cc:255: warning: int format, different type arg (arg 2) make[3]: *** [asyncio.lo] Error 1 make[3]: Leaving directory `/usr/local/src/xorp/libxorp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/xorp/libxorp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/xorp' make: *** [all] Error 2 bash-2.04# any tips for a fix ? xorp is from CVS. From ongbh@ispworkshop.com Wed Dec 29 08:14:04 2004 From: ongbh@ispworkshop.com (Ong Beng Hui) Date: Wed, 29 Dec 2004 16:14:04 +0800 Subject: [Xorp-users] 64 bit box ? Message-ID: <41D2674C.7020507@ispworkshop.com> Hi, Just curious... Has anyone tried xorp on 64bit platform yet ? ie.. freebsd/netbsd on alpha, usparc64. From atanu@ICSI.Berkeley.EDU Wed Dec 29 23:42:49 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 29 Dec 2004 15:42:49 -0800 Subject: [Xorp-users] mailman was down Message-ID: <53841.1104363769@tigger.icir.org> Hi, Our mailing list server was down for the last four days. Some spam email confused it enough, to stop it forwarding any email. Hopefully its fixed now. Atanu.