From simon.vanderlinden at student.uclouvain.be  Wed Feb 10 10:20:46 2010
From: simon.vanderlinden at student.uclouvain.be (Simon van der Linden)
Date: Wed, 10 Feb 2010 19:20:46 +0100
Subject: [Xorp-hackers] Running multiple instances of a XORP process
Message-ID: <4B72F8FE.4050401@student.uclouvain.be>

Hi,

I'd like to start multiple instances of the same XORP process (BGP in 
this case) on different interfaces, with different target names. Is this 
doable using config.boot or any other config hook, or should I get my 
hands dirty by touching rtrmgr or some other process?

If I'm not mistaken, BGP uses any interface, so I'd have to change that 
anyway.

Regards,

-- 
Simon van der Linden
Computer Science and Engineering Student
INGI/EPL/UCLouvain


From lizhaous2000 at yahoo.com  Wed Feb 10 11:24:46 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 10 Feb 2010 11:24:46 -0800 (PST)
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
Message-ID: <44318.66818.qm@web58701.mail.re1.yahoo.com>

When I configured vrrp on one interface in linux embedded. The vrrp crashed
because of sigabrt in VrrpTarget::check_interfaces at vrrp_target.cc:221.

Anybody noticed this?

Li


      


From lizhaous2000 at yahoo.com  Wed Feb 10 12:50:12 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 10 Feb 2010 12:50:12 -0800 (PST)
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <44318.66818.qm@web58701.mail.re1.yahoo.com>
Message-ID: <174682.60982.qm@web58705.mail.re1.yahoo.com>


What I can see is that MAC of interface was changed corectly to 00:00:5e:00:01:c8. But I do not know why vrrp died.

--- On Wed, 2/10/10, Li Zhao <lizhaous2000 at yahoo.com> wrote:

> From: Li Zhao <lizhaous2000 at yahoo.com>
> Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
> To: xorp-hackers at xorp.org
> Date: Wednesday, February 10, 2010, 2:24 PM
> When I configured vrrp on one
> interface in linux embedded. The vrrp crashed
> because of sigabrt in VrrpTarget::check_interfaces at
> vrrp_target.cc:221.
> 
> Anybody noticed this?
> 
> Li
> 
> 
> ? ? ? 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From lizhaous2000 at yahoo.com  Thu Feb 11 08:07:41 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 11 Feb 2010 08:07:41 -0800 (PST)
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
Message-ID: <997906.11884.qm@web58704.mail.re1.yahoo.com>

This is the gdb stack:

#3  0x00a72e18 in abort () at abort.c:88
#4  0xb7f3ace0 in xlog_fatal (module_name=0x80e9402 "VRRP", 
    where=0xbfa9329c "+173 vrrp_packet.cc finalize", 
    fmt=0x80e93ec "Assertion (%s) failed") at xlog.c:461
#5  0x0806b995 in VrrpPacket::finalize (this=0x88b3e00) at vrrp_packet.cc:172
#6  0x08066fae in Vrrp::prepare_advertisement (this=0x88b3db0, priority=100)
    at vrrp.cc:331
#7  0x080670c1 in Vrrp::send_advertisement (this=0x88b3db0, priority=100)
    at vrrp.cc:315
#8  0x08067144 in Vrrp::send_advertisement (this=0x88b3db0) at vrrp.cc:305
#9  0x080674e9 in Vrrp::adver_expiry (this=0x88b3db0) at vrrp.cc:368
#10 0x08069ae5 in XorpMemberCallback0B0<bool, Vrrp>::dispatch (this=0x88b1cc8)
    at ../libxorp/callback_nodebug.hh:286
#11 0xb7f6e870 in PeriodicTimerNode2::expire (this=0x88afd18, t=@0xbfa9b0c0)
    at timer.cc:183
#12 0xb7f6b7d7 in TimerList::expire_one (this=0xbfa9f078, worst_priority=4)
    at timer.cc:441
#13 0xb7f6b940 in TimerList::run (this=0xbfa9f078) at timer.cc:389
#14 0xb7f44746 in EventLoop::do_work (this=0xbfa9f074, can_block=true)
    at eventloop.cc:153
---Type <return> to continue, or q <return> to quit---
#15 0xb7f44a3c in EventLoop::run (this=0xbfa9f074) at eventloop.cc:99
#16 0x08059188 in start () at xorp_vrrp.cc:45
#17 0x080592bd in main (argc=Cannot access memory at address 0x483
) at xorp_vrrp.cc:58


--- On Wed, 2/10/10, Li Zhao <lizhaous2000 at yahoo.com> wrote:

> From: Li Zhao <lizhaous2000 at yahoo.com>
> Subject: Re: [Xorp-hackers] vrrp sigabrt in release 1.6
> To: xorp-hackers at xorp.org
> Date: Wednesday, February 10, 2010, 3:50 PM
> 
> What I can see is that MAC of interface was changed
> corectly to 00:00:5e:00:01:c8. But I do not know why vrrp
> died.
> 
> --- On Wed, 2/10/10, Li Zhao <lizhaous2000 at yahoo.com>
> wrote:
> 
> > From: Li Zhao <lizhaous2000 at yahoo.com>
> > Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
> > To: xorp-hackers at xorp.org
> > Date: Wednesday, February 10, 2010, 2:24 PM
> > When I configured vrrp on one
> > interface in linux embedded. The vrrp crashed
> > because of sigabrt in VrrpTarget::check_interfaces at
> > vrrp_target.cc:221.
> > 
> > Anybody noticed this?
> > 
> > Li
> > 
> > 
> > ? ? ? 
> > 
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > 
> 
> 
> ? ? ? 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


      
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100211/eb6612a2/attachment.txt 

From greearb at candelatech.com  Thu Feb 11 10:00:38 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 11 Feb 2010 10:00:38 -0800
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <997906.11884.qm@web58704.mail.re1.yahoo.com>
References: <997906.11884.qm@web58704.mail.re1.yahoo.com>
Message-ID: <4B7445C6.8080503@candelatech.com>

On 02/11/2010 08:07 AM, Li Zhao wrote:
> This is the gdb stack:
>
> #3  0x00a72e18 in abort () at abort.c:88
> #4  0xb7f3ace0 in xlog_fatal (module_name=0x80e9402 "VRRP",
>      where=0xbfa9329c "+173 vrrp_packet.cc finalize",
>      fmt=0x80e93ec "Assertion (%s) failed") at xlog.c:461
> #5  0x0806b995 in VrrpPacket::finalize (this=0x88b3e00) at vrrp_packet.cc:172
> #6  0x08066fae in Vrrp::prepare_advertisement (this=0x88b3db0, priority=100)
>      at vrrp.cc:331
> #7  0x080670c1 in Vrrp::send_advertisement (this=0x88b3db0, priority=100)
>      at vrrp.cc:315
> #8  0x08067144 in Vrrp::send_advertisement (this=0x88b3db0) at vrrp.cc:305
> #9  0x080674e9 in Vrrp::adver_expiry (this=0x88b3db0) at vrrp.cc:368
> #10 0x08069ae5 in XorpMemberCallback0B0<bool, Vrrp>::dispatch (this=0x88b1cc8)
>      at ../libxorp/callback_nodebug.hh:286
> #11 0xb7f6e870 in PeriodicTimerNode2::expire (this=0x88afd18, t=@0xbfa9b0c0)
>      at timer.cc:183
> #12 0xb7f6b7d7 in TimerList::expire_one (this=0xbfa9f078, worst_priority=4)
>      at timer.cc:441
> #13 0xb7f6b940 in TimerList::run (this=0xbfa9f078) at timer.cc:389
> #14 0xb7f44746 in EventLoop::do_work (this=0xbfa9f074, can_block=true)
>      at eventloop.cc:153
> ---Type<return>  to continue, or q<return>  to quit---
> #15 0xb7f44a3c in EventLoop::run (this=0xbfa9f074) at eventloop.cc:99
> #16 0x08059188 in start () at xorp_vrrp.cc:45
> #17 0x080592bd in main (argc=Cannot access memory at address 0x483
> ) at xorp_vrrp.cc:58

If you can reproduce this with latest svn tree, then we can probably
fix it.  No one that I know of is making any changes to the 1.6 code though.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From lizhaous2000 at yahoo.com  Thu Feb 11 11:21:54 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 11 Feb 2010 11:21:54 -0800 (PST)
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <4B7445C6.8080503@candelatech.com>
Message-ID: <922010.41464.qm@web58702.mail.re1.yahoo.com>

I am using 1.6. Anybody has experiences using VRRP to configure eth interface failover?

--- On Thu, 2/11/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] vrrp sigabrt in release 1.6
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: xorp-hackers at xorp.org
> Date: Thursday, February 11, 2010, 1:00 PM
> On 02/11/2010 08:07 AM, Li Zhao
> wrote:
> > This is the gdb stack:
> >
> > #3? 0x00a72e18 in abort () at abort.c:88
> > #4? 0xb7f3ace0 in xlog_fatal
> (module_name=0x80e9402 "VRRP",
> >? ? ? where=0xbfa9329c "+173
> vrrp_packet.cc finalize",
> >? ? ? fmt=0x80e93ec "Assertion (%s)
> failed") at xlog.c:461
> > #5? 0x0806b995 in VrrpPacket::finalize
> (this=0x88b3e00) at vrrp_packet.cc:172
> > #6? 0x08066fae in Vrrp::prepare_advertisement
> (this=0x88b3db0, priority=100)
> >? ? ? at vrrp.cc:331
> > #7? 0x080670c1 in Vrrp::send_advertisement
> (this=0x88b3db0, priority=100)
> >? ? ? at vrrp.cc:315
> > #8? 0x08067144 in Vrrp::send_advertisement
> (this=0x88b3db0) at vrrp.cc:305
> > #9? 0x080674e9 in Vrrp::adver_expiry
> (this=0x88b3db0) at vrrp.cc:368
> > #10 0x08069ae5 in XorpMemberCallback0B0<bool,
> Vrrp>::dispatch (this=0x88b1cc8)
> >? ? ? at
> ../libxorp/callback_nodebug.hh:286
> > #11 0xb7f6e870 in PeriodicTimerNode2::expire
> (this=0x88afd18, t=@0xbfa9b0c0)
> >? ? ? at timer.cc:183
> > #12 0xb7f6b7d7 in TimerList::expire_one
> (this=0xbfa9f078, worst_priority=4)
> >? ? ? at timer.cc:441
> > #13 0xb7f6b940 in TimerList::run (this=0xbfa9f078) at
> timer.cc:389
> > #14 0xb7f44746 in EventLoop::do_work (this=0xbfa9f074,
> can_block=true)
> >? ? ? at eventloop.cc:153
> > ---Type<return>? to continue, or
> q<return>? to quit---
> > #15 0xb7f44a3c in EventLoop::run (this=0xbfa9f074) at
> eventloop.cc:99
> > #16 0x08059188 in start () at xorp_vrrp.cc:45
> > #17 0x080592bd in main (argc=Cannot access memory at
> address 0x483
> > ) at xorp_vrrp.cc:58
> 
> If you can reproduce this with latest svn tree, then we can
> probably
> fix it.? No one that I know of is making any changes
> to the 1.6 code though.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 


      


From esj at cs.fiu.edu  Thu Feb 11 11:50:06 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 11 Feb 2010 14:50:06 -0500
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <922010.41464.qm@web58702.mail.re1.yahoo.com> 
References: <922010.41464.qm@web58702.mail.re1.yahoo.com>
Message-ID: <20100211195007.9A520B8843D@cheetah.cs.fiu.edu>


lizhaous2000 at yahoo.com said:
> I am using 1.6. Anybody has experiences using VRRP to configure eth
> interface failover?

I had similar issues with VRRP on 1.6 and linux. I basically 
gave up and used a standalone vrrp daemon (vrrpd) "under" xorp
for VRRP functionality. That seems to be working fine.

As an aside I can't even begin the build of the SVN version, 
the scons doesn't seem to be working on CentOS 5.4

Anyone have a clue on what I am missing?

E

--


[root at test-router xorp-svn-20100211]# gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)

[root at test-router xorp-svn-20100211]# scons
scons: Reading SConscript files ...
Mkdir("/opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu")
Mkdir("/opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu")
scons: *** /opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu: File exists
Build System Type:  i686-pc-linux-gnu
Host System Type:   i686-pc-linux-gnu
Source path:        /opt/router/src/xorp-svn-20100211
Build path:         /opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu
Install prefix:     /usr/local/xorp
CC:                gcc
CXX:               g++
STRIP:             strip
Strip binaries:    True
Optimize code:     yes
Profile code:      no
Default XRL transport: local
Shared libraries:  True
Use rtld ORIGIN:   True
Ignore check errors:  False
Debug symbols:     full
Debug STL:         False
Debug messages:    False
Debug function names:  False
Debug callbacks:   False
Debug XRL syntax:  False
Checking for Boost version >= 1.39... no
Checking for Boost regex library... yes
Checking whether byte ordering is bigendian... (cached) no
Checking for C header file stdint.h... yes
Checking for C header file inttypes.h... yes
Checking for C type int8_t... yes
Checking for C type uint8_t... yes
Checking for C type int16_t... yes
Checking for C type uint16_t... yes
Checking for C type int32_t... yes
Checking for C type uint32_t... yes
Checking for C type int64_t... yes
Checking for C type uint64_t... yes
Checking for C header file stddef.h... yes
Checking for C header file stdarg.h... yes
Checking for C header file stdlib.h... yes
Checking for C header file strings.h... yes
Checking for C header file string.h... yes
Checking for C header file signal.h... yes
Checking for C header file math.h... yes
Checking for C header file memory.h... yes
Checking for C function strftime()... yes
Checking for C function strlcpy()... no
Checking for C function strlcat()... no
Checking whether va_copy is declared... yes
Checking for C header file sys/types.h... yes
Checking for C header file fcntl.h... yes
Checking for C header file getopt.h... yes
Checking for C header file glob.h... yes
Checking for C header file grp.h... yes
Checking for C header file pthread.h... yes
Checking for C header file pwd.h... yes
Checking for C header file mqueue.h... yes
Checking for C header file syslog.h... yes
Checking for C header file termios.h... yes
Checking for C header file time.h... yes
Checking for C header file unistd.h... yes
Checking for C header file vfork.h... no
Checking for C function readv()... yes
Checking for C function strerror()... yes
Checking for C function syslog()... yes
Checking for C function uname()... yes
Checking for C function writev()... yes
Checking for C library xnet... no
Checking for C function recvmsg()... yes
Checking for C function sendmsg()... yes
Checking for C library rt... yes
Checking for C function clock_gettime()... yes
Checking whether CLOCK_MONOTONIC is declared... yes
Checking whether CLOCK_MONOTONIC_FAST is declared... no
Checking for C type struct timespec... yes
Checking for C header file paths.h... yes
Checking for C header file sysexits.h... yes
Checking for C function realpath()... yes
Checking for C function strptime()... yes
Checking for C function sysctl()... yes
Checking for C header file netdb.h... yes
Checking for C library resolv... yes
Checking for C function hstrerror()... yes
Checking for C header file sys/cdefs.h... yes
Checking for C header file sys/param.h... yes
Checking for C header file sys/utsname.h... yes
Checking for C header file sys/errno.h... yes
Checking for C header file sys/wait.h... yes
Checking for C header file sys/signal.h... yes
Checking for C header file sys/time.h... yes
Checking for C header file sys/uio.h... yes
Checking for C header file sys/ioctl.h... yes
Checking for C header file sys/select.h... yes
Checking for C header file sys/socket.h... yes
Checking for C header file sys/sockio.h... no
Checking for C header file sys/un.h... yes
Checking for C header file sys/mount.h... yes
Checking for C header file sys/resource.h... yes
Checking for C header file sys/stat.h... yes
Checking for C header file sys/syslog.h... yes
Checking for C header file sys/linker.h... no
Checking for C header file sys/sysctl.h... yes
Checking for C header file linux/types.h... yes
Checking for C header file linux/sockios.h... yes
Checking for C type struct iovec... yes
Checking for C type struct msghdr... yes
Checking for C type struct cmsghdr... yes
Checking whether AF_INET is declared... yes
Checking whether AF_INET6 is declared... yes
Checking whether SOCK_STREAM is declared... yes
Checking whether SOCK_DGRAM is declared... yes
Checking whether SOCK_RAW is declared... yes
Checking whether C type struct msghdr has member msg_control... yes
Checking whether C type struct msghdr has member msg_iov... yes
Checking whether C type struct msghdr has member msg_name... yes
Checking whether C type struct msghdr has member msg_namelen... yes
Checking whether C type struct sockaddr has member sa_len... no
Checking whether C type struct sockaddr_storage has member ss_len... no
Checking whether C type struct sockaddr_un has member sun_len... no
Checking for C header file net/ethernet.h... yes
Checking for C header file sys/ethernet.h... no
Checking for C header file net/if.h... yes
Checking for C header file net/if_arp.h... yes
Checking for C header file net/if_dl.h... no
Checking for C header file net/if_ether.h... no
Checking for C header file net/if_media.h... no
Checking for C header file net/if_var.h... no
Checking for C header file net/if_types.h... no
Checking for C header file net/route.h... yes
Checking for C header file ifaddrs.h... yes
Checking for C header file stropts.h... yes
Checking for C header file linux/ethtool.h... yes
Checking for C header file linux/if_tun.h... yes
Checking for C header file linux/netlink.h... yes
Checking for C header file linux/rtnetlink.h... yes
Checking whether RTA_TABLE is declared... yes
Checking whether C type struct sockaddr_dl has member sdl_len... no
Checking whether C type struct ifreq has member ifr_hwaddr... yes
Checking whether C type struct ifreq has member ifr_ifindex... yes
Checking for C function ether_aton()... yes
Checking for C function ether_aton_r()... yes
Checking for C function ether_ntoa()... yes
Checking for C function ether_ntoa_r()... yes
Checking for C function getaddrinfo()... yes
Checking for C function getifaddrs()... yes
Checking for C function getnameinfo()... yes
Checking for C function if_indextoname()... yes
Checking for C function if_nametoindex()... yes
Checking for C function inet_ntop()... yes
Checking for C function inet_pton()... yes
Checking for C type struct ether_addr... yes
Checking whether system has sysctl NET_RT_DUMP... no
Checking whether system has sysctl NET_RT_IFLIST... no
Checking whether SIOCGIFCONF is declared... yes
Checking for C header file netinet/in.h... yes
Checking for C header file netinet/in_systm.h... yes
Checking for C header file netinet/in_var.h... no
Checking for C header file netinet/ip.h... yes
Checking for C header file netinet/tcp.h... yes
Checking for C header file netinet/igmp.h... yes
Checking for C header file netinet/ether.h... yes
Checking for C header file netinet/if_ether.h... yes
Checking for C header file inet/nd.h... no
Checking for C header file inet/ip.h... no
Checking for C header file arpa/inet.h... yes
Checking for C header file arpa/telnet.h... yes
Checking whether C type struct sockaddr_in has member sin_len... no
Checking whether IP_MULTICAST_IF is declared... yes
Checking whether IP_MULTICAST_TTL is declared... yes
Checking whether IP_MULTICAST_LOOP is declared... yes
Checking whether IP_ADD_MEMBERSHIP is declared... yes
Checking whether IP_DROP_MEMBERSHIP is declared... yes
Checking whether system has sysctl IPCTL_FORWARDING... no
Checking whether __KAME__ is declared... no
Checking whether inet6_opt_init is declared... yes
Checking whether C type struct sockaddr_in6 has member sin6_len... no
Checking whether C type struct sockaddr_in6 has member sin6_scope_id... yes
Checking for C header file netinet/ip6.h... yes
Checking for C header file netinet/icmp6.h... yes
Checking for C type struct mld_hdr... yes
Checking for C header file netinet6/in6_var.h... no
Checking for C header file netinet6/nd6.h... no
Checking for C++ header file netinet6/nd6.h... no
Checking whether system has sysctl IPV6CTL_FORWARDING... no
Checking whether system has sysctl IPV6CTL_ACCEPT_RTADV... no
Checking whether IPV6_MULTICAST_IF is declared... yes
Checking whether IPV6_MULTICAST_LOOP is declared... yes
Checking for C header file netinet/ip_mroute.h... no
Checking for C header file net/ip_mroute/ip_mroute.h... no
Checking for C header file linux/mroute.h... no
Checking for C type struct mfcctl2... no
Checking whether C type struct mfcctl2 has member mfcc_flags... no
Checking whether C type struct mfcctl2 has member mfcc_rp... no
Checking for C header file netinet/pim.h... no
Checking for C type struct pim... no
Checking whether C type struct pim has member pim_vt... no
Checking for C header file netinet6/ip6_mroute.h... no
Checking for C header file linux/mroute6.h... no
Checking for C type struct mf6cctl2... no
Checking whether C type struct mf6cctl2 has member mf6cc_flags... no
Checking whether C type struct mf6cctl2 has member mf6cc_rp... no
Checking for C header file netinet/ip_compat.h... no
Checking for C header file netinet/ip_fil.h... no
Checking for C header file netinet/ip_fw.h... no
Checking for C header file net/pfvar.h... no
Checking for C++ header file linux/netfilter_ipv4/ip_tables.h... no
Checking for C++ header file linux/netfilter_ipv6/ip6_tables.h... no
Checking for C header file net/if_vlanvar.h... no
Checking for C header file net/if_vlan_var.h... no
Checking for C header file net/vlan/if_vlan_var.h... no
Checking for C header file linux/if_vlan.h... yes
Checking for C header file openssl/md5.h... yes
Checking for C library crypto... no
Checking for C function MD5_Init()... no
Checking for C header file dlfcn.h... yes
Checking for C library dl... yes
Checking for C function dlopen()... yes
Checking for C header file pcap.h... yes
Checking for C library pcap... yes
Checking for C function pcap_sendpacket()... yes
Checking for C library curses... yes
Detected libraries: boost_regex rt resolv dl pcap curses
TypeError: expected a character buffer object:
  File "/opt/router/src/xorp-svn-20100211/SConstruct", line 482:
    Split(env['CFLAGS']))
  File "/opt/router/src/xorp-svn-20100211/SConstruct", line 481:
    lambda s: not s.startswith(tuple(strip_pg_flags)),


From lizhaous2000 at yahoo.com  Thu Feb 11 12:42:08 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 11 Feb 2010 12:42:08 -0800 (PST)
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <20100211195007.9A520B8843D@cheetah.cs.fiu.edu>
Message-ID: <277379.80478.qm@web58702.mail.re1.yahoo.com>

Then probably we have to fix xorp_vrrp.

--- On Thu, 2/11/10, Eric S. Johnson <esj at cs.fiu.edu> wrote:

> From: Eric S. Johnson <esj at cs.fiu.edu>
> Subject: Re: [Xorp-hackers] vrrp sigabrt in release 1.6
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "Ben Greear" <greearb at candelatech.com>, xorp-hackers at xorp.org
> Date: Thursday, February 11, 2010, 2:50 PM
> 
> lizhaous2000 at yahoo.com
> said:
> > I am using 1.6. Anybody has experiences using VRRP to
> configure eth
> > interface failover?
> 
> I had similar issues with VRRP on 1.6 and linux. I
> basically 
> gave up and used a standalone vrrp daemon (vrrpd) "under"
> xorp
> for VRRP functionality. That seems to be working fine.
> 
> As an aside I can't even begin the build of the SVN
> version, 
> the scons doesn't seem to be working on CentOS 5.4
> 
> Anyone have a clue on what I am missing?
> 
> E
> 
> --
> 
> 
> [root at test-router xorp-svn-20100211]# gcc -v
> Using built-in specs.
> Target: i386-redhat-linux
> Configured with: ../configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib
> --enable-__cxa_atexit --disable-libunwind-exceptions
> --enable-libgcj-multifile
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi --enable-plugin
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --with-cpu=generic --host=i386-redhat-linux
> Thread model: posix
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
> 
> [root at test-router xorp-svn-20100211]# scons
> scons: Reading SConscript files ...
> Mkdir("/opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu")
> Mkdir("/opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu")
> scons: ***
> /opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu:
> File exists
> Build System Type:? i686-pc-linux-gnu
> Host System Type:???i686-pc-linux-gnu
> Source path:? ? ? ?
> /opt/router/src/xorp-svn-20100211
> Build path:? ? ?
> ???/opt/router/src/xorp-svn-20100211/obj/i686-pc-linux-gnu
> Install prefix:? ???/usr/local/xorp
> CC:? ? ? ? ? ? ? ?
> gcc
> CXX:? ? ? ? ? ?
> ???g++
> STRIP:? ? ? ? ?
> ???strip
> Strip binaries:? ? True
> Optimize code:? ???yes
> Profile code:? ? ? no
> Default XRL transport: local
> Shared libraries:? True
> Use rtld ORIGIN:???True
> Ignore check errors:? False
> Debug symbols:? ???full
> Debug STL:? ? ? ???False
> Debug messages:? ? False
> Debug function names:? False
> Debug callbacks:???False
> Debug XRL syntax:? False
> Checking for Boost version >= 1.39... no
> Checking for Boost regex library... yes
> Checking whether byte ordering is bigendian... (cached) no
> Checking for C header file stdint.h... yes
> Checking for C header file inttypes.h... yes
> Checking for C type int8_t... yes
> Checking for C type uint8_t... yes
> Checking for C type int16_t... yes
> Checking for C type uint16_t... yes
> Checking for C type int32_t... yes
> Checking for C type uint32_t... yes
> Checking for C type int64_t... yes
> Checking for C type uint64_t... yes
> Checking for C header file stddef.h... yes
> Checking for C header file stdarg.h... yes
> Checking for C header file stdlib.h... yes
> Checking for C header file strings.h... yes
> Checking for C header file string.h... yes
> Checking for C header file signal.h... yes
> Checking for C header file math.h... yes
> Checking for C header file memory.h... yes
> Checking for C function strftime()... yes
> Checking for C function strlcpy()... no
> Checking for C function strlcat()... no
> Checking whether va_copy is declared... yes
> Checking for C header file sys/types.h... yes
> Checking for C header file fcntl.h... yes
> Checking for C header file getopt.h... yes
> Checking for C header file glob.h... yes
> Checking for C header file grp.h... yes
> Checking for C header file pthread.h... yes
> Checking for C header file pwd.h... yes
> Checking for C header file mqueue.h... yes
> Checking for C header file syslog.h... yes
> Checking for C header file termios.h... yes
> Checking for C header file time.h... yes
> Checking for C header file unistd.h... yes
> Checking for C header file vfork.h... no
> Checking for C function readv()... yes
> Checking for C function strerror()... yes
> Checking for C function syslog()... yes
> Checking for C function uname()... yes
> Checking for C function writev()... yes
> Checking for C library xnet... no
> Checking for C function recvmsg()... yes
> Checking for C function sendmsg()... yes
> Checking for C library rt... yes
> Checking for C function clock_gettime()... yes
> Checking whether CLOCK_MONOTONIC is declared... yes
> Checking whether CLOCK_MONOTONIC_FAST is declared... no
> Checking for C type struct timespec... yes
> Checking for C header file paths.h... yes
> Checking for C header file sysexits.h... yes
> Checking for C function realpath()... yes
> Checking for C function strptime()... yes
> Checking for C function sysctl()... yes
> Checking for C header file netdb.h... yes
> Checking for C library resolv... yes
> Checking for C function hstrerror()... yes
> Checking for C header file sys/cdefs.h... yes
> Checking for C header file sys/param.h... yes
> Checking for C header file sys/utsname.h... yes
> Checking for C header file sys/errno.h... yes
> Checking for C header file sys/wait.h... yes
> Checking for C header file sys/signal.h... yes
> Checking for C header file sys/time.h... yes
> Checking for C header file sys/uio.h... yes
> Checking for C header file sys/ioctl.h... yes
> Checking for C header file sys/select.h... yes
> Checking for C header file sys/socket.h... yes
> Checking for C header file sys/sockio.h... no
> Checking for C header file sys/un.h... yes
> Checking for C header file sys/mount.h... yes
> Checking for C header file sys/resource.h... yes
> Checking for C header file sys/stat.h... yes
> Checking for C header file sys/syslog.h... yes
> Checking for C header file sys/linker.h... no
> Checking for C header file sys/sysctl.h... yes
> Checking for C header file linux/types.h... yes
> Checking for C header file linux/sockios.h... yes
> Checking for C type struct iovec... yes
> Checking for C type struct msghdr... yes
> Checking for C type struct cmsghdr... yes
> Checking whether AF_INET is declared... yes
> Checking whether AF_INET6 is declared... yes
> Checking whether SOCK_STREAM is declared... yes
> Checking whether SOCK_DGRAM is declared... yes
> Checking whether SOCK_RAW is declared... yes
> Checking whether C type struct msghdr has member
> msg_control... yes
> Checking whether C type struct msghdr has member msg_iov...
> yes
> Checking whether C type struct msghdr has member
> msg_name... yes
> Checking whether C type struct msghdr has member
> msg_namelen... yes
> Checking whether C type struct sockaddr has member
> sa_len... no
> Checking whether C type struct sockaddr_storage has member
> ss_len... no
> Checking whether C type struct sockaddr_un has member
> sun_len... no
> Checking for C header file net/ethernet.h... yes
> Checking for C header file sys/ethernet.h... no
> Checking for C header file net/if.h... yes
> Checking for C header file net/if_arp.h... yes
> Checking for C header file net/if_dl.h... no
> Checking for C header file net/if_ether.h... no
> Checking for C header file net/if_media.h... no
> Checking for C header file net/if_var.h... no
> Checking for C header file net/if_types.h... no
> Checking for C header file net/route.h... yes
> Checking for C header file ifaddrs.h... yes
> Checking for C header file stropts.h... yes
> Checking for C header file linux/ethtool.h... yes
> Checking for C header file linux/if_tun.h... yes
> Checking for C header file linux/netlink.h... yes
> Checking for C header file linux/rtnetlink.h... yes
> Checking whether RTA_TABLE is declared... yes
> Checking whether C type struct sockaddr_dl has member
> sdl_len... no
> Checking whether C type struct ifreq has member
> ifr_hwaddr... yes
> Checking whether C type struct ifreq has member
> ifr_ifindex... yes
> Checking for C function ether_aton()... yes
> Checking for C function ether_aton_r()... yes
> Checking for C function ether_ntoa()... yes
> Checking for C function ether_ntoa_r()... yes
> Checking for C function getaddrinfo()... yes
> Checking for C function getifaddrs()... yes
> Checking for C function getnameinfo()... yes
> Checking for C function if_indextoname()... yes
> Checking for C function if_nametoindex()... yes
> Checking for C function inet_ntop()... yes
> Checking for C function inet_pton()... yes
> Checking for C type struct ether_addr... yes
> Checking whether system has sysctl NET_RT_DUMP... no
> Checking whether system has sysctl NET_RT_IFLIST... no
> Checking whether SIOCGIFCONF is declared... yes
> Checking for C header file netinet/in.h... yes
> Checking for C header file netinet/in_systm.h... yes
> Checking for C header file netinet/in_var.h... no
> Checking for C header file netinet/ip.h... yes
> Checking for C header file netinet/tcp.h... yes
> Checking for C header file netinet/igmp.h... yes
> Checking for C header file netinet/ether.h... yes
> Checking for C header file netinet/if_ether.h... yes
> Checking for C header file inet/nd.h... no
> Checking for C header file inet/ip.h... no
> Checking for C header file arpa/inet.h... yes
> Checking for C header file arpa/telnet.h... yes
> Checking whether C type struct sockaddr_in has member
> sin_len... no
> Checking whether IP_MULTICAST_IF is declared... yes
> Checking whether IP_MULTICAST_TTL is declared... yes
> Checking whether IP_MULTICAST_LOOP is declared... yes
> Checking whether IP_ADD_MEMBERSHIP is declared... yes
> Checking whether IP_DROP_MEMBERSHIP is declared... yes
> Checking whether system has sysctl IPCTL_FORWARDING... no
> Checking whether __KAME__ is declared... no
> Checking whether inet6_opt_init is declared... yes
> Checking whether C type struct sockaddr_in6 has member
> sin6_len... no
> Checking whether C type struct sockaddr_in6 has member
> sin6_scope_id... yes
> Checking for C header file netinet/ip6.h... yes
> Checking for C header file netinet/icmp6.h... yes
> Checking for C type struct mld_hdr... yes
> Checking for C header file netinet6/in6_var.h... no
> Checking for C header file netinet6/nd6.h... no
> Checking for C++ header file netinet6/nd6.h... no
> Checking whether system has sysctl IPV6CTL_FORWARDING...
> no
> Checking whether system has sysctl IPV6CTL_ACCEPT_RTADV...
> no
> Checking whether IPV6_MULTICAST_IF is declared... yes
> Checking whether IPV6_MULTICAST_LOOP is declared... yes
> Checking for C header file netinet/ip_mroute.h... no
> Checking for C header file net/ip_mroute/ip_mroute.h... no
> Checking for C header file linux/mroute.h... no
> Checking for C type struct mfcctl2... no
> Checking whether C type struct mfcctl2 has member
> mfcc_flags... no
> Checking whether C type struct mfcctl2 has member
> mfcc_rp... no
> Checking for C header file netinet/pim.h... no
> Checking for C type struct pim... no
> Checking whether C type struct pim has member pim_vt... no
> Checking for C header file netinet6/ip6_mroute.h... no
> Checking for C header file linux/mroute6.h... no
> Checking for C type struct mf6cctl2... no
> Checking whether C type struct mf6cctl2 has member
> mf6cc_flags... no
> Checking whether C type struct mf6cctl2 has member
> mf6cc_rp... no
> Checking for C header file netinet/ip_compat.h... no
> Checking for C header file netinet/ip_fil.h... no
> Checking for C header file netinet/ip_fw.h... no
> Checking for C header file net/pfvar.h... no
> Checking for C++ header file
> linux/netfilter_ipv4/ip_tables.h... no
> Checking for C++ header file
> linux/netfilter_ipv6/ip6_tables.h... no
> Checking for C header file net/if_vlanvar.h... no
> Checking for C header file net/if_vlan_var.h... no
> Checking for C header file net/vlan/if_vlan_var.h... no
> Checking for C header file linux/if_vlan.h... yes
> Checking for C header file openssl/md5.h... yes
> Checking for C library crypto... no
> Checking for C function MD5_Init()... no
> Checking for C header file dlfcn.h... yes
> Checking for C library dl... yes
> Checking for C function dlopen()... yes
> Checking for C header file pcap.h... yes
> Checking for C library pcap... yes
> Checking for C function pcap_sendpacket()... yes
> Checking for C library curses... yes
> Detected libraries: boost_regex rt resolv dl pcap curses
> TypeError: expected a character buffer object:
> ? File "/opt/router/src/xorp-svn-20100211/SConstruct",
> line 482:
> ? ? Split(env['CFLAGS']))
> ? File "/opt/router/src/xorp-svn-20100211/SConstruct",
> line 481:
> ? ? lambda s: not
> s.startswith(tuple(strip_pg_flags)),
> 
> 


      


From mohd.arif at nechclst.in  Thu Feb  4 01:53:39 2010
From: mohd.arif at nechclst.in (Mohd Arif)
Date: Thu, 4 Feb 2010 15:23:39 +0530
Subject: [Xorp-hackers] [XORP] XORP BUG: reinterpret_cast issue in Big
	Endian (PPC Architecture)
Message-ID: <0A8CFEC45B7F4C419F7543867C47442303D0319A@mailserver.nechclst.in>

Dear All,
            Is it a serious bug? 
I have successfully built the package for PPC architecture.
On running the PPC compiled package on board, There is a severe effect
on PIM-SM functionality.
 
Issue
====
a) When I configure a router as static RP in my router card with any
priority value say 100 or default (192), the command "show pim rps"   is
always showing priority as zero for that static RP irrespective of value
specified through xorpsh. 
b) The same problem is occurring in case of Candidate-BSR priority &
Candidate-RP priority & holdtime. Bootstrap message is showing priority
as zero & Cand-RP Adv message showing RP priority & hold time as zero.
 
Reason of Issue
============
When I searched through the code, I found that at a place there was a
conversion going from uint32_t to uint8_t (reinterpret operator) for all
above mentioned values.
 I applied debug message before & after this conversion and found that
this conversion was returning 0 all the time..... However this problem
didn't occurred when I tested XORP on PC.
The problem is the difference in Endianness of Intel PC and PPC
Architecture. Intel PC is little endian whereas PPC is big endian.
For proper understanding I am attaching an image, clearly specifying
this problem.
 
My whole project has got stuck so please help me out.....Any help is
appreciable.
 
Best Regards,
Mohd. Arif



DISCLAIMER: 
----------------------------------------------------------------------------------------------------------------------- 
The contents of this e-mail and any attachment(s) are confidential and
intended 
for the named recipient(s) only.  
It shall not attach any liability on the originator or NECHCL or its 
affiliates. Any views or opinions presented in  
this email are solely those of the author and may not necessarily reflect the 
opinions of NECHCL or its affiliates.  
Any form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of  
this message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have  
received this email in error please delete it and notify the sender 
immediately. . 
-----------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100204/9382d37a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp_src_snapshot.JPG
Type: image/jpeg
Size: 97503 bytes
Desc: xorp_src_snapshot.JPG
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100204/9382d37a/attachment-0001.jpe 

From esj at cs.fiu.edu  Mon Feb 15 16:01:00 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Mon, 15 Feb 2010 19:01:00 -0500
Subject: [Xorp-hackers] Getting XORP svn to compile (and run) on Centos
	(RHEL) 5 - solution
Message-ID: <20100216000100.64567B88488@cheetah.cs.fiu.edu>


Below is a diff of $SRCTOP/SConstruct that allows the SVN xorp 
to compile on Centos5 (and I assume would work for RHEL 5 too)

The first part allowed it to find libcrypto in /usr/lib. 

The second part gets rid of the

.....
TypeError: expected a character buffer object:
  File "/opt/router/src/xorp-svn-20100211/SConstruct", line 482:
    Split(env['CFLAGS']))
  File "/opt/router/src/xorp-svn-20100211/SConstruct", line 481:
    lambda s: not s.startswith(tuple(strip_pg_flags)),

error from scons. But it is a brute force with massive ignorance solution.
I am not much of a python/scons hacker.


It builds and so far runs fine (with a simple interface/ospf config). 
I have not attacked the PIM and VRRPD issues I saw with 1.6 yet. 
Seeing if those problems still exist will be fun for tomorrow :)

E

-------



[root at test-router xorp-svn-20100211]# diff -c SConstruct.orig SConstruct
*** SConstruct.orig     2010-02-11 16:09:04.000000000 -0500
--- SConstruct  2010-02-15 13:39:10.000000000 -0500
***************
*** 136,142 ****
                  ENV = os.environ,
                  BUILDDIR = builddir,
                  CPPPATH=['/usr/local/include', '$BUILDDIR'],
!                 LIBPATH=['/usr/local/lib'],
                  variables = vars)
  
  prefix = env['prefix']
--- 136,142 ----
                  ENV = os.environ,
                  BUILDDIR = builddir,
                  CPPPATH=['/usr/local/include', '$BUILDDIR'],
!                 LIBPATH=['/usr/lib:/usr/local/lib'],
                  variables = vars)
  
  prefix = env['prefix']
***************
*** 477,490 ****
  and shared libraries. This is UNSUPPORTED, and probably will not link.
  """
      strip_pg_flags = [ '-pg', '-finstrument-functions', '-fno-omit-frame-pointer', '-fno-optimize-sibling-calls' ]
!     env.Replace( CFLAGS = filter(
!       lambda s: not s.startswith(tuple(strip_pg_flags)),
!       Split(env['CFLAGS']))
!     )
!     env.Replace( CXXFLAGS = filter(
!       lambda s: not s.startswith(tuple(strip_pg_flags)),
!       Split(env['CXXFLAGS']))
!     )
      # Full use of profiling may require more than one flag, so Split() them.
      pgdict = {'no': '',
                'gprof': '-pg',
--- 477,491 ----
  and shared libraries. This is UNSUPPORTED, and probably will not link.
  """
      strip_pg_flags = [ '-pg', '-finstrument-functions', '-fno-omit-frame-pointer', '-fno-optimize-sibling-calls' ]
! #ESJ
! #    env.Replace( CFLAGS = filter(
! #     lambda s: not s.startswith(tuple(strip_pg_flags)),
! #     Split(env['CFLAGS']))
! #    )
! #    env.Replace( CXXFLAGS = filter(
! #     lambda s: not s.startswith(tuple(strip_pg_flags)),
! #     Split(env['CXXFLAGS']))
! #    )
      # Full use of profiling may require more than one flag, so Split() them.
      pgdict = {'no': '',
                'gprof': '-pg',


From bms at incunabulum.net  Sun Feb 21 11:14:43 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun, 21 Feb 2010 19:14:43 +0000
Subject: [Xorp-hackers] Running multiple instances of a XORP process
In-Reply-To: <4B72F8FE.4050401@student.uclouvain.be>
References: <4B72F8FE.4050401@student.uclouvain.be>
Message-ID: <4B818623.2000108@incunabulum.net>

On 10/02/2010 18:20, Simon van der Linden wrote:
> Hi,
>
> I'd like to start multiple instances of the same XORP process (BGP in
> this case) on different interfaces, with different target names. Is this
> doable using config.boot or any other config hook, or should I get my
> hands dirty by touching rtrmgr or some other process?
>
> If I'm not mistaken, BGP uses any interface, so I'd have to change that
> anyway.
>    

There's no architectural reason why you can't have multiple instances, 
but you need to be sure that router manager, rib etc are looking at the 
right instance.

FWIW you'll probably need to tell RIB not to re-register the same IGP 
table, and this will probably mean reworking some of the logic in the 
processes involved.

Good luck.


From bms at incunabulum.net  Sun Feb 21 11:15:03 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun, 21 Feb 2010 19:15:03 +0000
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <44318.66818.qm@web58701.mail.re1.yahoo.com>
References: <44318.66818.qm@web58701.mail.re1.yahoo.com>
Message-ID: <4B818637.8020607@incunabulum.net>

On 10/02/2010 19:24, Li Zhao wrote:
> When I configured vrrp on one interface in linux embedded. The vrrp crashed
> because of sigabrt in VrrpTarget::check_interfaces at vrrp_target.cc:221.
>
>    

Are you able to reproduce this with SVN sources?


From esj at cs.fiu.edu  Sun Feb 21 12:54:57 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Sun, 21 Feb 2010 15:54:57 -0500
Subject: [Xorp-hackers] xorp interoperate with IOS - RFC4813 LLS and auth
Message-ID: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>


Recent versions of IOS seem to like to do RFC4813 - OSPF Link-Local
Signaling *by default*. This was not working with xorp ospf v2
speakers with MD5 auth. You can turn off ospf LLS on cisco routers with

conf t
int blahblah
    ip ospf lls disable

but this patch allows xorp to correctly inter-operate with these 4813 speakers.

xorp was assuming that an OSPF packet ended with the 16 octet
md5 checksum. With RFC4813 there can be more things beyond the md5
checksum. This patch ignores anything past the md5 checksum, and computes
the md5 checksum over the correct data.

IT DOES NOT implement RFC 4813, other than to ignore it correctly.

NOTE: this patch applies clean to xorp 1.6 also.

E


---
diff -r -U5 xorp-svn-20100217.orig/ospf/auth.cc xorp-svn-20100217/ospf/auth.cc
--- xorp-svn-20100217.orig/ospf/auth.cc 2010-02-17 10:26:02.000000000 -0500
+++ xorp-svn-20100217/ospf/auth.cc 2010-02-19 07:17:43.000000000 -0500
@@ -494,16 +494,19 @@


    MD5_CTX ctx;
    uint8_t digest[MD5_DIGEST_LENGTH];


+ // length to compute MD5 over
+ uint32_t md5_packet_length = extract_16(&ptr[Packet::LEN_OFFSET]);
+

    MD5_Init(&ctx);

- MD5_Update(&ctx, &ptr[0], pkt.size() - MD5_DIGEST_LENGTH);
+ MD5_Update(&ctx, &ptr[0], md5_packet_length);

    MD5_Update(&ctx, key->key_data(), key->key_data_bytes());
    MD5_Final(&digest[0], &ctx);


- if (0 != memcmp(&digest[0], &ptr[pkt.size() - MD5_DIGEST_LENGTH],
+ if (0 != memcmp(&digest[0], &ptr[md5_packet_length],

    MD5_DIGEST_LENGTH)) {

    set_error(c_format("authentication digest doesn't match local key "

        "(key ID = %d)", key->id()));

    // #define DUMP_BAD_MD5
    #ifdef DUMP_BAD_MD5


From aleksandar.cvjetic at gmail.com  Sun Feb 21 13:42:02 2010
From: aleksandar.cvjetic at gmail.com (Aleksandar Cvjetic)
Date: Sun, 21 Feb 2010 22:42:02 +0100
Subject: [Xorp-hackers] BGP decision process
Message-ID: <249ccfe91002211342y3235143bo5eca97b9f1a553bc@mail.gmail.com>

Hello,

If i understand well code in route_table_decision.cc, new route comming from
a peer is added to the end of the list of alternative routes (*alternatives*)
and compared with ALL others routes in that list (not only with previous
winner), right? In the function implementing decision process ( *
find_winner()* ) alternative routes are eliminated one-by-one up to the step
where only one remains. At the end of decision process, the remaining route
(new winner) may be newly-received route, previous winner or even some third
route in the *alternatives* list, rignt? Is there a way to take back (from
list of alternatives) just recently received route (new route) if, after
several decision process steps (call them "AS-wide"), more then one route
remains in decision process and forward that route downstream the pipeline
stopping decision process? This may sound confusing, but I'm trying to play
with possibility of advertising more then one iBGP routes into an AS, by
advertising newly received route and not deleting previous winner (under
some circumstances).

Thank you,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100221/fd920b4d/attachment.html 

From greearb at candelatech.com  Mon Feb 22 10:19:22 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 22 Feb 2010 10:19:22 -0800
Subject: [Xorp-hackers] Getting XORP svn to compile (and run) on Centos
 (RHEL) 5 - solution
In-Reply-To: <20100216000100.64567B88488@cheetah.cs.fiu.edu>
References: <20100216000100.64567B88488@cheetah.cs.fiu.edu>
Message-ID: <4B82CAAA.9040304@candelatech.com>

On 02/15/2010 04:01 PM, Eric S. Johnson wrote:
>
> Below is a diff of $SRCTOP/SConstruct that allows the SVN xorp
> to compile on Centos5 (and I assume would work for RHEL 5 too)
>
> The first part allowed it to find libcrypto in /usr/lib.

This builds fine for me on F11, so adding that to my tree.

Thanks for the patch.

>
> The second part gets rid of the
>
> .....
> TypeError: expected a character buffer object:
>    File "/opt/router/src/xorp-svn-20100211/SConstruct", line 482:
>      Split(env['CFLAGS']))
>    File "/opt/router/src/xorp-svn-20100211/SConstruct", line 481:
>      lambda s: not s.startswith(tuple(strip_pg_flags)),
>
> error from scons. But it is a brute force with massive ignorance solution.
> I am not much of a python/scons hacker.

Can you let us know the version of Python you are using?

Maybe scons too?

python --version
scons --version

Maybe we can conditionally ignore that code for just those versions until
someone comes up with a better fix.  I don't want to disable it for the
systems where it works.

> It builds and so far runs fine (with a simple interface/ospf config).
> I have not attacked the PIM and VRRPD issues I saw with 1.6 yet.
> Seeing if those problems still exist will be fun for tomorrow :)

Any luck reproducing the PIM and VRRPD issues you reported
in the svn tree code?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Mon Feb 22 10:23:40 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 22 Feb 2010 10:23:40 -0800
Subject: [Xorp-hackers] xorp interoperate with IOS - RFC4813 LLS and auth
In-Reply-To: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
Message-ID: <4B82CBAC.1020505@candelatech.com>

On 02/21/2010 12:54 PM, Eric S. Johnson wrote:
>
> Recent versions of IOS seem to like to do RFC4813 - OSPF Link-Local
> Signaling *by default*. This was not working with xorp ospf v2
> speakers with MD5 auth. You can turn off ospf LLS on cisco routers with
>
> conf t
> int blahblah
>      ip ospf lls disable
>
> but this patch allows xorp to correctly inter-operate with these 4813 speakers.
>
> xorp was assuming that an OSPF packet ended with the 16 octet
> md5 checksum. With RFC4813 there can be more things beyond the md5
> checksum. This patch ignores anything past the md5 checksum, and computes
> the md5 checksum over the correct data.
>
> IT DOES NOT implement RFC 4813, other than to ignore it correctly.
>
> NOTE: this patch applies clean to xorp 1.6 also.

Bruce:  Do you plan to add this to your upstream tree?  If so, I'll wait
for you and pull it into my tree.  Otherwise, I'll put it in my tree
directly.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From esj at cs.fiu.edu  Mon Feb 22 11:37:59 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Mon, 22 Feb 2010 14:37:59 -0500
Subject: [Xorp-hackers] Getting XORP svn to compile (and run) on Centos
	(RHEL) 5 - solution
In-Reply-To: <4B82CAAA.9040304@candelatech.com> 
References: <20100216000100.64567B88488@cheetah.cs.fiu.edu>
	<4B82CAAA.9040304@candelatech.com>
Message-ID: <20100222193759.59991B8843D@cheetah.cs.fiu.edu>


>Can you let us know the version of Python you are using?

[root at test-router router]# scons --version
SCons by Steven Knight et al.:
        script: v1.2.0.r3842, 2008/12/20 22:59:52, by scons on scons-dev
        engine: v1.2.0.r3842, 2008/12/20 22:59:52, by scons on scons-dev
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation

[root at test-router router]# python -V
Python 2.4.3

rpms are

python-2.4.3-27.el5
python-devel-2.4.3-27.el5
scons-1.2.0-1.el5.rf


Based on some input from Bruce, I changed the $SRCTOP/SConstruct to 
use python lists for LIBPATH.

Also, after running it I found that there was no "multicast" since mroute.h
didn't compile. Some existing comments clued me in, but I clarified 
the problem in BUILD_NOTES in a new section for centos 5.

below are my "centos 5" patches for the latest SVN.

I put these in the sourceforge trac system too..

>Any luck reproducing the PIM and VRRPD issues you reported
>in the svn tree code?

PIM/IGMPv2 is working great for me with the svn code. Have not yet played 
with VRRPD.

E




diff -r -U5 xorp-svn-20100217.orig/BUILD_NOTES xorp-svn-20100217/BUILD_NOTES
--- xorp-svn-20100217.orig/BUILD_NOTES  2010-02-17 10:26:48.000000000 -0500
+++ xorp-svn-20100217/BUILD_NOTES       2010-02-17 10:48:54.000000000 -0500
@@ -384,10 +384,25 @@
       - libpcap-devel
         This package is needed for sending/receiving link layer data frames.
     - The code compiles, and the internal tests appear to succeed.
     - gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)
 
+  * Linux CentOS 5.4 (2.6.18-164.6.1.el5)
+    - You must install the following packages:
+      - gcc
+      - gcc-c++
+      - openssl-devel
+      - scons-1.2.0-1.el5.rf
+    - Optionally install the following packages:
+      - libpcap-devel
+        This package is needed for sending/receiving link layer data frames.
+    - gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
+    - must comment out:  if has_netinet_in_h:
+                             prereq_linux_mroute_h.append('netinet/in.h')
+      around line 550 of site_scons/config/allconfig.py
+
+
   * Linux Debian-3.1 (sarge) (2.4.27-3-386):
     - You must install the following packages:
       - libssl (e.g., libssl0.9.7)
       - libssl-dev
       - gcc (e.g., gcc-3.3)
diff -r -U5 xorp-svn-20100217.orig/SConstruct xorp-svn-20100217/SConstruct
--- xorp-svn-20100217.orig/SConstruct   2010-02-17 10:26:48.000000000 -0500
+++ xorp-svn-20100217/SConstruct        2010-02-21 15:04:25.000000000 -0500
@@ -134,11 +134,11 @@
                  TOOLS = ['default', 'autotest', 'clntgen', 'tgtgen',
                           'TOOL_SUBST'],
                  ENV = os.environ,
                  BUILDDIR = builddir,
                  CPPPATH=['/usr/local/include', '$BUILDDIR'],
-                 LIBPATH=['/usr/local/lib'],
+                 LIBPATH=['/usr/lib', '/usr/local/lib'],
                  variables = vars)
 
 prefix = env['prefix']
 
 print 'Build System Type: ', build
@@ -475,18 +475,19 @@
         print """
 WARNING: You have requested GNU gprof style profiling
 and shared libraries. This is UNSUPPORTED, and probably will not link.
 """
     strip_pg_flags = [ '-pg', '-finstrument-functions', '-fno-omit-frame-pointer', '-fno-optimize-sibling-calls' ]
-    env.Replace( CFLAGS = filter(
-       lambda s: not s.startswith(tuple(strip_pg_flags)),
-       Split(env['CFLAGS']))
-    )
-    env.Replace( CXXFLAGS = filter(
-       lambda s: not s.startswith(tuple(strip_pg_flags)),
-       Split(env['CXXFLAGS']))
-    )
+#ESJ
+#    env.Replace( CFLAGS = filter(
+#      lambda s: not s.startswith(tuple(strip_pg_flags)),
+#      Split(env['CFLAGS']))
+#    )
+#    env.Replace( CXXFLAGS = filter(
+#      lambda s: not s.startswith(tuple(strip_pg_flags)),
+#      Split(env['CXXFLAGS']))
+#    )
     # Full use of profiling may require more than one flag, so Split() them.
     pgdict = {'no': '',
               'gprof': '-pg',
               'pprof': '',
     }
diff -r -U5 xorp-svn-20100217.orig/site_scons/config/allconfig.py xorp-svn-20100217/site_scons/config/allconfig.py
--- xorp-svn-20100217.orig/site_scons/config/allconfig.py       2010-02-17 10:26:14.000000000 -0500
+++ xorp-svn-20100217/site_scons/config/allconfig.py    2010-02-17 10:48:54.000000000 -0500
@@ -541,17 +541,20 @@
     # TODO: The autoconf feature test for this contained a hack to exclude 
     # <linux/in.h> that might be included by <linux/mroute.h>, because
     # <linux/in.h> might conflict with <netinet/in.h> that was included
     # earlier.  This is currently difficult to replicate in SCons, as
     # you can't pass arbitrary code that is prepended to the test.
+    #
+    # for Centos5 at least, netinet/in.h is not needed and breaks things
+    #
     prereq_linux_mroute_h = []
     if has_sys_types_h:
        prereq_linux_mroute_h.append('sys/types.h')
     if has_sys_socket_h:
        prereq_linux_mroute_h.append('sys/socket.h')
-    if has_netinet_in_h:
-       prereq_linux_mroute_h.append('netinet/in.h')
+    #if has_netinet_in_h:
+    #   prereq_linux_mroute_h.append('netinet/in.h')
     if has_linux_types_h:
        prereq_linux_mroute_h.append('linux/types.h')
     linux_mroute_h = 'linux/mroute.h'
     has_linux_mroute_h = conf.CheckHeader(prereq_linux_mroute_h + [ linux_mroute_h ])
     if has_linux_mroute_h:


From esj at cs.fiu.edu  Wed Feb 24 07:57:20 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Wed, 24 Feb 2010 10:57:20 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B82CBAC.1020505@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
Message-ID: <20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>


Ok, I got VRRP to  *almost* work with SVN xorp on Centos 5.
Without patch below it will start, but will crash as soon as 
it becomes master for an interface.

It is a hack patch, because basically there are two defines 
that scons doesn't catch and make, but configure used to...
There is probably a better way to do this with scons... 

But now I think I am about where I was with 1.6 back last fall.

What happens now when you become master is:

xorp will report it is master 
xorp will change the MAC on the interface to appropriate virtual mac.
xorp doesn't seem to add the virtual IP to the interface.
(you can manually add via "ip addr add blah dev blah"  on the
command line and it seems to work.)
xorp starts logging errors of the type: 

[ 2010/02/24 10:04:19 WARNING xorp_fea FEA ] Received packet on interface eth0.21 vif eth0.21: packet is too short (captured 56 expecting at least 60 octets)

(which I remember from playing with 1.6 last fall too, but don't remember 
what I found out when investigating)

So anyway, Ill be probing further as time permits.

E


---

diff -ru xorp-svn-20100217.orig/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc xorp-svn-20100217/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
--- xorp-svn-20100217.orig/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc       2010-02-17 10:25:17.000000000 -0500
+++ xorp-svn-20100217/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc    2010-02-24 10:27:49.000000000 -0500
@@ -538,6 +538,8 @@
     else
        interface_flags &= ~IFF_UP;
 
+// ESJ
+#define HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
 #ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
     static const size_t        buffer_size = sizeof(struct nlmsghdr)
        + sizeof(struct ifinfomsg) + 2*sizeof(struct rtattr) + 512;
diff -ru xorp-svn-20100217.orig/fea/data_plane/io/io_link_pcap.hh xorp-svn-20100217/fea/data_plane/io/io_link_pcap.hh
--- xorp-svn-20100217.orig/fea/data_plane/io/io_link_pcap.hh    2010-02-17 10:25:18.000000000 -0500
+++ xorp-svn-20100217/fea/data_plane/io/io_link_pcap.hh 2010-02-23 16:39:18.000000000 -0500
@@ -34,6 +34,7 @@
 
 #ifdef HAVE_PCAP_H
 #include <pcap.h>
+#define HAVE_PCAP
 #endif
 
 #include "fea/io_link.hh"




From lizhaous2000 at yahoo.com  Wed Feb 24 08:05:50 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 24 Feb 2010 08:05:50 -0800 (PST)
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <4B818637.8020607@incunabulum.net>
Message-ID: <889500.7920.qm@web58707.mail.re1.yahoo.com>

I can reproduce that with 1.6 on my system. I noticed xorp_fea aborted in 
IoLinkComm::remove_filter at io_link_manager.cc:241 first. Then xorp_vrrp crashed.

--- On Sun, 2/21/10, Bruce Simpson <bms at incunabulum.net> wrote:

> From: Bruce Simpson <bms at incunabulum.net>
> Subject: Re: [Xorp-hackers] vrrp sigabrt in release 1.6
> To: xorp-hackers at icir.org
> Date: Sunday, February 21, 2010, 2:15 PM
> On 10/02/2010 19:24, Li Zhao wrote:
> > When I configured vrrp on one interface in linux
> embedded. The vrrp crashed
> > because of sigabrt in VrrpTarget::check_interfaces at
> vrrp_target.cc:221.
> >
> >? ? 
> 
> Are you able to reproduce this with SVN sources?
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From lizhaous2000 at yahoo.com  Wed Feb 24 08:51:47 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 24 Feb 2010 08:51:47 -0800 (PST)
Subject: [Xorp-hackers] IP-IP/GRE tunnel
Message-ID: <978057.83852.qm@web58705.mail.re1.yahoo.com>

Does xorp support IP-IP/GRE tunnel as special interfaces? For example, 
after we configure a tunnel, we can configure a static route using this 
tunnel as egress interface or using destination IP address on the tunnel 
as next-hop. All the configuration should be done on xorp cli. I dont want 
to configure tunnels on Linux command line. Can Linux system and windows 
system form IP-IP/GRE tunnels?

Thanks.


      


From greearb at candelatech.com  Wed Feb 24 09:22:51 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 09:22:51 -0800
Subject: [Xorp-hackers] vrrp sigabrt in release 1.6
In-Reply-To: <889500.7920.qm@web58707.mail.re1.yahoo.com>
References: <889500.7920.qm@web58707.mail.re1.yahoo.com>
Message-ID: <4B85606B.4030207@candelatech.com>

On 02/24/2010 08:05 AM, Li Zhao wrote:
> I can reproduce that with 1.6 on my system. I noticed xorp_fea aborted in
> IoLinkComm::remove_filter at io_link_manager.cc:241 first. Then xorp_vrrp crashed.

1.6 is not SVN code.

If you use my tree (based on upstream SVN tree) then I might be
able to help.  If you use the official SVN tree, then Bruce might
be able to help.

Either way, please post your xorp config and detailed steps on
how to reproduce this.  Please make the config file as simple
as possible (and still able to reproduce the problem).

Thanks,
Ben


>
> --- On Sun, 2/21/10, Bruce Simpson<bms at incunabulum.net>  wrote:
>
>> From: Bruce Simpson<bms at incunabulum.net>
>> Subject: Re: [Xorp-hackers] vrrp sigabrt in release 1.6
>> To: xorp-hackers at icir.org
>> Date: Sunday, February 21, 2010, 2:15 PM
>> On 10/02/2010 19:24, Li Zhao wrote:
>>> When I configured vrrp on one interface in linux
>> embedded. The vrrp crashed
>>> because of sigabrt in VrrpTarget::check_interfaces at
>> vrrp_target.cc:221.
>>>
>>>
>>
>> Are you able to reproduce this with SVN sources?
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>>
>
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Wed Feb 24 09:24:43 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 09:24:43 -0800
Subject: [Xorp-hackers] IP-IP/GRE tunnel
In-Reply-To: <978057.83852.qm@web58705.mail.re1.yahoo.com>
References: <978057.83852.qm@web58705.mail.re1.yahoo.com>
Message-ID: <4B8560DB.4080901@candelatech.com>

On 02/24/2010 08:51 AM, Li Zhao wrote:
> Does xorp support IP-IP/GRE tunnel as special interfaces? For example,
> after we configure a tunnel, we can configure a static route using this
> tunnel as egress interface or using destination IP address on the tunnel
> as next-hop. All the configuration should be done on xorp cli. I dont want
> to configure tunnels on Linux command line. Can Linux system and windows
> system form IP-IP/GRE tunnels?

I don't think it can..you'll need to create them outside of xorp
and then use xorpsh to update xorp configuration.

The official xorp tree does not always deal well with dynamically
adding/removing interfaces.  I've added a bunch of fixes for these
issues to my tree (since my application deals extensively with
dynamically updating xorp interfaces and such).

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Wed Feb 24 09:32:39 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 09:32:39 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
Message-ID: <4B8562B7.6000809@candelatech.com>

On 02/24/2010 07:57 AM, Eric S. Johnson wrote:
>
> Ok, I got VRRP to  *almost* work with SVN xorp on Centos 5.
> Without patch below it will start, but will crash as soon as
> it becomes master for an interface.

You mean 'With the patch' ?

Can you post a full diff -u of all your changes?  I'd like to
apply what I can to my tree, and if time allows, try to fix
up scons to do the pcap detection and such better...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From lizhaous2000 at yahoo.com  Wed Feb 24 09:39:05 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 24 Feb 2010 09:39:05 -0800 (PST)
Subject: [Xorp-hackers] IP-IP/GRE tunnel
In-Reply-To: <4B8560DB.4080901@candelatech.com>
Message-ID: <248921.8376.qm@web58706.mail.re1.yahoo.com>

The reason I like to configure every thing in xorpsh is I want the xorp behaves more like a cisco router.

--- On Wed, 2/24/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] IP-IP/GRE tunnel
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: xorp-hackers at icir.org
> Date: Wednesday, February 24, 2010, 12:24 PM
> On 02/24/2010 08:51 AM, Li Zhao
> wrote:
> > Does xorp support IP-IP/GRE tunnel as special
> interfaces? For example,
> > after we configure a tunnel, we can configure a static
> route using this
> > tunnel as egress interface or using destination IP
> address on the tunnel
> > as next-hop. All the configuration should be done on
> xorp cli. I dont want
> > to configure tunnels on Linux command line. Can Linux
> system and windows
> > system form IP-IP/GRE tunnels?
> 
> I don't think it can..you'll need to create them outside of
> xorp
> and then use xorpsh to update xorp configuration.
> 
> The official xorp tree does not always deal well with
> dynamically
> adding/removing interfaces.? I've added a bunch of
> fixes for these
> issues to my tree (since my application deals extensively
> with
> dynamically updating xorp interfaces and such).
> 
> Thanks,
> Ben
> 
> -- Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From greearb at candelatech.com  Wed Feb 24 09:45:08 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 09:45:08 -0800
Subject: [Xorp-hackers] IP-IP/GRE tunnel
In-Reply-To: <248921.8376.qm@web58706.mail.re1.yahoo.com>
References: <248921.8376.qm@web58706.mail.re1.yahoo.com>
Message-ID: <4B8565A4.7090405@candelatech.com>

On 02/24/2010 09:39 AM, Li Zhao wrote:
> The reason I like to configure every thing in xorpsh is I want the xorp behaves more like a cisco router.

Well, you could probably add code to xorp to do the tunnel creation/destruction commands.
I'm not sure how easy that would be, however.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From esj at cs.fiu.edu  Wed Feb 24 09:47:01 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Wed, 24 Feb 2010 12:47:01 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B8562B7.6000809@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
Message-ID: <20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>


greearb at candelatech.com said:
>> Ok, I got VRRP to  *almost* work with SVN xorp on Centos 5.
>> Without patch below it will start, but will crash as soon as
>> it becomes master for an interface.

> You mean 'With the patch' ? 

No. Without *any* patches the svn would compile fine, and even 
appear to configure and function fine as a "backup" router.

As soon as it tried to become the virtual router (change of priority
or other router(s) stopped) the vrrp and fea would crash.

With the patch of the last message, it starts, and now
when it becomes the primary for an interface the MAC is correctly
changed to the virtual mac, but the virtual IP doesn't get
added to the interface. 

>Can you post a full diff -u of all your changes?  I'd like to
>apply what I can to my tree, and if time allows, try to fix
>up scons to do the pcap detection and such better...

Included below. Thanks.

E


[root at test-router src]# diff -ru xorp-svn-20100217.orig xorp-svn-20100217
diff -ru xorp-svn-20100217.orig/BUILD_NOTES xorp-svn-20100217/BUILD_NOTES
--- xorp-svn-20100217.orig/BUILD_NOTES  2010-02-17 10:26:48.000000000 -0500
+++ xorp-svn-20100217/BUILD_NOTES       2010-02-17 10:48:54.000000000 -0500
@@ -386,6 +386,21 @@
     - The code compiles, and the internal tests appear to succeed.
     - gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)
 
+  * Linux CentOS 5.4 (2.6.18-164.6.1.el5)
+    - You must install the following packages:
+      - gcc
+      - gcc-c++
+      - openssl-devel
+      - scons-1.2.0-1.el5.rf
+    - Optionally install the following packages:
+      - libpcap-devel
+        This package is needed for sending/receiving link layer data frames.
+    - gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
+    - must comment out:  if has_netinet_in_h:
+                             prereq_linux_mroute_h.append('netinet/in.h')
+      around line 550 of site_scons/config/allconfig.py
+
+
   * Linux Debian-3.1 (sarge) (2.4.27-3-386):
     - You must install the following packages:
       - libssl (e.g., libssl0.9.7)
diff -ru xorp-svn-20100217.orig/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc xorp-svn-20100217/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
--- xorp-svn-20100217.orig/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc       2010-02-17 10:25:17.000000000 -0500
+++ xorp-svn-20100217/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc    2010-02-24 10:27:49.000000000 -0500
@@ -538,6 +538,8 @@
     else
        interface_flags &= ~IFF_UP;
 
+// ESJ
+#define HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
 #ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
     static const size_t        buffer_size = sizeof(struct nlmsghdr)
        + sizeof(struct ifinfomsg) + 2*sizeof(struct rtattr) + 512;
diff -ru xorp-svn-20100217.orig/fea/data_plane/io/io_link_pcap.hh xorp-svn-20100217/fea/data_plane/io/io_link_pcap.hh
--- xorp-svn-20100217.orig/fea/data_plane/io/io_link_pcap.hh    2010-02-17 10:25:18.000000000 -0500
+++ xorp-svn-20100217/fea/data_plane/io/io_link_pcap.hh 2010-02-23 16:39:18.000000000 -0500
@@ -34,6 +34,7 @@
 
 #ifdef HAVE_PCAP_H
 #include <pcap.h>
+#define HAVE_PCAP
 #endif
 
 #include "fea/io_link.hh"
Only in xorp-svn-20100217: obj
diff -ru xorp-svn-20100217.orig/ospf/auth.cc xorp-svn-20100217/ospf/auth.cc
--- xorp-svn-20100217.orig/ospf/auth.cc 2010-02-17 10:26:02.000000000 -0500
+++ xorp-svn-20100217/ospf/auth.cc      2010-02-19 07:17:43.000000000 -0500
@@ -496,12 +496,15 @@
     MD5_CTX ctx;
     uint8_t digest[MD5_DIGEST_LENGTH];
 
+    // length to compute MD5 over
+    uint32_t md5_packet_length = extract_16(&ptr[Packet::LEN_OFFSET]);
+
     MD5_Init(&ctx);
-    MD5_Update(&ctx, &ptr[0], pkt.size() - MD5_DIGEST_LENGTH);
+    MD5_Update(&ctx, &ptr[0], md5_packet_length);
     MD5_Update(&ctx, key->key_data(), key->key_data_bytes());
     MD5_Final(&digest[0], &ctx);
 
-    if (0 != memcmp(&digest[0], &ptr[pkt.size() - MD5_DIGEST_LENGTH],
+    if (0 != memcmp(&digest[0], &ptr[md5_packet_length],
                    MD5_DIGEST_LENGTH)) {
        set_error(c_format("authentication digest doesn't match local key "
                           "(key ID = %d)", key->id()));
diff -ru xorp-svn-20100217.orig/ospf/peer.cc xorp-svn-20100217/ospf/peer.cc
--- xorp-svn-20100217.orig/ospf/peer.cc 2010-02-17 10:26:02.000000000 -0500
+++ xorp-svn-20100217/ospf/peer.cc      2010-02-17 10:48:54.000000000 -0500
@@ -2609,16 +2609,17 @@
     case Loopback: {
        // XXX - We should be checking to see if this is p2p unnumbered.
        uint16_t prefix_length;
-       if (_passive_host)
+       if (_passive_host) {
            prefix_length = IPv4::ADDR_BITLEN;
-       else {
+           router_link.set_metric(0);
+       } else {
            prefix_length = get_interface_prefix_length();
+            router_link.set_metric(_peerout.get_interface_cost());
        }
        IPNet<IPv4> net(get_interface_address(), prefix_length);
        router_link.set_type(RouterLink::stub);
        router_link.set_link_id(ntohl(net.masked_addr().addr()));
        router_link.set_link_data(ntohl(net.netmask().addr()));
-       router_link.set_metric(0);
        router_links.push_back(router_link);
     }
        return;
Only in xorp-svn-20100217: relpath.pyc
diff -ru xorp-svn-20100217.orig/SConstruct xorp-svn-20100217/SConstruct
--- xorp-svn-20100217.orig/SConstruct   2010-02-17 10:26:48.000000000 -0500
+++ xorp-svn-20100217/SConstruct        2010-02-22 20:51:51.000000000 -0500
@@ -136,7 +136,7 @@
                  ENV = os.environ,
                  BUILDDIR = builddir,
                  CPPPATH=['/usr/local/include', '$BUILDDIR'],
-                 LIBPATH=['/usr/local/lib'],
+                 LIBPATH=['/usr/lib', '/usr/local/lib'],
                  variables = vars)
 
 prefix = env['prefix']
@@ -477,14 +477,18 @@
 and shared libraries. This is UNSUPPORTED, and probably will not link.
 """
     strip_pg_flags = [ '-pg', '-finstrument-functions', '-fno-omit-frame-pointer', '-fno-optimize-sibling-calls' ]
-    env.Replace( CFLAGS = filter(
-       lambda s: not s.startswith(tuple(strip_pg_flags)),
-       Split(env['CFLAGS']))
-    )
-    env.Replace( CXXFLAGS = filter(
-       lambda s: not s.startswith(tuple(strip_pg_flags)),
-       Split(env['CXXFLAGS']))
-    )
+    try:
+         env.Replace( CFLAGS = filter(
+            lambda s: not s.startswith(tuple(strip_pg_flags)),
+            Split(env['CFLAGS']))
+         )
+         env.Replace( CXXFLAGS = filter(
+            lambda s: not s.startswith(tuple(strip_pg_flags)),
+            Split(env['CXXFLAGS']))
+         )
+    except TypeError:
+        print "Scons type error, shared libs and profiled code cannot work..and cannot work-around this automatically with your scons version."
+
     # Full use of profiling may require more than one flag, so Split() them.
     pgdict = {'no': '',
               'gprof': '-pg',
diff -ru xorp-svn-20100217.orig/site_scons/config/allconfig.py xorp-svn-20100217/site_scons/config/allconfig.py
--- xorp-svn-20100217.orig/site_scons/config/allconfig.py       2010-02-17 10:26:14.000000000 -0500
+++ xorp-svn-20100217/site_scons/config/allconfig.py    2010-02-17 10:48:54.000000000 -0500
@@ -543,13 +543,16 @@
     # <linux/in.h> might conflict with <netinet/in.h> that was included
     # earlier.  This is currently difficult to replicate in SCons, as
     # you can't pass arbitrary code that is prepended to the test.
+    #
+    # for Centos5 at least, netinet/in.h is not needed and breaks things
+    #
     prereq_linux_mroute_h = []
     if has_sys_types_h:
        prereq_linux_mroute_h.append('sys/types.h')
     if has_sys_socket_h:
        prereq_linux_mroute_h.append('sys/socket.h')
-    if has_netinet_in_h:
-       prereq_linux_mroute_h.append('netinet/in.h')
+    #if has_netinet_in_h:
+    #   prereq_linux_mroute_h.append('netinet/in.h')
     if has_linux_types_h:
        prereq_linux_mroute_h.append('linux/types.h')
     linux_mroute_h = 'linux/mroute.h'
Only in xorp-svn-20100217/site_scons/config: allconfig.pyc
Only in xorp-svn-20100217/site_scons/config: boost.pyc
Only in xorp-svn-20100217/site_scons/config: endian.pyc
Only in xorp-svn-20100217/site_scons/config: __init__.pyc
Only in xorp-svn-20100217/site_scons/config: member.pyc
Only in xorp-svn-20100217/site_scons/config: sysctl.pyc
Only in xorp-svn-20100217/site_scons/site_tools: autotest.pyc
Only in xorp-svn-20100217/site_scons/site_tools: clntgen.pyc
Only in xorp-svn-20100217/site_scons/site_tools: tgtgen.pyc
Only in xorp-svn-20100217/site_scons/site_tools: TOOL_SUBST.pyc
Only in xorp-svn-20100217/xrl/scripts/Xif: __init__.pyc
Only in xorp-svn-20100217/xrl/scripts/Xif: kdoc.pyc
Only in xorp-svn-20100217/xrl/scripts/Xif: parse.pyc
Only in xorp-svn-20100217/xrl/scripts/Xif: util.pyc
Only in xorp-svn-20100217/xrl/scripts/Xif: xiftypes.pyc


From lizhaous2000 at yahoo.com  Wed Feb 24 10:02:59 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 24 Feb 2010 10:02:59 -0800 (PST)
Subject: [Xorp-hackers] IP-IP/GRE tunnel
In-Reply-To: <4B8565A4.7090405@candelatech.com>
Message-ID: <526990.56043.qm@web58708.mail.re1.yahoo.com>

Probably. But can xorp use tunnel as an egress interface of a unicast static route now?

Thanks.

--- On Wed, 2/24/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] IP-IP/GRE tunnel
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: xorp-hackers at icir.org
> Date: Wednesday, February 24, 2010, 12:45 PM
> On 02/24/2010 09:39 AM, Li Zhao
> wrote:
> > The reason I like to configure every thing in xorpsh
> is I want the xorp behaves more like a cisco router.
> 
> Well, you could probably add code to xorp to do the tunnel
> creation/destruction commands.
> I'm not sure how easy that would be, however.
> 
> Thanks,
> Ben
> 
> -- Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From greearb at candelatech.com  Wed Feb 24 10:07:58 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 10:07:58 -0800
Subject: [Xorp-hackers] IP-IP/GRE tunnel
In-Reply-To: <526990.56043.qm@web58708.mail.re1.yahoo.com>
References: <526990.56043.qm@web58708.mail.re1.yahoo.com>
Message-ID: <4B856AFE.9020705@candelatech.com>

On 02/24/2010 10:02 AM, Li Zhao wrote:
> Probably. But can xorp use tunnel as an egress interface of a unicast static route now?
>
> Thanks.

I don't know..I've never tried to do that.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Wed Feb 24 11:13:09 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 11:13:09 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
Message-ID: <4B857A45.7040409@candelatech.com>



Could you try this patch instead for mroute detection on your system
and let me know if that works?  It compiles fine on my system, but
I'm not hitting that code branch.

I have all the other patches applied to my tree now..so hopefully
soon it will build w/out modification on CentOS 5.


[greearb at ben-dt2 xorp.ct]$ git diff
diff --git a/site_scons/config/allconfig.py b/site_scons/config/allconfig.py
index 917e640..4a39226 100644
--- a/site_scons/config/allconfig.py
+++ b/site_scons/config/allconfig.py
@@ -557,6 +557,21 @@ def DoAllConfig(env, conf, host_os):
      if has_linux_mroute_h:
          prereq_mroute_h = prereq_linux_mroute_h
          mroute_h = linux_mroute_h
+    else:
+        # Try without netinet/in.h, older releases (CentOS 5, for instance) doesn't need it
+        # and break with it.
+        prereq_linux_mroute_h = []
+        if has_sys_types_h:
+            prereq_linux_mroute_h.append('sys/types.h')
+        if has_sys_socket_h:
+            prereq_linux_mroute_h.append('sys/socket.h')
+        if has_linux_types_h:
+            prereq_linux_mroute_h.append('linux/types.h')
+        linux_mroute_h = 'linux/mroute.h'
+        has_linux_mroute_h = conf.CheckHeader(prereq_linux_mroute_h + [ linux_mroute_h ])
+        if has_linux_mroute_h:
+            prereq_mroute_h = prereq_linux_mroute_h
+            mroute_h = linux_mroute_h

      mfcctl2_includes = []
      for s in prereq_mroute_h + [ mroute_h ]:


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Wed Feb 24 11:16:48 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 11:16:48 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
Message-ID: <4B857B20.6090308@candelatech.com>

On 02/24/2010 09:47 AM, Eric S. Johnson wrote:

> diff -ru xorp-svn-20100217.orig/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc xorp-svn-20100217/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
> --- xorp-svn-20100217.orig/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc       2010-02-17 10:25:17.000000000 -0500
> +++ xorp-svn-20100217/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc    2010-02-24 10:27:49.000000000 -0500
> @@ -538,6 +538,8 @@
>       else
>          interface_flags&= ~IFF_UP;
>
> +// ESJ
> +#define HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
>   #ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
>       static const size_t        buffer_size = sizeof(struct nlmsghdr)
>          + sizeof(struct ifinfomsg) + 2*sizeof(struct rtattr) + 512;

Without this, does it fail to compile, or does it compile and just not work?

I'm hoping for some way to auto-detect what to do here either at run-time
or during scons configuration...

> diff -ru xorp-svn-20100217.orig/fea/data_plane/io/io_link_pcap.hh xorp-svn-20100217/fea/data_plane/io/io_link_pcap.hh
> --- xorp-svn-20100217.orig/fea/data_plane/io/io_link_pcap.hh    2010-02-17 10:25:18.000000000 -0500
> +++ xorp-svn-20100217/fea/data_plane/io/io_link_pcap.hh 2010-02-23 16:39:18.000000000 -0500
> @@ -34,6 +34,7 @@
>
>   #ifdef HAVE_PCAP_H
>   #include<pcap.h>
> +#define HAVE_PCAP
>   #endif

I don't see any reason to have the HAVE_PCAP define...I'm going to change all checks to
HAVE_PCAP_H so that this hack isn't needed.

I'm attaching my version of your changes.  Assuming the allconfig.py detection
for mcast works, I'll go ahead and push this into my tree.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100224/39185a8e/attachment.ksh 

From esj at cs.fiu.edu  Wed Feb 24 13:33:21 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Wed, 24 Feb 2010 16:33:21 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B857A45.7040409@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
Message-ID: <20100224213321.78A48B88415@cheetah.cs.fiu.edu>


greearb at candelatech.com said:
> Could you try this patch instead for mroute detection on your system
> and let me know if that works?  It compiles fine on my system, but
> I'm not hitting that code branch. 

It is still building, but I think it worked. (scons 
reported: Checking for C header file linux/mroute.h... yes)


> I have all the other patches applied to my tree now..so hopefully
> soon it will build w/out modification on CentOS 5. 

Im gonna have to try your tree soon :)


Thanks
E


From greearb at candelatech.com  Wed Feb 24 13:41:54 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 24 Feb 2010 13:41:54 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100224213321.78A48B88415@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
Message-ID: <4B859D22.1050000@candelatech.com>

On 02/24/2010 01:33 PM, Eric S. Johnson wrote:
>
> greearb at candelatech.com said:
>> Could you try this patch instead for mroute detection on your system
>> and let me know if that works?  It compiles fine on my system, but
>> I'm not hitting that code branch.
>
> It is still building, but I think it worked. (scons
> reported: Checking for C header file linux/mroute.h... yes)
>
>
>> I have all the other patches applied to my tree now..so hopefully
>> soon it will build w/out modification on CentOS 5.
>
> Im gonna have to try your tree soon :)

Sweet!

The final hack seems to be that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
bit.

Could you temporarily remove your change there and send me the build
errors?  Hopefully I can figure out how to write a scons rule to
auto-detect whether it's broken or not...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From esj at cs.fiu.edu  Thu Feb 25 05:59:24 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 25 Feb 2010 08:59:24 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B859D22.1050000@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
Message-ID: <20100225135924.16C11B88440@cheetah.cs.fiu.edu>


greearb at candelatech.com said:

> The final hack seems to be that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN bit.

> Could you temporarily remove your change there and send me the build
> errors?  Hopefully I can figure out how to write a scons rule to
> auto-detect whether it's broken or not... 

It (svn xorp) compiles fine and runs without the define of 
HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN. The problem is that 
scons doesn't detect that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN on
centos 5, so when the router becomes the primary VRRP router for a network
it goes into the code that tries to use netlink, fails, and vrrp
aborts.

There is a else clause in

fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc

that works (or at least doesn't have vrrp process die)

#ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN

	code that uses netlink and doesn't work and makes vrrp go south

#else // HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN

    //
    // XXX: a work-around in case the kernel doesn't support setting
    // the flags on an interface by using netlink.
    // In this case, the work-around is to use ioctl(). Sigh...
    //
	code that use a ioctl instead and seems to work.

#endif


In 1.6 the configure has a test, and sets that define appropriately 
in config.h.

Hmm, just checked and xorp-1.6/config/aclinux.m4 has this:

dnl ---------------------------------------------------------------
dnl Check for netlink sockets in the build environment (AF_NETLINK)
dnl ---------------------------------------------------------------
dnl
dnl Note that if we have netlink sockets, then we unconditionally set
dnl HAVE_NETLINK_SOCKETS_SET_MTU_IS_BROKEN and
dnl HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN to 1.
dnl The reason for this is because if we attempt to set the MTU or the
dnl interface flags on a Linux system (e.g., Linux RedHat-7.x with
dnl kernel 2.4-x), this is a no-op: nothing happens, but the kernel doesn't
dnl return an error. The test whether we can really set the MTU and the
dnl interface flags in the kernel is rather complicated, and would require
dnl root privileges. Enjoy... :-(
dnl

So maybe you can just piggy back on test of AF_NETLINK like 1.6 did?



With that patch, vrrp *almost* works. It does the right thing 
on an interface that is in backup/standby mode (nothing). When 
an interface becomes master for the virtual address, it changes 
the MAC address correctly to the VRRP mac. But it does not add
the layer 3 (IP) virtual address to the interface.

It seems to be designed such that a fake arp daemonish section of 
code would respond to arp requests on behalf of the virtual IP.
That code has some errors I have found (like throwing away frames
that are smaller than the "minimum ethernet frame size" (which 
doesn't exist for full duplex ethernet), but so far even correcting that
hasn't made it work. I am still working through that code.

More info coming as it develops. 

E



E


From lizhaous2000 at yahoo.com  Thu Feb 25 09:09:14 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 25 Feb 2010 09:09:14 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
Message-ID: <42515.43926.qm@web58707.mail.re1.yahoo.com>

After I configure vrrp vrid (100), in my code I got an error "No I/O Link 
plugin to send a link raw packet on interface eth1 vif eth1 from 
0:0:5e:0:1:64 to 1:0:5e:0:0:12 EtherType 2048". What is the second MAC 
address 1:0:5e:0:0:12? Anybody has a clue?

Thanks.

Li


      


From esj at cs.fiu.edu  Thu Feb 25 09:30:46 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 25 Feb 2010 12:30:46 -0500
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <42515.43926.qm@web58707.mail.re1.yahoo.com> 
References: <42515.43926.qm@web58707.mail.re1.yahoo.com>
Message-ID: <20100225173046.637B3B88442@cheetah.cs.fiu.edu>


lizhaous2000 at yahoo.com said:
> After I configure vrrp vrid (100), in my code I got an error "No I/O
> Link  plugin to send a link raw packet on interface eth1 vif eth1
> from  0:0:5e:0:1:64 to 1:0:5e:0:0:12 EtherType 2048". What is the
> second MAC  address 1:0:5e:0:0:12? Anybody has a clue? 

That is the multicast address VRRP advertisments are sent too.

I seem to remember from previous messages you are running 
xorp on linux? 

Are you using xorp-1.6?

I think I saw that error when the build system did not have or 
did not correctly detect /usr/lib/libpcap.{a,so} which is from  
the libpcap-devel RPM in the centos/redhat world....


E




From esj at cs.fiu.edu  Thu Feb 25 09:46:17 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 25 Feb 2010 12:46:17 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100225135924.16C11B88440@cheetah.cs.fiu.edu> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
Message-ID: <20100225174617.A4FADB883EF@cheetah.cs.fiu.edu>


esj at cs.fiu.edu said:
> With that patch, vrrp *almost* works. It does the right thing  on an
> interface that is in backup/standby mode (nothing). When  an
> interface becomes master for the virtual address, it changes  the
> MAC address correctly to the VRRP mac. But it does not add the layer
> 3 (IP) virtual address to the interface.

> It seems to be designed such that a fake arp daemonish section of
> code would respond to arp requests on behalf of the virtual IP. That
> code has some errors I have found (like throwing away frames that
> are smaller than the "minimum ethernet frame size" (which  doesn't
> exist for full duplex ethernet), but so far even correcting that
> hasn't made it work. I am still working through that code. 

Ok, so it turns out the fake arp daemon code is working just
fine. After a router becomes master on an interface it
correctly receives and responds to ARP requests for the virtual 
IP address. (with the patch below).

The problem now seems to be simply that it does not add
the virtual Layer 3 address to the interface.

In fact, a manual 
	ip addr add x.x.x.x/y dev xxx

makes everything work. 

I am not seeing where vrrp/vrrp.cc even tries to add the 
IP to the interface in 


void
Vrrp::become_master()
{
    _state = MASTER;

    _vif.add_mac(_source_mac);
    send_advertisement();
    send_arps();
    setup_timers();
    _arpd.start();
}


E






--- xorp-svn-20100217.orig/fea/io_link.cc       2010-02-17 10:25:29.000000000 -0500
+++ xorp-svn-20100217/fea/io_link.cc    2010-02-25 11:12:32.000000000 -0500
@@ -105,16 +105,17 @@
     const uint8_t* ptr = packet;
 
     // Test the received packet size
-    if (packet_size < ETHERNET_MIN_FRAME_SIZE) {
-       XLOG_WARNING("Received packet on interface %s vif %s: "
-                    "packet is too short "
-                    "(captured %u expecting at least %u octets)",
-                    if_name().c_str(),
-                    vif_name().c_str(),
-                    XORP_UINT_CAST(packet_size),
-                    XORP_UINT_CAST(ETHERNET_MIN_FRAME_SIZE));
-       return;                 // Error
-    }
+// ESJ um no... this is the 21st century after all :)
+//    if (packet_size < ETHERNET_MIN_FRAME_SIZE) {
+//     XLOG_WARNING("Received packet on interface %s vif %s: "
+//                  "packet is too short "
+//                  "(captured %u expecting at least %u octets)",
+//                  if_name().c_str(),
+//                  vif_name().c_str(),
+//                  XORP_UINT_CAST(packet_size),
+//                  XORP_UINT_CAST(ETHERNET_MIN_FRAME_SIZE));
+//     return;                 // Error
+//   }
 
     // Extract the MAC destination and source address
     dst_address.copy_in(ptr);


From greearb at candelatech.com  Thu Feb 25 09:51:24 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 09:51:24 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100225135924.16C11B88440@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
Message-ID: <4B86B89C.6060303@candelatech.com>

On 02/25/2010 05:59 AM, Eric S. Johnson wrote:
>
> greearb at candelatech.com said:
>
>> The final hack seems to be that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN bit.
>
>> Could you temporarily remove your change there and send me the build
>> errors?  Hopefully I can figure out how to write a scons rule to
>> auto-detect whether it's broken or not...
>
> It (svn xorp) compiles fine and runs without the define of
> HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN. The problem is that
> scons doesn't detect that HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN on
> centos 5, so when the router becomes the primary VRRP router for a network
> it goes into the code that tries to use netlink, fails, and vrrp
> aborts.
>
> There is a else clause in
>
> fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
>
> that works (or at least doesn't have vrrp process die)
>
> #ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
>
> 	code that uses netlink and doesn't work and makes vrrp go south
>
> #else // HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
>
>      //
>      // XXX: a work-around in case the kernel doesn't support setting
>      // the flags on an interface by using netlink.
>      // In this case, the work-around is to use ioctl(). Sigh...
>      //
> 	code that use a ioctl instead and seems to work.
>
> #endif
>
>
> In 1.6 the configure has a test, and sets that define appropriately
> in config.h.
>
> Hmm, just checked and xorp-1.6/config/aclinux.m4 has this:

If it compiles fine, then maybe a run-time check in xorp itself would
work.  Attempt to do the set with netlink, check to see if it worked,
if it fails, then fall back to the ioctl (and set flag to no longer
try netlink for the rest of this run).

That should get rid of that #define entirely.

> dnl ---------------------------------------------------------------
> dnl Check for netlink sockets in the build environment (AF_NETLINK)
> dnl ---------------------------------------------------------------
> dnl
> dnl Note that if we have netlink sockets, then we unconditionally set
> dnl HAVE_NETLINK_SOCKETS_SET_MTU_IS_BROKEN and
> dnl HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN to 1.
> dnl The reason for this is because if we attempt to set the MTU or the
> dnl interface flags on a Linux system (e.g., Linux RedHat-7.x with
> dnl kernel 2.4-x), this is a no-op: nothing happens, but the kernel doesn't
> dnl return an error. The test whether we can really set the MTU and the
> dnl interface flags in the kernel is rather complicated, and would require
> dnl root privileges. Enjoy... :-(
> dnl
>
> So maybe you can just piggy back on test of AF_NETLINK like 1.6 did?

That seems lame.  That code is only valid if netlink exists, but then they
disable it..so probably in the history of xorp, that code was never executed
if I understand these comments correctly.

> With that patch, vrrp *almost* works. It does the right thing
> on an interface that is in backup/standby mode (nothing). When
> an interface becomes master for the virtual address, it changes
> the MAC address correctly to the VRRP mac. But it does not add
> the layer 3 (IP) virtual address to the interface.
>
> It seems to be designed such that a fake arp daemonish section of
> code would respond to arp requests on behalf of the virtual IP.
> That code has some errors I have found (like throwing away frames
> that are smaller than the "minimum ethernet frame size" (which
> doesn't exist for full duplex ethernet), but so far even correcting that
> hasn't made it work. I am still working through that code.

Well, on the wire the frame will be a minimum size of 60 bytes (not counting ether CRC),
but it can easily be padded with crap that is not logically part of the packet
and doesn't need to be passed up to user-space.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From john.tavs at xorp.net  Thu Feb 25 10:00:25 2010
From: john.tavs at xorp.net (John Tavs)
Date: Thu, 25 Feb 2010 10:00:25 -0800
Subject: [Xorp-hackers] XORP Asset Sales Notification
Message-ID: <acf85971002251000h26f32b3dn391531b6a64292fc@mail.gmail.com>

With profound regrets, the board of XORP Inc. has vote to shut down the
company and put the assets of XORP up for sale.

The asset of XORP have been broken into 3 packages that are being sold.

?       XORP: The rights to the XORP Open Source purchase from ICSI and its
derivative works from XORP employees and contractors as posted on the XORP
project web site (currently located at http://sourceforge.net/projects/xorp/).


Note, while the project is maintained as an Open Source Project under GPL
license terms on sourceforge, the owner of this asset will have rights to
create additional licensing terms.

?       Netstack: The rights of the port of the XORP code to the Broadcom
Switching Platform using proprietary Broadcom SDK (www.broadcom.com)
 including XORP developed Layer 2 functionality (or ?Netstack?).

?       Appstack: The rights to the HTTP load balancing application that
XORP has developed for data centers.

If you are interested in participating in this auction and, please contact
David Johnson  at Sherword Partners ( DJohnson at shrwood.com ) before the
auction closes on March 19, 2010.



Regards,

    John Tavs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100225/bad031b9/attachment-0001.html 

From esj at cs.fiu.edu  Thu Feb 25 10:15:37 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 25 Feb 2010 13:15:37 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B86B89C.6060303@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
Message-ID: <20100225181537.9BBE1B883F5@cheetah.cs.fiu.edu>


greearb at candelatech.com said:
> Well, on the wire the frame will be a minimum size of 60 bytes (not
> counting ether CRC), but it can easily be padded with crap that is
> not logically part of the packet and doesn't need to be passed up to
> user-space. 

That minimum is not needed in full duplex ethernet (it was there
to ensure 512bits on the wire for collision detection).

Modern ethernet drivers have no problem sending smaller
packets when the link is full duplex. Arp's on full duplex
wire are usually shorter.

xorps pseudo arp deamon is/was throwing those away.

E


From lizhaous2000 at yahoo.com  Thu Feb 25 10:43:00 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 25 Feb 2010 10:43:00 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <20100225173046.637B3B88442@cheetah.cs.fiu.edu>
Message-ID: <140697.44642.qm@web58706.mail.re1.yahoo.com>

Yes, I am running xorp1.6 on Linux on a diskless VM. I have installed libpcap.so.0.9 on /usr/lib. I am looking for this error root.

--- On Thu, 2/25/10, Eric S. Johnson <esj at cs.fiu.edu> wrote:

> From: Eric S. Johnson <esj at cs.fiu.edu>
> Subject: Re: [Xorp-hackers] VRRP error
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: xorp-hackers at icir.org
> Date: Thursday, February 25, 2010, 12:30 PM
> 
> lizhaous2000 at yahoo.com
> said:
> > After I configure vrrp vrid (100), in my code I got an
> error "No I/O
> > Link? plugin to send a link raw packet on
> interface eth1 vif eth1
> > from? 0:0:5e:0:1:64 to 1:0:5e:0:0:12 EtherType
> 2048". What is the
> > second MAC? address 1:0:5e:0:0:12? Anybody has a
> clue? 
> 
> That is the multicast address VRRP advertisments are sent
> too.
> 
> I seem to remember from previous messages you are running 
> xorp on linux? 
> 
> Are you using xorp-1.6?
> 
> I think I saw that error when the build system did not have
> or 
> did not correctly detect /usr/lib/libpcap.{a,so} which is
> from? 
> the libpcap-devel RPM in the centos/redhat world....
> 
> 
> E
> 
> 
> 
> 


      


From greearb at candelatech.com  Thu Feb 25 11:12:03 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 11:12:03 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100225174617.A4FADB883EF@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<20100225174617.A4FADB883EF@cheetah.cs.fiu.edu>
Message-ID: <4B86CB83.5050309@candelatech.com>

On 02/25/2010 09:46 AM, Eric S. Johnson wrote:

> --- xorp-svn-20100217.orig/fea/io_link.cc       2010-02-17 10:25:29.000000000 -0500
> +++ xorp-svn-20100217/fea/io_link.cc    2010-02-25 11:12:32.000000000 -0500
> @@ -105,16 +105,17 @@
>       const uint8_t* ptr = packet;
>
>       // Test the received packet size
> -    if (packet_size<  ETHERNET_MIN_FRAME_SIZE) {
> -       XLOG_WARNING("Received packet on interface %s vif %s: "
> -                    "packet is too short "
> -                    "(captured %u expecting at least %u octets)",
> -                    if_name().c_str(),
> -                    vif_name().c_str(),
> -                    XORP_UINT_CAST(packet_size),
> -                    XORP_UINT_CAST(ETHERNET_MIN_FRAME_SIZE));
> -       return;                 // Error
> -    }
> +// ESJ um no... this is the 21st century after all :)
> +//    if (packet_size<  ETHERNET_MIN_FRAME_SIZE) {
> +//     XLOG_WARNING("Received packet on interface %s vif %s: "
> +//                  "packet is too short "
> +//                  "(captured %u expecting at least %u octets)",
> +//                  if_name().c_str(),
> +//                  vif_name().c_str(),
> +//                  XORP_UINT_CAST(packet_size),
> +//                  XORP_UINT_CAST(ETHERNET_MIN_FRAME_SIZE));
> +//     return;                 // Error
> +//   }

We still need to protect against truly bogus packets so we don't run of the
end of the packet buffer and read bogus memory (and probably SEGV).

How about the attached patch?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp-min-ether.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100225/d63a6023/attachment.ksh 

From greearb at candelatech.com  Thu Feb 25 11:16:35 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 11:16:35 -0800
Subject: [Xorp-hackers] XORP Asset Sales Notification
In-Reply-To: <acf85971002251000h26f32b3dn391531b6a64292fc@mail.gmail.com>
References: <acf85971002251000h26f32b3dn391531b6a64292fc@mail.gmail.com>
Message-ID: <4B86CC93.2010204@candelatech.com>

On 02/25/2010 10:00 AM, John Tavs wrote:
> With profound regrets, the board of XORP Inc. has vote to shut down the
> company and put the assets of XORP up for sale.

I'm sorry to hear this!

My best wishes go out to all of the XORP Inc folks.

And, I am very grateful that you all chose to put xorp under
the GPL so that the project can live on in one form or another!

Sincerely,
Ben Greear

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From esj at cs.fiu.edu  Thu Feb 25 11:42:52 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 25 Feb 2010 14:42:52 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B86CB83.5050309@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<20100225174617.A4FADB883EF@cheetah.cs.fiu.edu>
	<4B86CB83.5050309@candelatech.com>
Message-ID: <20100225194252.3A836B883F5@cheetah.cs.fiu.edu>


Heh, yes. That is much cleaner and saner. 

Thanks!
E


From greearb at candelatech.com  Thu Feb 25 12:02:46 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 12:02:46 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B86B89C.6060303@candelatech.com>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>	<4B82CBAC.1020505@candelatech.com>	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>	<4B8562B7.6000809@candelatech.com>	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>	<4B857A45.7040409@candelatech.com>	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>	<4B859D22.1050000@candelatech.com>	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
Message-ID: <4B86D766.4060007@candelatech.com>

On 02/25/2010 09:51 AM, Ben Greear wrote:
> On 02/25/2010 05:59 AM, Eric S. Johnson wrote:

>> There is a else clause in
>>
>> fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
>>
>> that works (or at least doesn't have vrrp process die)
>>
>> #ifndef HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
>>
>> 	code that uses netlink and doesn't work and makes vrrp go south
>>
>> #else // HAVE_NETLINK_SOCKETS_SET_FLAGS_IS_BROKEN
>>
>>       //
>>       // XXX: a work-around in case the kernel doesn't support setting
>>       // the flags on an interface by using netlink.
>>       // In this case, the work-around is to use ioctl(). Sigh...
>>       //
>> 	code that use a ioctl instead and seems to work.
>>
>> #endif

Can you try the attached patch and see if it properly detects the failure
(at runtime) and takes proper action to use the ioctl?  You should see one
complaint in the logs about having to switch to ioctl, but after that it
should not complain if I wrote the code correctly.

		    error_msg = c_format("ERROR:  Settting interface status using netlink failed"
					 " on: %s.  Will try to use ioctl method instead.",
					 ifname.c_str());

This is compile tested only.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp-set-status.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100225/7ce64651/attachment.ksh 

From lizhaous2000 at yahoo.com  Thu Feb 25 13:02:04 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 25 Feb 2010 13:02:04 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <140697.44642.qm@web58706.mail.re1.yahoo.com>
Message-ID: <780808.65894.qm@web58704.mail.re1.yahoo.com>


It turns out to be fea is complaining _io_link_manager is empty. What does that mean?
--- On Thu, 2/25/10, Li Zhao <lizhaous2000 at yahoo.com> wrote:

> From: Li Zhao <lizhaous2000 at yahoo.com>
> Subject: Re: [Xorp-hackers] VRRP error
> To: "Eric S. Johnson" <esj at cs.fiu.edu>
> Cc: xorp-hackers at icir.org
> Date: Thursday, February 25, 2010, 1:43 PM
> Yes, I am running xorp1.6 on Linux on
> a diskless VM. I have installed libpcap.so.0.9 on /usr/lib.
> I am looking for this error root.
> 
> --- On Thu, 2/25/10, Eric S. Johnson <esj at cs.fiu.edu>
> wrote:
> 
> > From: Eric S. Johnson <esj at cs.fiu.edu>
> > Subject: Re: [Xorp-hackers] VRRP error
> > To: "Li Zhao" <lizhaous2000 at yahoo.com>
> > Cc: xorp-hackers at icir.org
> > Date: Thursday, February 25, 2010, 12:30 PM
> > 
> > lizhaous2000 at yahoo.com
> > said:
> > > After I configure vrrp vrid (100), in my code I
> got an
> > error "No I/O
> > > Link? plugin to send a link raw packet on
> > interface eth1 vif eth1
> > > from? 0:0:5e:0:1:64 to 1:0:5e:0:0:12 EtherType
> > 2048". What is the
> > > second MAC? address 1:0:5e:0:0:12? Anybody has
> a
> > clue? 
> > 
> > That is the multicast address VRRP advertisments are
> sent
> > too.
> > 
> > I seem to remember from previous messages you are
> running 
> > xorp on linux? 
> > 
> > Are you using xorp-1.6?
> > 
> > I think I saw that error when the build system did not
> have
> > or 
> > did not correctly detect /usr/lib/libpcap.{a,so} which
> is
> > from? 
> > the libpcap-devel RPM in the centos/redhat world....
> > 
> > 
> > E
> > 
> > 
> > 
> > 
> 
> 
> ? ? ? 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From greearb at candelatech.com  Thu Feb 25 13:13:49 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 13:13:49 -0800
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <780808.65894.qm@web58704.mail.re1.yahoo.com>
References: <780808.65894.qm@web58704.mail.re1.yahoo.com>
Message-ID: <4B86E80D.4010608@candelatech.com>

On 02/25/2010 01:02 PM, Li Zhao wrote:
>
> It turns out to be fea is complaining _io_link_manager is empty. What does that mean?

Any reason not to try my tree or official SVN tree?  I think
we'll have more luck debugging and fixing problems there...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From lizhaous2000 at yahoo.com  Thu Feb 25 13:46:33 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 25 Feb 2010 13:46:33 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <4B86E80D.4010608@candelatech.com>
Message-ID: <98718.96922.qm@web58703.mail.re1.yahoo.com>


After I downloaded 1.6 last Sept, my development was isolated from the main stream. Let me see if it is easy to use you guy's trees. Thanks.

Li
--- On Thu, 2/25/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] VRRP error
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "Eric S. Johnson" <esj at cs.fiu.edu>, xorp-hackers at icir.org
> Date: Thursday, February 25, 2010, 4:13 PM
> On 02/25/2010 01:02 PM, Li Zhao
> wrote:
> >
> > It turns out to be fea is complaining _io_link_manager
> is empty. What does that mean?
> 
> Any reason not to try my tree or official SVN tree?? I
> think
> we'll have more luck debugging and fixing problems
> there...
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From greearb at candelatech.com  Thu Feb 25 13:52:31 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 13:52:31 -0800
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <98718.96922.qm@web58703.mail.re1.yahoo.com>
References: <98718.96922.qm@web58703.mail.re1.yahoo.com>
Message-ID: <4B86F11F.8050306@candelatech.com>

On 02/25/2010 01:46 PM, Li Zhao wrote:
>
> After I downloaded 1.6 last Sept, my development was isolated from the main stream. Let me see if it is easy to use you guy's trees. Thanks.

Post a patch (diff -u) of your changes...maybe we can integrate some of them into my tree.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From esj at cs.fiu.edu  Thu Feb 25 14:50:07 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 25 Feb 2010 17:50:07 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B86D766.4060007@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
	<4B86D766.4060007@candelatech.com>
Message-ID: <20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>


greearb at candelatech.com said:
> Can you try the attached patch and see if it properly detects the
> failure (at runtime) and takes proper action to use the ioctl? 

Quick answer, with no time today to investigate further, it didn't
work. I see what you tried to do, but something just wasn't right.

It looked to me like:

        if (NlmUtils::check_netlink_request(_ns_reader, ns, nlh->nlmsg_seq,
                                            last_errno, error_msg)
            != XORP_OK) {
            error_msg = c_format("check_netlink_request Cannot set the interface flags to 0x%x on "
                                 "interface %s: %s",
                                 interface_flags, ifname.c_str(),
                                 error_msg.c_str());
            return (XORP_ERROR);
         }

failed and vrrp aborted. I changed the error message to be different 
than the one above it, that is how I know this one is the one that 
failed.

I tried just commenting out the return but that didn't help either.  

Heading home, will review in more detail tomorrow.

E



From greearb at candelatech.com  Thu Feb 25 14:51:59 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 25 Feb 2010 14:51:59 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
	<4B86D766.4060007@candelatech.com>
	<20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
Message-ID: <4B86FF0F.6070804@candelatech.com>

On 02/25/2010 02:50 PM, Eric S. Johnson wrote:
>
> greearb at candelatech.com said:
>> Can you try the attached patch and see if it properly detects the
>> failure (at runtime) and takes proper action to use the ioctl?
>
> Quick answer, with no time today to investigate further, it didn't
> work. I see what you tried to do, but something just wasn't right.
>
> It looked to me like:
>
>          if (NlmUtils::check_netlink_request(_ns_reader, ns, nlh->nlmsg_seq,
>                                              last_errno, error_msg)
>              != XORP_OK) {
>              error_msg = c_format("check_netlink_request Cannot set the interface flags to 0x%x on "
>                                   "interface %s: %s",
>                                   interface_flags, ifname.c_str(),
>                                   error_msg.c_str());
>              return (XORP_ERROR);
>           }
>
> failed and vrrp aborted. I changed the error message to be different
> than the one above it, that is how I know this one is the one that
> failed.
>
> I tried just commenting out the return but that didn't help either.

Ok, so maybe that is what I need to key off of to try the ioctl.  I'll
read that check_netlink_request code closer...

Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Feb 26 09:54:06 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 26 Feb 2010 09:54:06 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
	<4B86D766.4060007@candelatech.com>
	<20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
Message-ID: <4B880ABE.10407@candelatech.com>

On 02/25/2010 02:50 PM, Eric S. Johnson wrote:
>
> greearb at candelatech.com said:
>> Can you try the attached patch and see if it properly detects the
>> failure (at runtime) and takes proper action to use the ioctl?
>
> Quick answer, with no time today to investigate further, it didn't
> work. I see what you tried to do, but something just wasn't right.
>
> It looked to me like:
>
>          if (NlmUtils::check_netlink_request(_ns_reader, ns, nlh->nlmsg_seq,
>                                              last_errno, error_msg)
>              != XORP_OK) {
>              error_msg = c_format("check_netlink_request Cannot set the interface flags to 0x%x on "
>                                   "interface %s: %s",
>                                   interface_flags, ifname.c_str(),
>                                   error_msg.c_str());
>              return (XORP_ERROR);
>           }
>
> failed and vrrp aborted. I changed the error message to be different
> than the one above it, that is how I know this one is the one that
> failed.
>
> I tried just commenting out the return but that didn't help either.
>
> Heading home, will review in more detail tomorrow.

Can you let me know exactly what the error message was?  That check_netlink_request
can fail in several different ways...

I think if you replace that return (XORP_ERROR) with:
goto try_ioctl;

it will work, but before I commit this, I'd like to see if I can only do that goto
logic on certain errors from netlink..

Thanks,
Ben


>
> E
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Feb 26 10:17:14 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 26 Feb 2010 10:17:14 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B880ABE.10407@candelatech.com>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>	<4B82CBAC.1020505@candelatech.com>	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>	<4B8562B7.6000809@candelatech.com>	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>	<4B857A45.7040409@candelatech.com>	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>	<4B859D22.1050000@candelatech.com>	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>	<4B86B89C.6060303@candelatech.com>	<4B86D766.4060007@candelatech.com>	<20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
	<4B880ABE.10407@candelatech.com>
Message-ID: <4B88102A.7090102@candelatech.com>

Can you try the attached patch and see if it works better?

This compile tested only.

I'd also like to see the error logs from the run with this patch if that's convenient.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp-set-status.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100226/94d9df63/attachment.ksh 

From esj at cs.fiu.edu  Fri Feb 26 11:41:20 2010
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Fri, 26 Feb 2010 14:41:20 -0500
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <4B88102A.7090102@candelatech.com> 
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
	<4B86D766.4060007@candelatech.com>
	<20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
	<4B880ABE.10407@candelatech.com> <4B88102A.7090102@candelatech.com>
Message-ID: <20100226194120.E6E86B88443@cheetah.cs.fiu.edu>




greearb at candelatech.com said:
> Can you try the attached patch and see if it works better?
> This compile tested only.
> I'd also like to see the error logs from the run with this patch if
> that's convenient. 


Hey. Nope. Failed again. here is what seems to be relevant from the logs. 
It doesn't make sense to me. 

Im gonna hack on this a bit now and see if I can figure out what is happening.


[ 2010/02/26 14:24:41  ERROR xorp_fea:26641 FEA +684 fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc set_interface_status ] WARNING:  Settting interface status using netlink failed on: eth0.21 but ioctl method worked.  Will use ioctl method from now on.
[ 2010/02/26 14:24:41  ERROR xorp_fea:26641 FEA +426 fea/data_plane/ifconfig/ifconfig_set.cc push_interface_begin ] Interface error on eth0.21: WARNING:  Settting interface status using netlink failed on: eth0.21 but ioctl method worked.  Will use ioctl method from now on.
[ 2010/02/26 14:24:41  FATAL xorp_fea:26641 MFEA +538 fea/mfea_node.cc vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed
[ 2010/02/26 14:24:41  ERROR xorp_fib2mrib:26660 FIB2MRIB +1572 fib2mrib/xrl_fib2mrib_node.cc finder_event_observer_0_1_xrl_target_death ] FEA (instance fea-3b90867596963d786b2b833ce92a6ad0 at 127.0.0.1) has died, shutting down.
[ 2010/02/26 14:24:41  ERROR xorp_igmp:26661 MLD6IGMP +1624 mld6igmp/xrl_mld6igmp_node.cc finder_event_observer_0_1_xrl_target_death ] FEA (instance fea-3b90867596963d786b2b833ce92a6ad0 at 127.0.0.1) has died, shutting down.

E


From greearb at candelatech.com  Fri Feb 26 11:48:00 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 26 Feb 2010 11:48:00 -0800
Subject: [Xorp-hackers] xorp svn VRRP centos
In-Reply-To: <20100226194120.E6E86B88443@cheetah.cs.fiu.edu>
References: <20100221205457.DBF58B88434@cheetah.cs.fiu.edu>
	<4B82CBAC.1020505@candelatech.com>
	<20100224155720.4FF65B8848A@cheetah.cs.fiu.edu>
	<4B8562B7.6000809@candelatech.com>
	<20100224174701.C5D42B8841E@cheetah.cs.fiu.edu>
	<4B857A45.7040409@candelatech.com>
	<20100224213321.78A48B88415@cheetah.cs.fiu.edu>
	<4B859D22.1050000@candelatech.com>
	<20100225135924.16C11B88440@cheetah.cs.fiu.edu>
	<4B86B89C.6060303@candelatech.com>
	<4B86D766.4060007@candelatech.com>
	<20100225225007.DC2A8B88162@cheetah.cs.fiu.edu>
	<4B880ABE.10407@candelatech.com> <4B88102A.7090102@candelatech.com>
	<20100226194120.E6E86B88443@cheetah.cs.fiu.edu>
Message-ID: <4B882570.7060200@candelatech.com>

On 02/26/2010 11:41 AM, Eric S. Johnson wrote:
>
>
>
> greearb at candelatech.com said:
>> Can you try the attached patch and see if it works better?
>> This compile tested only.
>> I'd also like to see the error logs from the run with this patch if
>> that's convenient.
>
>
> Hey. Nope. Failed again. here is what seems to be relevant from the logs.
> It doesn't make sense to me.
>
> Im gonna hack on this a bit now and see if I can figure out what is happening.
>
>
> [ 2010/02/26 14:24:41  ERROR xorp_fea:26641 FEA +684 fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc set_interface_status ] WARNING:  Settting interface status using netlink failed on: eth0.21 but ioctl method worked.  Will use ioctl method from now on.
> [ 2010/02/26 14:24:41  ERROR xorp_fea:26641 FEA +426 fea/data_plane/ifconfig/ifconfig_set.cc push_interface_begin ] Interface error on eth0.21: WARNING:  Settting interface status using netlink failed on: eth0.21 but ioctl method worked.  Will use ioctl method from now on.
> [ 2010/02/26 14:24:41  FATAL xorp_fea:26641 MFEA +538 fea/mfea_node.cc vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed

Hard to see how my change would have created that assert unless it's a race.  I'd add more debugging around that vif_update() method logic
to see why the fatal assert hits.

I also modified fea & interface logic a lot in my tree, (though not necessarily fixing
or making this particular problem worse).

If there's an easy way to reproduce this, maybe let me know your config & commands?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From lizhaous2000 at yahoo.com  Fri Feb 26 13:01:09 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Fri, 26 Feb 2010 13:01:09 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <4B86F11F.8050306@candelatech.com>
Message-ID: <15561.63761.qm@web58705.mail.re1.yahoo.com>

Actually the configuration is very simple to reproduce the problem on Linux.



protocols {
        vrrp {
            interface eth1 {
                vif eth1 {
                    vrid 100 {
                        priority: 100
                        interval: 1
                        preempt: true
                        disable: false
                    }
                }
            }
        }
    }
    interfaces {
        restore-original-config-on-shutdown: false
        interface eth1 {
            description: ""
            disable: false
            discard: false
            unreachable: false
            management: false
            vif eth1 {
                disable: false
                address 10.0.0.1 {
                    prefix-length: 24
                    disable: false
                }
            }
        }
    }

ps -xa

PID  Uid     VmSize Stat Command
    1 root        356 S   init                 
    2 root            SW< [kthreadd]
    3 root            SW< [migration/0]
    4 root            SW< [ksoftirqd/0]
    5 root            SW< [watchdog/0]
    6 root            SW< [events/0]
    7 root            SW< [khelper]
   10 root            SW< [kstop/0]
  121 root            SW< [kintegrityd/0]
  123 root            SW< [kblockd/0]
  125 root            SW< [kacpid]
  126 root            SW< [kacpi_notify]
  172 root            SW< [cqueue]
  178 root            SW< [kseriod]
  229 root            SW  [pdflush]
  230 root            SW  [pdflush]
  231 root            SW< [kswapd0]
  279 root            SW< [aio/0]
  290 root            SW< [nfsiod]
  298 root            SW< [jfsIO]
  299 root            SW< [jfsCommit]
  300 root            SW< [jfsSync]
  308 root            SW< [xfs_mru_cache]
  309 root            SW< [xfslogd/0]
  310 root            SW< [xfsdatad/0]
 1009 root            SW< [kpsmoused]
 1013 root            SW< [hid_compat]
 1022 root            SW< [rpciod/0]
 1056 bin         324 S   /sbin/portmap 
 1058 root            SW< [lockd]
 1064 root       1280 S   /sbin/rsyslogd -c 3 
 1073 root        468 S   /usr/local/sbin/dropbear -d /etc/dropbear_dsa_host_ke
 1074 root       8740 S   /usr/local/xorp/bin/xorp_rtrmgr -b /usr/local/xorp/em
 1076 root        116 S   init                 
 1077 root        996 R   /usr/local/sbin/dropbear -d /etc/dropbear_dsa_host_ke
 1079 root       1476 R   -bash 
 1181 root       7892 T   xorp_fea 
 1222 root       4776 S   xorp_rib 
 1225 root        540 S   gdbserver l:6666 --attach 1181

(gdb) c
Continuing.

Breakpoint 1, IoLinkComm::send_packet (this=0x87d7e78, src_address=@0x878ef70, 
    dst_address=@0xb7f94f3c, ether_type=2054, payload=@0xbfb9924c, 
    error_msg=@0xbfb97298) at io_link_manager.cc:261
261		error_msg = c_format("No I/O Link plugin to send a link raw packet on "
(gdb) bt
#0  IoLinkComm::send_packet (this=0x87d7e78, src_address=@0x878ef70, 
    dst_address=@0xb7f94f3c, ether_type=2054, payload=@0xbfb9924c, 
    error_msg=@0xbfb97298) at io_link_manager.cc:261
#1  0x080e8840 in IoLinkManager::send (this=0xbfba794c, if_name=@0x878e830, 
    vif_name=@0x87a51a0, src_address=@0x878ef70, dst_address=@0xb7f94f3c, 
    ether_type=2054, payload=@0xbfb9924c, error_msg=@0xbfb97298)
    at io_link_manager.cc:698
#2  0x08076767 in XrlFeaTarget::raw_link_0_1_send (this=0xbfba827c, 
    if_name=@0x878e830, vif_name=@0x87a51a0, src_address=@0x878ef70, 
    dst_address=@0xb7f94f3c, ether_type=@0xbfb99268, payload=@0xbfb9924c)
    at xrl_fea_target.cc:3361
#3  0x0807d12a in XrlFeaTarget::send_gratuitous_arps (this=0xbfba827c, 
    ifname=@0x878e830, mac=@0x878ef70, error_msg=@0xbfb9b458)
    at xrl_fea_target.cc:2284
#4  0x0807dd1e in XrlFeaTarget::set_mac (this=0xbfba827c, ifname=@0x878e830, 
    mac=@0x878ef70, error_msg=@0xbfb9b458) at xrl_fea_target.cc:2238
#5  0x0807e6bb in XrlFeaTarget::add_remove_mac (this=0xbfba827c, add=true, 
    ifname=@0x878e830, mac=@0x878ef70, error_msg=@0xbfb9b458)
    at xrl_fea_target.cc:2138
#6  0x0807f331 in XrlFeaTarget::ifmgr_0_1_create_mac (this=0xbfba827c, 
    ifname=@0x878e830, mac=@0x878ef70) at xrl_fea_target.cc:2043
#7  0x081fd791 in XrlFeaTargetBase::handle_ifmgr_0_1_create_mac (
    this=0xbfba827c, xa_inputs=@0x87d74f4) at fea_base.cc:2667
---Type <return> to continue, or q <return> to quit---
#8  0x08217cbb in XorpMemberCallback2B0<XrlCmdError const, XrlFeaTargetBase, XrlArgs const&, XrlArgs*>::dispatch (this=0x87842d0, a1=@0x87d74f4, a2=0xbfb9d59c)
    at ../../libxorp/callback_nodebug.hh:4616
#9  0xb8012165 in XrlCmdEntry::dispatch (this=0x8784324, inputs=@0x87d74f4, 
    outputs=0xbfb9d59c) at xrl_cmd_map.hh:43
#10 0xb803e670 in XrlDispatcher::dispatch_xrl_fast (this=0xbfba74e0, 
    xi=@0x87d74e8, outputs=@0xbfb9d59c) at xrl_dispatcher.cc:83
#11 0xb80549da in STCPRequestHandler::do_dispatch (this=0x8785290, 
    packed_xrl=0xb7c32194 "?", packed_xrl_bytes=96, response=@0xbfb9d59c)
    at xrl_pf_stcp.cc:264
#12 0xb8054ac5 in STCPRequestHandler::dispatch_request (this=0x8785290, 
    seqno=2, batch=false, packed_xrl=0xb7c32194 "?", packed_xrl_bytes=96)
    at xrl_pf_stcp.cc:276

--- On Thu, 2/25/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] VRRP error
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "Eric S. Johnson" <esj at cs.fiu.edu>, xorp-hackers at icir.org
> Date: Thursday, February 25, 2010, 4:52 PM
> On 02/25/2010 01:46 PM, Li Zhao
> wrote:
> >
> > After I downloaded 1.6 last Sept, my development was
> isolated from the main stream. Let me see if it is easy to
> use you guy's trees. Thanks.
> 
> Post a patch (diff -u) of your changes...maybe we can
> integrate some of them into my tree.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From greearb at candelatech.com  Fri Feb 26 13:59:30 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 26 Feb 2010 13:59:30 -0800
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <15561.63761.qm@web58705.mail.re1.yahoo.com>
References: <15561.63761.qm@web58705.mail.re1.yahoo.com>
Message-ID: <4B884442.5000506@candelatech.com>

On 02/26/2010 01:01 PM, Li Zhao wrote:
> Actually the configuration is very simple to reproduce the problem on Linux.

I tried starting this on my system, and get an assertion.

I ran it with:
/usr/local/xorp/bin/xorp_rtrmgr -b /root/xorp_vrrp.conf

The config file is exactly as you posted.

[ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] Clearing iftree: copy of user-config
[ 2010/02/26 13:53:36  FATAL xorp_vrrp:13019 VRRP vrrp_packet.cc:173 finalize ] Assertion (_data.size() == _data.capacity() && _data.size() == 
VRRP_MAX_PACKET_SIZE) failed
[ 2010/02/26 13:53:36  ERROR xorp_rtrmgr:12925 RTRMGR module_manager.cc:764 done_cb ] Command "/usr/local/xorp/vrrp/xorp_vrrp": terminated with signal 6.

I ran it again with the latest code (mostly changes Eric has been testing), and
now it crashes:

[ 2010/02/26 13:57:34 WARNING xorp_fea XrlFeaTarget ] Handling method for ifmgr/0.1/create_mac failed: XrlCmdError 102 Command failed Cannot add MAC address 
0:0:5e:0:1:64 on interface eth1: MAC already added
[ 2010/02/26 13:57:34  FATAL xorp_vrrp:14729 VRRP vrrp_target.cc:362 xrl_cb ] XRL error: 102 Command failed Cannot add MAC address 0:0:5e:0:1:64 on interface 
eth1: MAC already added
[ 2010/02/26 13:57:34  ERROR xorp_rtrmgr:14644 RTRMGR module_manager.cc:764 done_cb ] Command "/usr/local/xorp/vrrp/xorp_vrrp": terminated with signal 6.


Looks like it's time to remove some asserts :P


Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Feb 26 14:47:37 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 26 Feb 2010 14:47:37 -0800
Subject: [Xorp-hackers] Future Xorp development?
Message-ID: <4B884F89.4080507@candelatech.com>

Hello!

Considering Xorp.inc folded, I'm curious if anyone (with upstream commit privileges)
is planning any more significant changes to xorp?

In particular, does anyone still care about using libboost?  If not, I'm very tempted
to remove it to get rid of a big external dependency.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Feb 26 16:28:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 26 Feb 2010 16:28:45 -0800
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <15561.63761.qm@web58705.mail.re1.yahoo.com>
References: <15561.63761.qm@web58705.mail.re1.yahoo.com>
Message-ID: <4B88673D.7000609@candelatech.com>

On 02/26/2010 01:01 PM, Li Zhao wrote:
> Actually the configuration is very simple to reproduce the problem on Linux.

With the attached patch (on top of my tree), your config starts w/out
crashing, but I don't know that it's actually doing anything useful.

It certainly complains about adding a MAC that already exists and then
later trying to remove it when it's the only MAC around.  I just made
the errors non-fatal, but probably some logic in vrrp is busted
and should be fixed.

I can't see how the VrrpPacket::finalize() method ever failed to
assert that assert that I commented out, but surely someone successfully
got VRRP working at one time?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp-vrrp-crash.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100226/6b1fe13e/attachment.ksh 

From aleksandar.cvjetic at gmail.com  Sat Feb 27 04:46:37 2010
From: aleksandar.cvjetic at gmail.com (Aleksandar Cvjetic)
Date: Sat, 27 Feb 2010 13:46:37 +0100
Subject: [Xorp-hackers] BGP route table
Message-ID: <249ccfe91002270446v3c5a5f4as292811c6cfb0d31a@mail.gmail.com>

Hello,

I' m wondering where BGP route table is implemented in xorp? Searching into
docum. and code I found each branch (i.e. peer) has its own RIbIn table
where all routes from that peer are stored and the best one for each
destination is flagged.  Typing "show bgp routes" all BGP routes are
displayed, from each branch (peer). Is there a single BGP route table
containing all BGP routes from all peers (and "show bgp routes" display its
content, which I believe is not case in xorp, but I'm not sure) or a method
fetch all routes from each RibIn table when "show bgp routes" is invoked?

Any help appreciated!

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100227/0bd9791e/attachment.html 

From lizhaous2000 at yahoo.com  Sat Feb 27 05:23:15 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Sat, 27 Feb 2010 05:23:15 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <4B884442.5000506@candelatech.com>
Message-ID: <519882.69985.qm@web58706.mail.re1.yahoo.com>

I tried to remove those two assertion before, but MAC wno't be updated and there were some other problems. Now what I found was fea has some thing wrong. During debugging, I will post any findings as soon as possible.

Thanks

--- On Fri, 2/26/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] VRRP error
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "Eric S. Johnson" <esj at cs.fiu.edu>, xorp-hackers at icir.org
> Date: Friday, February 26, 2010, 4:59 PM
> On 02/26/2010 01:01 PM, Li Zhao
> wrote:
> > Actually the configuration is very simple to reproduce
> the problem on Linux.
> 
> I tried starting this on my system, and get an assertion.
> 
> I ran it with:
> /usr/local/xorp/bin/xorp_rtrmgr -b /root/xorp_vrrp.conf
> 
> The config file is exactly as you posted.
> 
> [ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] Clearing
> iftree: copy of user-config
> [ 2010/02/26 13:53:36? FATAL xorp_vrrp:13019 VRRP
> vrrp_packet.cc:173 finalize ] Assertion (_data.size() ==
> _data.capacity() && _data.size() ==
> VRRP_MAX_PACKET_SIZE) failed
> [ 2010/02/26 13:53:36? ERROR xorp_rtrmgr:12925 RTRMGR
> module_manager.cc:764 done_cb ] Command
> "/usr/local/xorp/vrrp/xorp_vrrp": terminated with signal 6.
> 
> I ran it again with the latest code (mostly changes Eric
> has been testing), and
> now it crashes:
> 
> [ 2010/02/26 13:57:34 WARNING xorp_fea XrlFeaTarget ]
> Handling method for ifmgr/0.1/create_mac failed: XrlCmdError
> 102 Command failed Cannot add MAC address 0:0:5e:0:1:64 on
> interface eth1: MAC already added
> [ 2010/02/26 13:57:34? FATAL xorp_vrrp:14729 VRRP
> vrrp_target.cc:362 xrl_cb ] XRL error: 102 Command failed
> Cannot add MAC address 0:0:5e:0:1:64 on interface eth1: MAC
> already added
> [ 2010/02/26 13:57:34? ERROR xorp_rtrmgr:14644 RTRMGR
> module_manager.cc:764 done_cb ] Command
> "/usr/local/xorp/vrrp/xorp_vrrp": terminated with signal 6.
> 
> 
> Looks like it's time to remove some asserts :P
> 
> 
> Thanks,
> Ben
> 
> -- Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From lizhaous2000 at yahoo.com  Sat Feb 27 05:27:19 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Sat, 27 Feb 2010 05:27:19 -0800 (PST)
Subject: [Xorp-hackers] Future Xorp development?
In-Reply-To: <4B884F89.4080507@candelatech.com>
Message-ID: <112362.22753.qm@web58708.mail.re1.yahoo.com>

I am curious. Because of that ex-Xorp Inc, there could not have been changes to xorp code?

--- On Fri, 2/26/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: [Xorp-hackers] Future Xorp development?
> To: "xorp" <xorp-hackers at xorp.org>
> Date: Friday, February 26, 2010, 5:47 PM
> Hello!
> 
> Considering Xorp.inc folded, I'm curious if anyone (with
> upstream commit privileges)
> is planning any more significant changes to xorp?
> 
> In particular, does anyone still care about using
> libboost?? If not, I'm very tempted
> to remove it to get rid of a big external dependency.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From lizhaous2000 at yahoo.com  Sat Feb 27 05:30:03 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Sat, 27 Feb 2010 05:30:03 -0800 (PST)
Subject: [Xorp-hackers] VRRP error
In-Reply-To: <4B88673D.7000609@candelatech.com>
Message-ID: <32414.26848.qm@web58707.mail.re1.yahoo.com>

I will read your patch on Monday. I assume vrrp should have been working at some time point.

--- On Fri, 2/26/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] VRRP error
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "Eric S. Johnson" <esj at cs.fiu.edu>, xorp-hackers at icir.org
> Date: Friday, February 26, 2010, 7:28 PM
> On 02/26/2010 01:01 PM, Li Zhao
> wrote:
> > Actually the configuration is very simple to reproduce
> the problem on Linux.
> 
> With the attached patch (on top of my tree), your config
> starts w/out
> crashing, but I don't know that it's actually doing
> anything useful.
> 
> It certainly complains about adding a MAC that already
> exists and then
> later trying to remove it when it's the only MAC
> around.? I just made
> the errors non-fatal, but probably some logic in vrrp is
> busted
> and should be fixed.
> 
> I can't see how the VrrpPacket::finalize() method ever
> failed to
> assert that assert that I commented out, but surely someone
> successfully
> got VRRP working at one time?
> 
> Thanks,
> Ben
> 
> -- Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From lizhaous2000 at yahoo.com  Sat Feb 27 05:34:45 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Sat, 27 Feb 2010 05:34:45 -0800 (PST)
Subject: [Xorp-hackers] BGP route table
In-Reply-To: <249ccfe91002270446v3c5a5f4as292811c6cfb0d31a@mail.gmail.com>
Message-ID: <864527.29360.qm@web58707.mail.re1.yahoo.com>

If understand your question correctly, you want some cli command to show 
the routing tables from all peers on one router cli. That is not the 
common practice on any commercial routers, like CISCO, juniper or Ericsson.

--- On Sat, 2/27/10, Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com> wrote:

> From: Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com>
> Subject: [Xorp-hackers] BGP route table
> To: xorp-hackers at icir.org
> Date: Saturday, February 27, 2010, 7:46 AM
> Hello,
> 
> I' m wondering where BGP route table is implemented in
> xorp? Searching into docum. and code I found each branch
> (i.e. peer) has its own RIbIn table where all routes from
> that peer are stored and the best one for each destination
> is flagged.? Typing "show bgp routes" all BGP
> routes are displayed, from each branch (peer). Is there a
> single BGP route table containing all BGP routes from all
> peers (and "show bgp routes" display its content,
> which I believe is not case in xorp, but I'm not sure)
> or a method fetch all routes from each RibIn table when
> "show bgp routes" is invoked? 
> 
> 
> Any help appreciated!
> 
> Thanks,
> Alex
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From aleksandar.cvjetic at gmail.com  Sat Feb 27 06:00:00 2010
From: aleksandar.cvjetic at gmail.com (Aleksandar Cvjetic)
Date: Sat, 27 Feb 2010 15:00:00 +0100
Subject: [Xorp-hackers] BGP route table
In-Reply-To: <864527.29360.qm@web58707.mail.re1.yahoo.com>
References: <249ccfe91002270446v3c5a5f4as292811c6cfb0d31a@mail.gmail.com>
	<864527.29360.qm@web58707.mail.re1.yahoo.com>
Message-ID: <249ccfe91002270600k3b80eb1bxe766476b90956778@mail.gmail.com>

Actually not. Existing command "show bgp routes" display content of xorp BGP
route table, right? This table should contains BGP routes from all BGP
peers, not particular one. Looking into code, I cannot see a single BGP
route table containing BGP routes from all peers (not only the best but all
BGP routes). So I suppose when one invoke "show bgp routes" on xorp there
must be some method fetching BGP routes from RibIn tables for each branch
(peer) because RibIn table is the only BGP table in plumbing containing all
(unmodified) BGP routes from the peer. At least, this is my understanding
after spending some time looking into code. I'm not sure how does commercial
routers implements BGP route table, but similar command will always display
content of BGP route table containing all BGP routes from all peers.

Thanks,
Alex

On Sat, Feb 27, 2010 at 2:34 PM, Li Zhao <lizhaous2000 at yahoo.com> wrote:

> If understand your question correctly, you want some cli command to show
> the routing tables from all peers on one router cli. That is not the
> common practice on any commercial routers, like CISCO, juniper or Ericsson.
>
> --- On Sat, 2/27/10, Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com>
> wrote:
>
> > From: Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com>
> > Subject: [Xorp-hackers] BGP route table
> > To: xorp-hackers at icir.org
> > Date: Saturday, February 27, 2010, 7:46 AM
> > Hello,
> >
> > I' m wondering where BGP route table is implemented in
> > xorp? Searching into docum. and code I found each branch
> > (i.e. peer) has its own RIbIn table where all routes from
> > that peer are stored and the best one for each destination
> > is flagged.  Typing "show bgp routes" all BGP
> > routes are displayed, from each branch (peer). Is there a
> > single BGP route table containing all BGP routes from all
> > peers (and "show bgp routes" display its content,
> > which I believe is not case in xorp, but I'm not sure)
> > or a method fetch all routes from each RibIn table when
> > "show bgp routes" is invoked?
> >
> >
> > Any help appreciated!
> >
> > Thanks,
> > Alex
> >
> >
> > -----Inline Attachment Follows-----
> >
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100227/1b7e264f/attachment.html 

From greearb at candelatech.com  Sat Feb 27 10:47:41 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 27 Feb 2010 10:47:41 -0800
Subject: [Xorp-hackers] Future Xorp development?
In-Reply-To: <112362.22753.qm@web58708.mail.re1.yahoo.com>
References: <112362.22753.qm@web58708.mail.re1.yahoo.com>
Message-ID: <4B8968CD.7050206@candelatech.com>

On 02/27/2010 05:27 AM, Li Zhao wrote:
> I am curious. Because of that ex-Xorp Inc, there could not have been changes to xorp code?

Xorp on source-forge and my tree is all GPL code, so nothing that happens to xorp.inc or
anything else can take that away or stop us from making changes to and/or using xorp
so long as we follow the rules of the GPL license.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From lizhaous2000 at yahoo.com  Sat Feb 27 19:29:03 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Sat, 27 Feb 2010 19:29:03 -0800 (PST)
Subject: [Xorp-hackers] BGP route table
In-Reply-To: <249ccfe91002270600k3b80eb1bxe766476b90956778@mail.gmail.com>
Message-ID: <480874.26926.qm@web58703.mail.re1.yahoo.com>

I think I misunderstood your question. Sorry about that.

--- On Sat, 2/27/10, Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com> wrote:

> From: Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com>
> Subject: Re: [Xorp-hackers] BGP route table
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: xorp-hackers at icir.org
> Date: Saturday, February 27, 2010, 9:00 AM
> Actually not. Existing command "show
> bgp routes" display content of xorp BGP route table,
> right? This table should contains BGP routes from all BGP
> peers, not particular one. Looking into code, I cannot see a
> single BGP route table containing BGP routes from all peers
> (not only the best but all BGP routes). So I suppose when
> one invoke "show bgp routes" on xorp there must be
> some method fetching BGP routes from RibIn tables for each
> branch (peer) because RibIn table is the only BGP table in
> plumbing containing all (unmodified) BGP routes from the
> peer. At least, this is my understanding after spending some
> time looking into code. I'm not sure how does commercial
> routers implements BGP route table, but similar command will
> always display content of BGP route table containing all BGP
> routes from all peers. 
> 
> 
> Thanks,
> Alex 
> 
> 
> On Sat, Feb 27, 2010 at 2:34 PM,
> Li Zhao <lizhaous2000 at yahoo.com>
> wrote:
> 
> 
> If understand your question correctly, you want some cli
> command to show
> 
> the routing tables from all peers on one router cli. That
> is not the
> 
> common practice on any commercial routers, like CISCO,
> juniper or Ericsson.
> 
> 
> 
> --- On Sat, 2/27/10, Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com>
> wrote:
> 
> 
> 
> > From: Aleksandar Cvjetic <aleksandar.cvjetic at gmail.com>
> 
> > Subject: [Xorp-hackers] BGP route table
> 
> > To: xorp-hackers at icir.org
> 
> > Date: Saturday, February 27, 2010, 7:46 AM
> 
> > Hello,
> 
> >
> 
> > I' m wondering where BGP route table is
> implemented in
> 
> > xorp? Searching into docum. and code I found each
> branch
> 
> > (i.e. peer) has its own RIbIn table where all routes
> from
> 
> > that peer are stored and the best one for each
> destination
> 
> > is flagged.? Typing "show bgp routes" all
> BGP
> 
> > routes are displayed, from each branch (peer). Is
> there a
> 
> > single BGP route table containing all BGP routes from
> all
> 
> > peers (and "show bgp routes" display its
> content,
> 
> > which I believe is not case in xorp, but I'm not
> sure)
> 
> > or a method fetch all routes from each RibIn table
> when
> 
> > "show bgp routes" is invoked?
> 
> >
> 
> >
> 
> > Any help appreciated!
> 
> >
> 
> > Thanks,
> 
> > Alex
> 
> >
> 
> >
> 
> > -----Inline Attachment Follows-----
> 
> >
> 
> > _______________________________________________
> 
> > Xorp-hackers mailing list
> 
> > Xorp-hackers at icir.org
> 
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
>