From atanu at xorp.org  Thu Oct  2 10:53:12 2008
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 02 Oct 2008 10:53:12 -0700
Subject: [Xorp-hackers] XORP License change
Message-ID: <3717.1222969992@xorps.icir.org>

As of Thursday, October 2, 2008, we will be licensing XORP.org code
under the GNU General Public License, Version 2 (GPL v2), with selected
libraries made available under the GNU Lesser General Public License,
Version 2.1 (LGPL v2.1). The license changes will apply to all code
currently in the XORP.org CVS tree and to all future XORP.org releases,
with the exception of code derived from other sources.

Our goals in moving to the GPLv2 and LGPLv2.1 licenses are threefold:

- First, we want to ensure that improvements and extensions to the
XORP.org code base are made freely available to the XORP.org
community. The copyleft provision of the GPLv2 maximizes the likelihood
that this will be the case.

- At the same time, we believe that the best way to encourage innovation
in the broader networking arena is to make it easy for network
application developers to take advantage of XORP's open APIs and
extensible architecture. We aim to build an ecosystem of developers who
adopt XORP as their network operating system of choice, regardless of
whether their own code is open or proprietary. The LGPLv2.1 provides a
straightforward way for them to do so.

- Finally, we don't want to proliferate open source licenses. Moving
from the customized wording of our original XORP license to the broadly
used OSI-approved GPLv2 and LGPLv2.1 licenses is a step toward that end.

Commercial users of XORP who believe they may be impacted or limited by
the XORP.org license changes are encouraged to contact us at info at xorp.net.

--The XORP Team 


From greearb at candelatech.com  Tue Oct  7 15:37:55 2008
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Oct 2008 15:37:55 -0700
Subject: [Xorp-hackers] libxorp eventloop.cc comments
Message-ID: <48EBE4C3.7080205@candelatech.com>

I notice that some work was done on the event
loop recently.

I haven't actually tried to run this yet (it conflicts badly
with my own hackings...I'm still resolving that), but I think it
still has some of the same issues I hit before.

Mainly:  Each call to do_work() will run a timer OR a task OR a selector.

If it is ever possible that a task is high priority, but is waiting
on a selector, then we have effective deadlock.

I can't remember if I ever saw this for certain, but it would seem
possible to me.

At the least, if the selector is ready to read, the loop is going to spin
(since select() will not block now) until the socket(s) are dealt with.

So, I still like my original patch that got rid of all of the priority
stuff between selectors, timers, and tasks and ran each of them at each
spin through do_work.  Always run the selector last, since it may sleep if
there are no tasks or timers waiting to run.

      TimeVal t;

-    _timer_list.advance_time();
      _timer_list.get_next_delay(t);

+    // Run timers if they need it.
+    if (t == TimeVal::ZERO()) {
+	_timer_list.run();
+    }
+
+    if (!_task_list.empty()) {
+	_task_list.run();
+	if (!_task_list.empty()) {
+	    // Run task again as soon as possible.
+	    t = TimeVal::ZERO();
+	}
+    }
+
+#ifdef HOST_OS_WINDOWS
+    _win_dispatcher.wait_and_dispatch(t);
+#else
+    _selector_list.wait_and_dispatch(t);
+#endif
+
+    _timer_list.current_time(last_ev_run);
+
+#if 0
      int timer_priority = XorpTask::PRIORITY_INFINITY;
      int selector_priority = XorpTask::PRIORITY_INFINITY;
      int task_priority = XorpTask::PRIORITY_INFINITY;
@@ -139,6 +157,7 @@ EventLoop::run()
      }

      last_ev_run = time(0);
+#endif
  }



Also, last_ev_run should NOT be a static variable..it should be a member
of the EventLoop class.

Thanks,
Ben

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


From greearb at candelatech.com  Tue Oct  7 16:04:49 2008
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Oct 2008 16:04:49 -0700
Subject: [Xorp-hackers] eventloop and aggressiveness
Message-ID: <48EBEB11.7050705@candelatech.com>

I read through the 'aggressiveness' code in the eventloop code.

Since it's my opinion that the whole priority thing is a waste of
time anyway, my preferred aggressive approach would be to run multiple
timers, multiple tasks, and then call the select dispatcher (assuming
the timers and tasks are ready to run now).

That said, if the priority code remains, then the aggressiveness code
is probably OK.

Thanks,
Ben

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


From greearb at candelatech.com  Fri Oct 10 13:26:01 2008
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Oct 2008 13:26:01 -0700
Subject: [Xorp-hackers] Compile fix for FC5
Message-ID: <48EFBA59.3000206@candelatech.com>

This is needed to build on FC5:

[greearb at file-server vrrp]$ git diff *
diff --git a/vrrp/vrrp.cc b/vrrp/vrrp.cc
index 02597e8..1c3ba0d 100644
--- a/vrrp/vrrp.cc
+++ b/vrrp/vrrp.cc
@@ -172,7 +172,7 @@ Vrrp::setup_timers(bool skew)

      case BACKUP:
         _master_down_timer.schedule_after_ms(
-               (skew ? _skew_time : _master_down_interval) * 1000.0);
+           (int)((skew ? _skew_time : _master_down_interval) * 1000.0));
         break;
      }
  }

Thanks,
Ben

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


From pavlin at ICSI.Berkeley.EDU  Fri Oct 10 15:14:56 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Fri, 10 Oct 2008 15:14:56 -0700
Subject: [Xorp-hackers] Compile fix for FC5
In-Reply-To: <48EFBA59.3000206@candelatech.com> 
References: <48EFBA59.3000206@candelatech.com>
Message-ID: <200810102215.m9AMEubq012155@fruitcake.ICSI.Berkeley.EDU>

Fixed in CVS.

Thanks,
Pavlin

Ben Greear <greearb at candelatech.com> wrote:

> This is needed to build on FC5:
> 
> [greearb at file-server vrrp]$ git diff *
> diff --git a/vrrp/vrrp.cc b/vrrp/vrrp.cc
> index 02597e8..1c3ba0d 100644
> --- a/vrrp/vrrp.cc
> +++ b/vrrp/vrrp.cc
> @@ -172,7 +172,7 @@ Vrrp::setup_timers(bool skew)
> 
>       case BACKUP:
>          _master_down_timer.schedule_after_ms(
> -               (skew ? _skew_time : _master_down_interval) * 1000.0);
> +           (int)((skew ? _skew_time : _master_down_interval) * 1000.0));
>          break;
>       }
>   }
> 
> 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 xorp2008 at yahoo.com.cn  Tue Oct 14 01:15:13 2008
From: xorp2008 at yahoo.com.cn (=?gb2312?q?=D6=DC=BD=DC?=)
Date: Tue, 14 Oct 2008 16:15:13 +0800 (CST)
Subject: [Xorp-hackers] how to add a process into XORP
Message-ID: <784061.82159.qm@web15107.mail.cnb.yahoo.com>

Hi ,XORP,
   
  I am at present a postgraduate studying in Xorp in China, and we are now working to add a web interface to Xorp. However, we have little knowledge on this subject except for some articles from the website(www.xorp.org), for example, An Introduction to Writing a XORP Process, XRL Interfaces: Specifications and Tools, XORP Inter-Process Communication Library Overview, so we are still unconscious of what to do next.
   
  so we sincerely hope that someone could give us some suggestions and methods. I am looking forward to your answer. Thank you again for your time!
   

       
---------------------------------
 ????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081014/015abcad/attachment.html 

From greearb at candelatech.com  Fri Oct 17 10:29:15 2008
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 17 Oct 2008 10:29:15 -0700
Subject: [Xorp-hackers] Assert in recent cvs
Message-ID: <48F8CB6B.5080307@candelatech.com>

We're still trying to figure out if this is reproducible, but
here's the stack trace.  This is with all of my patches applied,
so it's possible something we are doing wrong.


#0  0xffffe430 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe430 in __kernel_vsyscall ()
#1  0x438df690 in raise () from /lib/libc.so.6
#2  0x438e0f91 in abort () from /lib/libc.so.6
#3  0x081895c5 in xlog_fatal (module_name=0x8212738 "LIBXORP",
     where=0xbfb74198 "asyncio.cc:413 sigpipe_handler",
     fmt=0x8212908 "Assertion (%s) failed") at xlog.c:446
#4  0x0818b0b8 in AsyncFileWriter::sigpipe_handler () at asyncio.cc:413
#5  <signal handler called>
#6  0xffffe430 in __kernel_vsyscall ()
#7  0x4397a3c3 in __write_nocancel () from /lib/libc.so.6
#8  0x43919474 in _IO_new_file_write () from /lib/libc.so.6
#9  0x43919135 in new_do_write () from /lib/libc.so.6
#10 0x439193ef in _IO_new_file_xsputn () from /lib/libc.so.6
#11 0x4390f14a in fputs () from /lib/libc.so.6
#12 0x08086c58 in ModuleManager::Process::stdout_cb (this=0x8524498,
     run_command=0x8567088, output=@0xbfb7a3bc) at module_manager.cc:739
#13 0x0808ba2c in XorpMemberCallback2B0<void, ModuleManager::Process, RunCommand *, std::string const&>::dispatch (this=0x85632a0, a1=0x8567088, a2=@0xbfb7a3bc)
     at ../libxorp/callback_nodebug.hh:4636
#14 0x081a0532 in RunCommand::stdout_cb_dispatch (this=0x8567088,
     output=@0xbfb7a3bc) at run_command.hh:489
#15 0x0819e03c in RunCommandBase::append_data (this=0x8567088,
     event=AsyncFileOperator::DATA,
Missing separate debuginfos, use: debuginfo-install gcc.i386 glibc.i686 openssl. i686 zlib.i386
---Type <return> to continue, or q <return> to quit---
     buffer=0x85670b0 "[ 2008/10/17 09:57:43  WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:205 enable_interface_vif ] XRL-IO: Enable Interface rddVR1 Vif rddVR1\n[ 2008/10/17 09:57:43  WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:20"...,
     offset=2428) at run_command.cc:595
#16 0x081a0fae in XorpMemberCallback4B0<void, RunCommandBase, AsyncFileOperator::Event, unsigned char const*, unsigned int, unsigned int>::dispatch (
     this=0x853fc80, a1=AsyncFileOperator::DATA,
     a2=0x85670b0 "[ 2008/10/17 09:57:43  WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:205 enable_interface_vif ] XRL-IO: Enable Interface rddVR1 Vif rddVR1\n[ 2008/10/17 09:57:43 WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:20"..., a3=8192,
     a4=2428) at ../libxorp/callback_nodebug.hh:8966
#17 0x0818cb74 in AsyncFileReader::BufferInfo::dispatch_callback (
     this=0x8561070, e=AsyncFileOperator::DATA) at asyncio.hh:224
#18 0x0818a735 in AsyncFileReader::complete_transfer (this=0x85654e8, err=0,
     done=92) at asyncio.cc:271
#19 0x0818ca1c in AsyncFileReader::read (this=0x85654e8, fd={_filedesc = 32},
     type=IOT_READ) at asyncio.cc:230
#20 0x0818d360 in XorpMemberCallback2B0<void, AsyncFileReader, XorpFd, IoEventType>::dispatch (this=0x855a458, a1={_filedesc = 32}, a2=IOT_READ)
     at ../libxorp/callback_nodebug.hh:4636
#21 0x081a4622 in SelectorList::Node::run_hooks (this=0x8511c98, m=SEL_RD, fd=
       {_filedesc = 32}) at selector.cc:155
#22 0x081a355a in SelectorList::wait_and_dispatch (this=0xbfb823e8,
---Type <return> to continue, or q <return> to quit---
     timeout=@0xbfb7e430) at selector.cc:440
#23 0x081910e2 in EventLoop::do_work (this=0xbfb823a0, can_block=true)
     at eventloop.cc:132
#24 0x081911e6 in EventLoop::run (this=0xbfb823a0) at eventloop.cc:85
#25 0x08067e48 in Rtrmgr::run (this=0xbfb828e4) at main_rtrmgr.cc:349
#26 0x08068912 in main (argc=5, argv=0xbfb829f4) at main_rtrmgr.cc:632
(gdb)


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


From pavlin at ICSI.Berkeley.EDU  Fri Oct 17 14:56:21 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Fri, 17 Oct 2008 14:56:21 -0700
Subject: [Xorp-hackers] Assert in recent cvs
In-Reply-To: <48F8CB6B.5080307@candelatech.com> 
References: <48F8CB6B.5080307@candelatech.com>
Message-ID: <200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU>

Ben Greear <greearb at candelatech.com> wrote:

> We're still trying to figure out if this is reproducible, but
> here's the stack trace.  This is with all of my patches applied,
> so it's possible something we are doing wrong.

Please send instructions how to reproduce the problem: rtrmgr
command line options, configuration file and any actions you did.
I need the command line options so I know where the log output is
redirected to.

Also, please reverse-back the rev. 1.68 change to the
rtrmgr/module_manager.cc file:
1.68      +5 -3;  commitid: 11fdf48f7e12041a7; xorp/rtrmgr/module_manager.cc

In particular, change back the two XLOG_*() messages to fprintf(),
and see whether you still get the error.
This will guide us choosing the next step in debugging the problem.

Pavlin

> 
> #0  0xffffe430 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xffffe430 in __kernel_vsyscall ()
> #1  0x438df690 in raise () from /lib/libc.so.6
> #2  0x438e0f91 in abort () from /lib/libc.so.6
> #3  0x081895c5 in xlog_fatal (module_name=0x8212738 "LIBXORP",
>      where=0xbfb74198 "asyncio.cc:413 sigpipe_handler",
>      fmt=0x8212908 "Assertion (%s) failed") at xlog.c:446
> #4  0x0818b0b8 in AsyncFileWriter::sigpipe_handler () at asyncio.cc:413
> #5  <signal handler called>
> #6  0xffffe430 in __kernel_vsyscall ()
> #7  0x4397a3c3 in __write_nocancel () from /lib/libc.so.6
> #8  0x43919474 in _IO_new_file_write () from /lib/libc.so.6
> #9  0x43919135 in new_do_write () from /lib/libc.so.6
> #10 0x439193ef in _IO_new_file_xsputn () from /lib/libc.so.6
> #11 0x4390f14a in fputs () from /lib/libc.so.6
> #12 0x08086c58 in ModuleManager::Process::stdout_cb (this=0x8524498,
>      run_command=0x8567088, output=@0xbfb7a3bc) at module_manager.cc:739
> #13 0x0808ba2c in XorpMemberCallback2B0<void, ModuleManager::Process, RunCommand *, std::string const&>::dispatch (this=0x85632a0, a1=0x8567088, a2=@0xbfb7a3bc)
>      at ../libxorp/callback_nodebug.hh:4636
> #14 0x081a0532 in RunCommand::stdout_cb_dispatch (this=0x8567088,
>      output=@0xbfb7a3bc) at run_command.hh:489
> #15 0x0819e03c in RunCommandBase::append_data (this=0x8567088,
>      event=AsyncFileOperator::DATA,
> Missing separate debuginfos, use: debuginfo-install gcc.i386 glibc.i686 openssl. i686 zlib.i386
> ---Type <return> to continue, or q <return> to quit---
>      buffer=0x85670b0 "[ 2008/10/17 09:57:43  WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:205 enable_interface_vif ] XRL-IO: Enable Interface rddVR1 Vif rddVR1\n[ 2008/10/17 09:57:43  WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:20"...,
>      offset=2428) at run_command.cc:595
> #16 0x081a0fae in XorpMemberCallback4B0<void, RunCommandBase, AsyncFileOperator::Event, unsigned char const*, unsigned int, unsigned int>::dispatch (
>      this=0x853fc80, a1=AsyncFileOperator::DATA,
>      a2=0x85670b0 "[ 2008/10/17 09:57:43  WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:205 enable_interface_vif ] XRL-IO: Enable Interface rddVR1 Vif rddVR1\n[ 2008/10/17 09:57:43 WARNING xorp_ospfv2:23095 OSPF xrl_io.cc:20"..., a3=8192,
>      a4=2428) at ../libxorp/callback_nodebug.hh:8966
> #17 0x0818cb74 in AsyncFileReader::BufferInfo::dispatch_callback (
>      this=0x8561070, e=AsyncFileOperator::DATA) at asyncio.hh:224
> #18 0x0818a735 in AsyncFileReader::complete_transfer (this=0x85654e8, err=0,
>      done=92) at asyncio.cc:271
> #19 0x0818ca1c in AsyncFileReader::read (this=0x85654e8, fd={_filedesc = 32},
>      type=IOT_READ) at asyncio.cc:230
> #20 0x0818d360 in XorpMemberCallback2B0<void, AsyncFileReader, XorpFd, IoEventType>::dispatch (this=0x855a458, a1={_filedesc = 32}, a2=IOT_READ)
>      at ../libxorp/callback_nodebug.hh:4636
> #21 0x081a4622 in SelectorList::Node::run_hooks (this=0x8511c98, m=SEL_RD, fd=
>        {_filedesc = 32}) at selector.cc:155
> #22 0x081a355a in SelectorList::wait_and_dispatch (this=0xbfb823e8,
> ---Type <return> to continue, or q <return> to quit---
>      timeout=@0xbfb7e430) at selector.cc:440
> #23 0x081910e2 in EventLoop::do_work (this=0xbfb823a0, can_block=true)
>      at eventloop.cc:132
> #24 0x081911e6 in EventLoop::run (this=0xbfb823a0) at eventloop.cc:85
> #25 0x08067e48 in Rtrmgr::run (this=0xbfb828e4) at main_rtrmgr.cc:349
> #26 0x08068912 in main (argc=5, argv=0xbfb829f4) at main_rtrmgr.cc:632
> (gdb)
> 
> 
> -- 
> 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 greearb at candelatech.com  Fri Oct 17 16:15:23 2008
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 17 Oct 2008 16:15:23 -0700
Subject: [Xorp-hackers] Assert in recent cvs
In-Reply-To: <200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU>
References: <48F8CB6B.5080307@candelatech.com>
	<200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <48F91C8B.5070907@candelatech.com>

Pavlin Radoslavov wrote:
> Ben Greear <greearb at candelatech.com> wrote:
> 
>> We're still trying to figure out if this is reproducible, but
>> here's the stack trace.  This is with all of my patches applied,
>> so it's possible something we are doing wrong.
> 
> Please send instructions how to reproduce the problem: rtrmgr
> command line options, configuration file and any actions you did.
> I need the command line options so I know where the log output is
> redirected to.
> 
> Also, please reverse-back the rev. 1.68 change to the
> rtrmgr/module_manager.cc file:
> 1.68      +5 -3;  commitid: 11fdf48f7e12041a7; xorp/rtrmgr/module_manager.cc
> 
> In particular, change back the two XLOG_*() messages to fprintf(),
> and see whether you still get the error.
> This will guide us choosing the next step in debugging the problem.

Ok, here is how you reproduce the problem:

I have a program called 'logchopper' that reads from stdin
and writes to log files, rotating them when they are large.
This way I can 'log' stdout and stderr by piping it into
logchopper.

When I shutdown my xorp instances, I do a 'killall -r xorp', which
sometimes kills the logchoppers before the parent xorp.  This causes
a sigpipe, I guess, and then xorp_rtrmgr dumps core.

I think you could use 'tee' in place of my logchopper and
have the same result.  If you want, I can send you the logchopper
source.

I'm going to try just commenting out the assert in the sig-pipe
handler.  In my case, xorp will be killed shortly anyway, and even if
not, I'd rather xorp run w/out stdout/stderr (or maybe exit cleanly)
than crash.

Thanks,
Ben

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


From pavlin at ICSI.Berkeley.EDU  Sat Oct 18 20:02:29 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Sat, 18 Oct 2008 20:02:29 -0700
Subject: [Xorp-hackers] Assert in recent cvs
In-Reply-To: <48F91C8B.5070907@candelatech.com> 
References: <48F8CB6B.5080307@candelatech.com>
	<200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU>
	<48F91C8B.5070907@candelatech.com>
Message-ID: <200810190302.m9J32Tfd023102@fruitcake.ICSI.Berkeley.EDU>

A non-text attachment was scrubbed...
Name: sigpipe.patch
Type: text/x-c++
Size: 6065 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081018/92c1c8b2/attachment.bin 

From pavlin at ICSI.Berkeley.EDU  Sun Oct 19 14:08:30 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Sun, 19 Oct 2008 14:08:30 -0700
Subject: [Xorp-hackers] XORP Web site search
Message-ID: <200810192108.m9JL8UgG008416@fruitcake.ICSI.Berkeley.EDU>

All,

Now the http://www.xorp.org/ Web site has a search bar in the upper
right corner. You would have to reload the front page if you don't
see it.
Please give it a try and send feedbacks to either xorp-users at xorp.org
or feedback at xorp.org (the latter if you prefer to keep the feedbacks
private).

The XORP Team.


From pavlin at ICSI.Berkeley.EDU  Tue Oct 21 17:28:33 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 21 Oct 2008 17:28:33 -0700
Subject: [Xorp-hackers] Assert in recent cvs
In-Reply-To: <200810190302.m9J32Tfd023102@fruitcake.ICSI.Berkeley.EDU> 
References: <48F8CB6B.5080307@candelatech.com>
	<200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU>
	<48F91C8B.5070907@candelatech.com>
	<200810190302.m9J32Tfd023102@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <200810220028.m9M0SXBN002751@fruitcake.ICSI.Berkeley.EDU>

> Ben,
> 
> Could you try the following patch.
> It basically gets rid of the SIGPIPE handling and uses
> "signal(SIGPIPE, SIG_IGN)" to completely ignore SIGPIPE inside the
> EventLoop constructor.
> Instead of dealing with SIGPIPE, we handle error conditions by
> using the return error code.

Patch committed to CVS:

Revision  Changes                               Path
1.28      +1 -4;  commitid: 7b5d48fe72eb41a7;   xorp/libxipc/finder_main.cc
1.46      +9 -36;  commitid: 7b5d48fe72eb41a7;  xorp/libxorp/asyncio.cc
1.35      +1 -4;  commitid: 7b5d48fe72eb41a7;   xorp/libxorp/asyncio.hh
1.47      +10 -1;  commitid: 7b5d48fe72eb41a7;  xorp/libxorp/eventloop.cc
1.75      +1 -12;  commitid: 7b5d48fe72eb41a7;  xorp/rtrmgr/xorpsh_main.cc


Scream loudly if it breaks things for you.

Pavlin


From eshe168 at gmail.com  Tue Oct 21 19:09:34 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Wed, 22 Oct 2008 10:09:34 +0800
Subject: [Xorp-hackers] About statement name
Message-ID: <56f9e0990810211909h651cbdd8p4ea2240ec6d99f6e@mail.gmail.com>

Hi,

When I used "ipv4" as the name of a statement, the xorp_rtrmgr can not
start. How can i resolve it, please?

The following is error message:
[ 2008/10/22 10:07:20  ERROR xorp_rtrmgr:25444 RTRMGR +237
main_rtrmgr.cc run ] Shutting down due to an init error: PARSE ERROR
[Template File: /home/yxs/xorp-cli/xorp-demo/etc/templates/test.tp
line 2]: syntax error; Last symbol parsed was "vlans"

B.R.

Xiaoshuai Yang


From pavlin at ICSI.Berkeley.EDU  Tue Oct 21 20:13:21 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Tue, 21 Oct 2008 20:13:21 -0700
Subject: [Xorp-hackers] About statement name
In-Reply-To: <56f9e0990810211909h651cbdd8p4ea2240ec6d99f6e@mail.gmail.com> 
References: <56f9e0990810211909h651cbdd8p4ea2240ec6d99f6e@mail.gmail.com>
Message-ID: <200810220313.m9M3DLxD015440@fruitcake.ICSI.Berkeley.EDU>

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

> Hi,
> 
> When I used "ipv4" as the name of a statement, the xorp_rtrmgr can not
> start. How can i resolve it, please?

"ipv4" is a reserved token name to specify the type so you can't use
it for the name of a statement. See the "XORP Router Manager Process
(rtrmgr)" design document or the rtrmgr/template.ll for the list of
reserved token names.

Pavlin

> The following is error message:
> [ 2008/10/22 10:07:20  ERROR xorp_rtrmgr:25444 RTRMGR +237
> main_rtrmgr.cc run ] Shutting down due to an init error: PARSE ERROR
> [Template File: /home/yxs/xorp-cli/xorp-demo/etc/templates/test.tp
> line 2]: syntax error; Last symbol parsed was "vlans"
> 
> B.R.
> 
> Xiaoshuai Yang
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From greearb at candelatech.com  Wed Oct 22 11:23:43 2008
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 22 Oct 2008 11:23:43 -0700
Subject: [Xorp-hackers] Assert in recent cvs
In-Reply-To: <200810220028.m9M0SXBN002751@fruitcake.ICSI.Berkeley.EDU>
References: <48F8CB6B.5080307@candelatech.com>
	<200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU>
	<48F91C8B.5070907@candelatech.com>
	<200810190302.m9J32Tfd023102@fruitcake.ICSI.Berkeley.EDU>
	<200810220028.m9M0SXBN002751@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <48FF6FAF.2090900@candelatech.com>

Pavlin Radoslavov wrote:
>> Ben,
>>
>> Could you try the following patch.
>> It basically gets rid of the SIGPIPE handling and uses
>> "signal(SIGPIPE, SIG_IGN)" to completely ignore SIGPIPE inside the
>> EventLoop constructor.
>> Instead of dealing with SIGPIPE, we handle error conditions by
>> using the return error code.
> 
> Patch committed to CVS:

Thanks for this.  I have been too busy to try this out, but should
have time next week.

Thanks,
Ben

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


From greearb at candelatech.com  Wed Oct 22 11:26:29 2008
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 22 Oct 2008 11:26:29 -0700
Subject: [Xorp-hackers] BGP assertion
Message-ID: <48FF7055.6050106@candelatech.com>

I configured two virtual routers to have BGP and to
talk to each other.  At one point or another, it crashed
with this assert.  I haven't had time to try to reproduce
it, but should get time next week.

NOTE:  This is patched with my patch to bind to a local device,
*but*, I had it configured to NOT bind since that seems to be
a bad idea now that I understand things better.

The assert that hits is this from socket.cc:

void
SocketClient::connect_socket_break()
{
     XLOG_ASSERT(_connecting);
     _connecting = false;

     eventloop().remove_ioevent_cb(get_sock());
     close_socket();
}


#0  0xffffe430 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe430 in __kernel_vsyscall ()
#1  0x438df690 in raise () from /lib/libc.so.6
#2  0x438e0f91 in abort () from /lib/libc.so.6
#3  0x082be6f9 in xlog_fatal (module_name=0x82ed387 "BGP",
     where=0xbfe208f4 "socket.cc:569 connect_socket_break", fmt=0x82ed371 "Assertion (%s) failed")
     at xlog.c:446
#4  0x08144667 in SocketClient::connect_socket_break (this=0x83f8d28) at socket.cc:569
#5  0x081446d1 in SocketClient::connect_break (this=0x83f8d28) at socket.cc:227
#6  0x0809292f in BGPPeer::event_closed (this=0x83d8da8) at peer.cc:707
#7  0x0809507d in BGPPeer::get_message (this=0x83d8da8, status=BGPPacket::CONNECTION_CLOSED,
     buf=0x0, length=0, socket_client=0x83f8d28) at peer.cc:140
#8  0x08059544 in XorpMemberCallback4B0<bool, BGPPeer, BGPPacket::Status, unsigned char const*, unsig ned int, SocketClient*>::dispatch (this=0x83d94c0, a1=BGPPacket::CONNECTION_CLOSED, a2=0x0, a3=0,
     a4=0x83f8d28) at ../libxorp/callback_nodebug.hh:8946
#9  0x0814425e in SocketClient::async_read_message (this=0x83f8d28,
     ev=AsyncFileOperator::END_OF_FILE, buf=0x83f8f13 '?' <repeats 16 times>, buf_bytes=19, offset=0)
     at socket.cc:353
#10 0x0814591c in XorpMemberCallback4B0<void, SocketClient, AsyncFileOperator::Event, unsigned char c onst*, unsigned int, unsigned int>::dispatch (this=0x83d59d8, a1=AsyncFileOperator::END_OF_FILE,
     a2=0x83f8f13 '?' <repeats 16 times>, a3=19, a4=0) at ../libxorp/callback_nodebug.hh:8966
#11 0x082c1ca8 in AsyncFileReader::BufferInfo::dispatch_callback (this=0x83fb720,
     e=AsyncFileOperator::END_OF_FILE) at asyncio.hh:224
#12 0x082bf8c4 in AsyncFileReader::complete_transfer (this=0x83fb6f8, err=0, done=0)
     at asyncio.cc:281
#13 0x082c1b50 in AsyncFileReader::read (this=0x83fb6f8, fd={_filedesc = 40}, type=IOT_READ)
     at asyncio.cc:230
#14 0x082c2494 in XorpMemberCallback2B0<void, AsyncFileReader, XorpFd, IoEventType>::dispatch (
     this=0x83d5b30, a1={_filedesc = 40}, a2=IOT_READ) at ../libxorp/callback_nodebug.hh:4636
#15 0x082d7f36 in SelectorList::Node::run_hooks (this=0x83daf38, m=SEL_RD, fd={_filedesc = 40})
     at selector.cc:155
Missing separate debuginfos, use: debuginfo-install gcc.i386 glibc.i686 openssl.i686 zlib.i386
---Type <return> to continue, or q <return> to quit---
#16 0x082d6e6e in SelectorList::wait_and_dispatch (this=0xbfe2e890, timeout=@0xbfe2c860)
     at selector.cc:440
#17 0x082c6216 in EventLoop::do_work (this=0xbfe2e848, can_block=true) at eventloop.cc:132
#18 0x082c631a in EventLoop::run (this=0xbfe2e848) at eventloop.cc:85
#19 0x08051305 in BGPMain::main_loop (this=0xbfe2ebbc) at bgp.cc:802
#20 0x0805f3aa in main (argv=0xbfe2eda4) at main.cc:93
(gdb)

Thanks,
Ben

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


From samuellucas at datacom.ind.br  Wed Oct 22 14:58:41 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Wed, 22 Oct 2008 19:58:41 -0200
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
Message-ID: <48FFA211.4070406@datacom.ind.br>

Hi!

I'm playing around with pimsm4 and found a strange behavior that seems to be a bug.

To reproduce it, first add a cand-rp for any group-prefix and commit. Then, add a cand-bsr for the same group-prefix. When trying to commit I got the following error:

102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 for zone 224.0.0.0/4(non-scoped): already have scope zone 224.0.0.0/4(non-scoped)

=================================================
samuellucas at erdinger# set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 cand-rp-by-vif-name eth0
[edit]
samuellucas at erdinger# commit
OK
[edit]
samuellucas at erdinger# set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 cand-bsr-by-vif-name eth0
[edit]
samuellucas at erdinger# commit
Commit Failed
102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 for zone 224.0.0.0/4(non-scoped): already have scope zone 224.0.0.0/4(non-scoped)[edit]
samuellucas at erdinger# 
==================================================


In the code I found that PimNode::add_config_cand_rp adds a BSR zone when adding the RP and add_config_cand_bsr fails when finds this added zone. Also, this zone is not visible in the configuration tree (otherwise xorpsh/rtrmgr would have handled this as a modification in a existing cand-bsr, which works fine).

I'm wondering what would be the best way to handle this. 
There are a few options: We can replace the automatically created zone with the user provided one, we can report the zone to rtrmgr/xorpsh or we can reuse the created zone and merge the changes, if possible.

What do you recommend?


BTW, after writing a patch how do I submit it? Just mail it to this list?


Thank you,

 - Samuel





From pavlin at ICSI.Berkeley.EDU  Wed Oct 22 17:57:27 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Wed, 22 Oct 2008 17:57:27 -0700
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <48FFA211.4070406@datacom.ind.br> 
References: <48FFA211.4070406@datacom.ind.br>
Message-ID: <200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> Hi!
> 
> I'm playing around with pimsm4 and found a strange behavior that seems to be a bug.
> 
> To reproduce it, first add a cand-rp for any group-prefix and commit. Then, add a cand-bsr for the same group-prefix. When trying to commit I got the following error:
> 
> 102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 for zone 224.0.0.0/4(non-scoped): already have scope zone 224.0.0.0/4(non-scoped)
> 
> =================================================
> samuellucas at erdinger# set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 cand-rp-by-vif-name eth0
> [edit]
> samuellucas at erdinger# commit
> OK
> [edit]
> samuellucas at erdinger# set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 cand-bsr-by-vif-name eth0
> [edit]
> samuellucas at erdinger# commit
> Commit Failed
> 102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 for zone 224.0.0.0/4(non-scoped): already have scope zone 224.0.0.0/4(non-scoped)[edit]
> samuellucas at erdinger# 
> ==================================================

I need to double-check with the PIM BSR spec, but I think that
224.0.0.0/4 has special meaning (it is the "global" zone) and cannot
be configured as a scoped zone.
Hence, the behavior is correct, though the error could be more user
friendly.

If you think the above statement is incorrect, then please submit a
Bugzilla entry about the issue. For the time being no need to write
a patch, until we know it is actually a bug :)

Thanks,
Pavlin

> In the code I found that PimNode::add_config_cand_rp adds a BSR zone when adding the RP and add_config_cand_bsr fails when finds this added zone. Also, this zone is not visible in the configuration tree (otherwise xorpsh/rtrmgr would have handled this as a modification in a existing cand-bsr, which works fine).
> 
> I'm wondering what would be the best way to handle this. 
> There are a few options: We can replace the automatically created zone with the user provided one, we can report the zone to rtrmgr/xorpsh or we can reuse the created zone and merge the changes, if possible.
> 
> What do you recommend?
> 
> 
> BTW, after writing a patch how do I submit it? Just mail it to this list?
> 
> 
> Thank you,
> 
>  - Samuel
> 
> 
> 
> 
> _______________________________________________
> 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 Oct 23 00:41:57 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 23 Oct 2008 00:41:57 -0700
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU> 
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>

> > I'm playing around with pimsm4 and found a strange behavior that seems to be a bug.
> > 
> > To reproduce it, first add a cand-rp for any group-prefix and commit. Then, add a cand-bsr for the same group-prefix. When trying to commit I got the following error:
> > 
> > 102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 for zone 224.0.0.0/4(non-scoped): already have scope zone 224.0.0.0/4(non-scoped)
> > 
> > =================================================
> > samuellucas at erdinger# set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 cand-rp-by-vif-name eth0
> > [edit]
> > samuellucas at erdinger# commit
> > OK
> > [edit]
> > samuellucas at erdinger# set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 cand-bsr-by-vif-name eth0
> > [edit]
> > samuellucas at erdinger# commit
> > Commit Failed
> > 102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 for zone 224.0.0.0/4(non-scoped): already have scope zone 224.0.0.0/4(non-scoped)[edit]
> > samuellucas at erdinger# 
> > ==================================================

================
> I need to double-check with the PIM BSR spec, but I think that
> 224.0.0.0/4 has special meaning (it is the "global" zone) and cannot
> be configured as a scoped zone.
> Hence, the behavior is correct, though the error could be more user
> friendly.
================

Please ignore my statement above, because it is complete nonsense
(I was in a hurry and overlooked a number of things).

Yes, I think what you see is a bug.

> > In the code I found that PimNode::add_config_cand_rp adds a BSR zone when adding the RP and add_config_cand_bsr fails when finds this added zone. Also, this zone is not visible in the configuration tree (otherwise xorpsh/rtrmgr would have handled this as a modification in a existing cand-bsr, which works fine).
> > 
> > I'm wondering what would be the best way to handle this. 
> > There are a few options: We can replace the automatically created zone with the user provided one, we can report the zone to rtrmgr/xorpsh or we can reuse the created zone and merge the changes, if possible.

The second one is not really an option, because we never propagate
state back to the rtrmgr/xorpsh.
I think the correct behavior is the third one: reuse the created
zone and merge the changes (if possible).
The first one (replace the automatically created zone with the user
provided one) might result in losing the Cand-RP state, which we
definitely want to avoid.

> > What do you recommend?
> > 
> > 
> > BTW, after writing a patch how do I submit it? Just mail it to this list?

Please open a Bugzilla entry about the issue and add te patch to
that entry.

Thanks,
Pavlin


From samuellucas at datacom.ind.br  Thu Oct 23 10:14:36 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Thu, 23 Oct 2008 15:14:36 -0200
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <4900B0FC.4050801@datacom.ind.br>

Pavlin Radoslavov wrote:
> The second one is not really an option, because we never propagate
> state back to the rtrmgr/xorpsh.
> I think the correct behavior is the third one: reuse the created
> zone and merge the changes (if possible).
> The first one (replace the automatically created zone with the user
> provided one) might result in losing the Cand-RP state, which we
> definitely want to avoid.
> 
>>> What do you recommend?
>>>
>>>
>>> BTW, after writing a patch how do I submit it? Just mail it to this list?
> 
> Please open a Bugzilla entry about the issue and add te patch to
> that entry.
> 

Done. Bugzilla entry #803 with patch attached.

 - Samuel


From pavlin at ICSI.Berkeley.EDU  Thu Oct 23 17:16:41 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 23 Oct 2008 17:16:41 -0700
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <4900B0FC.4050801@datacom.ind.br> 
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
Message-ID: <200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> Pavlin Radoslavov wrote:
> > The second one is not really an option, because we never propagate
> > state back to the rtrmgr/xorpsh.
> > I think the correct behavior is the third one: reuse the created
> > zone and merge the changes (if possible).
> > The first one (replace the automatically created zone with the user
> > provided one) might result in losing the Cand-RP state, which we
> > definitely want to avoid.
> > 
> >>> What do you recommend?
> >>>
> >>>
> >>> BTW, after writing a patch how do I submit it? Just mail it to this list?
> > 
> > Please open a Bugzilla entry about the issue and add te patch to
> > that entry.
> > 
> 
> Done. Bugzilla entry #803 with patch attached.

Fixed in CVS. Note that the problem was deeper: it could be
triggered even if the user tried to update the PIM Bootstrap
configuration at runtime via xorpsh.

Thanks,
Pavlin


From samuellucas at datacom.ind.br  Fri Oct 24 10:36:55 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Fri, 24 Oct 2008 15:36:55 -0200
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <490207B7.9050900@datacom.ind.br>

Pavlin Radoslavov wrote:
> 
> Fixed in CVS. Note that the problem was deeper: it could be
> triggered even if the user tried to update the PIM Bootstrap
> configuration at runtime via xorpsh.
> 

Pavlin,

Is there any reason to not set _bsr_addr and _bsr_priority in BsrZone::update_config_bsr_zone() ?

Using your patch, the address is set correctly in the configured zone but as soon as the configured zone becomes Active it has no LocalAddress:

samuellucas at erdinger> show pim bootstrap 
Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 0.0.0.0           0 Pending             120        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 10.1.3.11         1 Init                 -1        -1

samuellucas at erdinger> show pim bootstrap 
Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 0.0.0.0           0 Elected               4        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 10.1.3.11         1 Init                 -1        -1

It seems that the active zone takes address and priority from the _bsr_addr and _bsr_priority instead of _my_bsr_addr and _my_bsr_priority.

I've tested here updating _bsr_addr and _bsr_priority in update_config_bsr_zone and it seems to work it out.

For configured zones, there is any situation when the _bsr_addr/_bsr_priority would be different of _my_bsr_addr/_my_bsr_priority ?


Thank you,

 - Samuel



From pavlin at ICSI.Berkeley.EDU  Fri Oct 24 17:16:31 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Fri, 24 Oct 2008 17:16:31 -0700
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <490207B7.9050900@datacom.ind.br> 
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
Message-ID: <200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> Pavlin Radoslavov wrote:
> > 
> > Fixed in CVS. Note that the problem was deeper: it could be
> > triggered even if the user tried to update the PIM Bootstrap
> > configuration at runtime via xorpsh.
> > 
> 
> Pavlin,
> 
> Is there any reason to not set _bsr_addr and _bsr_priority in BsrZone::update_config_bsr_zone() ?

Fields _bsr_addr and _bsr_priority are suppose to be the state for
the Elected BSR. They matter in the set of so called "active"
BsrZone entries, but are not used in the "configured" BsrZone
entries.

There was a bug in old code re. how the state from the "configured"
BsrZone was propagated to the "active" BsrZone.
That bug was exposed my previous change.

I just committed a fix to CVS, so please try it and let me know if
you still have this or some other issue:

Revision  Changes                              Path
1.56      +3 -3;  commitid: ec3e4902630a41a7;  xorp/pim/pim_bsr.cc


Thanks,
Pavlin

> Using your patch, the address is set correctly in the configured zone but as soon as the configured zone becomes Active it has no LocalAddress:
> 
> samuellucas at erdinger> show pim bootstrap 
> Active zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 0.0.0.0           0 Pending             120        -1
> Expiring zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> Configured zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 10.1.3.11         1 Init                 -1        -1
> 
> samuellucas at erdinger> show pim bootstrap 
> Active zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 0.0.0.0           0 Elected               4        -1
> Expiring zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> Configured zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 10.1.3.11         1 Init                 -1        -1
> 
> It seems that the active zone takes address and priority from the _bsr_addr and _bsr_priority instead of _my_bsr_addr and _my_bsr_priority.
> 
> I've tested here updating _bsr_addr and _bsr_priority in update_config_bsr_zone and it seems to work it out.
> 
> For configured zones, there is any situation when the _bsr_addr/_bsr_priority would be different of _my_bsr_addr/_my_bsr_priority ?
> 
> 
> Thank you,
> 
>  - Samuel
> 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From bms at incunabulum.net  Mon Oct 27 04:38:08 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Mon, 27 Oct 2008 11:38:08 +0000
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
Message-ID: <4905A820.5070408@incunabulum.net>

Hi,

When cross-compiling XORP for XScale, there is an alignment error 
triggered by line 776 of xrl_args.cc, causing compilation to fail. This 
is a reinterpret_cast from uint8_t* to uint32_t*.

Now at this point in the XRL code there appears to be no guarantee that 
the buffer passed to XrlArgs::unpack_header() will conform to any 
arbitrary alignment as may be required by the target platform.

The "right fix" to my mind is to use the extract_32() inline function 
from libproto/packet.hh, as the code immediately calls ntohl() on the 
casted rvalue.

Thoughts?
BMS


From bms at incunabulum.net  Mon Oct 27 05:03:25 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Mon, 27 Oct 2008 12:03:25 +0000
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
In-Reply-To: <4905A820.5070408@incunabulum.net>
References: <4905A820.5070408@incunabulum.net>
Message-ID: <4905AE0D.8050103@incunabulum.net>

These two patches work for me to get libxipc built.

However, there's still an alignment problem with ArpHeader in packet.cc.

Perhaps we should add a means of selectively disabling the alignment 
warnings (we use -Werror by default) until we can find and fix them 
where relevant.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081027/163334dc/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081027/163334dc/attachment-0001.ksh 

From bms at incunabulum.net  Mon Oct 27 05:28:52 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Mon, 27 Oct 2008 12:28:52 +0000
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
In-Reply-To: <4905A820.5070408@incunabulum.net>
References: <4905A820.5070408@incunabulum.net>
Message-ID: <4905B404.7040405@incunabulum.net>

There are only 2 other places where the alignment warning is triggered.

1. in packet.cc ArpHeader::assign().

uint8_t* is being cast to ArpHeader*, whose first member is uint16_t and 
thus triggers the alignment warning.

This code seems to be dubious where strict alignment is concerned.

2. in vrrp_packet.cc VrrpHeader::assign().

In this case, the first member is a C-style bit-field contained in a 
uint8_t.

Normally I wouldn't expect this to generate an error, it is possible 
that the compiler is attempting to use ARM bit-field opcodes, although I 
was under the impression these were only part of Thumb-2.

In both cases, we are casting an arbitrary uint8_t* pointer to a 
structure type. The two alignment warnings in the XRL layer are easily 
fixed by using extract_32(). However these further warnings refer to 
aggregate types so we can't deal with them so easily.

I'm sure I saw issues like this with the STCP packet header in libxipc.

regards
BMS


From pavlin at ICSI.Berkeley.EDU  Mon Oct 27 09:41:18 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Mon, 27 Oct 2008 09:41:18 -0700
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
In-Reply-To: <4905AE0D.8050103@incunabulum.net> 
References: <4905A820.5070408@incunabulum.net>
	<4905AE0D.8050103@incunabulum.net>
Message-ID: <200810271641.m9RGfIa1009869@fruitcake.ICSI.Berkeley.EDU>

Bruce M Simpson <bms at incunabulum.net> wrote:

> These two patches work for me to get libxipc built.

Both fixes seem the right thing to do, so please commit them.

What OS and gcc cross-compiler are you using?
I wonder why our periodic tinderbox cross-compilation for XScale
(and few other) didn't catch it (for XScale we are using
gcc-3.4.5).

Thanks,
Pavlin

> However, there's still an alignment problem with ArpHeader in packet.cc.
> 
> Perhaps we should add a means of selectively disabling the alignment warnings
> (we use -Werror by default) until we can find and fix them where relevant.
> --- ./libxipc/xrl_args.cc.orig	2008-10-27 11:40:07.000000000 +0000
> +++ ./libxipc/xrl_args.cc	2008-10-27 11:41:22.000000000 +0000
> @@ -27,6 +27,8 @@
>  #include "libxorp/xlog.h"
>  #include "libxorp/debug.h"
>  
> +#include "libproto/packet.hh"
> +
>  #include <functional>
>  #include <stdexcept>
>  
> @@ -773,8 +775,7 @@
>      if (len < 4)
>  	return 0;
>  
> -    uint32_t header = *(reinterpret_cast<const uint32_t*>(in));
> -    header = ntohl(header);
> +    uint32_t header = extract_32(in);
>  
>      // Check header sanity
>      if ((header >> 24) != PACKING_CHECK_CODE)
> 
> --- ./libxipc/xrl_atom.cc.orig	2008-10-27 11:41:32.000000000 +0000
> +++ ./libxipc/xrl_atom.cc	2008-10-27 11:42:10.000000000 +0000
> @@ -28,6 +28,8 @@
>  #include "libxorp/c_format.hh"
>  #include "libxorp/xlog.h"
>  
> +#include "libproto/packet.hh"
> +
>  #include <map>
>  #include <string>
>  
> @@ -1062,8 +1064,7 @@
>      if (len < sizeof(tl))
>  	return 0;
>  
> -    tl = *(reinterpret_cast<const uint32_t*>(buf));
> -    tl = ntohl(tl);
> +    tl = extract_32(buf);
>  
>      buf += sizeof(tl);
>      len -= sizeof(tl);
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin at ICSI.Berkeley.EDU  Mon Oct 27 09:56:41 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Mon, 27 Oct 2008 09:56:41 -0700
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
In-Reply-To: <4905B404.7040405@incunabulum.net> 
References: <4905A820.5070408@incunabulum.net>
	<4905B404.7040405@incunabulum.net>
Message-ID: <200810271656.m9RGufcl011910@fruitcake.ICSI.Berkeley.EDU>

Bruce M Simpson <bms at incunabulum.net> wrote:

> There are only 2 other places where the alignment warning is triggered.
> 
> 1. in packet.cc ArpHeader::assign().
> 
> uint8_t* is being cast to ArpHeader*, whose first member is uint16_t and 
> thus triggers the alignment warning.
> 
> This code seems to be dubious where strict alignment is concerned.

Even without the alignment issue, such casting is questionable (to
say the least) and very anti-C++.

> 2. in vrrp_packet.cc VrrpHeader::assign().
> 
> In this case, the first member is a C-style bit-field contained in a 
> uint8_t.
> 
> Normally I wouldn't expect this to generate an error, it is possible 
> that the compiler is attempting to use ARM bit-field opcodes, although I 
> was under the impression these were only part of Thumb-2.
> 
> In both cases, we are casting an arbitrary uint8_t* pointer to a 
> structure type. The two alignment warnings in the XRL layer are easily 
> fixed by using extract_32(). However these further warnings refer to 
> aggregate types so we can't deal with them so easily.

I agree with you.
Potential issues like this are some of the reasons that the
backend implementation of IpHeader4/IpHeader4Writer (and the
corresponding IPv6 version) in libproto/packet.hh is done the way it
is.

If fixing the issue is not going to be trivial, please submit a
Bugzilla entry.

Thanks,
Pavlin

> I'm sure I saw issues like this with the STCP packet header in libxipc.
> 
> regards
> BMS
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From bms at incunabulum.net  Mon Oct 27 14:40:41 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Mon, 27 Oct 2008 21:40:41 +0000
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
In-Reply-To: <200810271641.m9RGfIa1009869@fruitcake.ICSI.Berkeley.EDU>
References: <4905A820.5070408@incunabulum.net>
	<4905AE0D.8050103@incunabulum.net>
	<200810271641.m9RGfIa1009869@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <49063559.2010505@incunabulum.net>

Pavlin Radoslavov wrote:
> What OS and gcc cross-compiler are you using?
> I wonder why our periodic tinderbox cross-compilation for XScale
> (and few other) didn't catch it (for XScale we are using
> gcc-3.4.5).

Gentoo Linux 2008.1/x86 with a crosstool (not crossdev) built toolchain 
using the demo-arm-xscale.sh configuration: gcc 4.1.0.

cheers,
BMS


From samuellucas at datacom.ind.br  Mon Oct 27 15:00:53 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Mon, 27 Oct 2008 20:00:53 -0200
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
	<200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <49063A15.4030202@datacom.ind.br>

> Fields _bsr_addr and _bsr_priority are suppose to be the state for
> the Elected BSR. They matter in the set of so called "active"
> BsrZone entries, but are not used in the "configured" BsrZone
> entries.
> 
> There was a bug in old code re. how the state from the "configured"
> BsrZone was propagated to the "active" BsrZone.
> That bug was exposed my previous change.
> 
> I just committed a fix to CVS, so please try it and let me know if
> you still have this or some other issue:
> 
> Revision  Changes                              Path
> 1.56      +3 -3;  commitid: ec3e4902630a41a7;  xorp/pim/pim_bsr.cc
> 

Thank you Pavlin!

This basically fix it.
Just a minor issue: After getting elected, shouldn't _my_bsr_addr/_my_bsr_priority be copied to _bsr_addr/_bsr_priority ?

For me, it shows like this:

root at erdinger> show pim bootstrap 
Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 10.1.3.11         1 Elected              58        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 10.1.3.11         1 Init                 -1        -1

As the machine is elected as Active BSR, wouldn't the Active address be 10.1.3.11 instead of 0.0.0.0? I saw that i_am_bsr() checks if bsr_addr()==my_bsr_addr(), what would lead to further errors.


Another issue: If the node is Elected as BSR and I add another Cand-RP, it triggers bsr_stop() and bsr_start() what causes it to lose Elected state and return to Pending. Although this is not wrong, it would be better to just keep the state (the stop() causes Cand-RP-ADV with zero holdtime, what changes the state also in remote peers). I was wondering about writing an update method that apply the actions in stop() and start() only in the changed zones. What do you think?

Thank you,

 - Samuel


From pavlin at ICSI.Berkeley.EDU  Mon Oct 27 17:58:53 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Mon, 27 Oct 2008 17:58:53 -0700
Subject: [Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
In-Reply-To: <49063A15.4030202@datacom.ind.br> 
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
	<200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
	<49063A15.4030202@datacom.ind.br>
Message-ID: <200810280058.m9S0wrOd010897@fruitcake.ICSI.Berkeley.EDU>

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> > Fields _bsr_addr and _bsr_priority are suppose to be the state for
> > the Elected BSR. They matter in the set of so called "active"
> > BsrZone entries, but are not used in the "configured" BsrZone
> > entries.
> > 
> > There was a bug in old code re. how the state from the "configured"
> > BsrZone was propagated to the "active" BsrZone.
> > That bug was exposed my previous change.
> > 
> > I just committed a fix to CVS, so please try it and let me know if
> > you still have this or some other issue:
> > 
> > Revision  Changes                              Path
> > 1.56      +3 -3;  commitid: ec3e4902630a41a7;  xorp/pim/pim_bsr.cc
> > 
> 
> Thank you Pavlin!
> 
> This basically fix it.
> Just a minor issue: After getting elected, shouldn't _my_bsr_addr/_my_bsr_priority be copied to _bsr_addr/_bsr_priority ?
> 
> For me, it shows like this:
> 
> root at erdinger> show pim bootstrap 
> Active zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 10.1.3.11         1 Elected              58        -1
> Expiring zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> Configured zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 10.1.3.11         1 Init                 -1        -1
> 
> As the machine is elected as Active BSR, wouldn't the Active address be 10.1.3.11 instead of 0.0.0.0? I saw that i_am_bsr() checks if bsr_addr()==my_bsr_addr(), what would lead to further errors.

Yes, this was a bug which I created by my previous fix.
I just committed a fix to CVS:

Revision  Changes                               Path
1.57      +3 -1;  commitid: 17bbc49065a0f41a7;  xorp/pim/pim_bsr.cc
1.24      +2 -1;  commitid: 17bbc49065a0f41a7;  xorp/pim/pim_bsr.hh

Yes, you are right about copying _my_bsr_addr and _my_bsr_priority
to _bsr_addr and _bsr_priority.
In one of my earlier emails on the subject I said that _bsr_addr and
_bsr_priority are not used/needed for "configured" BsrZone entries.
While chasing this bug I discovered they are actually used (when
propagating the state to an "active" BsrZone entry), so now
they are set when the Cand-BSR state is updated.

> Another issue: If the node is Elected as BSR and I add another
> Cand-RP, it triggers bsr_stop() and bsr_start() what causes it to
> lose Elected state and return to Pending. Although this is not
> wrong, it would be better to just keep the state (the stop()
> causes Cand-RP-ADV with zero holdtime, what changes the state also
> in remote peers). I was wondering about writing an update method
> that apply the actions in stop() and start() only in the changed
> zones. What do you think?

Accidentally, couple of days ago I was thinking about the same when I
noticed the bsr_stop()/bsr_start().

If I remember correctly, I used bsr_stop()/bsr_start() because there
was lots of complexity when I tried to do the incremental update.
Though, I don't remember whether this applied to the first version
of the BSR implementation or to the (almost complete) rewrite I had
to do after I discovered major issues with the first version.

Another reason for the bsr_stop()/bsr_start() was because I wanted
atomic update (e.g., transaction like), otherwise during
reconfiguration there will be lots of flux with potentially
dangerous results (remember that consistent Cand-RP set across
all PIM-SM routers is critical).
At that time there was no easy way to apply some transaction-based
mechanism to achieve the atomic update, so the
bsr_stop()/bsr_start() was the simple work-around (e.g., note that
it is in the etc/templates/pimsm*.tp template files).

If you can find a simple way to do the update atomically without
bsr_stop()/bsr_start(), then give it a try and see how well it
works.
Otherwise, please submit a Bugzilla entry about the issue.

Thanks,
Pavlin


From bms at incunabulum.net  Tue Oct 28 06:29:09 2008
From: bms at incunabulum.net (Bruce M Simpson)
Date: Tue, 28 Oct 2008 13:29:09 +0000
Subject: [Xorp-hackers] Alignment problem in xrl_args.cc on xScale
In-Reply-To: <200810271641.m9RGfIa1009869@fruitcake.ICSI.Berkeley.EDU>
References: <4905A820.5070408@incunabulum.net>
	<4905AE0D.8050103@incunabulum.net>
	<200810271641.m9RGfIa1009869@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <490713A5.8010601@incunabulum.net>

Pavlin Radoslavov wrote:
> Bruce M Simpson <bms at incunabulum.net> wrote:
>
>   
>> These two patches work for me to get libxipc built.
>>     
>
> Both fixes seem the right thing to do, so please commit them.
>   

Committed, thanks.
BMS


From eshe168 at gmail.com  Tue Oct 28 23:12:45 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Wed, 29 Oct 2008 14:12:45 +0800
Subject: [Xorp-hackers] Bug report.
Message-ID: <56f9e0990810282312q35807459r1310ae268a6b14ca@mail.gmail.com>

     when you entry a "xxx xxxx" value into txt node. The xorpsh will
pass it. But when you use show -all in CLI, the information in your
screen is wrong. Apparently, text should not be "\"abc cba\"".

exp:
yxs at Lenny621# set vlans interface 312 text "abc cba"
yxs at Lenny621# show
    vlans {
        interface 312 {
>           text: "\"abc cba\""
        }
    }

BUG FIXED:
string
ConfigTreeNode::quoted_value(const string& value) const
{
    string result;
    ...
	if (x == '"')
>	    escaped += "\\\""; //should be escaped += "";
	else
	    escaped += x;
    ...
    return result;
}


B.R.
Xiaoshuai Yang


From samuellucas at datacom.ind.br  Wed Oct 29 06:50:22 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Wed, 29 Oct 2008 11:50:22 -0200
Subject: [Xorp-hackers]  BSR Restart
In-Reply-To: <200810280058.m9S0wrOd010897@fruitcake.ICSI.Berkeley.EDU>
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
	<200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
	<49063A15.4030202@datacom.ind.br>
	<200810280058.m9S0wrOd010897@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <49086A1E.8080107@datacom.ind.br>

>> Another issue: If the node is Elected as BSR and I add another
>> Cand-RP, it triggers bsr_stop() and bsr_start() what causes it to
>> lose Elected state and return to Pending. Although this is not
>> wrong, it would be better to just keep the state (the stop()
>> causes Cand-RP-ADV with zero holdtime, what changes the state also
>> in remote peers). I was wondering about writing an update method
>> that apply the actions in stop() and start() only in the changed
>> zones. What do you think?
> 
> Accidentally, couple of days ago I was thinking about the same when I
> noticed the bsr_stop()/bsr_start().
> 
> If I remember correctly, I used bsr_stop()/bsr_start() because there
> was lots of complexity when I tried to do the incremental update.
> Though, I don't remember whether this applied to the first version
> of the BSR implementation or to the (almost complete) rewrite I had
> to do after I discovered major issues with the first version.

The code in CVS is the rewritten code?


> Another reason for the bsr_stop()/bsr_start() was because I wanted
> atomic update (e.g., transaction like), otherwise during
> reconfiguration there will be lots of flux with potentially
> dangerous results (remember that consistent Cand-RP set across
> all PIM-SM routers is critical).
> At that time there was no easy way to apply some transaction-based
> mechanism to achieve the atomic update, so the
> bsr_stop()/bsr_start() was the simple work-around (e.g., note that
> it is in the etc/templates/pimsm*.tp template files).
> 
> If you can find a simple way to do the update atomically without
> bsr_stop()/bsr_start(), then give it a try and see how well it
> works.
> Otherwise, please submit a Bugzilla entry about the issue.

I played around a bit with this. 

I've tried to keep as close as possible to the stop()/start() approach. 
My idea was:

- Add a boolean parameter to bsr_start()/bsr_stop that is true during restarts
- Create a bsr_restart() method that calls bsr_stop(true) and then bsr_start(true)
- In stop(true), instead deleting the whole _active_bsr_zone_list delete only the non-elected zones. For the elected zones, delete all groupprefix (which contains the rps).
- In start(true) it will reuse the existing elected zone and add all configured groupprefix (and rps)
- In start(true), check if any elected zone was deleted from config and vanish them.
- After that, I put the elected zones back in the PENDING state and expire the bsr timer. The timer will put it back in the ELECTED state, compute the rp-set and send BSR Messages with the new rp-set.

In my tests it seems to work fine.
I'm sending the patch attached.

Can you have a look on it and check if I've forgotten something?


Regards,

 - Samuel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-BSR-restart-without-losing-BSR-Elected-state.patch
Type: text/x-diff
Size: 17744 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081029/57932e3f/attachment.bin 

From pavlin at ICSI.Berkeley.EDU  Wed Oct 29 17:01:23 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Wed, 29 Oct 2008 17:01:23 -0700
Subject: [Xorp-hackers] BSR Restart
In-Reply-To: <49086A1E.8080107@datacom.ind.br> 
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
	<200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
	<49063A15.4030202@datacom.ind.br>
	<200810280058.m9S0wrOd010897@fruitcake.ICSI.Berkeley.EDU>
	<49086A1E.8080107@datacom.ind.br>
Message-ID: <200810300001.m9U01NRQ003865@fruitcake.ICSI.Berkeley.EDU>

An embedded and charset-unspecified text was scrubbed...
Name: pim_bsr.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081029/f73a2009/attachment.ksh 

From pavlin at ICSI.Berkeley.EDU  Wed Oct 29 18:01:42 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Wed, 29 Oct 2008 18:01:42 -0700
Subject: [Xorp-hackers] Bug report.
In-Reply-To: <56f9e0990810282312q35807459r1310ae268a6b14ca@mail.gmail.com> 
References: <56f9e0990810282312q35807459r1310ae268a6b14ca@mail.gmail.com>
Message-ID: <200810300101.m9U11gtf012287@fruitcake.ICSI.Berkeley.EDU>

I agree the "show" output doesn't look right.
[BTW, after the change is committed the "show" output looks normal.]
Though, from your fix it looks like the "for ..." loop is not
needed at all, and it should be replaced with:

    result = "\"" + value + "\"";
    return result;

Please submit a Bugzilla entry so the issue can be tracked and
the fix can be tested properly.

Thanks,
Pavlin

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

>      when you entry a "xxx xxxx" value into txt node. The xorpsh will
> pass it. But when you use show -all in CLI, the information in your
> screen is wrong. Apparently, text should not be "\"abc cba\"".
> 
> exp:
> yxs at Lenny621# set vlans interface 312 text "abc cba"
> yxs at Lenny621# show
>     vlans {
>         interface 312 {
> >           text: "\"abc cba\""
>         }
>     }
> 
> BUG FIXED:
> string
> ConfigTreeNode::quoted_value(const string& value) const
> {
>     string result;
>     ...
> 	if (x == '"')
> >	    escaped += "\\\""; //should be escaped += "";
> 	else
> 	    escaped += x;
>     ...
>     return result;
> }
> 
> 
> B.R.
> Xiaoshuai Yang
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From yj_00 at mail.sdu.edu.cn  Wed Oct 29 19:30:39 2008
From: yj_00 at mail.sdu.edu.cn (=?gb2312?B?1Ky+6g==?=)
Date: Thu, 30 Oct 2008 10:30:39 +0800
Subject: [Xorp-hackers] question
Message-ID: <425333839.20668@mail.sdu.edu.cn>

Hi,
I want to add a new command ,so I would like to refer your method about
command-line parameters. But I do not know the files you put which
directory.Couldyou give me some tips?

thanks a lot
Juan Yuan



From eshe168 at gmail.com  Wed Oct 29 21:17:16 2008
From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=)
Date: Thu, 30 Oct 2008 12:17:16 +0800
Subject: [Xorp-hackers] Bug report.
In-Reply-To: <200810300101.m9U11gtf012287@fruitcake.ICSI.Berkeley.EDU>
References: <56f9e0990810282312q35807459r1310ae268a6b14ca@mail.gmail.com>
	<200810300101.m9U11gtf012287@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <56f9e0990810292117q5c4f2bf6oe8af893676248da5@mail.gmail.com>

OK, i have submit it.

Bug number is 806.


From xorp2008 at yahoo.com.cn  Thu Oct 30 01:26:33 2008
From: xorp2008 at yahoo.com.cn (=?gb2312?q?=D6=DC=BD=DC?=)
Date: Thu, 30 Oct 2008 16:26:33 +0800 (CST)
Subject: [Xorp-hackers] how to add a new command into XORP
Message-ID: <534880.49807.qm@web15101.mail.cnb.yahoo.com>

  Hi ,XORP,
   
   I am working to add a new process to Xorp. 
  However, now ,I want to know how to add a
  new command into xorp.
  could someone help me?
  thank you very much!!


       
---------------------------------
 ????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20081030/1344e9ab/attachment-0001.html 

From samuellucas at datacom.ind.br  Thu Oct 30 05:22:19 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Thu, 30 Oct 2008 10:22:19 -0200
Subject: [Xorp-hackers] how to add a new command into XORP
In-Reply-To: <534880.49807.qm@web15101.mail.cnb.yahoo.com>
References: <534880.49807.qm@web15101.mail.cnb.yahoo.com>
Message-ID: <4909A6FB.2060801@datacom.ind.br>

?? wrote:
> 
>     Hi ,XORP,
>      
>      I am working to add a new process to Xorp.
>     However, now ,I want to know how to add a
>     new command into xorp.
>     could someone help me?
>     thank you very much!!
> 

Hi ??,

Take a look in etc/templates/*.cmds files. They define the commands that xorpsh issues. These commands are sent to the target process by send_cli_processor_xrl, where they should be handled by the implementation of cli_processor.xif interface.

Regards,

 - Samuel



From samuellucas at datacom.ind.br  Thu Oct 30 06:16:42 2008
From: samuellucas at datacom.ind.br (Samuel Lucas Vaz de Mello)
Date: Thu, 30 Oct 2008 11:16:42 -0200
Subject: [Xorp-hackers] BSR Restart
In-Reply-To: <200810300001.m9U01NRQ003865@fruitcake.ICSI.Berkeley.EDU>
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
	<200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
	<49063A15.4030202@datacom.ind.br>
	<200810280058.m9S0wrOd010897@fruitcake.ICSI.Berkeley.EDU>
	<49086A1E.8080107@datacom.ind.br>
	<200810300001.m9U01NRQ003865@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <4909B3BA.1050208@datacom.ind.br>

Pavlin Radoslavov wrote:
> However, I have to admit that I didn't look into the details of what
> you are doing when the BSR is restarted, so I cannot comment whether
> it is the right thing or whether something is missing.
> I intend to do this in the future, but unfortunately I cannot do
> this right now (see below).
> 
> Currently we are in the process of code freeze, so I am afraid
> this fix has to wait (strictly speaking it is an
> optimization so it is not critical).
> In the mean time please have a look in my refactoring of your patch
> in case I messed-up something.. If it is OK for you and if it works,
> please create a Bugzilla entry about the issue, and add that patch
> to the entry. Thus we can track its status, update the patch, etc.

I think we need also the rest of bsr_stop(), the parts that sends the Cand-RP-Adv with zero holdtime and BSR Message with lowest priority if i'm not the elected bsr for the zone. This is needed to keep the current behavior for non-elected zones, but would duplicate the whole code, that's why I choosed to change bsr_start()/bsr_stop().

As this patch is target for the next version, maybe we should try a more intrusive approach making the configuration commands change also the active state and get rid of the restarts.

How long will the code freeze last? What is the release schedule for Xorp 1.6?

Regards,

 - Samuel


From pavlin at ICSI.Berkeley.EDU  Thu Oct 30 09:27:22 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 30 Oct 2008 09:27:22 -0700
Subject: [Xorp-hackers] how to add a new command into XORP
In-Reply-To: <4909A6FB.2060801@datacom.ind.br> 
References: <534880.49807.qm@web15101.mail.cnb.yahoo.com>
	<4909A6FB.2060801@datacom.ind.br>
Message-ID: <200810301627.m9UGRM0b002613@fruitcake.ICSI.Berkeley.EDU>

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> ?? wrote:
> > 
> >     Hi ,XORP,
> >      
> >      I am working to add a new process to Xorp.
> >     However, now ,I want to know how to add a
> >     new command into xorp.
> >     could someone help me?
> >     thank you very much!!
> > 
> 
> Hi ??,
> 
> Take a look in etc/templates/*.cmds files. They define the commands that xorpsh issues. These commands are sent to the target process by send_cli_processor_xrl, where they should be handled by the implementation of cli_processor.xif interface.

Small clarification:
Che send_cli_processor_xrl mechanism is a wrapper for (mostly) the
multicast-related "show" commands, and that mechanism will disappear
in the future. You should have your own program(s) handling the "show"
commands, and should not rely on the send_cli_processor_xrl program.

Pavlin


> Regards,
> 
>  - Samuel
> 
> 
> _______________________________________________
> 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 Oct 30 09:55:48 2008
From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov)
Date: Thu, 30 Oct 2008 09:55:48 -0700
Subject: [Xorp-hackers] BSR Restart
In-Reply-To: <4909B3BA.1050208@datacom.ind.br> 
References: <48FFA211.4070406@datacom.ind.br>
	<200810230057.m9N0vRsv019500@fruitcake.ICSI.Berkeley.EDU>
	<200810230741.m9N7fwFZ002600@fruitcake.ICSI.Berkeley.EDU>
	<4900B0FC.4050801@datacom.ind.br>
	<200810240016.m9O0GfwA009647@fruitcake.ICSI.Berkeley.EDU>
	<490207B7.9050900@datacom.ind.br>
	<200810250017.m9P0GVsF027687@fruitcake.ICSI.Berkeley.EDU>
	<49063A15.4030202@datacom.ind.br>
	<200810280058.m9S0wrOd010897@fruitcake.ICSI.Berkeley.EDU>
	<49086A1E.8080107@datacom.ind.br>
	<200810300001.m9U01NRQ003865@fruitcake.ICSI.Berkeley.EDU>
	<4909B3BA.1050208@datacom.ind.br>
Message-ID: <200810301655.m9UGtmwk007829@fruitcake.ICSI.Berkeley.EDU>

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> Pavlin Radoslavov wrote:
> > However, I have to admit that I didn't look into the details of what
> > you are doing when the BSR is restarted, so I cannot comment whether
> > it is the right thing or whether something is missing.
> > I intend to do this in the future, but unfortunately I cannot do
> > this right now (see below).
> > 
> > Currently we are in the process of code freeze, so I am afraid
> > this fix has to wait (strictly speaking it is an
> > optimization so it is not critical).
> > In the mean time please have a look in my refactoring of your patch
> > in case I messed-up something.. If it is OK for you and if it works,
> > please create a Bugzilla entry about the issue, and add that patch
> > to the entry. Thus we can track its status, update the patch, etc.
> 
> I think we need also the rest of bsr_stop(), the parts that sends the Cand-RP-Adv with zero holdtime and BSR Message with lowest priority if i'm not the elected bsr for the zone. This is needed to keep the current behavior for non-elected zones, but would duplicate the whole code, that's why I choosed to change bsr_start()/bsr_stop().

I see. In that case we might have to move the whole "for ..." block
in PimBsr::stop() to a new method, and then just use that method
where necessary.

> As this patch is target for the next version, maybe we should try a more intrusive approach making the configuration commands change also the active state and get rid of the restarts.
> 
> How long will the code freeze last? What is the release schedule for Xorp 1.6?

I cannot give you any concrete dates/timescales, but right now the
Q/A team are very close toward making a cut and start doing
lots of internal tests.
Hopefully very soon we will have a schedule on the Web site which
will answer your questions.

The BSR restart patch is not crystalized/polished yet, and it is a
notable change that could break things if not done right.
Hence we need to have a working and polished patch first before we
can consider it for inclusion.
In any case, the patch should go first to Bugzilla, so we can track
the issue, and all technical comments will be in one place.

Thanks,
Pavlin