From ss at comp.lancs.ac.uk  Fri Jun  3 04:06:22 2011
From: ss at comp.lancs.ac.uk (Steven Simpson)
Date: Fri, 03 Jun 2011 12:06:22 +0100
Subject: [Xorp-hackers] Async helper classes
Message-ID: <4DE8C02E.9010306@comp.lancs.ac.uk>

An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110603/b6d69956/attachment.html 

From ss at comp.lancs.ac.uk  Mon Jun  6 04:43:46 2011
From: ss at comp.lancs.ac.uk (Steven Simpson)
Date: Mon, 06 Jun 2011 12:43:46 +0100
Subject: [Xorp-hackers] Async helper classes
In-Reply-To: <4DE8C02E.9010306@comp.lancs.ac.uk>
References: <4DE8C02E.9010306@comp.lancs.ac.uk>
Message-ID: <4DECBD72.5070604@comp.lancs.ac.uk>

An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110606/1b4e6bab/attachment.html 

From ss at comp.lancs.ac.uk  Tue Jun  7 02:16:39 2011
From: ss at comp.lancs.ac.uk (ss at comp.lancs.ac.uk)
Date: Tue,  7 Jun 2011 10:16:39 +0100
Subject: [Xorp-hackers] [PATCH] Added helper classes for async responses.
In-Reply-To: <4DECBD72.5070604@comp.lancs.ac.uk>
References: <4DECBD72.5070604@comp.lancs.ac.uk>
Message-ID: <1307438199-2388-1-git-send-email-ss@comp.lancs.ac.uk>

From: Steven Simpson <ss at comp.lancs.ac.uk>

* Renamed generated callback function type *CB to *RF (for Response
  Function).

* tgt-gen creates *CB class (constructed from *RF) which offers
  respond(out-args) and fail(error) methods mapping onto *RF calls,
  and retains ->dispatch method for compatibility.  The name *CB
  continues to be used in method signatures (like each async_*
  function), so the new *CB class replaces the old *CB typedef.

* tgt-gen also generates *Rsp class as argument-holding version of
  *CB.  Not used in any generated signatures, but available to user.

Signed-off-by: Steven Simpson <ss at comp.lancs.ac.uk>
---
 xorp/xrl/scripts/tgt-gen |   75 ++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/xorp/xrl/scripts/tgt-gen b/xorp/xrl/scripts/tgt-gen
index acc2f3c..2998810 100755
--- a/xorp/xrl/scripts/tgt-gen
+++ b/xorp/xrl/scripts/tgt-gen
@@ -133,9 +133,80 @@ def target_virtual_fns(methods):
         r += "    XorpCallback%s<void, const XrlCmdError &" % (len(x.rargs()) + 1)
         for a in x.rargs():
             r += ",\n%sconst %s*" % (xorp_indent(2), a.cpp_type())
-        r += ">::RefPtr\n    %sCB;\n" % (caps_cpp_classname(x.name()))
+        r += ">::RefPtr\n    %sRF;\n\n" % (caps_cpp_classname(x.name()))
 
 
+        r += "    class %sCB {\n" % (caps_cpp_classname(x.name()))
+        r += "        %sRF cb;\n\n" % (caps_cpp_classname(x.name()))
+        r += "    public:\n"
+        r += "        operator const %sRF& () const { return cb; }\n" \
+            % (caps_cpp_classname(x.name()))
+        r += "        const %sRF& operator ->() const { return cb; }\n" \
+            % (caps_cpp_classname(x.name()))
+
+        r += "        %sCB(const %sRF& cb)\n" \
+            % (caps_cpp_classname(x.name()), caps_cpp_classname(x.name()))
+        r += "          : cb(cb) { }\n\n"
+
+        r += "        void fail(const XrlCmdError &e)"
+        r += " const { cb->dispatch(e"
+        for a in x.rargs():
+            r += ", NULL"
+        r += "); }\n\n"
+
+        r += "        void respond("
+        sep = ""
+        for a in x.rargs():
+            r += sep
+            sep = ",\n                     "
+            r += "const %s& arg_%s" \
+                % (a.cpp_type(), cpp_name(a.name()))
+        r += ") const {\n"
+        r += "            cb->dispatch(XrlCmdError::OKAY()"
+        for a in x.rargs():
+            r += ",\n                         &arg_%s" \
+                % (cpp_name(a.name()))
+        r += ");\n"
+        r += "        }\n"
+
+        r += "    };\n\n"
+
+
+
+        r += "    struct %sRsp :\n      public %sCB {\n" \
+            % (caps_cpp_classname(x.name()), caps_cpp_classname(x.name()))
+        if x.rargs():
+            r += "        struct args_str {\n"
+            for a in x.rargs():
+                r += "            %s %s;\n" \
+                    % (a.cpp_type(), cpp_name(a.name()))
+            r += "        };\n"
+            r += "\n    private:\n"
+            r += "        args_str args;\n"
+            r += "\n    public:\n"
+
+        r += "        %sRsp(const %sRF& cb)\n" \
+            % (caps_cpp_classname(x.name()), caps_cpp_classname(x.name()))
+        r += "          : %sCB(cb)" % (caps_cpp_classname(x.name()))
+        r += " { }\n\n"
+
+        if x.rargs():
+            r += "        void respond() const {\n"
+            r += "            %sCB::\n" % (caps_cpp_classname(x.name()))
+            r += "            respond("
+            sep = ""
+            for a in x.rargs():
+                r += sep;
+                sep = ",\n                        "
+                r += "args.%s" % (cpp_name(a.name()))
+            r += ");\n"
+            r += "        }\n\n"
+            r += "        args_str* operator ->() {\n"
+            r += "            return &args;\n"
+            r += "        }\n"
+
+        r += "    };\n\n"
+
 
         r += "    virtual void async_%s\n       (" \
             % cpp_name(x.name())
@@ -297,7 +368,7 @@ def target_handler_methods(cls, name, methods):
 
         s += xorp_indent(1) + "try {\n"
         s += xorp_indent(2) + \
-            "%sCB mycb =\n%scallback(this, &%s::callback_%s, pxa_outputs);\n" \
+            "%sRF mycb =\n%scallback(this, &%s::callback_%s, pxa_outputs);\n" \
             % (caps_cpp_classname(m.name()), xorp_indent(3), \
                    cls, cpp_name(m.name()))
 
-- 
1.7.0.4


From 43026437 at qq.com  Fri Jun 10 20:26:45 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Sat, 11 Jun 2011 11:26:45 +0800
Subject: [Xorp-hackers] firewall do not work.
Message-ID: <tencent_3D4910EF421C5D3C0E31C33D@qq.com>

dear Steven Simpson:
 when I install xorp 1.8.3,configure firewall,but it not work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110611/0f05a7ee/attachment.html 

From 43026437 at qq.com  Fri Jun 10 20:43:38 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Sat, 11 Jun 2011 11:43:38 +0800
Subject: [Xorp-hackers] firewall do not work
Message-ID: <tencent_5B1B107E22311624431B2E8E@qq.com>

when I install xorp 1.8.3,configure firewall,but it not work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110611/16e91a25/attachment.html 

From greearb at candelatech.com  Fri Jun 10 21:01:37 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Jun 2011 21:01:37 -0700
Subject: [Xorp-hackers] firewall do not work
In-Reply-To: <tencent_5B1B107E22311624431B2E8E@qq.com>
References: <tencent_5B1B107E22311624431B2E8E@qq.com>
Message-ID: <4DF2E8A1.7070006@candelatech.com>

On 06/10/2011 08:43 PM, wxh585 wrote:
> when I install xorp 1.8.3,configure firewall,but it not work.

Check the messages during the scons configure, it gives a hint on
how to enable building firewall (on Linux), at least.  You have
to edit some linux header files.

I've no idea if it actually works though.

Patches welcome if you get it working.

Thanks,
Ben

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


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


From phugg at crc.ca  Mon Jun 13 13:01:13 2011
From: phugg at crc.ca (Philip Hugg)
Date: Mon, 13 Jun 2011 16:01:13 -0400
Subject: [Xorp-hackers]  Some fixes to OLSR (topology.cc)
Message-ID: <4DF66C89.9090806@crc.ca>

Hello Ben /all

I have attached the modified file 'topology.cc' that contains the 
changes I've made
in the attempt to make OLSR more stable. Unfortunately, there are still 
problems
with the OLSR but at least we are one step closer.

Tested Topologies:

     1)  9 nodes inline (wireless)
             n9 - n8 - n7 - n6 - n1 - n2 - n3 - n4 - n5


     2) 16 nodes, in 4x4 grid (wireless)

             n1 - n2 - n3 - n4
             n5 - n6 - n7 - n8
             n9 - 10 - 11 - 12
             13 - 14 - 15 - 16

             where,  N1 is nei with N2, n5, n6,
                           N2 is nei with n1,n3,n5,n6,n7
                           N3 is nei with N2,n4,n6,n7,n8
                           ...
                           N16 is nei with n11, n12, n15.

             Topology is stable however a ping from N1 to N16 may not 
take the shortest path
             (n1-n6-n11-n16) which is 3 hops. Instead, it may follow 
path from N1-N2-N7-N12-N16 (4-hops?).
             When I re-issue the ping many times, it may take a 
different paths.

         3) Mobility test: 9 nodes inline (as above).
             When moving N9 from N8 to N7 until we get

                         N9
                          |
                 N8 - N7 - N6 - N1 ...

                 In this case, OLSR asserts.

These are some of the scenarios I used to find the bugs. However, I was 
pulled off
this work and assigned something else. I just thought I would contribute 
my findings
if anyone want to continue.


Phil.



-- 
Phil Hugg



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: topology.cc
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110613/146038b2/attachment-0002.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: topology.diff
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110613/146038b2/attachment-0003.ksh 

From greearb at candelatech.com  Mon Jun 13 13:53:21 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 13 Jun 2011 13:53:21 -0700
Subject: [Xorp-hackers] Some fixes to OLSR (topology.cc)
In-Reply-To: <4DF66C89.9090806@crc.ca>
References: <4DF66C89.9090806@crc.ca>
Message-ID: <4DF678C1.5060206@candelatech.com>

On 06/13/2011 01:01 PM, Philip Hugg wrote:
> Hello Ben /all
>
> I have attached the modified file 'topology.cc' that contains the
> changes I've made
> in the attempt to make OLSR more stable. Unfortunately, there are still
> problems
> with the OLSR but at least we are one step closer.
>
> Tested Topologies:
>
> 1) 9 nodes inline (wireless)
> n9 - n8 - n7 - n6 - n1 - n2 - n3 - n4 - n5
>
>
> 2) 16 nodes, in 4x4 grid (wireless)
>
> n1 - n2 - n3 - n4
> n5 - n6 - n7 - n8
> n9 - 10 - 11 - 12
> 13 - 14 - 15 - 16
>
> where, N1 is nei with N2, n5, n6,
> N2 is nei with n1,n3,n5,n6,n7
> N3 is nei with N2,n4,n6,n7,n8
> ...
> N16 is nei with n11, n12, n15.
>
> Topology is stable however a ping from N1 to N16 may not take the
> shortest path
> (n1-n6-n11-n16) which is 3 hops. Instead, it may follow path from
> N1-N2-N7-N12-N16 (4-hops?).
> When I re-issue the ping many times, it may take a different paths.

I'm not sure how OLSR is supposed to work exactly, but that does
sound buggy.  Could you open a bug with that test case and results?

>
> 3) Mobility test: 9 nodes inline (as above).
> When moving N9 from N8 to N7 until we get
>
> N9
> |
> N8 - N7 - N6 - N1 ...
>
> In this case, OLSR asserts.

Can you open a bug with the test case and assert message?  Might help the
next person to attempt this...

> These are some of the scenarios I used to find the bugs. However, I was
> pulled off
> this work and assigned something else. I just thought I would contribute
> my findings
> if anyone want to continue.

Thanks for the patch.

But, any chance you could generate a unified patch, ie: diff -u
or something like that?

That's a lot easier for me to read.

If you don't have time to open these bugs or generate a new diff,
let me know and I'll take care of it.

Thanks,
Ben

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


From phugg at crc.ca  Tue Jun 14 05:46:01 2011
From: phugg at crc.ca (Philip Hugg)
Date: Tue, 14 Jun 2011 08:46:01 -0400
Subject: [Xorp-hackers] Some fixes to OLSR (topology.cc)
In-Reply-To: <4DF678C1.5060206@candelatech.com>
References: <4DF66C89.9090806@crc.ca> <4DF678C1.5060206@candelatech.com>
Message-ID: <4DF75809.4080000@crc.ca>

On 13/06/2011 4:53 PM, Ben Greear wrote:
> On 06/13/2011 01:01 PM, Philip Hugg wrote:
>> Hello Ben /all
>>
>> I have attached the modified file 'topology.cc' that contains the
>> changes I've made
>> in the attempt to make OLSR more stable. Unfortunately, there are still
>> problems
>> with the OLSR but at least we are one step closer.
>>
>> Tested Topologies:
>>
>> 1) 9 nodes inline (wireless)
>> n9 - n8 - n7 - n6 - n1 - n2 - n3 - n4 - n5
>>
>>
>> 2) 16 nodes, in 4x4 grid (wireless)
>>
>> n1 - n2 - n3 - n4
>> n5 - n6 - n7 - n8
>> n9 - 10 - 11 - 12
>> 13 - 14 - 15 - 16
>>
>> where, N1 is nei with N2, n5, n6,
>> N2 is nei with n1,n3,n5,n6,n7
>> N3 is nei with N2,n4,n6,n7,n8
>> ...
>> N16 is nei with n11, n12, n15.
>>
>> Topology is stable however a ping from N1 to N16 may not take the
>> shortest path
>> (n1-n6-n11-n16) which is 3 hops. Instead, it may follow path from
>> N1-N2-N7-N12-N16 (4-hops?).
>> When I re-issue the ping many times, it may take a different paths.
>
> I'm not sure how OLSR is supposed to work exactly, but that does
> sound buggy.  Could you open a bug with that test case and results?
>
>>
>> 3) Mobility test: 9 nodes inline (as above).
>> When moving N9 from N8 to N7 until we get
>>
>> N9
>> |
>> N8 - N7 - N6 - N1 ...
>>
>> In this case, OLSR asserts.
>
> Can you open a bug with the test case and assert message?  Might help the
> next person to attempt this...
>
>> These are some of the scenarios I used to find the bugs. However, I was
>> pulled off
>> this work and assigned something else. I just thought I would contribute
>> my findings
>> if anyone want to continue.
>
> Thanks for the patch.
>
> But, any chance you could generate a unified patch, ie: diff -u
> or something like that?
>
> That's a lot easier for me to read.
>
> If you don't have time to open these bugs or generate a new diff,
> let me know and I'll take care of it.
>
> Thanks,
> Ben
>
I've included file 'topology.cc.patch'. Generated by
'diff -uEw modified  original > topology.cc.patch'.
Is this OK?

I will issue a bug report for the above.

Phil.

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

From greearb at candelatech.com  Tue Jun 14 09:29:17 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 14 Jun 2011 09:29:17 -0700
Subject: [Xorp-hackers] Some fixes to OLSR (topology.cc)
In-Reply-To: <4DF75809.4080000@crc.ca>
References: <4DF66C89.9090806@crc.ca> <4DF678C1.5060206@candelatech.com>
	<4DF75809.4080000@crc.ca>
Message-ID: <4DF78C5D.7000700@candelatech.com>

On 06/14/2011 05:46 AM, Philip Hugg wrote:

> I've included file 'topology.cc.patch'. Generated by
> 'diff -uEw modified original > topology.cc.patch'.
> Is this OK?

You should put the original first to generate a proper patch,
but I can fix that manually in this case.

If you remember, can you describe what this fix fixes?

Thanks,
Ben


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


From phugg at crc.ca  Tue Jun 14 11:12:28 2011
From: phugg at crc.ca (Philip Hugg)
Date: Tue, 14 Jun 2011 14:12:28 -0400
Subject: [Xorp-hackers] Some fixes to OLSR (topology.cc)
In-Reply-To: <4DF78C5D.7000700@candelatech.com>
References: <4DF66C89.9090806@crc.ca> <4DF678C1.5060206@candelatech.com>
	<4DF75809.4080000@crc.ca> <4DF78C5D.7000700@candelatech.com>
Message-ID: <4DF7A48C.1050007@crc.ca>

On 14/06/2011 12:29 PM, Ben Greear wrote:
> On 06/14/2011 05:46 AM, Philip Hugg wrote:
>
>> I've included file 'topology.cc.patch'. Generated by
>> 'diff -uEw modified original > topology.cc.patch'.
>> Is this OK?
>
> You should put the original first to generate a proper patch,
> but I can fix that manually in this case.
>
> If you remember, can you describe what this fix fixes?
>
> Thanks,
> Ben
>
>
Ben,

Sorry about the patch file.

The modifications generally fixes and stabilizes the entries in the 
OLSR's topology information base.

Fix 1-  File -> topology.cc, method-> update_tc_entry(...).
This was a programmatic fix. The code would find and set 'is_found = 
true' on an entry that really
didn't exist. The modification now does a more precise check of the entry.

Fix 2- method -> apply_tc_ansn(...)
This was an RFC fix. This seemed to have been forgotten during 
implementation. See RFC section 9.5,
paragraphs 2 and 3.

I hope this helps!
Phil.



From greearb at candelatech.com  Thu Jun 16 12:16:58 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 16 Jun 2011 12:16:58 -0700
Subject: [Xorp-hackers] Xorp release status
Message-ID: <4DFA56AA.6020700@candelatech.com>

Hello!

Just a quick heads-up on near-term xorp plans.

There are several fairly important fixes since the last release, so
I plan to commit the few outstanding patches posted recently to
the mailing list, let that cook for a week or two, and do a release.

Due to internal release schedules, I am holding off on applying the
pending changes until towards the end of next week.

Please let me know if you have any questions or suggestions.

Thanks,
Ben

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


From ss at comp.lancs.ac.uk  Fri Jun 17 04:24:48 2011
From: ss at comp.lancs.ac.uk (Steven Simpson)
Date: Fri, 17 Jun 2011 12:24:48 +0100
Subject: [Xorp-hackers] Uncatchable exceptions
Message-ID: <4DFB3980.4050201@comp.lancs.ac.uk>

An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110617/1bb447f8/attachment.html 

From greearb at candelatech.com  Fri Jun 17 08:39:33 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 17 Jun 2011 08:39:33 -0700
Subject: [Xorp-hackers] Uncatchable exceptions
In-Reply-To: <4DFB3980.4050201@comp.lancs.ac.uk>
References: <4DFB3980.4050201@comp.lancs.ac.uk>
Message-ID: <4DFB7535.9060405@candelatech.com>

On 06/17/2011 04:24 AM, Steven Simpson wrote:
> Hi Ben,
>
> I've just been struggling with C++'s rather slack exception system.  I was doing this:

I really hate C++ exceptions, and don't know how to use them well.

In general, I'd welcome code that removed exceptions and used error
return values instead to deal with error conditions.  That is liable
to be a lot of changes, but perhaps some pieces of code could be cleaned
up at a time.

For your particular issue, I'd do whatever is simplest unless you feel
like doing more serious exception removal work.

Thanks,
Ben


>
>    const XrlArgs&  in; // a parameter
>
>    try {
>      uint32_t delay;
>      in.get("boo_delay", delay);
>      ...
>    } catch (const XrlArgs:XrlAtomNotFound&  e) {
>      // Get other arguments.
>    }
>
> So obviously I was getting XrlAtomNotFound exceptions that were killing the process, and I added the try-catch to intercept them - but it wasn't working.
> Traces showed that the exception was certainly happening on [in.get], but the catch block never executed.
>
> The method I'm calling doesn't declare the exception I'm trying to catch:
>
>      void get(const char* n, uint32_t&  t) const throw (BadArgs);
>
> That method calls this one:
>
> const uint32_t&
> XrlArgs::get_uint32(const char* name) const throw (BadArgs)
> {
>      try {
> 	return get(XrlAtom(name, xrlatom_uint32)).uint32();
>      } catch (const XrlAtom::NoData&  e) {
>          xorp_throw(BadArgs, e.why());
>      } catch (const XrlAtom::WrongType&  e) {
>          xorp_throw(BadArgs, e.why());
>      }
> }
>
> ?and you can see that that code calls get(const XrlAtom&), which is declared to throw XrlAtomNotFound.  But get_uint32 doesn't catch that exception itself.
> According to this (under "Exception Specifications"):
>
> <http://4thmouse.com/mystuff/articles/UsingExceptionsEffectively.html>
>
> ?the uncaught exception simply terminates the program immediately; not even an unwinding of the stack, it seems!
>
> Two possible solutions are obvious: either propagate the declaration of XrlAtomNotFound, or catch it in this and related functions, and throw a BadArgs
> instead.  I suppose the latter would be much less disruptive.
>
> Incidentally, if the [get] call inside get_uint32 can only throw XrlAtomNotFound, can either of the existing catch clauses ever execute?
>
> Cheers,
>
> Steven
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


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


From 43026437 at qq.com  Sat Jun 25 17:50:54 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Sun, 26 Jun 2011 08:50:54 +0800
Subject: [Xorp-hackers] which hardware suport 10G interface for xorp ?
Message-ID: <tencent_45FE31DF3E9575BE69CBB0F9@qq.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110626/ecd6eb4f/attachment.html 

From greearb at candelatech.com  Sat Jun 25 22:31:53 2011
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 25 Jun 2011 22:31:53 -0700
Subject: [Xorp-hackers] which hardware suport 10G interface for xorp ?
In-Reply-To: <tencent_45FE31DF3E9575BE69CBB0F9@qq.com>
References: <tencent_45FE31DF3E9575BE69CBB0F9@qq.com>
Message-ID: <4E06C449.9080402@candelatech.com>

On 06/25/2011 05:50 PM, wxh585 wrote:
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

Intel 10G NICs work well.  Any Ethernet interface supported by
your operating system should also be supported by xorp.

Thanks,
Ben

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


From 43026437 at qq.com  Sun Jun 26 01:34:02 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Sun, 26 Jun 2011 16:34:02 +0800
Subject: [Xorp-hackers] vrrp is not work on freebsd 7.3
Message-ID: <tencent_2EE31F8F29217A047EED4B88@qq.com>

dear Ben Greear
 I configure flow,but it is not work
 admin at a.f# show -all
    protocols {
        vrrp {
            interface rl1 {
                vif rl1 {
                    vrid 1 {
                        priority: 2
                        interval: 1
                        preempt: true
                        ip 192.168.1.1 {
                            prefix-length: 24
                        }
                        disable: false
                    }
                }
            }
            interface rl2 {
                vif rl2 {
                    vrid 1 {
                        priority: 100
                        interval: 1
                        preempt: true
                        ip 192.168.1.1 {
                            prefix-length: 24
                        }
                        disable: false
                    }
                }
            }
        }
    }
 [edit]
 --More-- (END)
admin at a.f# quit
admin at a.f> show version
Version 1.8.3
admin at a.f> show vrrp
Interface       rl1
Vif             rl1
VRID            1
State           initialize
Master IP       0.0.0.0
 Interface       rl2
Vif             rl2
VRID            1
State           initialize
Master IP       0.0.0.0
admin at a.f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110626/e50db2b6/attachment.html 

From greearb at candelatech.com  Sun Jun 26 10:32:27 2011
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 26 Jun 2011 10:32:27 -0700
Subject: [Xorp-hackers] vrrp is not work on freebsd 7.3
In-Reply-To: <tencent_2EE31F8F29217A047EED4B88@qq.com>
References: <tencent_2EE31F8F29217A047EED4B88@qq.com>
Message-ID: <4E076D2B.1000702@candelatech.com>

On 06/26/2011 01:34 AM, wxh585 wrote:
> /dear Ben Greear/
> I configure flow,but it is not work

Can you try it on Linux?  I tested VRRP on Linux and I think
it was working as designed.  It may require some extra hacking
to get it functional on BSD.

Thanks,
Ben

> admin at a.f <mailto:admin at a.f># show -all
> protocols {
> vrrp {
> interface rl1 {
> vif rl1 {
> vrid 1 {
> priority: 2
> interval: 1
> preempt: true
> ip 192.168.1.1 {
> prefix-length: 24
> }
> disable: false
> }
> }
> }
> interface rl2 {
> vif rl2 {
> vrid 1 {
> priority: 100
> interval: 1
> preempt: true
> ip 192.168.1.1 {
> prefix-length: 24
> }
> disable: false
> }
> }
> }
> }
> }
> [edit]
> --More-- (END)
> admin at a.f <mailto:admin at a.f># quit
> admin at a.f <mailto:admin at a.f>> show version
> Version 1.8.3
> admin at a.f <mailto:admin at a.f>> show vrrp
> Interface rl1
> Vif rl1
> VRID 1
> State initialize
> Master IP 0.0.0.0
> Interface rl2
> Vif rl2
> VRID 1
> State initialize
> Master IP 0.0.0.0
> admin at a.f <mailto:admin at a.f>>
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


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


From 43026437 at qq.com  Mon Jun 27 00:51:18 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Mon, 27 Jun 2011 15:51:18 +0800
Subject: [Xorp-hackers] vrrp is not work on linux kernel 2.6.36 ?
Message-ID: <tencent_4A5E6A8121E589A92CE8441E@qq.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110627/1c3da8d4/attachment.html 

From 43026437 at qq.com  Mon Jun 27 02:19:13 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Mon, 27 Jun 2011 17:19:13 +0800
Subject: [Xorp-hackers] ospf is not work ,when one of link break.
Message-ID: <tencent_6F6487BC7F500A3264D5333C@qq.com>

ospf is not work ,when one of link break.two link to another route on network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110627/e33acea2/attachment.html 

From 43026437 at qq.com  Mon Jun 27 04:57:07 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Mon, 27 Jun 2011 19:57:07 +0800
Subject: [Xorp-hackers] when fxpX is down and config ospf,
	xorp router is not start on system start.
Message-ID: <tencent_52DD43D3058EE2281296433F@qq.com>

when fxpX is down and config ospf,xorp router is not start on system start.when I put fxpX to switch ,it is work on system start.
 $ xorpsh
[ 2011/06/27 19:41:33.652298 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:33.756380 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:33.860619 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:33.964909 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.69197 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.173485 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.277773 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.382063 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.486352 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.590646 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.694939 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.799226 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:34.903513 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:35.7809 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:35.112094 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
[ 2011/06/27 19:41:35.216386 WARNING xorpsh LIBXORP ] read error: _fd: 25  offset: 0  total-len: 4 error: Connection refused
$ uname -a
FreeBSD r.d 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Mon Apr  4 10:34:12 UTC 2011     root at r.d:/usr/obj/usr/src/sys/GENERIC2  i386
$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110627/1e862c4a/attachment.html 

From 43026437 at qq.com  Mon Jun 27 05:03:44 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Mon, 27 Jun 2011 20:03:44 +0800
Subject: [Xorp-hackers] route is break ,when one of link break.
Message-ID: <tencent_68B8D88E24A256050A383C86@qq.com>

route is break ,when one of link break.
 xorp router ======swithch-------cisco router
 cisco router configure:
 !
interface FastEthernet0/0.1
 encapsulation dot1Q 101
 ip address 192.168.3.1 255.255.255.252
!
interface FastEthernet0/0.2
 encapsulation dot1Q 102
 ip address 192.168.3.5 255.255.255.252
!
interface FastEthernet0/1
 ip address 192.168.6.1 255.255.255.0
 duplex auto
 speed 100
!
router ospf 878
 router-id 192.168.6.1
 log-adjacency-changes
 network 192.168.3.0 0.0.0.7 area 0.0.0.0
 network 192.168.6.0 0.0.0.255 area 0.0.0.0
!
ip classless
ip http server
!
!
line con 0
line aux 0
line vty 0 4
 password 123456
 login
!
!
!
end
 Router#
 xorp router configure
 admin at r.d# show
    protocols {
        ospf4 {
            router-id: 192.168.1.1
            area 0.0.0.0 {
                area-range 192.168.1.0/24 {
                }
                area-range 192.168.3.0/29 {
                }
                interface fxp1 {
                    vif fxp1 {
                        address 192.168.3.6 {
                        }
                    }
                }
                interface bge0 {
                    vif bge0 {
                        address 192.168.3.2 {
                        }
                    }
                }
            }
            export: "a1"
        }
    }
    policy {
        policy-statement a1 {
            term a {
                from {
                    protocol: "connected"
                }
            }
        }
    }
    interfaces {
        interface bge0 {
            vif bge0 {
                address 192.168.3.2 {
                    prefix-length: 30
                }
            }
        }
        interface fxp0 {
            vif fxp0 {
                address 192.168.1.1 {
                    prefix-length: 24
                }
            }
        }
        interface fxp1 {
            vif fxp1 {
                address 192.168.3.6 {
                    prefix-length: 30
                }
            }
        }
    }
 [edit]
 --More-- (END) 
admin at r.d#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110627/c209898d/attachment.html 

From 43026437 at qq.com  Mon Jun 27 05:10:45 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Mon, 27 Jun 2011 20:10:45 +0800
Subject: [Xorp-hackers] ospf is not configured on linux.
Message-ID: <tencent_1FE4307654339DD026B77E3B@qq.com>

ospf is not configured on linux.after command "set protocols ospf4 export a1" is excuted,"Finder disconnected. No Finder?" is display
 admin at 55> configure 
Entering configuration mode.
User admin is also in configuration mode.
[edit]
admin at 55# quit
admin at 55> 
admin at 55> show version 
Version 1.8.3
admin at 55> show host os
Linux 55 2.6.36.4-dacheng #1 SMP Tue Mar 29 04:57:02 EDT 2011 i686 GNU/Linux
admin at 55> configure 
Entering configuration mode.
User admin is also in configuration mode.
[edit]
admin at 55# show 
    protocols {
        ospf4 {
            router-id: 192.168.1.1
            area 0.0.0.0 {
                area-range 192.168.3.0/29 {
                }
                area-range 192.168.1.0/24 {
                }
                interface eth2 {
                    vif eth2 {
                        address 192.168.3.2 {
                        }
                    }
                }
                interface eth4 {
                    vif eth2 {
                        address 192.168.3.6 {
                        }
                    }
                }
            }
        }
    }
    policy {
        policy-statement a1 {
            term a1 {
                from {
                    protocol: "connected"
                }
            }
        }
    }
    interfaces {
        interface eth2 {
            vif eth2 {
                address 192.168.3.2 {
                    prefix-length: 30
                }
            }
        }
        interface eth4 {
            vif eth4 {
                address 192.168.3.6 {
                    prefix-length: 30
                }
            }
        }
        interface eth3 {
            vif eth3 {
                address 192.168.1.1 {
                    prefix-length: 24
                }
            }
        }
    }
 [edit]
 --More-- (END) 
admin at 55#
admin at 55# set protocols ospf4 export a1
[edit]
admin at 55# commit 
OK
[edit]
admin at 55# Finder disconnected. No Finder?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110627/3ef55eca/attachment-0001.html 

From greearb at candelatech.com  Mon Jun 27 07:39:59 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 27 Jun 2011 07:39:59 -0700
Subject: [Xorp-hackers] vrrp is not work on linux kernel 2.6.36 ?
In-Reply-To: <tencent_4A5E6A8121E589A92CE8441E@qq.com>
References: <tencent_4A5E6A8121E589A92CE8441E@qq.com>
Message-ID: <4E08963F.6070004@candelatech.com>

On 06/27/2011 12:51 AM, wxh585 wrote:
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

You have to provide a lot more details about how it is not working if
you want me to put any effort into debugging it.

Thanks,
Ben

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


From 43026437 at qq.com  Tue Jun 28 04:03:20 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Tue, 28 Jun 2011 19:03:20 +0800
Subject: [Xorp-hackers] vrrp is not work on linux 2.6.36 ,like freebsd 7.3
Message-ID: <tencent_2F6C9F970E0671FB061C421C@qq.com>

> admin at a.f <mailto:admin at a.f># show -all > protocols {
> vrrp {
> interface eth1 {
> vif eth1 {
> vrid 1 {
> priority: 2
> interval: 1
> preempt: true
> ip 192.168.1.1 { > prefix-length: 24 > }
> disable: false
> }
> }
> }
> interface eth2 {
> vif eth2 {
> vrid 1 {
> priority: 100
> interval: 1
> preempt: true
> ip 192.168.1.1 {
> prefix-length: 24
> }
> disable: false
> }
> }
> }
> }
> }
> [edit]
> --More-- (END)
> admin at a.f <mailto:admin at a.f># quit
> admin at a.f <mailto:admin at a.f>> show version
> Version 1.8.3
> admin at a.f <mailto:admin at a.f>> show vrrp
> Interface eth1
> Vif eth1
> VRID 1
> State initialize
> Master IP 0.0.0.0
> Interface eth2
> Vif eth2
> VRID 1
> State initialize
> Master IP 0.0.0.0
> admin at a.f <mailto:admin at a.f>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110628/5eb1c763/attachment.html 

From greearb at candelatech.com  Wed Jun 29 10:13:14 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 29 Jun 2011 10:13:14 -0700
Subject: [Xorp-hackers] ospf is not configured on linux.
In-Reply-To: <tencent_1FE4307654339DD026B77E3B@qq.com>
References: <tencent_1FE4307654339DD026B77E3B@qq.com>
Message-ID: <4E0B5D2A.3000908@candelatech.com>

On 06/27/2011 05:10 AM, wxh585 wrote:
> ospf is not configured on linux.after command "set protocols ospf4
> export a1" is excuted,"Finder disconnected. No Finder?" is display
> admin at 55 <mailto:admin at 55>> configure
> Entering configuration mode.
> User admin is also in configuration mode.
> [edit]
> admin at 55 <mailto:admin at 55># quit
> admin at 55 <mailto:admin at 55>>
> admin at 55 <mailto:admin at 55>> show version
> Version 1.8.3
> admin at 55 <mailto:admin at 55>> show host os
> Linux 55 2.6.36.4-dacheng #1 SMP Tue Mar 29 04:57:02 EDT 2011 i686 GNU/Linux
> admin at 55 <mailto:admin at 55>> configure
> Entering configuration mode.
> User admin is also in configuration mode.
> [edit]
> admin at 55 <mailto:admin at 55># show
> protocols {
> ospf4 {
> router-id: 192.168.1.1
> area 0.0.0.0 {
> area-range 192.168.3.0/29 {
> }
> area-range 192.168.1.0/24 {
> }
> interface eth2 {
> vif eth2 {
> address 192.168.3.2 {
> }
> }
> }
> interface eth4 {
> vif eth2 {
> address 192.168.3.6 {
> }
> }
> }
> }
> }
> }
> policy {
> policy-statement a1 {
> term a1 {
> from {
> protocol: "connected"
> }
> }
> }
> }
> interfaces {
> interface eth2 {
> vif eth2 {
> address 192.168.3.2 {
> prefix-length: 30
> }
> }
> }
> interface eth4 {
> vif eth4 {
> address 192.168.3.6 {
> prefix-length: 30
> }
> }
> }
> interface eth3 {
> vif eth3 {
> address 192.168.1.1 {
> prefix-length: 24
> }
> }
> }
> }
> [edit]
> --More-- (END)
> admin at 55 <mailto:admin at 55>#
> admin at 55 <mailto:admin at 55># set protocols ospf4 export a1
> [edit]
> admin at 55 <mailto:admin at 55># commit
> OK
> [edit]
> admin at 55 <mailto:admin at 55># Finder disconnected. No Finder?

Looks like you crashed xorp-rtrmgr.  Can you check for core files
and the xorp-rtrmgr log file for asserts?  Note that you may have
to run 'ulimit -c unlimited' before starting xorp-rtrmgr
to enable core file creation.

If you find cores, please post backtrace using gdb.

And, please open a bug in the xorp bugzilla.  I'm busy with other things
at the moment, but if you can provide some of the requested information,
I may be able to put some effort into this sometime soon.

Thanks,
Ben

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


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


From greearb at candelatech.com  Wed Jun 29 10:16:19 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 29 Jun 2011 10:16:19 -0700
Subject: [Xorp-hackers] route is break ,when one of link break.
In-Reply-To: <tencent_68B8D88E24A256050A383C86@qq.com>
References: <tencent_68B8D88E24A256050A383C86@qq.com>
Message-ID: <4E0B5DE3.6050200@candelatech.com>

On 06/27/2011 05:03 AM, wxh585 wrote:
> route is break ,when one of link break.

Please show output of:

route -n
ifconfig -a

(or whatever is equivalent on your OS)

before and after the link breakage.


Does it happen for both links?

Do you see ospf neighbors still existing after link break?

Thanks,
Ben


> xorp router ======swithch-------cisco router
> cisco router configure:
> !
> interface FastEthernet0/0.1
> encapsulation dot1Q 101
> ip address 192.168.3.1 255.255.255.252
> !
> interface FastEthernet0/0.2
> encapsulation dot1Q 102
> ip address 192.168.3.5 255.255.255.252
> !
> interface FastEthernet0/1
> ip address 192.168.6.1 255.255.255.0
> duplex auto
> speed 100
> !
> router ospf 878
> router-id 192.168.6.1
> log-adjacency-changes
> network 192.168.3.0 0.0.0.7 area 0.0.0.0
> network 192.168.6.0 0.0.0.255 area 0.0.0.0
> !
> ip classless
> ip http server
> !
> !
> line con 0
> line aux 0
> line vty 0 4
> password 123456
> login
> !
> !
> !
> end
> Router#
> xorp router configure
> admin at r.d <mailto:admin at r.d># show
> protocols {
> ospf4 {
> router-id: 192.168.1.1
> area 0.0.0.0 {
> area-range 192.168.1.0/24 {
> }
> area-range 192.168.3.0/29 {
> }
> interface fxp1 {
> vif fxp1 {
> address 192.168.3.6 {
> }
> }
> }
> interface bge0 {
> vif bge0 {
> address 192.168.3.2 {
> }
> }
> }
> }
> export: "a1"
> }
> }
> policy {
> policy-statement a1 {
> term a {
> from {
> protocol: "connected"
> }
> }
> }
> }
> interfaces {
> interface bge0 {
> vif bge0 {
> address 192.168.3.2 {
> prefix-length: 30
> }
> }
> }
> interface fxp0 {
> vif fxp0 {
> address 192.168.1.1 {
> prefix-length: 24
> }
> }
> }
> interface fxp1 {
> vif fxp1 {
> address 192.168.3.6 {
> prefix-length: 30
> }
> }
> }
> }
> [edit]
> --More-- (END)
> admin at r.d <mailto:admin at r.d>#
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


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


From greearb at candelatech.com  Wed Jun 29 10:18:11 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 29 Jun 2011 10:18:11 -0700
Subject: [Xorp-hackers] when fxpX is down and config ospf,
 xorp router is not start on system start.
In-Reply-To: <tencent_52DD43D3058EE2281296433F@qq.com>
References: <tencent_52DD43D3058EE2281296433F@qq.com>
Message-ID: <4E0B5E53.8080904@candelatech.com>

On 06/27/2011 04:57 AM, wxh585 wrote:
> when fxpX is down and config ospf,xorp router is not start on system
> start.when I put fxpX to switch ,it is work on system start.

Is this with xorp 1.8.3, or the latest code from git?  I think I
fixed some problems in this area after 1.8.3 was released.

Thanks,
Ben

> $ xorpsh
> [ 2011/06/27 19:41:33.652298 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:33.756380 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:33.860619 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:33.964909 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.69197 WARNING xorpsh LIBXORP ] read error: _fd: 25
> offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.173485 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.277773 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.382063 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.486352 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.590646 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.694939 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.799226 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:34.903513 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:35.7809 WARNING xorpsh LIBXORP ] read error: _fd: 25
> offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:35.112094 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> [ 2011/06/27 19:41:35.216386 WARNING xorpsh LIBXORP ] read error: _fd:
> 25 offset: 0 total-len: 4 error: Connection refused
> $ uname -a
> FreeBSD r.d 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Mon Apr 4 10:34:12 UTC
> 2011 root at r.d:/usr/obj/usr/src/sys/GENERIC2
> <mailto:root at r.d:/usr/obj/usr/src/sys/GENERIC2> i386
> $
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


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


From doi at criepi.denken.or.jp  Wed Jun 29 22:21:27 2011
From: doi at criepi.denken.or.jp (=?iso-2022-jp?B?GyRCRVowZhsoQiAbJEJHbkA4GyhC?=)
Date: Thu, 30 Jun 2011 14:21:27 +0900
Subject: [Xorp-hackers] Where can I get the raw packet?
Message-ID: <EA1D5A7F-3EAC-4A73-8D26-D3AB9E52C598@criepi.denken.or.jp>

I am a Japanese xorp user and a newbie xorp hacker :).

Now, I test a OSPF routing on xorp 1.8.3 with a simple network. 

(Linux box A, ubuntu 11.04, OSPF) <----> (Linux box B, ubuntu 11.04, OSPF)

At first, I try to understand the packet flow inside xorp.
So, I read the source code fea/data_plane/io/io_ip_socket.cc
I guessed that the routine proto_socket_read() receives the raw packets.
Although I can capture OSPF related packets (Hello, DB, LSA) in proto_socket_read() on Linux box A, I cannot capture the other packets (ping packets or ARP) when I send ping packets from Linux box B to Linux box A .
Also I guess that xorp has another routine to receive raw packets and filters the raw packets and send to  proto_socket_read().

Please suggest me the routine which receives the raw packet at first.
I would like to understand the packet flow from first.

Thank you for your kindness and efforts.
Hiroki Doi


From 43026437 at qq.com  Thu Jun 30 06:04:45 2011
From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=)
Date: Thu, 30 Jun 2011 21:04:45 +0800
Subject: [Xorp-hackers] route is break ,when one of link break.
Message-ID: <tencent_6EE4AB9E76E1C8C846D00ADA@qq.com>

xorp router ======switch------cisco router
 when one of link is breakage,link online is not "ping",
 cisco router configure:
 interface FastEthernet0/0
 no ip address
 duplex auto
 speed 100
!
interface FastEthernet0/0.1
 encapsulation dot1Q 101
 ip address 192.168.3.1 255.255.255.252
!
interface FastEthernet0/0.2
 encapsulation dot1Q 102
 ip address 192.168.3.5 255.255.255.252
!
interface FastEthernet0/1
 ip address 192.168.6.1 255.255.255.0
 duplex auto
 speed 100
!
router ospf 878
 router-id 192.168.6.1
 log-adjacency-changes
 network 192.168.3.0 0.0.0.7 area 0.0.0.0
 network 192.168.6.0 0.0.0.255 area 0.0.0.0
!
  
 before the link breakage.
 $ ifconfig
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:10:18:14:55:17
        inet 192.168.3.6 netmask 0xfffffffc broadcast 192.168.3.7
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9<RXCSUM,VLAN_MTU>
        ether 00:03:47:e2:9f:83
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9<RXCSUM,VLAN_MTU>
        ether 00:03:47:de:d2:75
        inet 192.168.3.2 netmask 0xfffffffc broadcast 192.168.3.3
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 
        inet6 ::1 prefixlen 128 
        inet 127.0.0.1 netmask 0xff000000 
$ 
$ ping 192.168.6.1
PING 192.168.6.1 (192.168.6.1): 56 data bytes
64 bytes from 192.168.6.1: icmp_seq=0 ttl=255 time=1.453 ms
64 bytes from 192.168.6.1: icmp_seq=1 ttl=255 time=1.305 ms
^C
--- 192.168.6.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.305/1.379/1.453/0.074 ms
$ ping 192.168.6.1
PING 192.168.6.1 (192.168.6.1): 56 data bytes
64 bytes from 192.168.6.1: icmp_seq=0 ttl=255 time=1.331 ms
64 bytes from 192.168.6.1: icmp_seq=1 ttl=255 time=1.330 ms
64 bytes from 192.168.6.1: icmp_seq=2 ttl=255 time=1.340 ms
64 bytes from 192.168.6.1: icmp_seq=3 ttl=255 time=1.268 ms
64 bytes from 192.168.6.1: icmp_seq=4 ttl=255 time=1.344 ms
^C
--- 192.168.6.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.268/1.323/1.344/0.028 ms
$ ping 192.168.3.2
PING 192.168.3.2 (192.168.3.2): 56 data bytes
64 bytes from 192.168.3.2: icmp_seq=0 ttl=64 time=0.056 ms
64 bytes from 192.168.3.2: icmp_seq=1 ttl=64 time=0.016 ms
64 bytes from 192.168.3.2: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 192.168.3.2: icmp_seq=3 ttl=64 time=0.015 ms
64 bytes from 192.168.3.2: icmp_seq=4 ttl=64 time=0.015 ms
^C
--- 192.168.3.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.015/0.024/0.056/0.016 ms
$ ping 192.168.3.6
PING 192.168.3.6 (192.168.3.6): 56 data bytes
64 bytes from 192.168.3.6: icmp_seq=0 ttl=64 time=0.054 ms
64 bytes from 192.168.3.6: icmp_seq=1 ttl=64 time=0.016 ms
64 bytes from 192.168.3.6: icmp_seq=2 ttl=64 time=0.018 ms
64 bytes from 192.168.3.6: icmp_seq=3 ttl=64 time=0.017 ms
64 bytes from 192.168.3.6: icmp_seq=4 ttl=64 time=0.014 ms
64 bytes from 192.168.3.6: icmp_seq=5 ttl=64 time=0.013 ms
^C
--- 192.168.3.6 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.013/0.022/0.054/0.014 ms
$ 
$ uname -a
FreeBSD r.d 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Mon Apr  4 10:34:12 UTC 2011     root at r.d:/usr/obj/usr/src/sys/GENERIC2  i386
$ xorpsh
Welcome to haizz router on r.d
admin at r.d> show ospf4 database 
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *192.168.1.1      192.168.1.1      0x80000041   264  0x2  0x3b2f  48
Router   192.168.6.1      192.168.6.1      0x80000025   270  0x22 0xf3eb  60
Network  192.168.3.1      192.168.6.1      0x80000001   277  0x22 0x8af8  32
Network  192.168.3.5      192.168.6.1      0x80000001   275  0x22 0x621d  32
ASExt-2 *192.168.1.0      192.168.1.1      0x80000001   274  0x2  0xdef   36
ASExt-2 *192.168.3.0      192.168.1.1      0x80000001   274  0x2  0x5837  36
ASExt-2 *192.168.3.4      192.168.1.1      0x80000001   274  0x2  0x681f  36
admin at r.d> show ospf4 neighbor 
  Address         Interface             State      ID              Pri  Dead
192.168.3.1      fxp1/fxp1              Full      192.168.6.1        1    38
192.168.3.5      bge0/bge0              Full      192.168.6.1        1    39
admin at r.d> 
admin at 55# show 
    protocols {
        ospf4 {
            router-id: 192.168.1.1
            area 0.0.0.0 {
                area-range 192.168.3.0/29 {
                }
                area-range 192.168.1.0/24 {
                }
                interface eth2 {
                    vif eth2 {
                        address 192.168.3.2 {
                        }
                    }
                }
                interface eth4 {
                    vif eth2 {
                        address 192.168.3.6 {
                        }
                    }
                }
            }
        }
    }
    policy {
        policy-statement a1 {
            term a1 {
                from {
                    protocol: "connected"
                }
            }
        }
    }
    interfaces {
        interface eth2 {
            vif eth2 {
                address 192.168.3.2 {
                    prefix-length: 30
                }
            }
        }
        interface eth4 {
            vif eth4 {
                address 192.168.3.6 {
                    prefix-length: 30
                }
            }
        }
        interface eth3 {
            vif eth3 {
                address 192.168.1.1 {
                    prefix-length: 24
                }
            }
        }
    }
 [edit]
 all port is alive
  
  
 after one of link breakage.
 $ ifconfig
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:10:18:14:55:17
        inet 192.168.3.6 netmask 0xfffffffc broadcast 192.168.3.7
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9<RXCSUM,VLAN_MTU>
        ether 00:03:47:e2:9f:83
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9<RXCSUM,VLAN_MTU>
        ether 00:03:47:de:d2:75
        inet 192.168.3.2 netmask 0xfffffffc broadcast 192.168.3.3
        media: Ethernet autoselect (none)
        status: no carrier          ------------------------------------break
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 
        inet6 ::1 prefixlen 128 
        inet 127.0.0.1 netmask 0xff000000 
$ ping 192.168.3.6
PING 192.168.3.6 (192.168.3.6): 56 data bytes
ping: sendto: No route to host-------------------------break
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 192.168.3.6 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
$ ping 192.168.3.5
PING 192.168.3.5 (192.168.3.5): 56 data bytes
ping: sendto: No route to host-----------------------break
ping: sendto: No route to host
ping: sendto: No route to host
$ ping 192.168.3.2
PING 192.168.3.2 (192.168.3.2): 56 data bytes
64 bytes from 192.168.3.2: icmp_seq=0 ttl=64 time=0.025 ms
64 bytes from 192.168.3.2: icmp_seq=1 ttl=64 time=0.017 ms
^C
--- 192.168.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.017/0.021/0.025/0.004 ms
$ ping 192.168.6.1
PING 192.168.6.1 (192.168.6.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 192.168.6.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
$ vty
Welcome to haizz router on r.d
admin at r.d> show ospf4 neighbor 
  Address         Interface             State      ID              Pri  Dead
192.168.3.5      bge0/bge0              Exchange  192.168.6.1        1    35
admin at r.d> show ospf4 database 
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *192.168.1.1      192.168.1.1      0x80000045    88  0x2  0x1ea9  36
Router   192.168.6.1      192.168.6.1      0x80000026    91  0x22 0xb999  60
Network  192.168.3.1      192.168.6.1      0x80000001   458  0x22 0x8af8  32
ASExt-2 *192.168.1.0      192.168.1.1      0x80000001   456  0x2  0xdef   36
ASExt-2 *192.168.3.4      192.168.1.1      0x80000001    90  0x2  0x681f  36
admin at r.d>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110630/82ac7a6f/attachment-0001.html 

From doi at criepi.denken.or.jp  Thu Jun 30 19:52:08 2011
From: doi at criepi.denken.or.jp (=?iso-2022-jp?B?GyRCRVowZhsoQiAbJEJHbkA4GyhC?=)
Date: Fri, 1 Jul 2011 11:52:08 +0900
Subject: [Xorp-hackers] compile error with debug=yes option
Message-ID: <E97D1244-F252-4318-915F-0C886B687173@criepi.denken.or.jp>

When I compile with debug=yes option, I meat a compile error.
Please check print_rin() in rib/rib.cc

Thank you for your kindness.
Hiroki Doi

linux (ubuntu 11.04)
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 

$ scons debug = yes

g++ -o obj/x86_64-unknown-linux-gnu/rib/rib.os -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DDEBUG_LOGGING -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-linux-gnu -I. -I. rib/rib.cc
cc1plus: warnings being treated as errors
rib/rib.cc: In member function ?void RIB<A>::print_rib() const [with A = IPv4]?:
rib/rib.cc:1617:16:   instantiated from here
rib/rib.cc:1582:2: error: format not a string literal and no format arguments
rib/rib.cc:1617:16:   instantiated from here
rib/rib.cc:1585:6: error: format not a string literal and no format arguments
rib/rib.cc: In member function ?void RIB<A>::print_rib() const [with A = IPv6]?:
rib/rib.cc:1621:16:   instantiated from here
rib/rib.cc:1582:2: error: format not a string literal and no format arguments
rib/rib.cc:1621:16:   instantiated from here
rib/rib.cc:1585:6: error: format not a string literal and no format arguments
scons: *** [obj/x86_64-unknown-linux-gnu/rib/rib.os] Error 1
scons: building terminated because of errors.