From greearb at candelatech.com  Mon Sep  1 13:23:49 2008
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 01 Sep 2008 13:23:49 -0700
Subject: [Xorp-hackers] Patch to fix issue with interface removal and
	multicast.
Message-ID: <48BC4F55.2050301@candelatech.com>

The attached patch fixes (or hacks around) some problems I see with
certain scenarios related to removing interfaces dynamically when
multicast is enabled.  It's possible this problem is because of my other
fea changes, but I think it's a problem with the base logic.

There is likely more that one issue here, but I think this use case 
described
below would probably reproduce this on un-patched xorp configured with
multicast.

My case is with my patched xorp, and the patch is on top of my other 
patches.

Here is the scenario:

Suppose a xorp instance has 3 interfaces, br0, eth0, eth1, and suppose 
eth0 and eth1
are usb NICs that can dissappear when removed from the machine (I'm using
different virtual interfaces, but the logic is similar.)

I have a control program that notices (or causes) interface removal, and 
when it does,
it sends cli commands to xorpsh to remove the config related to that 
interface.

Now, xorp is all fine with 3 interfaces.
...
eth0 is removed
 my monitor program initiates xorpsh commands to remove eth0 config info
eth1 is removed
 xorp notices eth0 is removed and cleans up fea logic.
 xorp notices eth1 is removed and cleans up fea logic.
 xorpsh commands above get to the 'commit' stage
 monitor program queues additional commands to remove eth1 config info

The commit fails, because the commit tries to set info for eth1, and the 
device is no
longer in the kernel.  Since this commit fails, the next one to remove 
eth1 will as well
(because eth0 is still in the config, and still not in the OS).

The scenario above can happen in several different orders, but the basic 
problem is that
xorp commit cannot deal with interfaces being removed from the OS at 
arbitrary times.

The attached patch ignores failure cases related to interfaces being 
removed.  I think
it would be better if we could return a warning message to the xorpsh 
without
failing the commit, but that is beyond the scope of what I have time to 
accomplish
currently.

Please consider applying any part of this you see as useful, and/or 
coming up with something
better.

Thanks,
Ben


-- 

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp_mcast_commit.patch
Type: text/x-patch
Size: 8929 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080901/c04d7161/attachment.bin 

From mcastuser at gmail.com  Tue Sep  2 01:54:11 2008
From: mcastuser at gmail.com (Adriano Favaro)
Date: Tue, 2 Sep 2008 05:54:11 -0300
Subject: [Xorp-hackers] Data Plane Integration
Message-ID: <a1a398280809020154s3fd5df5chee4c794d332f53fa@mail.gmail.com>

We are using XORP in a product development mostly on the Control Plane
because Data Plane is executed on-chip by our system. I would like to know
if anybody heard about a similar use-case for XORP.

Also I was wonder to know if anybody heard about XORP being used by
so-called "famous" vendors on networking maket.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080902/38a4bcaa/attachment.html 

From bms at incunabulum.net  Tue Sep  2 05:53:42 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Tue, 02 Sep 2008 13:53:42 +0100
Subject: [Xorp-hackers] Data Plane Integration
In-Reply-To: <a1a398280809020154s3fd5df5chee4c794d332f53fa@mail.gmail.com>
References: <a1a398280809020154s3fd5df5chee4c794d332f53fa@mail.gmail.com>
Message-ID: <48BD3756.8010502@incunabulum.net>

Adriano Favaro wrote:
> We are using XORP in a product development mostly on the Control Plane 
> because Data Plane is executed on-chip by our system. I would like to 
> know if anybody heard about a similar use-case for XORP.

That's pretty much how things are designed -- the forwarding plane is
not part of XORP per se.

The FEA process just wraps the existing host operating system
facilities, which typically operate in software. The FEA process would
need to be extended to support forwarding plane hardware. There is a
plug-in type interface for doing this in the code.

cheers
BMS


From pavlin at ICSI.Berkeley.EDU  Tue Sep  2 15:25:12 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 02 Sep 2008 15:25:12 -0700
Subject: [Xorp-hackers] Patch to fix issue with interface removal and
	multicast.
In-Reply-To: <48BC4F55.2050301@candelatech.com> 
References: <48BC4F55.2050301@candelatech.com>
Message-ID: <200809022225.m82MPChF012821@fruitcake.ICSI.Berkeley.EDU>

Ben,

XORP has to be able to handle interfaces that disappear, including
pure software-created interfaces like tunnels and VPNs.
Hence, please submit a bug about the issue including a little bit
more detailed instructions how to reproduce it. E.g., please include
the starting configuration, and your monitoring script.

I am afraid that the patch itself cannot be accepted for
the following two reasons:
* It hides the real problem instead of fixing it.
* Performing error checking by testing the content of the error
  message itself is not acceptable: it is error prone and is not
  efficient.
However, the patch could be useful to point toward the problem,
hence feel free to include it in the Bugzilla entry.

Thanks,
Pavlin

Ben Greear <greearb at candelatech.com> wrote:

> The attached patch fixes (or hacks around) some problems I see with
> certain scenarios related to removing interfaces dynamically when
> multicast is enabled.  It's possible this problem is because of my other
> fea changes, but I think it's a problem with the base logic.
> 
> There is likely more that one issue here, but I think this use case described
> below would probably reproduce this on un-patched xorp configured with
> multicast.
> 
> My case is with my patched xorp, and the patch is on top of my other patches.
> 
> Here is the scenario:
> 
> Suppose a xorp instance has 3 interfaces, br0, eth0, eth1, and suppose eth0
> and eth1
> are usb NICs that can dissappear when removed from the machine (I'm using
> different virtual interfaces, but the logic is similar.)
> 
> I have a control program that notices (or causes) interface removal, and when
> it does,
> it sends cli commands to xorpsh to remove the config related to that interface.
> 
> Now, xorp is all fine with 3 interfaces.
> ...
> eth0 is removed
>  my monitor program initiates xorpsh commands to remove eth0 config info
> eth1 is removed
>  xorp notices eth0 is removed and cleans up fea logic.
>  xorp notices eth1 is removed and cleans up fea logic.
>  xorpsh commands above get to the 'commit' stage
>  monitor program queues additional commands to remove eth1 config info
> 
> The commit fails, because the commit tries to set info for eth1, and the
> device is no
> longer in the kernel.  Since this commit fails, the next one to remove eth1
> will as well
> (because eth0 is still in the config, and still not in the OS).
> 
> The scenario above can happen in several different orders, but the basic
> problem is that
> xorp commit cannot deal with interfaces being removed from the OS at arbitrary
> times.
> 
> The attached patch ignores failure cases related to interfaces being removed.
> I think
> it would be better if we could return a warning message to the xorpsh without
> failing the commit, but that is beyond the scope of what I have time to
> accomplish
> currently.
> 
> Please consider applying any part of this you see as useful, and/or coming up
> with something
> better.
> 
> Thanks,
> Ben
> 
> 
> -- 
> 
> Ben Greear <greearb at candelatech.com> Candela Technologies Inc
> http://www.candelatech.com
> 
> 
> diff --git a/fea/data_plane/ifconfig/ifconfig_set.cc b/fea/data_plane/ifconfig/ifconfig_set.cc
> index 5693373..9362d3c 100644
> --- a/fea/data_plane/ifconfig/ifconfig_set.cc
> +++ b/fea/data_plane/ifconfig/ifconfig_set.cc
> @@ -140,9 +140,11 @@ IfConfigSet::push_config(const IfTree& iftree)
>  		// XXX: ignore deleted interfaces that are not recognized
>  		continue;
>  	    }
> -	    error_reporter.interface_error(config_iface.ifname(),
> -					   "interface not recognized");
> -	    break;
> +	    // Maybe it was already deleted from xorp due to OS removal.  We should
> +	    // just ignore this one
> +	    //error_reporter.interface_error(config_iface.ifname(),
> +	    //			   "interface not recognized");
> +	    //break;
>  	}
>  
>  	//
> @@ -244,6 +246,7 @@ IfConfigSet::push_config(const IfTree& iftree)
>  
>  	    push_vif_creation(system_ifp, system_vifp, config_iface,
>  			      config_vif);
> +
>  	}
>      }
>  
> @@ -648,8 +651,24 @@ IfConfigSet::push_vif_address(const IfTreeInterface*	system_ifp,
>  			       config_iface, config_vif, config_addr,
>  			       error_msg)
>  	    != XORP_OK) {
> -	    error_msg = c_format("Failed to add address: %s",
> -				 error_msg.c_str());
> +	    if (strstr(error_msg.c_str(), "No such device")) {
> +		XLOG_ERROR("Failed to configure address because of device not found: %s",
> +			   error_msg.c_str());
> +		// We can't pass this back as an error to the cli because the device is gone,
> +		// and if we fail this set, the whole commit will fail.  This commit could be
> +		// deleting *another* device, with a (very near) future set of xorpsh commands
> +		// coming in to delete *this* interface in question.
> +		// This is a hack...we really need a way to pass warnings back to the
> +		// cli but NOT fail the commit if the logical state is correct but the
> +		// (transient, unpredictable, asynchronously discovered) state of the actual
> +		// OS network devices is currently out of state.
> +		// --Ben
> +		error_msg = "";
> +	    }
> +	    else {
> +		error_msg = c_format("Failed to add address, not device-no-found error: %s",
> +				     error_msg.c_str());
> +	    }
>  	}
>      } else {
>  	//
> @@ -720,8 +739,24 @@ IfConfigSet::push_vif_address(const IfTreeInterface*	system_ifp,
>  			       config_iface, config_vif, config_addr,
>  			       error_msg)
>  	    != XORP_OK) {
> -	    error_msg = c_format("Failed to configure address: %s",
> -				 error_msg.c_str());
> +	    if (strstr(error_msg.c_str(), "No such device")) {
> +		XLOG_ERROR("Failed to configure address because of device not found: %s",
> +			   error_msg.c_str());
> +		// We can't pass this back as an error to the cli because the device is gone,
> +		// and if we fail this set, the whole commit will fail.  This commit could be
> +		// deleting *another* device, with a (very near) future set of xorpsh commands
> +		// coming in to delete *this* interface in question.
> +		// This is a hack...we really need a way to pass warnings back to the
> +		// cli but NOT fail the commit if the logical state is correct but the
> +		// (transient, unpredictable, asynchronously discovered) state of the actual
> +		// OS network devices is currently out of state.
> +		// --Ben
> +		error_msg = "";
> +	    }
> +	    else {
> +		error_msg = c_format("Failed to configure address, not device-no-found error: %s",
> +				     error_msg.c_str());
> +	    }
>  	}
>      } else {
>  	//
> diff --git a/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc b/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
> index 0880b5d..2381d6b 100644
> --- a/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
> +++ b/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc
> @@ -961,7 +961,7 @@ IfConfigSetNetlinkSocket::add_addr(const string& ifname,
>      if (ns.sendto(&buffer, nlh->nlmsg_len, 0,
>  		  reinterpret_cast<struct sockaddr*>(&snl), sizeof(snl))
>  	!= (ssize_t)nlh->nlmsg_len) {
> -	error_msg = c_format("Cannot add address '%s' "
> +	error_msg = c_format("IfConfigSetNetlinkSocket::add_addr: sendto: Cannot add address '%s' "
>  			     "on interface '%s' vif '%s': %s",
>  			     addr.str().c_str(),
>  			     ifname.c_str(), vifname.c_str(), strerror(errno));
> @@ -970,7 +970,7 @@ IfConfigSetNetlinkSocket::add_addr(const string& ifname,
>      if (NlmUtils::check_netlink_request(_ns_reader, ns, nlh->nlmsg_seq,
>  					last_errno, error_msg)
>  	!= XORP_OK) {
> -	error_msg = c_format("Cannot add address '%s' "
> +	error_msg = c_format("IfConfigSetNetlinkSocket::add_addr: check_nl_req: Cannot add address '%s' "
>  			     "on interface '%s' vif '%s': %s",
>  			     addr.str().c_str(),
>  			     ifname.c_str(), vifname.c_str(),
> diff --git a/fea/mfea_node.cc b/fea/mfea_node.cc
> index 04027d7..a216414 100644
> --- a/fea/mfea_node.cc
> +++ b/fea/mfea_node.cc
> @@ -1125,7 +1125,7 @@ MfeaNode::enable_vif(const string& vif_name, string& error_msg)
>  {
>      MfeaVif *mfea_vif = vif_find_by_name(vif_name);
>      if (mfea_vif == NULL) {
> -	error_msg = c_format("Cannot enable vif %s: no such vif",
> +	error_msg = c_format("MfeaNode:  Cannot enable vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
>  	return (XORP_ERROR);
> @@ -1153,7 +1153,9 @@ MfeaNode::disable_vif(const string& vif_name, string& error_msg)
>  	error_msg = c_format("Cannot disable vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
> -	return (XORP_ERROR);
> +        // If it's gone, it's as disabled as it can be.
> +	//return (XORP_ERROR);
> +        return XORP_OK;
>      }
>      
>      mfea_vif->disable();
> @@ -1211,7 +1213,10 @@ MfeaNode::stop_vif(const string& vif_name, string& error_msg)
>  	error_msg = c_format("Cannot stop vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
> -	return (XORP_ERROR);
> +	// If it doesn't exist, it's as stopped as it's going to get.  Returning
> +	// error will cause entire commit to fail.
> +	//return (XORP_ERROR);
> +	return XORP_OK;
>      }
>      
>      if (mfea_vif->stop(error_msg) != XORP_OK) {
> diff --git a/fea/xrl_mfea_node.cc b/fea/xrl_mfea_node.cc
> index 79a1afd..b834f21 100644
> --- a/fea/xrl_mfea_node.cc
> +++ b/fea/xrl_mfea_node.cc
> @@ -1407,8 +1407,10 @@ XrlMfeaNode::mfea_0_1_enable_vif(
>      else
>  	ret_code = MfeaNode::disable_vif(vif_name, error_msg);
>  
> -    if (ret_code != XORP_OK)
> -	return XrlCmdError::COMMAND_FAILED(error_msg);
> +    if (ret_code != XORP_OK) {
> +        XLOG_ERROR("Mfea, enable/disable vif failed.  Allowing commit to succeed anyway since this is likely a race with a deleted interface, error: %s\n", error_msg.c_str());
> +	//return XrlCmdError::COMMAND_FAILED(error_msg);
> +    }
>      
>      return XrlCmdError::OKAY();
>  }
> diff --git a/mld6igmp/mld6igmp_node.cc b/mld6igmp/mld6igmp_node.cc
> index bd4610d..d0b70b6 100644
> --- a/mld6igmp/mld6igmp_node.cc
> +++ b/mld6igmp/mld6igmp_node.cc
> @@ -1028,7 +1028,7 @@ Mld6igmpNode::enable_vif(const string& vif_name, string& error_msg)
>  {
>      Mld6igmpVif *mld6igmp_vif = vif_find_by_name(vif_name);
>      if (mld6igmp_vif == NULL) {
> -	error_msg = c_format("Cannot enable vif %s: no such vif",
> +	error_msg = c_format("Mld6igmpNode:  Cannot enable vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
>  	return (XORP_ERROR);
> @@ -1056,7 +1056,9 @@ Mld6igmpNode::disable_vif(const string& vif_name, string& error_msg)
>  	error_msg = c_format("Cannot disable vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
> -	return (XORP_ERROR);
> +	// It's as disabled as it will get, don't fail commit.
> +	error_msg = "";
> +	return XORP_OK;
>      }
>      
>      mld6igmp_vif->disable();
> diff --git a/pim/pim_node.cc b/pim/pim_node.cc
> index 7ea543c..e18feee 100644
> --- a/pim/pim_node.cc
> +++ b/pim/pim_node.cc
> @@ -1155,7 +1155,7 @@ PimNode::enable_vif(const string& vif_name, string& error_msg)
>  {
>      PimVif *pim_vif = vif_find_by_name(vif_name);
>      if (pim_vif == NULL) {
> -	error_msg = c_format("Cannot enable vif %s: no such vif",
> +	error_msg = c_format("PimNode:  Cannot enable vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
>  	return (XORP_ERROR);
> @@ -1183,7 +1183,9 @@ PimNode::disable_vif(const string& vif_name, string& error_msg)
>  	error_msg = c_format("Cannot disable vif %s: no such vif",
>  			     vif_name.c_str());
>  	XLOG_ERROR("%s", error_msg.c_str());
> -	return (XORP_ERROR);
> +	// It's as disabled as it's going to get..don't fail the commit.
> +	error_msg = "";
> +	return XORP_OK;
>      }
>      
>      pim_vif->disable();
> diff --git a/pim/xrl_pim_node.cc b/pim/xrl_pim_node.cc
> index 45da17e..6cb38cd 100644
> --- a/pim/xrl_pim_node.cc
> +++ b/pim/xrl_pim_node.cc
> @@ -1322,8 +1322,9 @@ XrlPimNode::mfea_client_send_register_unregister_protocol_cb(
>  	//
>  	// If a command failed because the other side rejected it, this is
>  	// fatal.
> +	// Shouldn't be fatal, network device can suddenly dissappear, for instance.
>  	//
> -	XLOG_FATAL("Cannot %s protocol with the MFEA: %s",
> +	XLOG_ERROR("Cannot %s protocol with the MFEA: %s",
>  		   entry->operation_name(), xrl_error.str().c_str());
>  	break;
>  
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From rtp.techie at gmail.com  Tue Sep  2 15:38:05 2008
From: rtp.techie at gmail.com (RTP Techie)
Date: Tue, 2 Sep 2008 18:38:05 -0400
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on MIPS64/Linux/GCC3.4.3
Message-ID: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>

Hi,
 I just downloaded the XORP 1.5 and was trying to compile it. I was able to
compile it with no problem on native Linux EL3 using GCC 3.4.5
But when I try to cross compile it for mips64 using GCC 3.4.3 (that is the
tool chain that we are using on the embedded system).
I got the following compilatin errors and hope if anyone knows how to
address it:



gmake[3]: Entering directory `/export/home/cmchan/dev/xorp-1.5/libxorp' /bin/sh
../libtool --tag=CXX   --mode=compile
/export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ -DHAVE_CONFIG_H
-I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
-mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
-mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
-Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT asyncio.lo
-MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
 /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ -DHAVE_CONFIG_H
-I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
-mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
-mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
-Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT asyncio.lo
-MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
In file included from
/export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
                 from ../libxorp/xorp.h:64,
                 from asyncio.cc:22:
/export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
error: expected unqualified-id before "unsigned"
/export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
error: expected `;' before "unsigned"
In file included from ../libxorp/xorp.h:64,
                 from asyncio.cc:22:
/export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
error: declaration of `operator new' as non-function
/export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
error: expected unqualified-id before "unsigned"

Thanks,
RT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080902/d9b00340/attachment.html 

From greearb at candelatech.com  Tue Sep  2 15:40:14 2008
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 02 Sep 2008 15:40:14 -0700
Subject: [Xorp-hackers] Patch to fix issue with interface removal and
 multicast.
In-Reply-To: <200809022225.m82MPChF012821@fruitcake.ICSI.Berkeley.EDU>
References: <48BC4F55.2050301@candelatech.com>
	<200809022225.m82MPChF012821@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <48BDC0CE.4040306@candelatech.com>

Pavlin Radoslavov wrote:
> Ben,
> 
> XORP has to be able to handle interfaces that disappear, including
> pure software-created interfaces like tunnels and VPNs.
> Hence, please submit a bug about the issue including a little bit
> more detailed instructions how to reproduce it. E.g., please include
> the starting configuration, and your monitoring script.
> 
> I am afraid that the patch itself cannot be accepted for
> the following two reasons:
> * It hides the real problem instead of fixing it.
> * Performing error checking by testing the content of the error
>   message itself is not acceptable: it is error prone and is not
>   efficient.
> However, the patch could be useful to point toward the problem,
> hence feel free to include it in the Bugzilla entry.

I agree the patch is a hack.  I'll open a bug with more info,
but I'm afraid I can't really give you a simple way to reproduce this:

It requires not only my own program but a partner's program
that is driving mine to easily reproduce this.  I'm quite sure
I can get permission to install their stuff on a system (for no charge)
if you want to test with our full package.  With everying enabled,
this is 100% reproducible with a few simple commands.

I think the basic problem is that pieces of xorp expect that it
knows the state of the OS, when in fact it can only know the *preferred*
state at any given time.

For instance, if I tell xorp to enable multicast on eth4, and eth4
does not currently exist, it should not fail the commit but remember
the config and apply it if eth4 ever does come into existence.  The
only time a commit should fail is if the requested config is logically
incorrect regardless of the current state of the OS's interfaces.

That is at least my opinion, and what I believe I need to drive
it programatically in a dynamic environment.

Thanks,
Ben

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


From pavlin at ICSI.Berkeley.EDU  Tue Sep  2 16:33:54 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 02 Sep 2008 16:33:54 -0700
Subject: [Xorp-hackers] Patch to fix issue with interface removal and
	multicast.
In-Reply-To: <48BDC0CE.4040306@candelatech.com> 
References: <48BC4F55.2050301@candelatech.com>
	<200809022225.m82MPChF012821@fruitcake.ICSI.Berkeley.EDU>
	<48BDC0CE.4040306@candelatech.com>
Message-ID: <200809022333.m82NXs57020946@fruitcake.ICSI.Berkeley.EDU>

> I think the basic problem is that pieces of xorp expect that it
> knows the state of the OS, when in fact it can only know the *preferred*
> state at any given time.
> 
> For instance, if I tell xorp to enable multicast on eth4, and eth4
> does not currently exist, it should not fail the commit but remember
> the config and apply it if eth4 ever does come into existence.  The
> only time a commit should fail is if the requested config is logically
> incorrect regardless of the current state of the OS's interfaces.

Agree. The multicast code's interface/vif handling is overdue for
refactoring. Once the refactoring is done, the interface
appearing/disappearing should be handled properly.
You might want to add your paragraph above as well to the Bugzilla
entry.

Pavlin

> That is at least my opinion, and what I believe I need to drive
> it programatically in a dynamic environment.
> 
> 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 pavlin at ICSI.Berkeley.EDU  Tue Sep  2 17:22:40 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 02 Sep 2008 17:22:40 -0700
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com> 
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
Message-ID: <200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>

RTP Techie <rtp.techie at gmail.com> wrote:

> Hi,
>  I just downloaded the XORP 1.5 and was trying to compile it. I was able to
> compile it with no problem on native Linux EL3 using GCC 3.4.5
> But when I try to cross compile it for mips64 using GCC 3.4.3 (that is the
> tool chain that we are using on the embedded system).
> I got the following compilatin errors and hope if anyone knows how to
> address it:

It looks like some of the C++ header files generate those errors.
Could you try to compile the following simple C++ program using the
mips64_fp_be-g++ compiler:

#include <new>
#include <iostream>

int
main()
{
    return (0);
}


First try to do it without any extra arguments:
/export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ test.cc

Then try it with the -I/export/crosstools/mvl40/mips64/fp_be/include
g++ argument.

This will help us narrow our focus on the problem.

Pavlin

P.S. Have you modified file libxorp/asyncio.cc?
The first error below referes to file xorph.h included from
asyncio.cc line 22, but in the XORP-1.5 source code the actual line
where xorp.h is included is 20.


> gmake[3]: Entering directory `/export/home/cmchan/dev/xorp-1.5/libxorp' /bin/sh
> ../libtool --tag=CXX   --mode=compile
> /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ -DHAVE_CONFIG_H
> -I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> -mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT asyncio.lo
> -MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
>  /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ -DHAVE_CONFIG_H
> -I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> -mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT asyncio.lo
> -MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
> In file included from
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
>                  from ../libxorp/xorp.h:64,
>                  from asyncio.cc:22:
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> error: expected unqualified-id before "unsigned"
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> error: expected `;' before "unsigned"
> In file included from ../libxorp/xorp.h:64,
>                  from asyncio.cc:22:
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> error: declaration of `operator new' as non-function
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> error: expected unqualified-id before "unsigned"
> 
> Thanks,
> RT
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From rtp.techie at gmail.com  Wed Sep  3 16:18:11 2008
From: rtp.techie at gmail.com (RTP Techie)
Date: Wed, 3 Sep 2008 19:18:11 -0400
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>

Thanks both Pavlin and Bruce.

It is stupid me. Since I need to manually setup the env var for x-compiler,
I miss-typed some of the stuffs for the preprocessor.



So, I got it compiled finally.

Here is the next issue that I've when run it from my target system.

There is not enough space for me to copy the files to "tagert".

>From the target, I mnt it back to my host system from "/mnt/xorp" to
"/home/cmchan/dev/xorp-builds/mips64-montavista-linux".



By following the user guide, I need to run xorp_rtrmgr 1st.

By default it looks for config and template files from the host-path, so I
need to use command option to set them correctly, like in below:

./mips64-montavista-linux-xorp_rtrmgr -v -b /mnt/xorp/config/static.boot  -x
/mnt/xorp/xrl/targets/ -t /mnt/xorp/etc/templates/



Yes, I also create a group and add root to it.

But then I see the following error, and not sure what to do with it.



root at target:/mnt/xorp/bin# ./mips64-montavista-linux-xorp_rtrmgr -v -b
/mnt/xorp/config/static.boot  -x /mnt/xorp/xrl/targets/ -t /mnt/x
orp/etc/templates/

[ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
Boot file                  := /mnt/xorp/config/static.boot

[ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
Templates directory        := /mnt/xorp/etc/templates/

[ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ] Xrl
targets directory      := /mnt/xorp/xrl/targets/

[ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
Execute Xrls               := true

[ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
Restart failed processes   := false

[ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
Print verbose information  := true

[ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
+239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall,
fea, rib, policy, static_routes

[ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
+2253 task.cc fail_tasklist_initialization ] Cannot create module
interfaces:
/home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
not exist

[ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
+641 master_conf_tree.cc commit_changes_pass2 ] Commit failed in deciding
startups

[ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
+251 master_conf_tree.cc config_done ] Configuration failed: Cannot create
module interfaces:
/home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
not exist

[ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
+2228 task.cc run_task ] No more tasks to run




Seem like xorp_rtrmgr is trying to exec "xorp_fea" from my host path? How to
address this?
Thanks,

RT



On Tue, Sep 2, 2008 at 8:22 PM, Pavlin Radoslavov
<pavlin at icsi.berkeley.edu>wrote:

> RTP Techie <rtp.techie at gmail.com> wrote:
>
> > Hi,
> >  I just downloaded the XORP 1.5 and was trying to compile it. I was able
> to
> > compile it with no problem on native Linux EL3 using GCC 3.4.5
> > But when I try to cross compile it for mips64 using GCC 3.4.3 (that is
> the
> > tool chain that we are using on the embedded system).
> > I got the following compilatin errors and hope if anyone knows how to
> > address it:
>
> It looks like some of the C++ header files generate those errors.
> Could you try to compile the following simple C++ program using the
> mips64_fp_be-g++ compiler:
>
> #include <new>
> #include <iostream>
>
> int
> main()
> {
>    return (0);
> }
>
>
> First try to do it without any extra arguments:
> /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ test.cc
>
> Then try it with the -I/export/crosstools/mvl40/mips64/fp_be/include
> g++ argument.
>
> This will help us narrow our focus on the problem.
>
> Pavlin
>
> P.S. Have you modified file libxorp/asyncio.cc?
> The first error below referes to file xorph.h included from
> asyncio.cc line 22, but in the XORP-1.5 source code the actual line
> where xorp.h is included is 20.
>
>
> > gmake[3]: Entering directory `/export/home/cmchan/dev/xorp-1.5/libxorp'
> /bin/sh
> > ../libtool --tag=CXX   --mode=compile
> > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> -DHAVE_CONFIG_H
> > -I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > -mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> asyncio.lo
> > -MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
> >  /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> -DHAVE_CONFIG_H
> > -I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > -mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> asyncio.lo
> > -MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
> > In file included from
> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
> >                  from ../libxorp/xorp.h:64,
> >                  from asyncio.cc:22:
> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> > error: expected unqualified-id before "unsigned"
> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> > error: expected `;' before "unsigned"
> > In file included from ../libxorp/xorp.h:64,
> >                  from asyncio.cc:22:
> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> > error: declaration of `operator new' as non-function
> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> > error: expected unqualified-id before "unsigned"
> >
> > Thanks,
> > RT
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers<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/20080903/cfc9d66b/attachment.html 

From bms at ICSI.Berkeley.EDU  Wed Sep  3 16:30:55 2008
From: bms at ICSI.Berkeley.EDU (Bruce M. Simpson)
Date: Thu, 04 Sep 2008 00:30:55 +0100
Subject: [Xorp-hackers] Patch to fix issue with interface removal and
 multicast.
In-Reply-To: <200809022333.m82NXs57020946@fruitcake.ICSI.Berkeley.EDU>
References: <48BC4F55.2050301@candelatech.com>	<200809022225.m82MPChF012821@fruitcake.ICSI.Berkeley.EDU>	<48BDC0CE.4040306@candelatech.com>
	<200809022333.m82NXs57020946@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <48BF1E2F.6010405@icsi.berkeley.edu>

Pavlin Radoslavov wrote:
> Agree. The multicast code's interface/vif handling is overdue for
> refactoring. Once the refactoring is done, the interface
> appearing/disappearing should be handled properly.
>   

Just my 2p: we need that functionality to support hot-swappable 
interfaces, for both datacenter and MANET deployments.

cheers
BMS


From pavlin at ICSI.Berkeley.EDU  Thu Sep  4 06:48:22 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 04 Sep 2008 06:48:22 -0700
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com> 
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
Message-ID: <200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>

RTP Techie <rtp.techie at gmail.com> wrote:

> Here is the next issue that I've when run it from my target system.
> 
> There is not enough space for me to copy the files to "tagert".
> 
> From the target, I mnt it back to my host system from "/mnt/xorp" to
> "/home/cmchan/dev/xorp-builds/mips64-montavista-linux".
> 
> 
> 
> By following the user guide, I need to run xorp_rtrmgr 1st.
> 
> By default it looks for config and template files from the host-path, so I
> need to use command option to set them correctly, like in below:
> 
> ./mips64-montavista-linux-xorp_rtrmgr -v -b /mnt/xorp/config/static.boot  -x
> /mnt/xorp/xrl/targets/ -t /mnt/xorp/etc/templates/
> 
> 
> 
> Yes, I also create a group and add root to it.
> 
> But then I see the following error, and not sure what to do with it.

It looks like something is mixed-up when the rtrmgr tries to choose
the path to the XORP binaries. Assuming everything is installed
under /mnt/xorp, you could try to set the XORP_ROOT environmental
variable. E.g.:

setenv XORP_ROOT /mnt/xorp
/mnt/xorp/bin/xorp_rtrmgr -b /mnt/xorp/config/static.boot

Hope that helps,
Pavlin

> 
> 
> root at target:/mnt/xorp/bin# ./mips64-montavista-linux-xorp_rtrmgr -v -b
> /mnt/xorp/config/static.boot  -x /mnt/xorp/xrl/targets/ -t /mnt/x
> orp/etc/templates/
> 
> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> Boot file                  := /mnt/xorp/config/static.boot
> 
> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> Templates directory        := /mnt/xorp/etc/templates/
> 
> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ] Xrl
> targets directory      := /mnt/xorp/xrl/targets/
> 
> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> Execute Xrls               := true
> 
> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> Restart failed processes   := false
> 
> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> Print verbose information  := true
> 
> [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> +239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall,
> fea, rib, policy, static_routes
> 
> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> +2253 task.cc fail_tasklist_initialization ] Cannot create module
> interfaces:
> /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
> not exist
> 
> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> +641 master_conf_tree.cc commit_changes_pass2 ] Commit failed in deciding
> startups
> 
> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> +251 master_conf_tree.cc config_done ] Configuration failed: Cannot create
> module interfaces:
> /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
> not exist
> 
> [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> +2228 task.cc run_task ] No more tasks to run
> 
> 
> 
> 
> Seem like xorp_rtrmgr is trying to exec "xorp_fea" from my host path? How to
> address this?
> Thanks,
> 
> RT
> 
> 
> 
> On Tue, Sep 2, 2008 at 8:22 PM, Pavlin Radoslavov
> <pavlin at icsi.berkeley.edu>wrote:
> 
> > RTP Techie <rtp.techie at gmail.com> wrote:
> >
> > > Hi,
> > >  I just downloaded the XORP 1.5 and was trying to compile it. I was able
> > to
> > > compile it with no problem on native Linux EL3 using GCC 3.4.5
> > > But when I try to cross compile it for mips64 using GCC 3.4.3 (that is
> > the
> > > tool chain that we are using on the embedded system).
> > > I got the following compilatin errors and hope if anyone knows how to
> > > address it:
> >
> > It looks like some of the C++ header files generate those errors.
> > Could you try to compile the following simple C++ program using the
> > mips64_fp_be-g++ compiler:
> >
> > #include <new>
> > #include <iostream>
> >
> > int
> > main()
> > {
> >    return (0);
> > }
> >
> >
> > First try to do it without any extra arguments:
> > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ test.cc
> >
> > Then try it with the -I/export/crosstools/mvl40/mips64/fp_be/include
> > g++ argument.
> >
> > This will help us narrow our focus on the problem.
> >
> > Pavlin
> >
> > P.S. Have you modified file libxorp/asyncio.cc?
> > The first error below referes to file xorph.h included from
> > asyncio.cc line 22, but in the XORP-1.5 source code the actual line
> > where xorp.h is included is 20.
> >
> >
> > > gmake[3]: Entering directory `/export/home/cmchan/dev/xorp-1.5/libxorp'
> > /bin/sh
> > > ../libtool --tag=CXX   --mode=compile
> > > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> > -DHAVE_CONFIG_H
> > > -I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > -mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> > asyncio.lo
> > > -MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
> > >  /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> > -DHAVE_CONFIG_H
> > > -I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > -mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> > asyncio.lo
> > > -MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
> > > In file included from
> > >
> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
> > >                  from ../libxorp/xorp.h:64,
> > >                  from asyncio.cc:22:
> > >
> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> > > error: expected unqualified-id before "unsigned"
> > >
> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> > > error: expected `;' before "unsigned"
> > > In file included from ../libxorp/xorp.h:64,
> > >                  from asyncio.cc:22:
> > >
> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> > > error: declaration of `operator new' as non-function
> > >
> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> > > error: expected unqualified-id before "unsigned"
> > >
> > > Thanks,
> > > RT
> > > _______________________________________________
> > > Xorp-hackers mailing list
> > > Xorp-hackers at icir.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers<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 a.greenhalgh at cs.ucl.ac.uk  Thu Sep  4 07:06:23 2008
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Thu, 4 Sep 2008 15:06:23 +0100
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>

Hi,

I think this comes back to the cross compile issue I bug reported a
while back where configures --prefix is being overloaded.

Adam

2008/9/4 Pavlin Radoslavov <pavlin at icsi.berkeley.edu>:
> RTP Techie <rtp.techie at gmail.com> wrote:
>
>> Here is the next issue that I've when run it from my target system.
>>
>> There is not enough space for me to copy the files to "tagert".
>>
>> From the target, I mnt it back to my host system from "/mnt/xorp" to
>> "/home/cmchan/dev/xorp-builds/mips64-montavista-linux".
>>
>>
>>
>> By following the user guide, I need to run xorp_rtrmgr 1st.
>>
>> By default it looks for config and template files from the host-path, so I
>> need to use command option to set them correctly, like in below:
>>
>> ./mips64-montavista-linux-xorp_rtrmgr -v -b /mnt/xorp/config/static.boot  -x
>> /mnt/xorp/xrl/targets/ -t /mnt/xorp/etc/templates/
>>
>>
>>
>> Yes, I also create a group and add root to it.
>>
>> But then I see the following error, and not sure what to do with it.
>
> It looks like something is mixed-up when the rtrmgr tries to choose
> the path to the XORP binaries. Assuming everything is installed
> under /mnt/xorp, you could try to set the XORP_ROOT environmental
> variable. E.g.:
>
> setenv XORP_ROOT /mnt/xorp
> /mnt/xorp/bin/xorp_rtrmgr -b /mnt/xorp/config/static.boot
>
> Hope that helps,
> Pavlin
>
>>
>>
>> root at target:/mnt/xorp/bin# ./mips64-montavista-linux-xorp_rtrmgr -v -b
>> /mnt/xorp/config/static.boot  -x /mnt/xorp/xrl/targets/ -t /mnt/x
>> orp/etc/templates/
>>
>> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
>> Boot file                  := /mnt/xorp/config/static.boot
>>
>> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
>> Templates directory        := /mnt/xorp/etc/templates/
>>
>> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ] Xrl
>> targets directory      := /mnt/xorp/xrl/targets/
>>
>> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
>> Execute Xrls               := true
>>
>> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
>> Restart failed processes   := false
>>
>> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
>> Print verbose information  := true
>>
>> [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
>> +239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall,
>> fea, rib, policy, static_routes
>>
>> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
>> +2253 task.cc fail_tasklist_initialization ] Cannot create module
>> interfaces:
>> /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
>> not exist
>>
>> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
>> +641 master_conf_tree.cc commit_changes_pass2 ] Commit failed in deciding
>> startups
>>
>> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
>> +251 master_conf_tree.cc config_done ] Configuration failed: Cannot create
>> module interfaces:
>> /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
>> not exist
>>
>> [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
>> +2228 task.cc run_task ] No more tasks to run
>>
>>
>>
>>
>> Seem like xorp_rtrmgr is trying to exec "xorp_fea" from my host path? How to
>> address this?
>> Thanks,
>>
>> RT
>>
>>
>>
>> On Tue, Sep 2, 2008 at 8:22 PM, Pavlin Radoslavov
>> <pavlin at icsi.berkeley.edu>wrote:
>>
>> > RTP Techie <rtp.techie at gmail.com> wrote:
>> >
>> > > Hi,
>> > >  I just downloaded the XORP 1.5 and was trying to compile it. I was able
>> > to
>> > > compile it with no problem on native Linux EL3 using GCC 3.4.5
>> > > But when I try to cross compile it for mips64 using GCC 3.4.3 (that is
>> > the
>> > > tool chain that we are using on the embedded system).
>> > > I got the following compilatin errors and hope if anyone knows how to
>> > > address it:
>> >
>> > It looks like some of the C++ header files generate those errors.
>> > Could you try to compile the following simple C++ program using the
>> > mips64_fp_be-g++ compiler:
>> >
>> > #include <new>
>> > #include <iostream>
>> >
>> > int
>> > main()
>> > {
>> >    return (0);
>> > }
>> >
>> >
>> > First try to do it without any extra arguments:
>> > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ test.cc
>> >
>> > Then try it with the -I/export/crosstools/mvl40/mips64/fp_be/include
>> > g++ argument.
>> >
>> > This will help us narrow our focus on the problem.
>> >
>> > Pavlin
>> >
>> > P.S. Have you modified file libxorp/asyncio.cc?
>> > The first error below referes to file xorph.h included from
>> > asyncio.cc line 22, but in the XORP-1.5 source code the actual line
>> > where xorp.h is included is 20.
>> >
>> >
>> > > gmake[3]: Entering directory `/export/home/cmchan/dev/xorp-1.5/libxorp'
>> > /bin/sh
>> > > ../libtool --tag=CXX   --mode=compile
>> > > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
>> > -DHAVE_CONFIG_H
>> > > -I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
>> > > -mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
>> > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
>> > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
>> > asyncio.lo
>> > > -MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
>> > >  /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
>> > -DHAVE_CONFIG_H
>> > > -I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
>> > > -mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
>> > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
>> > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
>> > asyncio.lo
>> > > -MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
>> > > In file included from
>> > >
>> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
>> > >                  from ../libxorp/xorp.h:64,
>> > >                  from asyncio.cc:22:
>> > >
>> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
>> > > error: expected unqualified-id before "unsigned"
>> > >
>> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
>> > > error: expected `;' before "unsigned"
>> > > In file included from ../libxorp/xorp.h:64,
>> > >                  from asyncio.cc:22:
>> > >
>> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
>> > > error: declaration of `operator new' as non-function
>> > >
>> > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
>> > > error: expected unqualified-id before "unsigned"
>> > >
>> > > Thanks,
>> > > RT
>> > > _______________________________________________
>> > > Xorp-hackers mailing list
>> > > Xorp-hackers at icir.org
>> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers<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
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From rtp.techie at gmail.com  Thu Sep  4 09:03:09 2008
From: rtp.techie at gmail.com (RTP Techie)
Date: Thu, 4 Sep 2008 12:03:09 -0400
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
	<4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>
Message-ID: <5c95ad230809040903v3146d56ak6029680bda3d6a81@mail.gmail.com>

I will try to set the env var let you folks know if it works for me

So, since I'm new to the code base, is there any more of these env var get
documented somewhere?


On Thu, Sep 4, 2008 at 10:06 AM, Adam Greenhalgh
<a.greenhalgh at cs.ucl.ac.uk>wrote:

> Hi,
>
> I think this comes back to the cross compile issue I bug reported a
> while back where configures --prefix is being overloaded.
>
> Adam
>
> 2008/9/4 Pavlin Radoslavov <pavlin at icsi.berkeley.edu>:
>  > RTP Techie <rtp.techie at gmail.com> wrote:
> >
> >> Here is the next issue that I've when run it from my target system.
> >>
> >> There is not enough space for me to copy the files to "tagert".
> >>
> >> From the target, I mnt it back to my host system from "/mnt/xorp" to
> >> "/home/cmchan/dev/xorp-builds/mips64-montavista-linux".
> >>
> >>
> >>
> >> By following the user guide, I need to run xorp_rtrmgr 1st.
> >>
> >> By default it looks for config and template files from the host-path, so
> I
> >> need to use command option to set them correctly, like in below:
> >>
> >> ./mips64-montavista-linux-xorp_rtrmgr -v -b /mnt/xorp/config/static.boot
>  -x
> >> /mnt/xorp/xrl/targets/ -t /mnt/xorp/etc/templates/
> >>
> >>
> >>
> >> Yes, I also create a group and add root to it.
> >>
> >> But then I see the following error, and not sure what to do with it.
> >
> > It looks like something is mixed-up when the rtrmgr tries to choose
> > the path to the XORP binaries. Assuming everything is installed
> > under /mnt/xorp, you could try to set the XORP_ROOT environmental
> > variable. E.g.:
> >
> > setenv XORP_ROOT /mnt/xorp
> > /mnt/xorp/bin/xorp_rtrmgr -b /mnt/xorp/config/static.boot
> >
> > Hope that helps,
> > Pavlin
> >
> >>
> >>
> >> root at target:/mnt/xorp/bin# ./mips64-montavista-linux-xorp_rtrmgr -v -b
> >> /mnt/xorp/config/static.boot  -x /mnt/xorp/xrl/targets/ -t /mnt/x
> >> orp/etc/templates/
> >>
> >> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> >> Boot file                  := /mnt/xorp/config/static.boot
> >>
> >> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> >> Templates directory        := /mnt/xorp/etc/templates/
> >>
> >> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> Xrl
> >> targets directory      := /mnt/xorp/xrl/targets/
> >>
> >> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> >> Execute Xrls               := true
> >>
> >> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> >> Restart failed processes   := false
> >>
> >> [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> >> Print verbose information  := true
> >>
> >> [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444
> RTRMGR
> >> +239 master_conf_tree.cc execute ] Changed modules: interfaces,
> firewall,
> >> fea, rib, policy, static_routes
> >>
> >> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444
> RTRMGR
> >> +2253 task.cc fail_tasklist_initialization ] Cannot create module
> >> interfaces:
> >> /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file
> does
> >> not exist
> >>
> >> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444
> RTRMGR
> >> +641 master_conf_tree.cc commit_changes_pass2 ] Commit failed in
> deciding
> >> startups
> >>
> >> [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444
> RTRMGR
> >> +251 master_conf_tree.cc config_done ] Configuration failed: Cannot
> create
> >> module interfaces:
> >> /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file
> does
> >> not exist
> >>
> >> [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444
> RTRMGR
> >> +2228 task.cc run_task ] No more tasks to run
> >>
> >>
> >>
> >>
> >> Seem like xorp_rtrmgr is trying to exec "xorp_fea" from my host path?
> How to
> >> address this?
> >> Thanks,
> >>
> >> RT
> >>
> >>
> >>
> >> On Tue, Sep 2, 2008 at 8:22 PM, Pavlin Radoslavov
> >> <pavlin at icsi.berkeley.edu>wrote:
> >>
> >> > RTP Techie <rtp.techie at gmail.com> wrote:
> >> >
> >> > > Hi,
> >> > >  I just downloaded the XORP 1.5 and was trying to compile it. I was
> able
> >> > to
> >> > > compile it with no problem on native Linux EL3 using GCC 3.4.5
> >> > > But when I try to cross compile it for mips64 using GCC 3.4.3 (that
> is
> >> > the
> >> > > tool chain that we are using on the embedded system).
> >> > > I got the following compilatin errors and hope if anyone knows how
> to
> >> > > address it:
> >> >
> >> > It looks like some of the C++ header files generate those errors.
> >> > Could you try to compile the following simple C++ program using the
> >> > mips64_fp_be-g++ compiler:
> >> >
> >> > #include <new>
> >> > #include <iostream>
> >> >
> >> > int
> >> > main()
> >> > {
> >> >    return (0);
> >> > }
> >> >
> >> >
> >> > First try to do it without any extra arguments:
> >> > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ test.cc
> >> >
> >> > Then try it with the -I/export/crosstools/mvl40/mips64/fp_be/include
> >> > g++ argument.
> >> >
> >> > This will help us narrow our focus on the problem.
> >> >
> >> > Pavlin
> >> >
> >> > P.S. Have you modified file libxorp/asyncio.cc?
> >> > The first error below referes to file xorph.h included from
> >> > asyncio.cc line 22, but in the XORP-1.5 source code the actual line
> >> > where xorp.h is included is 20.
> >> >
> >> >
> >> > > gmake[3]: Entering directory
> `/export/home/cmchan/dev/xorp-1.5/libxorp'
> >> > /bin/sh
> >> > > ../libtool --tag=CXX   --mode=compile
> >> > > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> >> > -DHAVE_CONFIG_H
> >> > > -I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include
> -mtune=sb1
> >> > > -mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include
> -mtune=sb1
> >> > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual
> -Wpointer-arith
> >> > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> >> > asyncio.lo
> >> > > -MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
> >> > >  /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> >> > -DHAVE_CONFIG_H
> >> > > -I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include
> -mtune=sb1
> >> > > -mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> >> > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual
> -Wpointer-arith
> >> > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> >> > asyncio.lo
> >> > > -MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
> >> > > In file included from
> >> > >
> >> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
> >> > >                  from ../libxorp/xorp.h:64,
> >> > >                  from asyncio.cc:22:
> >> > >
> >> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> >> > > error: expected unqualified-id before "unsigned"
> >> > >
> >> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> >> > > error: expected `;' before "unsigned"
> >> > > In file included from ../libxorp/xorp.h:64,
> >> > >                  from asyncio.cc:22:
> >> > >
> >> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> >> > > error: declaration of `operator new' as non-function
> >> > >
> >> >
> /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> >> > > error: expected unqualified-id before "unsigned"
> >> > >
> >> > > Thanks,
> >> > > RT
> >> > > _______________________________________________
> >> > > Xorp-hackers mailing list
> >> > > Xorp-hackers at icir.org
> >> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers<http://mailman.icsi.berkeley.edu/mailman/listinfo/xorp-hackers>
> <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<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<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/20080904/76aa7916/attachment-0001.html 

From pavlin at ICSI.Berkeley.EDU  Thu Sep  4 09:08:00 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 04 Sep 2008 09:08:00 -0700
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU> 
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <200809041608.m84G80tx016269@fruitcake.ICSI.Berkeley.EDU>

After some additional investigation I think I found the root of the
problem.

If XORP_ROOT is not set, then the derived path to the executables is
either the install path (/usr/local/xorp by default) or the build
directory (if XORP is running from the build directory itself).
In your case you have mounted the original install directory under
a different path (/mnt/xorp) hence the executables needed by the
rtrmgr are not found.

Currently there is no command-line option to explicitly set the path
to the binary files (e.g., like the setting of the targets and
templates directories).
The solution is to use the XORP_ROOT environmental variable as I
specified in my previous email.

Pavlin

Pavlin Radoslavov <pavlin at ICSI.Berkeley.EDU> wrote:

> RTP Techie <rtp.techie at gmail.com> wrote:
> 
> > Here is the next issue that I've when run it from my target system.
> > 
> > There is not enough space for me to copy the files to "tagert".
> > 
> > From the target, I mnt it back to my host system from "/mnt/xorp" to
> > "/home/cmchan/dev/xorp-builds/mips64-montavista-linux".
> > 
> > 
> > 
> > By following the user guide, I need to run xorp_rtrmgr 1st.
> > 
> > By default it looks for config and template files from the host-path, so I
> > need to use command option to set them correctly, like in below:
> > 
> > ./mips64-montavista-linux-xorp_rtrmgr -v -b /mnt/xorp/config/static.boot  -x
> > /mnt/xorp/xrl/targets/ -t /mnt/xorp/etc/templates/
> > 
> > 
> > 
> > Yes, I also create a group and add root to it.
> > 
> > But then I see the following error, and not sure what to do with it.
> 
> It looks like something is mixed-up when the rtrmgr tries to choose
> the path to the XORP binaries. Assuming everything is installed
> under /mnt/xorp, you could try to set the XORP_ROOT environmental
> variable. E.g.:
> 
> setenv XORP_ROOT /mnt/xorp
> /mnt/xorp/bin/xorp_rtrmgr -b /mnt/xorp/config/static.boot
> 
> Hope that helps,
> Pavlin
> 
> > 
> > 
> > root at target:/mnt/xorp/bin# ./mips64-montavista-linux-xorp_rtrmgr -v -b
> > /mnt/xorp/config/static.boot  -x /mnt/xorp/xrl/targets/ -t /mnt/x
> > orp/etc/templates/
> > 
> > [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> > Boot file                  := /mnt/xorp/config/static.boot
> > 
> > [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> > Templates directory        := /mnt/xorp/etc/templates/
> > 
> > [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ] Xrl
> > targets directory      := /mnt/xorp/xrl/targets/
> > 
> > [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> > Execute Xrls               := true
> > 
> > [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> > Restart failed processes   := false
> > 
> > [ 1970/06/29 06:46:26 TRACE mips64-montavista-linux-xorp_rtrmgr RTRMGR ]
> > Print verbose information  := true
> > 
> > [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> > +239 master_conf_tree.cc execute ] Changed modules: interfaces, firewall,
> > fea, rib, policy, static_routes
> > 
> > [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> > +2253 task.cc fail_tasklist_initialization ] Cannot create module
> > interfaces:
> > /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
> > not exist
> > 
> > [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> > +641 master_conf_tree.cc commit_changes_pass2 ] Commit failed in deciding
> > startups
> > 
> > [ 1970/06/29 06:46:31  ERROR mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> > +251 master_conf_tree.cc config_done ] Configuration failed: Cannot create
> > module interfaces:
> > /home/cmchan/dev/xorp-builds/mips64-montavista-linux/fea/xorp_fea: file does
> > not exist
> > 
> > [ 1970/06/29 06:46:31  INFO mips64-montavista-linux-xorp_rtrmgr:8444 RTRMGR
> > +2228 task.cc run_task ] No more tasks to run
> > 
> > 
> > 
> > 
> > Seem like xorp_rtrmgr is trying to exec "xorp_fea" from my host path? How to
> > address this?
> > Thanks,
> > 
> > RT
> > 
> > 
> > 
> > On Tue, Sep 2, 2008 at 8:22 PM, Pavlin Radoslavov
> > <pavlin at icsi.berkeley.edu>wrote:
> > 
> > > RTP Techie <rtp.techie at gmail.com> wrote:
> > >
> > > > Hi,
> > > >  I just downloaded the XORP 1.5 and was trying to compile it. I was able
> > > to
> > > > compile it with no problem on native Linux EL3 using GCC 3.4.5
> > > > But when I try to cross compile it for mips64 using GCC 3.4.3 (that is
> > > the
> > > > tool chain that we are using on the embedded system).
> > > > I got the following compilatin errors and hope if anyone knows how to
> > > > address it:
> > >
> > > It looks like some of the C++ header files generate those errors.
> > > Could you try to compile the following simple C++ program using the
> > > mips64_fp_be-g++ compiler:
> > >
> > > #include <new>
> > > #include <iostream>
> > >
> > > int
> > > main()
> > > {
> > >    return (0);
> > > }
> > >
> > >
> > > First try to do it without any extra arguments:
> > > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++ test.cc
> > >
> > > Then try it with the -I/export/crosstools/mvl40/mips64/fp_be/include
> > > g++ argument.
> > >
> > > This will help us narrow our focus on the problem.
> > >
> > > Pavlin
> > >
> > > P.S. Have you modified file libxorp/asyncio.cc?
> > > The first error below referes to file xorph.h included from
> > > asyncio.cc line 22, but in the XORP-1.5 source code the actual line
> > > where xorp.h is included is 20.
> > >
> > >
> > > > gmake[3]: Entering directory `/export/home/cmchan/dev/xorp-1.5/libxorp'
> > > /bin/sh
> > > > ../libtool --tag=CXX   --mode=compile
> > > > /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> > > -DHAVE_CONFIG_H
> > > > -I. -I.. -I..  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > > -mabi=n32  -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> > > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> > > asyncio.lo
> > > > -MD -MP -MF .deps/asyncio.Tpo -c -o asyncio.lo asyncio.cc
> > > >  /export/crosstools/mvl40/mips64/fp_be/bin/mips64_fp_be-g++
> > > -DHAVE_CONFIG_H
> > > > -I. -I.. -I.. -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > > -mabi=n32 -I/export/crosstools/mvl40/mips64/fp_be/include -mtune=sb1
> > > > -mabi=n32 -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> > > > -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT
> > > asyncio.lo
> > > > -MD -MP -MF .deps/asyncio.Tpo -c asyncio.cc -o asyncio.o
> > > > In file included from
> > > >
> > > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:41,
> > > >                  from ../libxorp/xorp.h:64,
> > > >                  from asyncio.cc:22:
> > > >
> > > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> > > > error: expected unqualified-id before "unsigned"
> > > >
> > > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/cstddef:53:
> > > > error: expected `;' before "unsigned"
> > > > In file included from ../libxorp/xorp.h:64,
> > > >                  from asyncio.cc:22:
> > > >
> > > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> > > > error: declaration of `operator new' as non-function
> > > >
> > > /export/crosstools/mvl40/mips64/fp_be/bin/../lib/gcc/mips64-montavista-linux/3.4.3/../../../../target/usr/include/c++/3.4.3/new:84:
> > > > error: expected unqualified-id before "unsigned"
> > > >
> > > > Thanks,
> > > > RT
> > > > _______________________________________________
> > > > Xorp-hackers mailing list
> > > > Xorp-hackers at icir.org
> > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers<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
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin at ICSI.Berkeley.EDU  Thu Sep  4 09:16:36 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 04 Sep 2008 09:16:36 -0700
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <5c95ad230809040903v3146d56ak6029680bda3d6a81@mail.gmail.com> 
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
	<4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>
	<5c95ad230809040903v3146d56ak6029680bda3d6a81@mail.gmail.com>
Message-ID: <200809041616.m84GGaqv017612@fruitcake.ICSI.Berkeley.EDU>

RTP Techie <rtp.techie at gmail.com> wrote:

> I will try to set the env var let you folks know if it works for me
> 
> So, since I'm new to the code base, is there any more of these env var get
> documented somewhere?

XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION to overwrite the
default xorpsh prompt in operational and configuration mode
respectively (see Section 1.7.1 in the User Manual).

Other (undocumented) interesting variables are:
XORP_FINDER_SERVER_ADDRESS
XORP_FINDER_SERVER_PORT
XORP_FINDER_CLIENT_ADDRESS
XRLTRACE

The first three are useful if you want to run XORP as a distributed
router (i.e., different components on different machines).
XRLTRACE is useful if you want to debug the XRL IPC exchange.

Pavlin


From rtp.techie at gmail.com  Thu Sep  4 12:36:57 2008
From: rtp.techie at gmail.com (RTP Techie)
Date: Thu, 4 Sep 2008 15:36:57 -0400
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <200809041616.m84GGaqv017612@fruitcake.ICSI.Berkeley.EDU>
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
	<4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>
	<5c95ad230809040903v3146d56ak6029680bda3d6a81@mail.gmail.com>
	<200809041616.m84GGaqv017612@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <5c95ad230809041236p38784dcbvd10e6700cf3303e8@mail.gmail.com>

Ok setting the env var works for me.

Just another minor thing:

Since when running configure, I specified target=mips64-montavista-linux

When installing, the install script copies all the binaries with prefix
"mips64-montavista-linux", like

mips64-montavista-linux-xorp_rtrmgr
However, when starting mips64-montavista-linux-xorp_rtrmgr, it will start
"xorp_fea".

On Thu, Sep 4, 2008 at 12:16 PM, Pavlin Radoslavov <pavlin at icsi.berkeley.edu
> wrote:

> RTP Techie <rtp.techie at gmail.com> wrote:
>
> > I will try to set the env var let you folks know if it works for me
> >
> > So, since I'm new to the code base, is there any more of these env var
> get
> > documented somewhere?
>
> XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION to overwrite the
> default xorpsh prompt in operational and configuration mode
> respectively (see Section 1.7.1 in the User Manual).
>
> Other (undocumented) interesting variables are:
> XORP_FINDER_SERVER_ADDRESS
> XORP_FINDER_SERVER_PORT
> XORP_FINDER_CLIENT_ADDRESS
> XRLTRACE
>
> The first three are useful if you want to run XORP as a distributed
> router (i.e., different components on different machines).
> XRLTRACE is useful if you want to debug the XRL IPC exchange.
>
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080904/7c10563e/attachment.html 

From pavlin at ICSI.Berkeley.EDU  Thu Sep  4 14:53:19 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 04 Sep 2008 14:53:19 -0700
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <5c95ad230809041236p38784dcbvd10e6700cf3303e8@mail.gmail.com> 
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>
	<4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>
	<5c95ad230809040903v3146d56ak6029680bda3d6a81@mail.gmail.com>
	<200809041616.m84GGaqv017612@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809041236p38784dcbvd10e6700cf3303e8@mail.gmail.com>
Message-ID: <200809042153.m84LrJkj008955@fruitcake.ICSI.Berkeley.EDU>

> Just another minor thing:
> 
> Since when running configure, I specified target=mips64-montavista-linux
> 
> When installing, the install script copies all the binaries with prefix
> "mips64-montavista-linux", like
> 
> mips64-montavista-linux-xorp_rtrmgr
> However, when starting mips64-montavista-linux-xorp_rtrmgr, it will start
> "xorp_fea".

This looks like a bug in the XORP installation mechanism.
Please submit a Bugzilla entry with the exact instructions you used
to run ./configure and install XORP.

Pavlin


From rtp.techie at gmail.com  Thu Sep  4 17:04:17 2008
From: rtp.techie at gmail.com (RTP Techie)
Date: Thu, 4 Sep 2008 20:04:17 -0400
Subject: [Xorp-hackers] Multiple protocol instances within the same process.
Message-ID: <5c95ad230809041704x2d983e41t2e19f18570d70da9@mail.gmail.com>

Xorp-Hackers,


I saw a discussion on running multiple instances/processes of the same
protocol within the same host machine.

But I was interested in running multiple instances of the same protocols
within the same processes.  Like within OSPFv2 process, I would want to run
50 ospfv2 routing engines.

They should be just interdependent instances and don't need to know each
other and only learn about each other through the normal protocols
interactions. The reason is that I want to emulate a network instead of just
a distributed router. If I'm trying to run 50 or even few hundreds processes
on my system, it won't be the desired operations.



I know that it is not the model that is currently supported, but I want to
get some directions as where/how to start.  Just reading the design
documents, the first thing that I see the issue is the XLR target. From what
I can tell, a target is associated wit the process, in order words, I cannot
address a particular instance within the process.



Beside that from the OSPF or any protocol implementation point of view,
would there is any issue as well?



Any thoughts/suggestions/pointers will be appreciated.

Thanks,

RT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080904/943fcb85/attachment.html 

From greearb at candelatech.com  Thu Sep  4 21:46:19 2008
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 04 Sep 2008 21:46:19 -0700
Subject: [Xorp-hackers] Multiple protocol instances within the same
	process.
In-Reply-To: <5c95ad230809041704x2d983e41t2e19f18570d70da9@mail.gmail.com>
References: <5c95ad230809041704x2d983e41t2e19f18570d70da9@mail.gmail.com>
Message-ID: <48C0B99B.2030308@candelatech.com>

RTP Techie wrote:
> Xorp-Hackers,
>  
>
> I saw a discussion on running multiple instances/processes of the same 
> protocol within the same host machine.
>
>  
> But I was interested in running multiple instances of the same 
> protocols within the same processes.  Like within OSPFv2 process, I 
> would want to run 50 ospfv2 routing engines.
>
> They should be just interdependent instances and don't need to know 
> each other and only learn about each other through the normal 
> protocols interactions. The reason is that I want to emulate a network 
> instead of just a distributed router. If I'm trying to run 50 or even 
> few hundreds processes on my system, it won't be the desired operations.
>
>  
>
> I know that it is not the model that is currently supported, but I 
> want to get some directions as where/how to start.  Just reading the 
> design documents, the first thing that I see the issue is the XLR 
> target. From what I can tell, a target is associated wit the process, 
> in order words, I cannot address a particular instance within the process.
>
>  
>
> Beside that from the OSPF or any protocol implementation point of 
> view, would there is any issue as well?
>
Using one set of xorp processes per virtual router, we (Candela) can 
support 50+ on a high end machine ( 2 x 4-core system).

In my opinion, the thing to do for more scalability would be to have all 
of the xorp processes for a single router
in the same process (not 4+ processes like it is now).  This would 
probably be a lot easier to support than
having multiple virtual routing engines inside a single process, and 
would cut down on a lot of extraneous message
passing between processes.

Thanks,
Ben

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



From bms at incunabulum.net  Fri Sep  5 07:03:36 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Fri, 05 Sep 2008 15:03:36 +0100
Subject: [Xorp-hackers] Compile failed @ asyncio.cc on
	MIPS64/Linux/GCC3.4.3
In-Reply-To: <5c95ad230809041236p38784dcbvd10e6700cf3303e8@mail.gmail.com>
References: <5c95ad230809021538m22e115a7pd2ee7915c07bd299@mail.gmail.com>	
	<200809030022.m830Me0J026122@fruitcake.ICSI.Berkeley.EDU>	
	<5c95ad230809031618s7ea39cebn7a1fbf4ca9a1f577@mail.gmail.com>	
	<200809041348.m84DmM9Z024686@fruitcake.ICSI.Berkeley.EDU>	
	<4769af410809040706q607985dag9ec4c5082dc61c8e@mail.gmail.com>	
	<5c95ad230809040903v3146d56ak6029680bda3d6a81@mail.gmail.com>	
	<200809041616.m84GGaqv017612@fruitcake.ICSI.Berkeley.EDU>
	<5c95ad230809041236p38784dcbvd10e6700cf3303e8@mail.gmail.com>
Message-ID: <48C13C38.3010109@incunabulum.net>

RTP Techie wrote:
> ...
>
> When installing, the install script copies all the binaries with 
> prefix "mips64-montavista-linux", like
>
> mips64-montavista-linux-xorp_rtrmgr
> However, when starting mips64-montavista-linux-xorp_rtrmgr, it will 
> start "xorp_fea".
>

It is an artefact of how GNU Autoconf normally names cross-compiled
binaries when it sees you have used --target. In this case however it
breaks the deployment because it doesn't match what the Router Manager
sees in the template files.

Try specifying --program-prefix=NONE to configure when using --target
and let us know if this works around the issue.


From bms at incunabulum.net  Fri Sep  5 07:13:08 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Fri, 05 Sep 2008 15:13:08 +0100
Subject: [Xorp-hackers] Multiple protocol instances within the
	same	process.
In-Reply-To: <48C0B99B.2030308@candelatech.com>
References: <5c95ad230809041704x2d983e41t2e19f18570d70da9@mail.gmail.com>
	<48C0B99B.2030308@candelatech.com>
Message-ID: <48C13E74.1030404@incunabulum.net>

Ben Greear wrote:
> Using one set of xorp processes per virtual router, we (Candela) can 
> support 50+ on a high end machine ( 2 x 4-core system).
>
> In my opinion, the thing to do for more scalability would be to have all 
> of the xorp processes for a single router
> in the same process (not 4+ processes like it is now).  This would 
> probably be a lot easier to support than
> having multiple virtual routing engines inside a single process, and 
> would cut down on a lot of extraneous message
> passing between processes.
>   

Sadly, it isn't a simple matter of doing what crunchgen on FreeBSD does; 
it is similar in intention to busybox; it coalesces multiple executables 
into a single image.

A single process approach is hard to achieve with the current 
architecture, when one considers that there are things going on in 
function main() individually for each process; it would require 
refactoring a number of things e.g. folding everything into the same 
EventLoop, changing calls which use getpid() to use a different form of 
unique identifier, no doubt there are other things which need changing.

It's not impossible, it's just a lot of work. In the short to medium 
term, to gain scalability, shared libraries are an easier change to make 
(reduce memory footprint), followed by, perhaps, shared memory based 
XRLs (streamline IPC latency).

Back to the original question:
    We do support multiple instances of OSPFv3, but not for OSPFv2. 
There hasn't been a requirement for it. I understand though that folk 
might be interested in that for things like traffic engineering, vpn etc 
when using OSPFv2 as their IGP.
    If folk are willing to transplant the OSPFv3 instance tags to 
OSPFv2, great stuff; it will involve some amount of refactoring.
    When writing xorp_olsr last year I ended up importing xorp_ospf into 
Bouml to understand how things were put together. I probably still have 
the UML models somewhere if folk are interested in that.

thanks
BMS


From eshe168 at gmail.com  Tue Sep  9 01:58:45 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Tue, 9 Sep 2008 16:58:45 +0800
Subject: [Xorp-hackers] About develop a Xorp process!
Message-ID: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>

Hi,
      I want to develop a process, cpl. But, in the startup, there is a error.

      The error message:
         [ 2008/09/09 16:54:29  ERROR cli_cpl:14768 XRL +640
xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed.  No
Finder?

      I have done everything, according to the documentation, An
Introduction to Writing a XORP Process.

Please help me!

B.R.
Xiaoshuai Yang


From bms at incunabulum.net  Tue Sep  9 05:43:22 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Tue, 09 Sep 2008 13:43:22 +0100
Subject: [Xorp-hackers] About develop a Xorp process!
In-Reply-To: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>
References: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>
Message-ID: <48C66F6A.9080206@incunabulum.net>

?????? wrote:
> Hi,
>       I want to develop a process, cpl. But, in the startup, there is a error.
>
>       The error message:
>          [ 2008/09/09 16:54:29  ERROR cli_cpl:14768 XRL +640
> xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed.  No
> Finder?
>
>       I have done everything, according to the documentation, An
> Introduction to Writing a XORP Process.
>   

* Do you have any connectivity problems on your system?

* Which operating system are you using to develop your XORP process?

   This will let people better advise you about which tools to use to
discover why your process can't connect to the Finder, of course it is a
shot in the dark without seeing your code.

thanks
BMS


From eshe168 at gmail.com  Tue Sep  9 18:12:57 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Wed, 10 Sep 2008 09:12:57 +0800
Subject: [Xorp-hackers] About develop a Xorp process!
In-Reply-To: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>
References: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>
Message-ID: <56f9e0990809091812p59c60c89k2900258988380611@mail.gmail.com>

It's no connectivity problems on my system.
    My OS is Debian.

There is my segment of my code.

#include "xrl_cpl_node.hh"

XrlCplNode::XrlCplNode(EventLoop& eventloop, const string& xrl_cpl_targetname,
              const string& xrl_finder_targetname,
              const string& finder_hostname, uint16_t finder_port)
   : _eventloop(eventloop),
   _xrl_router(eventloop, xrl_cpl_targetname.c_str(),
                 finder_hostname.c_str(), finder_port),
   _xrl_finder_targetname(xrl_finder_targetname)
{

}

int XrlCplNode::startup()
{
   wait_until_xrl_router_is_ready(eventloop(), xrl_router());

   xrl_cpl_interface().startup();

   return XORP_OK;
}

In another file?
cpl_main(const string& finder_hostname, uint16_t finder_port)
{
   EventLoop eventloop;
   XrlCplNode xrl_cpl_node(eventloop, xrl_cpl_targetname,
                           xrl_finder_targetname, finder_hostname,
                           finder_port);

   // Start operations
   xrl_cpl_node.startup();

   //
   // Main loop
   //
   while (!xrl_cpl_node.is_shutdown_received())
   {
           eventloop.run();
   }

   //
   // Shutdown request received. Shutdown all operations and cleanup.
   //
   xrl_cpl_node.shutdown();
   while (xrl_cpl_node.is_running())
   {
           eventloop.run();
   }
}

2008/9/9 ??? <eshe168 at gmail.com>:
> Hi,
>      I want to develop a process, cpl. But, in the startup, there is a error.
>
>      The error message:
>         [ 2008/09/09 16:54:29  ERROR cli_cpl:14768 XRL +640
> xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed.  No
> Finder?
>
>      I have done everything, according to the documentation, An
> Introduction to Writing a XORP Process.
>
> Please help me!
>
> B.R.
> Xiaoshuai Yang
>


From eshe168 at gmail.com  Tue Sep  9 22:32:36 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Wed, 10 Sep 2008 13:32:36 +0800
Subject: [Xorp-hackers] About develop a Xorp process!
In-Reply-To: <56f9e0990809091812p59c60c89k2900258988380611@mail.gmail.com>
References: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>
	<56f9e0990809091812p59c60c89k2900258988380611@mail.gmail.com>
Message-ID: <56f9e0990809092232w66c918f6g2ec1ca09c9a004e5@mail.gmail.com>

Does the XORP process class that I do define must be a child of the
XrlStdRouter base class?

2008/9/10 ??? <eshe168 at gmail.com>:
> It's no connectivity problems on my system.
>    My OS is Debian.
>
> There is my segment of my code.
>
> #include "xrl_cpl_node.hh"
>
> XrlCplNode::XrlCplNode(EventLoop& eventloop, const string& xrl_cpl_targetname,
>              const string& xrl_finder_targetname,
>              const string& finder_hostname, uint16_t finder_port)
>   : _eventloop(eventloop),
>   _xrl_router(eventloop, xrl_cpl_targetname.c_str(),
>                 finder_hostname.c_str(), finder_port),
>   _xrl_finder_targetname(xrl_finder_targetname)
> {
>
> }
>
> int XrlCplNode::startup()
> {
>   wait_until_xrl_router_is_ready(eventloop(), xrl_router());
>
>   xrl_cpl_interface().startup();
>
>   return XORP_OK;
> }
>
> In another file?
> cpl_main(const string& finder_hostname, uint16_t finder_port)
> {
>   EventLoop eventloop;
>   XrlCplNode xrl_cpl_node(eventloop, xrl_cpl_targetname,
>                           xrl_finder_targetname, finder_hostname,
>                           finder_port);
>
>   // Start operations
>   xrl_cpl_node.startup();
>
>   //
>   // Main loop
>   //
>   while (!xrl_cpl_node.is_shutdown_received())
>   {
>           eventloop.run();
>   }
>
>   //
>   // Shutdown request received. Shutdown all operations and cleanup.
>   //
>   xrl_cpl_node.shutdown();
>   while (xrl_cpl_node.is_running())
>   {
>           eventloop.run();
>   }
> }
>
> 2008/9/9 ??? <eshe168 at gmail.com>:
>> Hi,
>>      I want to develop a process, cpl. But, in the startup, there is a error.
>>
>>      The error message:
>>         [ 2008/09/09 16:54:29  ERROR cli_cpl:14768 XRL +640
>> xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed.  No
>> Finder?
>>
>>      I have done everything, according to the documentation, An
>> Introduction to Writing a XORP Process.
>>
>> Please help me!
>>
>> B.R.
>> Xiaoshuai Yang
>>
>


From eshe168 at gmail.com  Tue Sep  9 23:29:53 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Wed, 10 Sep 2008 14:29:53 +0800
Subject: [Xorp-hackers] About develop a Xorp process!
In-Reply-To: <56f9e0990809092232w66c918f6g2ec1ca09c9a004e5@mail.gmail.com>
References: <56f9e0990809090158r3c440682wfaa3bdfefc5163d9@mail.gmail.com>
	<56f9e0990809091812p59c60c89k2900258988380611@mail.gmail.com>
	<56f9e0990809092232w66c918f6g2ec1ca09c9a004e5@mail.gmail.com>
Message-ID: <56f9e0990809092329w7c63fd05p42776d1a05e8818c@mail.gmail.com>

I have found the mistake.
        I do not initialize the XrlCplTargetBase, this class was
generated by the compiler.

Thanks all.


From eshe168 at gmail.com  Wed Sep 10 19:28:36 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Thu, 11 Sep 2008 10:28:36 +0800
Subject: [Xorp-hackers] About save and load!
Message-ID: <56f9e0990809101928u11ca3481y3a1dfcd4ac4dcb8b@mail.gmail.com>

      When I used save and load command in configuration, there were
something wrong. My OS is Debian.

yxs at Lenny621# save abc.conf
[ 2008/09/11 10:21:55  WARNING xorp_rtrmgr:3122 XrlRtrmgrTarget +637
rtrmgr_base.cc handle_rtrmgr_0_1_save_config ] Handling method for
rtrmgr/0.1/save_config failed: XrlCmdError 102 Command failed Cannot
set the effective group ID to 1006: Operation not permitted
ERROR: Save failed.
Cannot set the effective group ID to 1006: Operation not permitted


B.R.
Xiaoshuai Yang


From pavlin at ICSI.Berkeley.EDU  Thu Sep 11 12:05:23 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 11 Sep 2008 12:05:23 -0700
Subject: [Xorp-hackers] About save and load!
In-Reply-To: <56f9e0990809101928u11ca3481y3a1dfcd4ac4dcb8b@mail.gmail.com> 
References: <56f9e0990809101928u11ca3481y3a1dfcd4ac4dcb8b@mail.gmail.com>
Message-ID: <200809111905.m8BJ5Non028351@fruitcake.ICSI.Berkeley.EDU>

Few questions:

* Do you have group "xorp" on the system
* Is the user running xorpsh member of that group
* And are you running XORP as a root?

The answer of all questions above should be "yes".
FYI, when trying to save a config file, XORP tries to set the
effective group ID to "xorp", and this seems to be failing.

Pavlin

??? <eshe168 at gmail.com> wrote:

>       When I used save and load command in configuration, there were
> something wrong. My OS is Debian.
> 
> yxs at Lenny621# save abc.conf
> [ 2008/09/11 10:21:55  WARNING xorp_rtrmgr:3122 XrlRtrmgrTarget +637
> rtrmgr_base.cc handle_rtrmgr_0_1_save_config ] Handling method for
> rtrmgr/0.1/save_config failed: XrlCmdError 102 Command failed Cannot
> set the effective group ID to 1006: Operation not permitted
> ERROR: Save failed.
> Cannot set the effective group ID to 1006: Operation not permitted
> 
> 
> B.R.
> Xiaoshuai Yang
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From eshe168 at gmail.com  Thu Sep 11 17:46:25 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Fri, 12 Sep 2008 08:46:25 +0800
Subject: [Xorp-hackers] About save and load!
In-Reply-To: <56f9e0990809101928u11ca3481y3a1dfcd4ac4dcb8b@mail.gmail.com>
References: <56f9e0990809101928u11ca3481y3a1dfcd4ac4dcb8b@mail.gmail.com>
Message-ID: <56f9e0990809111746y6b25242eg628274068b7e876c@mail.gmail.com>

Thank you. I got it.


From eshe168 at gmail.com  Thu Sep 18 19:11:06 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Fri, 19 Sep 2008 10:11:06 +0800
Subject: [Xorp-hackers] About make yacc?
Message-ID: <56f9e0990809181911n27ec5720pb3667ba77262630@mail.gmail.com>

Hi,
     When I use make yacc, I found something wrong. And, The new
y.tplt_tab.cc is different with the old. I want to get reason. I do
not change template.yy. My OS is Debian.
     Looking forward your answer!
     Here is error information:
yxs at Lenny621:~/xorp-cli/xorp-demo/rtrmgr$ make yacc
( cd .;						\
	yacc -d -p tplt -o y.tplt_tab.c template.yy;		\
	mv y.tplt_tab.c y.tplt_tab.cc;				\
	bash ../utils/rcsid2ident.sh y.tplt_tab.cc;	\
	yacc -d -p boot -o y.boot_tab.c boot.yy;		\
	mv y.boot_tab.c y.boot_tab.cc;				\
	bash ../utils/rcsid2ident.sh y.boot_tab.cc;	\
	yacc -d -p opcmd -o y.opcmd_tab.c op_commands.yy;	\
	mv y.opcmd_tab.c y.opcmd_tab.cc;			\
	bash ../utils/rcsid2ident.sh y.opcmd_tab.cc;	\
	touch .yacc_generated_files )
61685
      static char const yyunexpected[] = "syntax error, unexpected %s";
?
56089
      static char const yyunexpected[] = "syntax error, unexpected %s";
?
56419
      static char const yyunexpected[] = "syntax error, unexpected %s";
?

B.R.
Xiaoshuai Yang


From pavlin at ICSI.Berkeley.EDU  Fri Sep 19 18:21:25 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Fri, 19 Sep 2008 18:21:25 -0700
Subject: [Xorp-hackers] About make yacc?
In-Reply-To: <56f9e0990809181911n27ec5720pb3667ba77262630@mail.gmail.com> 
References: <56f9e0990809181911n27ec5720pb3667ba77262630@mail.gmail.com>
Message-ID: <200809200122.m8K1LQs9005554@fruitcake.ICSI.Berkeley.EDU>

??? <eshe168 at gmail.com> wrote:

> Hi,
>      When I use make yacc, I found something wrong. And, The new
> y.tplt_tab.cc is different with the old. I want to get reason. I do
> not change template.yy. My OS is Debian.

Sometimes using different version/different OS of yacc generates
different result.
We use the default yacc that comes with FreeBSD-7.0, which is based
on the original Berkeley Yacc.
The yacc one from Ubuntu for example is a very different
implementation: it is based on GNU Bison.

I just did a quick experiment on Ubuntu by using "gmake yacc" in the
rtrmgr directory to regenerate the rtrmgr Yacc-generated files, and
I observed the following:

* The result generated files are very different from the
  original files (because of GNU Bison).
* The result generated files don't compile with the rest of the
  rtrmgr files:

g++ -DHAVE_CONFIG_H -I. -I.. -I/home/pavlin/xorp/rtrmgr -I/home/pavlin/xorp    -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT lex.boot.o -MD -MP -MF .deps/lex.boot.Tpo -c -o lex.boot.o /home/pavlin/xorp/rtrmgr/lex.boot.cc
boot.ll:20: error: conflicting declaration 'char* bootlval'
/home/pavlin/xorp/rtrmgr/y.boot_tab.h:104: error: 'bootlval' has a previous declaration as 'YYSTYPE bootlval'
boot.ll: In function 'int bootlex()':
boot.ll:264: error: invalid conversion from 'char*' to 'YYSTYPE'
boot.ll:269: error: invalid conversion from 'char*' to 'YYSTYPE'
boot.ll:274: error: invalid conversion from 'char*' to 'YYSTYPE'
boot.ll:279: error: invalid conversion from 'char*' to 'YYSTYPE'

...


Just curious, why do you need to run "gmake yacc"? Are you modifying
some of the original rtrmgr/*.ll or rtrmgr/*.yy files or are you
trying to make some fundamental changes to the rtrmgr parsing
mechanism?
If no, then you don't need to run "gmake yacc".
If yes, the Yacc-generation is known to work only on FreeBSD, and I
don't have a good answer how to do it on other OS-es. You can try to
get it working with GNU Bison, but I don't know how difficult this
would be.

Pavlin

>      Looking forward your answer!
>      Here is error information:
> yxs at Lenny621:~/xorp-cli/xorp-demo/rtrmgr$ make yacc
> ( cd .;						\
> 	yacc -d -p tplt -o y.tplt_tab.c template.yy;		\
> 	mv y.tplt_tab.c y.tplt_tab.cc;				\
> 	bash ../utils/rcsid2ident.sh y.tplt_tab.cc;	\
> 	yacc -d -p boot -o y.boot_tab.c boot.yy;		\
> 	mv y.boot_tab.c y.boot_tab.cc;				\
> 	bash ../utils/rcsid2ident.sh y.boot_tab.cc;	\
> 	yacc -d -p opcmd -o y.opcmd_tab.c op_commands.yy;	\
> 	mv y.opcmd_tab.c y.opcmd_tab.cc;			\
> 	bash ../utils/rcsid2ident.sh y.opcmd_tab.cc;	\
> 	touch .yacc_generated_files )
> 61685
>       static char const yyunexpected[] = "syntax error, unexpected %s";
> ?
> 56089
>       static char const yyunexpected[] = "syntax error, unexpected %s";
> ?
> 56419
>       static char const yyunexpected[] = "syntax error, unexpected %s";
> ?
> 
> B.R.
> Xiaoshuai Yang
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From eshe168 at gmail.com  Sun Sep 21 18:04:13 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Mon, 22 Sep 2008 09:04:13 +0800
Subject: [Xorp-hackers] Xorp-hackers Digest, Vol 30, Issue 12
In-Reply-To: <mailman.11.1221937211.18755.xorp-hackers@icir.org>
References: <mailman.11.1221937211.18755.xorp-hackers@icir.org>
Message-ID: <56f9e0990809211804q2394ae56r316eae3f6eb5cdcb@mail.gmail.com>

Hi, all

I need add some other data structure into template file, so I must to
modify the *.ll and *.yy.
I have found a solution, that is to modify the generated *.cc and *.h
source code.

B.R.
Xiaoshuai Yang

2008/9/21  <xorp-hackers-request at icir.org>:
> Send Xorp-hackers mailing list submissions to
>        xorp-hackers at icir.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> or, via email, send a message with subject or body 'help' to
>        xorp-hackers-request at icir.org
>
> You can reach the person managing the list at
>        xorp-hackers-owner at icir.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xorp-hackers digest..."
>
>
> Today's Topics:
>
>   1. Re: About make yacc? (Pavlin Radoslavov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 19 Sep 2008 18:21:25 -0700
> From: Pavlin Radoslavov <pavlin at ICSI.Berkeley.EDU>
> Subject: Re: [Xorp-hackers] About make yacc?
> To: " ??? " <eshe168 at gmail.com>
> Cc: xorp-hackers at icir.org
> Message-ID: <200809200122.m8K1LQs9005554 at fruitcake.ICSI.Berkeley.EDU>
> Content-Type: text/plain; charset=gb2312
>
> ??? <eshe168 at gmail.com> wrote:
>
>> Hi,
>>      When I use make yacc, I found something wrong. And, The new
>> y.tplt_tab.cc is different with the old. I want to get reason. I do
>> not change template.yy. My OS is Debian.
>
> Sometimes using different version/different OS of yacc generates
> different result.
> We use the default yacc that comes with FreeBSD-7.0, which is based
> on the original Berkeley Yacc.
> The yacc one from Ubuntu for example is a very different
> implementation: it is based on GNU Bison.
>
> I just did a quick experiment on Ubuntu by using "gmake yacc" in the
> rtrmgr directory to regenerate the rtrmgr Yacc-generated files, and
> I observed the following:
>
> * The result generated files are very different from the
>  original files (because of GNU Bison).
> * The result generated files don't compile with the rest of the
>  rtrmgr files:
>
> g++ -DHAVE_CONFIG_H -I. -I.. -I/home/pavlin/xorp/rtrmgr -I/home/pavlin/xorp    -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT lex.boot.o -MD -MP -MF .deps/lex.boot.Tpo -c -o lex.boot.o /home/pavlin/xorp/rtrmgr/lex.boot.cc
> boot.ll:20: error: conflicting declaration 'char* bootlval'
> /home/pavlin/xorp/rtrmgr/y.boot_tab.h:104: error: 'bootlval' has a previous declaration as 'YYSTYPE bootlval'
> boot.ll: In function 'int bootlex()':
> boot.ll:264: error: invalid conversion from 'char*' to 'YYSTYPE'
> boot.ll:269: error: invalid conversion from 'char*' to 'YYSTYPE'
> boot.ll:274: error: invalid conversion from 'char*' to 'YYSTYPE'
> boot.ll:279: error: invalid conversion from 'char*' to 'YYSTYPE'
>
> ...
>
>
> Just curious, why do you need to run "gmake yacc"? Are you modifying
> some of the original rtrmgr/*.ll or rtrmgr/*.yy files or are you
> trying to make some fundamental changes to the rtrmgr parsing
> mechanism?
> If no, then you don't need to run "gmake yacc".
> If yes, the Yacc-generation is known to work only on FreeBSD, and I
> don't have a good answer how to do it on other OS-es. You can try to
> get it working with GNU Bison, but I don't know how difficult this
> would be.
>
> Pavlin
>
>>      Looking forward your answer!
>>      Here is error information:
>> yxs at Lenny621:~/xorp-cli/xorp-demo/rtrmgr$ make yacc
>> ( cd .;                                               \
>>       yacc -d -p tplt -o y.tplt_tab.c template.yy;            \
>>       mv y.tplt_tab.c y.tplt_tab.cc;                          \
>>       bash ../utils/rcsid2ident.sh y.tplt_tab.cc;     \
>>       yacc -d -p boot -o y.boot_tab.c boot.yy;                \
>>       mv y.boot_tab.c y.boot_tab.cc;                          \
>>       bash ../utils/rcsid2ident.sh y.boot_tab.cc;     \
>>       yacc -d -p opcmd -o y.opcmd_tab.c op_commands.yy;       \
>>       mv y.opcmd_tab.c y.opcmd_tab.cc;                        \
>>       bash ../utils/rcsid2ident.sh y.opcmd_tab.cc;    \
>>       touch .yacc_generated_files )
>> 61685
>>       static char const yyunexpected[] = "syntax error, unexpected %s";
>> ?
>> 56089
>>       static char const yyunexpected[] = "syntax error, unexpected %s";
>> ?
>> 56419
>>       static char const yyunexpected[] = "syntax error, unexpected %s";
>> ?
>>
>> B.R.
>> Xiaoshuai Yang
>>
>> _______________________________________________
>> 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
>
>
> End of Xorp-hackers Digest, Vol 30, Issue 12
> ********************************************
>


From eshe168 at gmail.com  Tue Sep 23 20:10:02 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Wed, 24 Sep 2008 11:10:02 +0800
Subject: [Xorp-hackers] About misc.cmds
Message-ID: <56f9e0990809232010v7a61392q5a313dd204066e32@mail.gmail.com>

Hi,
     I added a new operational command, telnet, by modify the
misc.cmds. But when I use the telnet in the XORPshell, There is
nothing responsive. And the telnet can be used normally in shell.
     My OS is Debian. And, the complete command is telnet 127.0.0.1.

PS:
misc.cmds:
telnet <host> {
	%command: "telnet $2" %help: "Give an hostname or IP address.";
	%nomore_mode;
}

The information in XORPshell:
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

B.R.
Xiaoshuai Yang


From bms at incunabulum.net  Wed Sep 24 06:02:58 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Wed, 24 Sep 2008 14:02:58 +0100
Subject: [Xorp-hackers] About misc.cmds
In-Reply-To: <56f9e0990809232010v7a61392q5a313dd204066e32@mail.gmail.com>
References: <56f9e0990809232010v7a61392q5a313dd204066e32@mail.gmail.com>
Message-ID: <48DA3A82.4090300@incunabulum.net>

?????? wrote:
> Hi,
>      I added a new operational command, telnet, by modify the
> misc.cmds. But when I use the telnet in the XORPshell, There is
> nothing responsive. And the telnet can be used normally in shell.
>      My OS is Debian. And, the complete command is telnet 127.0.0.1.
>   

I haven't looked at that code in a while, as far as I remember the
xorpsh does not attempt to save all the terminal state when operational
commands are run.

It is likely that commands which need to take control of the terminal
will not work, as commands are normally run through pipes.

If this is a problem for you then you may wish to review that code and
come up with a patch. So far, there hasn't been a requirement for us, as
all the XORP operational commands just use stdout/stdin/stderr and don't
use POSIX termios or other features, AFAIK.

regards
BMS