From yuvalif at gmail.com  Thu Jul  5 06:49:46 2007
From: yuvalif at gmail.com (Yuval Lifshitz)
Date: Thu, 5 Jul 2007 16:49:46 +0300
Subject: [Xorp-hackers] NO_ADVERTISE for own messages
Message-ID: <b9a2dd30707050649y41fe4139l9b32b27dafa76c43@mail.gmail.com>

Hi all,
I use xorp for sending self initialized iBGP messages (from the XRL
interface) in order to change routes at other routers.
In bgp/route_table_filter.cc there is a function, that should prevent the
redistribution of BGP messages when it is not desired by the community:

template<class A> const InternalMessage<A>*
KnownCommunityFilter<A>::filter(const InternalMessage<A> *rtmsg,bool
&modified) const;

The problem is that if I don't want the XRL initiated BGP messages to be
advertized by my peers, they should be initiated with the "NO_ADVERTISE"
community.
And the above function filters them out.
Currently, I just commented out the lines:

// Routes with NO_ADVERTISE don't get sent to anyone else
if (ca->contains(CommunityAttribute::NO_ADVERTISE)) {
   drop_message(rtmsg, modified);
   return NULL;
}

This might cause a problem when I get NO_ADVERTISE messages. Does anyone can
think of a better solution to the problem?

Thanks,

Yuval.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070705/029262eb/attachment.html 

From yuvalif at gmail.com  Thu Jul  5 07:20:44 2007
From: yuvalif at gmail.com (Yuval Lifshitz)
Date: Thu, 5 Jul 2007 17:20:44 +0300
Subject: [Xorp-hackers] get_route_list_next assert on empty aggregator
Message-ID: <b9a2dd30707050720t5212800av1ca5418248fdf055@mail.gmail.com>

Hi all,
I use the "get_route_list_next" from the BGP main process in order to
iterate over the RIB.
It worked fine when I tried that in the lab, but when my peer was a real
Juniper T router, I got:

assert(aggregator.size()==0);

in: BGPMain::extract_attributes()
any idea? is that a valid message the Juniper sent?
could I just bury my head in the sand and comment it out?

Thanks,

Yuval.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070705/62ba70ec/attachment.html 

From atanu at ICSI.Berkeley.EDU  Thu Jul  5 12:40:49 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 05 Jul 2007 12:40:49 -0700
Subject: [Xorp-hackers] get_route_list_next assert on empty aggregator
In-Reply-To: Message from "Yuval Lifshitz" <yuvalif@gmail.com> of "Thu,
	05 Jul 2007 17:20:44 +0300."
	<b9a2dd30707050720t5212800av1ca5418248fdf055@mail.gmail.com> 
Message-ID: <67586.1183664449@tigger.icir.org>

Hi,

The assumption in the "BGPMain::get_route_list_next()" and
"BGPMain::extract_attributes()" are that the output parameters are
empty, the vector arguments of which "aggregator" is just one should be
set to size zero. These methods were designed to be called by an
external program via XRL to extract the routing table entries and each
call starts with zero size vectors. If you are calling
"BGPMain::get_route_list_next()" in a loop from within BGP and there is
an aggregator in the table the subsequent call will cause this
assert. So "aggregator.resize(0)" before calling
"BGPMain::get_route_list_next()" should fix you problem.

Adding code to BGP to use this interface to trawl the routing table is a
bad idea, you should look at print_routes.cc in bgp/tools that provides
an external program to extract the routes from BGP using this interface.

   Atanu.

>>>>> "Yuval" == Yuval Lifshitz <yuvalif at gmail.com> writes:

    Yuval>    Hi all, I use the "get_route_list_next" from the BGP main
    Yuval> process in order to iterate over the RIB.  It worked fine
    Yuval> when I tried that in the lab, but when my peer was a real
    Yuval> Juniper T router, I got: assert( aggregator.size()==0); in:
    Yuval> BGPMain::extract_attributes() any idea? is that a valid
    Yuval> message the Juniper sent?  could I just bury my head in the
    Yuval> sand and comment it out?  Thanks, Yuval.
    Yuval> _______________________________________________ Xorp-hackers
    Yuval> mailing list Xorp-hackers at icir.org
    Yuval> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From kristian at spritelink.net  Thu Jul 12 00:30:11 2007
From: kristian at spritelink.net (Kristian Larsson)
Date: Thu, 12 Jul 2007 09:30:11 +0200
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/fea
In-Reply-To: <200707112224.l6BMOpdC054403@xorpc.icir.org>
References: <200707112224.l6BMOpdC054403@xorpc.icir.org>
Message-ID: <4695D883.5070700@spritelink.net>


Hey Pavlin,

where can I find documentation on this new scheme for the dataplane 
managers?

Regards,
    Kristian.



Pavlin Radoslavov wrote:
> CVSROOT:	/usr/local/share/doc/apache/cvs
> Module name:	xorp
> Changes by:	pavlin at xorpc.icir.org	2007-07-11 22:24:51 UTC
> 
> XORP CVS repository
> 
> 
> Added files:
> 	fea           fea_data_plane_manager.cc fea_data_plane_manager.hh 
> 
> Log message:
> 	Continuing with the FEA refactoring.
> 	
> 	Now there are data plane managers (one per system) which control
> 	the plugins at the bottom of the FEA.
> 	The data plane managers allocate (or load) the plugins and
> 	register them with the generic IfConfig and FibConfig controllers.
> 	
> 	In addition to managing the plugins, the data plane managers are the
> 	entry point for plugin-specific configuration. E.g., all the
> 	Click-specific configuration is passed to the Click data plane manager,
> 	so the rest of the system doesn't know anything about Click.
> 	
> 	Note that the design and implementation was done in collaboration
> 	with Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
> 	
> 	Approved by:    Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
> 
> Revision  Changes    Path
> 1.1       +496 -0    xorp/fea/fea_data_plane_manager.cc (new)
> 1.1       +250 -0    xorp/fea/fea_data_plane_manager.hh (new)
> 
> _______________________________________________
> Xorp-cvs mailing list
> Xorp-cvs at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs



From pavlin at icir.org  Thu Jul 12 09:41:21 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 12 Jul 2007 09:41:21 -0700
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/fea
In-Reply-To: Message from Kristian Larsson <kristian@spritelink.net> 
	of "Thu, 12 Jul 2007 09:30:11 +0200." <4695D883.5070700@spritelink.net> 
Message-ID: <200707121641.l6CGfLDe075742@possum.icir.org>

Kristian Larsson <kristian at spritelink.net> wrote:

> 
> Hey Pavlin,
> 
> where can I find documentation on this new scheme for the dataplane 
> managers?
> 
> Regards,
>     Kristian.

There is no documentation yet.
The FEA design document will be updated after the FEA refactoring is
completed.
In the mean time don't hesitate to ask any questions you might have
about it.

Regards,
Pavlin


> 
> 
> Pavlin Radoslavov wrote:
> > CVSROOT:	/usr/local/share/doc/apache/cvs
> > Module name:	xorp
> > Changes by:	pavlin at xorpc.icir.org	2007-07-11 22:24:51 UTC
> > 
> > XORP CVS repository
> > 
> > 
> > Added files:
> > 	fea           fea_data_plane_manager.cc fea_data_plane_manager.hh 
> > 
> > Log message:
> > 	Continuing with the FEA refactoring.
> > 	
> > 	Now there are data plane managers (one per system) which control
> > 	the plugins at the bottom of the FEA.
> > 	The data plane managers allocate (or load) the plugins and
> > 	register them with the generic IfConfig and FibConfig controllers.
> > 	
> > 	In addition to managing the plugins, the data plane managers are the
> > 	entry point for plugin-specific configuration. E.g., all the
> > 	Click-specific configuration is passed to the Click data plane manager,
> > 	so the rest of the system doesn't know anything about Click.
> > 	
> > 	Note that the design and implementation was done in collaboration
> > 	with Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
> > 	
> > 	Approved by:    Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
> > 
> > Revision  Changes    Path
> > 1.1       +496 -0    xorp/fea/fea_data_plane_manager.cc (new)
> > 1.1       +250 -0    xorp/fea/fea_data_plane_manager.hh (new)
> > 
> > _______________________________________________
> > Xorp-cvs mailing list
> > Xorp-cvs at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs
> 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From kristian at spritelink.net  Fri Jul 13 08:30:02 2007
From: kristian at spritelink.net (Kristian Larsson)
Date: Fri, 13 Jul 2007 17:30:02 +0200
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/fea
In-Reply-To: <200707121641.l6CGfLDe075742@possum.icir.org>
References: <200707121641.l6CGfLDe075742@possum.icir.org>
Message-ID: <46979A7A.90301@spritelink.net>

Pavlin Radoslavov wrote:
> Kristian Larsson <kristian at spritelink.net> wrote:
> 
>> Hey Pavlin,
>>
>> where can I find documentation on this new scheme for the dataplane 
>> managers?
>>
>> Regards,
>>     Kristian.
> 
> There is no documentation yet.
> The FEA design document will be updated after the FEA refactoring is
> completed.
> In the mean time don't hesitate to ask any questions you might have
> about it.

Well yes, what is the reason for refactoring the FEA? What is the 
problem that needs to be fixed and what additional benefits will XORP 
gain from this refactoring?
If you could just describe this quite briefly I'd be grateful :)

Thanks
    Kristian.



>> Pavlin Radoslavov wrote:
>>> CVSROOT:	/usr/local/share/doc/apache/cvs
>>> Module name:	xorp
>>> Changes by:	pavlin at xorpc.icir.org	2007-07-11 22:24:51 UTC
>>>
>>> XORP CVS repository
>>>
>>>
>>> Added files:
>>> 	fea           fea_data_plane_manager.cc fea_data_plane_manager.hh 
>>>
>>> Log message:
>>> 	Continuing with the FEA refactoring.
>>> 	
>>> 	Now there are data plane managers (one per system) which control
>>> 	the plugins at the bottom of the FEA.
>>> 	The data plane managers allocate (or load) the plugins and
>>> 	register them with the generic IfConfig and FibConfig controllers.
>>> 	
>>> 	In addition to managing the plugins, the data plane managers are the
>>> 	entry point for plugin-specific configuration. E.g., all the
>>> 	Click-specific configuration is passed to the Click data plane manager,
>>> 	so the rest of the system doesn't know anything about Click.
>>> 	
>>> 	Note that the design and implementation was done in collaboration
>>> 	with Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
>>> 	
>>> 	Approved by:    Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
>>>
>>> Revision  Changes    Path
>>> 1.1       +496 -0    xorp/fea/fea_data_plane_manager.cc (new)
>>> 1.1       +250 -0    xorp/fea/fea_data_plane_manager.hh (new)
>>>
>>> _______________________________________________
>>> Xorp-cvs mailing list
>>> Xorp-cvs at icir.org
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



From pavlin at icir.org  Fri Jul 13 10:31:48 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 13 Jul 2007 10:31:48 -0700
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/fea
In-Reply-To: Message from Kristian Larsson <kristian@spritelink.net> 
	of "Fri, 13 Jul 2007 17:30:02 +0200." <46979A7A.90301@spritelink.net> 
Message-ID: <200707131731.l6DHVmU8086956@possum.icir.org>

Kristian Larsson <kristian at spritelink.net> wrote:

> Pavlin Radoslavov wrote:
> > Kristian Larsson <kristian at spritelink.net> wrote:
> > 
> >> Hey Pavlin,
> >>
> >> where can I find documentation on this new scheme for the dataplane 
> >> managers?
> >>
> >> Regards,
> >>     Kristian.
> > 
> > There is no documentation yet.
> > The FEA design document will be updated after the FEA refactoring is
> > completed.
> > In the mean time don't hesitate to ask any questions you might have
> > about it.
> 
> Well yes, what is the reason for refactoring the FEA? What is the 
> problem that needs to be fixed and what additional benefits will XORP 
> gain from this refactoring?
> If you could just describe this quite briefly I'd be grateful :)

The main purpose for the refactoring is to make it easier to add
support for new systems/platforms and new routing architectures
such as virtualization, distributed routers (incl. distributed FEA),
etc.

Regards,
Pavlin


> >> Pavlin Radoslavov wrote:
> >>> CVSROOT:	/usr/local/share/doc/apache/cvs
> >>> Module name:	xorp
> >>> Changes by:	pavlin at xorpc.icir.org	2007-07-11 22:24:51 UTC
> >>>
> >>> XORP CVS repository
> >>>
> >>>
> >>> Added files:
> >>> 	fea           fea_data_plane_manager.cc fea_data_plane_manager.hh 
> >>>
> >>> Log message:
> >>> 	Continuing with the FEA refactoring.
> >>> 	
> >>> 	Now there are data plane managers (one per system) which control
> >>> 	the plugins at the bottom of the FEA.
> >>> 	The data plane managers allocate (or load) the plugins and
> >>> 	register them with the generic IfConfig and FibConfig controllers.
> >>> 	
> >>> 	In addition to managing the plugins, the data plane managers are the
> >>> 	entry point for plugin-specific configuration. E.g., all the
> >>> 	Click-specific configuration is passed to the Click data plane manager,
> >>> 	so the rest of the system doesn't know anything about Click.
> >>> 	
> >>> 	Note that the design and implementation was done in collaboration
> >>> 	with Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
> >>> 	
> >>> 	Approved by:    Adam Greenhalgh <a.greenhalgh AT cs.ucl.ac.uk>
> >>>
> >>> Revision  Changes    Path
> >>> 1.1       +496 -0    xorp/fea/fea_data_plane_manager.cc (new)
> >>> 1.1       +250 -0    xorp/fea/fea_data_plane_manager.hh (new)
> >>>
> >>> _______________________________________________
> >>> Xorp-cvs mailing list
> >>> Xorp-cvs at icir.org
> >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs


From damien.leroy at uclouvain.be  Wed Jul 18 09:04:42 2007
From: damien.leroy at uclouvain.be (Damien Leroy)
Date: Wed, 18 Jul 2007 18:04:42 +0200
Subject: [Xorp-hackers] Generating the XRL interface
Message-ID: <469E3A1A.30501@uclouvain.be>

Hello,
I am trying to write a simple protocol in XORP 1.4. As explained in the 
document "An introduction to writing a XORP process", I have written a 
.xif file and modified the Makefile.am file. If I run a "./configure", a 
new Makefile is created but it does not take into account my changes of 
Makefile.am. So, there is no change when I "make".
Do I have to run "automake" or did I forget something ?
(I use gcc/g++  4.1, make 3.81, autoconf 2.61, automake 1.10, libtool 
1.5.22 and an Ubuntu 7.04)

Regards,

-- 
Damien Leroy
IP Networking Lab (http://inl.info.ucl.ac.be)
Computer Science & Engineering Dept. (INGI)
UCLouvain - Belgium


From atanu at ICSI.Berkeley.EDU  Wed Jul 18 09:19:43 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 18 Jul 2007 09:19:43 -0700
Subject: [Xorp-hackers] Generating the XRL interface
In-Reply-To: Message from Damien Leroy <damien.leroy@uclouvain.be> 
	of "Wed, 18 Jul 2007 18:04:42 +0200." <469E3A1A.30501@uclouvain.be> 
Message-ID: <80033.1184775583@tigger.icir.org>

Hi,

You need to run the script ./bootstrap in the top level directory.

    Atanu.

>>>>> "Damien" == Damien Leroy <damien.leroy at uclouvain.be> writes:

    Damien> Hello,
    Damien> I am trying to write a simple protocol in XORP 1.4. As explained in the 
    Damien> document "An introduction to writing a XORP process", I have written a 
    Damien> .xif file and modified the Makefile.am file. If I run a "./configure", a 
    Damien> new Makefile is created but it does not take into account my changes of 
    Damien> Makefile.am. So, there is no change when I "make".
    Damien> Do I have to run "automake" or did I forget something ?
    Damien> (I use gcc/g++  4.1, make 3.81, autoconf 2.61, automake 1.10, libtool 
    Damien> 1.5.22 and an Ubuntu 7.04)

    Damien> Regards,

    Damien> -- 
    Damien> Damien Leroy
    Damien> IP Networking Lab (http://inl.info.ucl.ac.be)
    Damien> Computer Science & Engineering Dept. (INGI)
    Damien> UCLouvain - Belgium

    Damien> _______________________________________________
    Damien> Xorp-hackers mailing list
    Damien> Xorp-hackers at icir.org
    Damien> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin at icir.org  Wed Jul 18 09:32:40 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 18 Jul 2007 09:32:40 -0700
Subject: [Xorp-hackers] Generating the XRL interface
In-Reply-To: Message from Damien Leroy <damien.leroy@uclouvain.be> 
	of "Wed, 18 Jul 2007 18:04:42 +0200." <469E3A1A.30501@uclouvain.be> 
Message-ID: <200707181632.l6IGWe1q094746@possum.icir.org>

Damien Leroy <damien.leroy at uclouvain.be> wrote:

> Hello,
> I am trying to write a simple protocol in XORP 1.4. As explained in the 
> document "An introduction to writing a XORP process", I have written a 
> .xif file and modified the Makefile.am file. If I run a "./configure", a 
> new Makefile is created but it does not take into account my changes of 
> Makefile.am. So, there is no change when I "make".
> Do I have to run "automake" or did I forget something ?
> (I use gcc/g++  4.1, make 3.81, autoconf 2.61, automake 1.10, libtool 
> 1.5.22 and an Ubuntu 7.04)

If you modify any of the Makefile.am or configure.in files, then you
need to run first ./bootstrap in the XORP top-level directory. 
It will run the appropriate autoconf/automake tools, and after that
you need to run ./configure and gmake.

However, XORP-1.4 requires that you use older versions of the
autotools:

    - autoconf version 2.53
    - automake version 1.5
    - libtool version 1.3.4

There could be various issues if you use newer versions with that
code, but you could give it a try.


If you get the latest XORP code from CVS, it has been updated to use
more recent autotool versions:
    - autoconf version 2.61
    - automake version 1.10
    - libtool version 1.5.22

Note however that the updated bootstrap script in CVS also expects
the autotool commands to have the following names:

ACLOCAL=${ACLOCAL:-"aclocal110"}
AUTOCONF=${AUTOCONF:-"autoconf261"}
AUTOHEADER=${AUTOHEADER:-"autoheader261"}
AUTOMAKE=${AUTOMAKE:-"automake110"}
LIBTOOLIZE=${LIBTOOLIZE:-"libtoolize"}

Most likely your Ubuntu installation uses different names.
To get around this you need to set the
ACLOCAL/AUTOCONF/AUTOHEADER/AUTOMAKE/LIBTOOLIZE variables in your
shell environment to the appropriate names before running
./bootstrap.

Regards,
Pavlin


From damien.leroy at uclouvain.be  Thu Jul 19 06:21:55 2007
From: damien.leroy at uclouvain.be (Damien Leroy)
Date: Thu, 19 Jul 2007 15:21:55 +0200
Subject: [Xorp-hackers] Generating the XRL interface
In-Reply-To: <80033.1184775583@tigger.icir.org>
References: <80033.1184775583@tigger.icir.org>
Message-ID: <469F6573.3020601@uclouvain.be>

If I run "./bootstrap", "./configure" and make, "make" directly
fails with "libtool: unrecognized option `--tag=CC'". If I replace
libtool of xorp/ by the one of my OS, "make" fails later with "libtool: link: `xrl_tokens.lo' is not a valid libtool object".


Regards,
Damien

Atanu Ghosh a ?crit :
> Hi,
>
> You need to run the script ./bootstrap in the top level directory.
>
>     Atanu.
>
>   
>>>>>> "Damien" == Damien Leroy <damien.leroy at uclouvain.be> writes:
>>>>>>             
>
>     Damien> Hello,
>     Damien> I am trying to write a simple protocol in XORP 1.4. As explained in the 
>     Damien> document "An introduction to writing a XORP process", I have written a 
>     Damien> .xif file and modified the Makefile.am file. If I run a "./configure", a 
>     Damien> new Makefile is created but it does not take into account my changes of 
>     Damien> Makefile.am. So, there is no change when I "make".
>     Damien> Do I have to run "automake" or did I forget something ?
>     Damien> (I use gcc/g++  4.1, make 3.81, autoconf 2.61, automake 1.10, libtool 
>     Damien> 1.5.22 and an Ubuntu 7.04)
>
>     Damien> Regards,
>
>     Damien> -- 
>     Damien> Damien Leroy
>     Damien> IP Networking Lab (http://inl.info.ucl.ac.be)
>     Damien> Computer Science & Engineering Dept. (INGI)
>     Damien> UCLouvain - Belgium
>
>     Damien> _______________________________________________
>     Damien> Xorp-hackers mailing list
>     Damien> Xorp-hackers at icir.org
>     Damien> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>   


From pavlin at icir.org  Thu Jul 19 20:46:43 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 19 Jul 2007 20:46:43 -0700
Subject: [Xorp-hackers] Generating the XRL interface
In-Reply-To: Message from Damien Leroy <damien.leroy@uclouvain.be> 
	of "Thu, 19 Jul 2007 15:21:55 +0200." <469F6573.3020601@uclouvain.be> 
Message-ID: <200707200346.l6K3khfZ023091@possum.icir.org>

Damien Leroy <damien.leroy at uclouvain.be> wrote:

> If I run "./bootstrap", "./configure" and make, "make" directly
> fails with "libtool: unrecognized option `--tag=CC'". If I replace
> libtool of xorp/ by the one of my OS, "make" fails later with "libtool: link: `xrl_tokens.lo' is not a valid libtool object".

Did you use XORP-1.4 or the latest code from CVS?
If the former, then as I mentioned in my previous email on the
subject you need to use older versions of the autotools.

The latest CVS code should work with the autotool versions you have,
so you should give it a try. Make sure that you start with a fresh
tree. Mixing any autotools related leftovers might break the
compilation. The xorp/libtool script should be autogenerated after
running ./configure so you shouldn't copy it from somewhere else.
The result of any such mixture is unpredictable.

Regards,
Pavlin


> 
> Regards,
> Damien
> 
> Atanu Ghosh a ?crit :
> > Hi,
> >
> > You need to run the script ./bootstrap in the top level directory.
> >
> >     Atanu.
> >
> >   
> >>>>>> "Damien" == Damien Leroy <damien.leroy at uclouvain.be> writes:
> >>>>>>             
> >
> >     Damien> Hello,
> >     Damien> I am trying to write a simple protocol in XORP 1.4. As explained in the 
> >     Damien> document "An introduction to writing a XORP process", I have written a 
> >     Damien> .xif file and modified the Makefile.am file. If I run a "./configure", a 
> >     Damien> new Makefile is created but it does not take into account my changes of 
> >     Damien> Makefile.am. So, there is no change when I "make".
> >     Damien> Do I have to run "automake" or did I forget something ?
> >     Damien> (I use gcc/g++  4.1, make 3.81, autoconf 2.61, automake 1.10, libtool 
> >     Damien> 1.5.22 and an Ubuntu 7.04)
> >
> >     Damien> Regards,
> >
> >     Damien> -- 
> >     Damien> Damien Leroy
> >     Damien> IP Networking Lab (http://inl.info.ucl.ac.be)
> >     Damien> Computer Science & Engineering Dept. (INGI)
> >     Damien> UCLouvain - Belgium
> >
> >     Damien> _______________________________________________
> >     Damien> Xorp-hackers mailing list
> >     Damien> Xorp-hackers at icir.org
> >     Damien> 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


From damien.leroy at uclouvain.be  Fri Jul 20 06:29:03 2007
From: damien.leroy at uclouvain.be (Damien Leroy)
Date: Fri, 20 Jul 2007 15:29:03 +0200
Subject: [Xorp-hackers] Generating the XRL interface
In-Reply-To: <200707200346.l6K3khfZ023091@possum.icir.org>
References: <200707200346.l6K3khfZ023091@possum.icir.org>
Message-ID: <46A0B89F.6070907@uclouvain.be>

I was using XORP-1.4.
I try with the CVS version and it seems to work.
Thanks!

Damien

Pavlin Radoslavov a ?crit :
> Damien Leroy <damien.leroy at uclouvain.be> wrote:
>
>   
>> If I run "./bootstrap", "./configure" and make, "make" directly
>> fails with "libtool: unrecognized option `--tag=CC'". If I replace
>> libtool of xorp/ by the one of my OS, "make" fails later with "libtool: link: `xrl_tokens.lo' is not a valid libtool object".
>>     
>
> Did you use XORP-1.4 or the latest code from CVS?
> If the former, then as I mentioned in my previous email on the
> subject you need to use older versions of the autotools.
>
> The latest CVS code should work with the autotool versions you have,
> so you should give it a try. Make sure that you start with a fresh
> tree. Mixing any autotools related leftovers might break the
> compilation. The xorp/libtool script should be autogenerated after
> running ./configure so you shouldn't copy it from somewhere else.
> The result of any such mixture is unpredictable.
>
> Regards,
> Pavlin
>
>
>   
>> Regards,
>> Damien
>>
>> Atanu Ghosh a ?crit :
>>     
>>> Hi,
>>>
>>> You need to run the script ./bootstrap in the top level directory.
>>>
>>>     Atanu.
>>>
>>>   
>>>       
>>>>>>>> "Damien" == Damien Leroy <damien.leroy at uclouvain.be> writes:
>>>>>>>>             
>>>>>>>>                 
>>>     Damien> Hello,
>>>     Damien> I am trying to write a simple protocol in XORP 1.4. As explained in the 
>>>     Damien> document "An introduction to writing a XORP process", I have written a 
>>>     Damien> .xif file and modified the Makefile.am file. If I run a "./configure", a 
>>>     Damien> new Makefile is created but it does not take into account my changes of 
>>>     Damien> Makefile.am. So, there is no change when I "make".
>>>     Damien> Do I have to run "automake" or did I forget something ?
>>>     Damien> (I use gcc/g++  4.1, make 3.81, autoconf 2.61, automake 1.10, libtool 
>>>     Damien> 1.5.22 and an Ubuntu 7.04)
>>>
>>>     Damien> Regards,
>>>
>>>     Damien> -- 
>>>     Damien> Damien Leroy
>>>     Damien> IP Networking Lab (http://inl.info.ucl.ac.be)
>>>     Damien> Computer Science & Engineering Dept. (INGI)
>>>     Damien> UCLouvain - Belgium
>>>
>>>     Damien> _______________________________________________
>>>     Damien> Xorp-hackers mailing list
>>>     Damien> Xorp-hackers at icir.org
>>>     Damien> 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
>>     


From euan.harris at cl.cam.ac.uk  Fri Jul 27 02:24:02 2007
From: euan.harris at cl.cam.ac.uk (Euan Harris)
Date: Fri, 27 Jul 2007 10:24:02 +0100
Subject: [Xorp-hackers] BGP SubnetRoute[Const]Ref copy constructor doesn't
	check for a NULL route
Message-ID: <7E691132-6545-4672-9A26-500FE5F43E0C@cl.cam.ac.uk>

Hi,

The copy constructor in BGP's SubnetRouteRef and SubnetRouteConstRef  
doesn't check whether the route pointed to by the Ref it is copying  
is NULL before calling bump_refcount on it.   The main constructor  
does check, so it is possible to construct a Ref to a NULL route  
without any trouble but cause a segfault when some other part of the  
program tries to copy it.  This might happen when you try to insert  
the reference into a RefTrie.

I've attached a tiny patch that adds the required check.   I don't  
think this problem will come up in the current Xorp code because it  
does not store NULL routes.

Thanks,
Euan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: subnetrouteref-null.patch.gz
Type: application/x-gzip
Size: 328 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070727/d8ca07b4/attachment.gz 

From pavlin at icir.org  Mon Jul 30 14:03:36 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 30 Jul 2007 14:03:36 -0700
Subject: [Xorp-hackers] BGP SubnetRoute[Const]Ref copy constructor
	doesn't check for a NULL route
In-Reply-To: Message from Euan Harris <euan.harris@cl.cam.ac.uk> of "Fri,
	27 Jul 2007 10:24:02 BST."
	<7E691132-6545-4672-9A26-500FE5F43E0C@cl.cam.ac.uk> 
Message-ID: <200707302103.l6UL3aCU055570@possum.icir.org>

Euan Harris <euan.harris at cl.cam.ac.uk> wrote:

> Hi,
> 
> The copy constructor in BGP's SubnetRouteRef and SubnetRouteConstRef  doesn't
> check whether the route pointed to by the Ref it is copying  is NULL before
> calling bump_refcount on it.   The main constructor  does check, so it is
> possible to construct a Ref to a NULL route  without any trouble but cause a
> segfault when some other part of the  program tries to copy it.  This might
> happen when you try to insert  the reference into a RefTrie.
> 
> I've attached a tiny patch that adds the required check.   I don't  think this
> problem will come up in the current Xorp code because it  does not store NULL
> routes.

Euan,

I think you are right, it is a bug.
I just committed your fix to CVS:

Revision  Changes                               Path
1.24      +5 -3;  commitid: 126d846ae51177ea6;  xorp/bgp/subnet_route.hh

Thanks,
Pavlin