You might want to take a look at the spanning_tree component:
http://www.openflow.org/wk/index.php/Basic_Spanning_Tree
-- Murphy
On Thu, 2011-04-14 at 01:01 +0530, sachin sharma wrote:
>
>
> Hi,
>
>
> I am interested to test openflow in wireless networks where loops are
> present in topology.
So this is certainly not an official statement of any sort, but I would
not expect to see OpenFlow 1.1 support in NOX for a while. I believe
there's some consensus that supporting both 1.0 and 1.1 well will
require some nontrivial API changes (and we're due for some API changes
anyway), and there
For the record, it looks like I already pushed the log configuration
stuff to destiny, so everything I mentioned in the other message is
indeed already there.
-- Murphy
On Wed, 2011-03-23 at 14:33 -0400, John Meylor wrote:
> I'm looking for information on setting configuration files and verbosity
If you want to disable that behavior, you can edit builtin/nox.cc.
Delete the following three lines from around line 1264:
if ( send_openflow_command(dpid, &ofm->header, false) == EAGAIN) {
lg.err("Error, unable to clear flow table on startup");
}
.. and that should do it.
Can I ask why the ta
I think you have boost_filesystem 1.44 or above installed. I believe
NOX currently works fine with semi-recent versions up to 1.40, and
possibly has very minor problems with 1.42 (maybe only on 64 bit?). I
think these versions are what are in recent Ubuntu, even up through
11.04b3.
Potential way
Nope. I think it's easier to specify a protocol than a software
platform or whatever you want to call NOX, and I don't think a real
specification has ever been much of a priority. I think the closest
thing we have is the doxygen documentation.
-- Murphy
On Thu, 2011-03-24 at 12:23 +0800, linbo
So for reference, the log formatting looks like:
||:message
The log settings are in the form:
::
module is the name of a component or other module. Something like "nox"
or "pyrt" or "pyswitch", for example. "ANY" is a special string which
matches every module.
facility is the logging facility.
Is this the zaku branch? The first thing I'd try is seeing if the
destiny branch works (zaku will have other problems on 10.10 anyway).
-- Murphy
On Fri, 2011-03-18 at 17:13 -0700, David Meyer wrote:
> On 2.6.35-28-server #49-Ubuntu SMP Tue Mar 1 14:55:37 UTC 2011 x86_64
> GNU/Linux:
> ...
> ./
I notice in your code below you are using CACHE_TIMEOUT as the idle
timeout. Assuming you're modifying pyswitch, that's only 5 seconds. Is
this the actual code you're using? Are you sure your flows aren't just
timing out? If you change that to OFP_FLOW_PERMANENT, will it start
doing what you wa
he controller if I want the full packet.
>
> Thanks,
>
> Aaron
>
> On Tue, Mar 1, 2011 at 7:28 PM, James "Murphy" McCauley
> wrote:
> I didn't just add the "+ str(self.type)". I also switched it
> to a print
> f
5, in hdr
> packet += option.to_bytes()
> File "./nox/lib/packet/tcp.py", line 78, in to_bytes
> self.msg('(tcp_opt to_bytes) warning, unknown option') + str(self.type)
> AttributeError: tcp_opt instance has no attribute 'msg'
>
>
>
> O
7;s saying
> "This frame is a suspected retransmission" and in tcpdump at
> the host that is getting these packets its saying:
>
>
> 18:13:48.227362 IP truncated-ip - 730 bytes missing!
> 130.127.39.173.59276 > 130.127.39.2
.
>
> The MSS of these packets are 1460 in the packet_in event.
>
> Any idea?
>
> Thanks,
>
> Aaron
>
>
> On Tue, Mar 1, 2011 at 3:51 PM, James "Murphy" McCauley
> wrote:
> You're not doing anything wrong here. You seem
You're not doing anything wrong here. You seem to be doing something
wrong elsewhere. Specifically, you seem to have constructed an MSS TCP
option with a tuple as its value, when the value should be some sort of
integer.
-- Murphy
On Tue, 2011-03-01 at 15:22 -0500, Aaron Rosen wrote:
> Hello I
You can also right-click on a packet from the controller traffic, select
Decode As..., and set OFP as the Transport protocol. This will let you
temporarily associate the port with the OpenFlow decoder without having
to recompile the plugin.
-- Murphy
On Wed, 2011-02-16 at 15:57 -0500, Niky Riga
Thanks! I'll put this on my queue.
-- Murphy
On Wed, 2011-02-16 at 16:29 +0530, karthikeyan ramaswamy wrote:
> Dear Nox developers,
>
> I wanted to have multiple actions involving modifying the vlan id and
> output to a port. I searched in mailing list and found the following
> post.
> http://w
So the to_python for ofp_match shows that there's at least an attempt to
do the right thing. Given that, the next thing I'd do is check the
ofp_flow_removed message on the wire (using Wireshark) to make sure I
think the wildcards field is set right there, which would indicate that
this is indeed a
We've never been that great about version numbers, and most "releases"
really just correlate to a snapshot of the repository. We're hopefully
a little bit more sane now. We currently have two active-ish branches
in the nox repository: a stable one named zaku (occasionally known as
0.9.0), and a d
OFPP_CONTROLLER) {
> > pyglue_setdict_string(dict, "max_len",
> > to_python(ntohs(ao.max_len)));
> > }
> > }
> > else if (type == OFPAT_STRIP_VLAN) {
> > /* nothing to set, no struct beyond the header */
> >
I believe the issue is that with the to_python() for ofp_flow_stats&, we
have no idea if the actions actually follow the ofp_flow_stats structure
since, for example, someone could have just made an ofp_flow_stats
struct and tried to pythonize it. I am not sure if this ever actually
happens, but wh
I think I fixed this in the destiny branch in commit
9b8aeb5c7401c0f6869c0f214566459520151358.
You should be able to apply that patch to zaku without problems.
-- Murphy
On Tue, 2011-01-25 at 15:17 +0900, Min-Hyup Kang wrote:
>Dear all
>
Hi, and welcome to nox-dev.
I believe your switch supports OpenFlow 1.0, so either the zaku (stable)
or destiny (unstable) branch of NOX should work.
I don't know if you're familiar with git at all, but installation
instructions can be found on the wiki at:
http://noxrepo.org/noxwiki/index.php/NO
This isn't just with the Error_event event -- it just behaves the same
as all the other Python events that currently keep the xid information,
and also the same as the C++ API which does not byte-swap header fields.
I agree it's probably not the most *desirable* behavior, but it is
*consistent* (fo
Could you please post your config.log?
-- Murphy
On Thu, 2010-12-16 at 17:57 -0800, Stephen Wong wrote:
> Hi Derek,
>
> Yes, I did:
>
> linux-ojon:/home/openflow/nox/nox/build # grep -n python *
> config.h:109:/* Provide macro indicating that twisted python was enabled */
> config.log:7: $
Have you installed a rule to send the entire packet (the type that you
want to duplicate) to the controller? If not, it may well be truncated.
So you may only be sending the truncated version out on the second dpid.
Depending on how you're checking to see if this is working, this may
just look lik
.. and a (hopefully) better fix than modifying your Python installation
is in destiny as commit 9b8aeb5c7401c0f6869c0f214566459520151358
-- Murphy
On Thu, 2010-12-09 at 16:51 -0800, Kyriakos Zarifis wrote:
> Hi Alexandre,
>
>
> this is an issue with more recent versions of Twisted (which versio
This will get into destiny in the next day or so. Here's a patch for
zaku. You should then be able to create the action with:
actions = [[openflow.OFPAT_ENQUEUE, (port, queue_id)]]
I haven't actually tried it. Let me know how it works. :)
-- Murphy
On Mon, 2010-11-29 at 13:36 -0500, Anand Baw
cookie=0, duration_sec=31s,
> > > duration_nsec=71000s, table_id=0,
> > > > priority=32768, n_packets=32,
> > > n_bytes=3136,
> > > >
> >
jamming eight random bytes into a field meant to "contain an
alpha-numeric string that is [a] textual description"?
-- Murphy
On Tue, 2010-11-16 at 00:33 -0500, Nicholas Bastin wrote:
> On Tue, Nov 16, 2010 at 00:17, James "Murphy" McCauley
> wrote:
> Rob an
rganizationally Specific TLV. If we ask
nicely, maybe we can use Nicira's OUI? Martin?
-- Murphy
On Mon, 2010-11-15 at 23:45 -0500, Nicholas Bastin wrote:
> On Mon, Nov 15, 2010 at 21:55, James "Murphy" McCauley
> wrote:
> I notice that the chassis ID TLV al
I know there's a longstanding issue with some switches that use more
than 48 bits for their DPIDs. This problem stemming from the fact that
discovery stuffs the DPID into a MAC subtype chassis ID TLV in the LLDP
packet it sends out, which obviously only has 48 bits. Thus, when we
get the LLDP pac
=0,icmp,dl_vlan=0x,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:04,nw_src=10.0.0.2,nw_dst=10.0.0.4,icmp_type=8,icmp_code=0,actions=mod_nw_tos:0x28,output:3
>
> Thanks,
>
> Aaron
>
>
> On Mon, Nov 15, 2010 at 7:51 PM, James "Murphy" McCauley
Try this patch.
Also, your parameter for OFPAT_SET_NW_TOS ("44") should probably be an
integer (44).
-- Murphy
On Mon, 2010-11-15 at 15:30 -0500, Aaron Rosen wrote:
> Thanks Niky,
>
>
> Does anyone know how I would modify those ToS bits then? Or what all I
> would have to add to make, make_ac
My patch has now been pushed to destiny. If it doesn't cause problems,
we can push it to zaku later.
-- Murphy
On Wed, 2010-11-10 at 18:27 +0900, Romain Lenglet wrote:
> Hi,
>
> This patch if for the zaku branch.
> This is a remake of my old patch for the openflow-1.0 branch here:
> http://noxr
monitoring is currently only in the destiny branch, so the way to fix
that is really to use destiny.
tests doesn't currently work. As far as I know, nobody has really used
it for quite some time. You can probably get it to at least sort of
work by removing dependencies that don't exist in the cu
Responses inline.
On Thu, 2010-11-11 at 15:24 -0500, Kavitesh Singh wrote:
> Hi,
>
>
>
> I have recently started learning Openflow using NOX controller. I have
> downloaded the VMware image available on OpenFlow website having
> inbuilt NOX controller.
>
>
>
> I am following the tutorial a
Add the -v switch to your commandline and the JSON box at least should
start working...
-- Murphy
On Wed, 2010-11-10 at 15:06 -0500, Christopher J. Tengi wrote:
> KK,
> What components must be included on the nox_core command line in
> order for nox-gui.py to be able to talk to it? Are the
You mention "./build/src/nox/coreapps/examples/pytutorial.py" and
"./nox/build/src/nox/coreapps/examples/pytutorial.py". I'm having trouble
making sense of these paths. Is one of them wrong, or are they not relative to
the same directory?
-- Murphy
On Oct 24, 2010, at 12:09 PM, Aaron Rosen w
It looks like you have a custom component that's maybe doing something bad
inside a timer handler? I'd start inspecting there (e.g., by disabling
timers...).
-- Murphy
On Oct 23, 2010, at 12:12 PM, Nikhil Handigol wrote:
> My NOX controller seems to be segfaulting quite a bit of late. What is
What distribution are you on? I think libboost1.35-dev is still in Debian
Lenny.
Are you on Ubuntu? Try just libboost-dev (or refer to the Ubuntu section of
the Dependencies page on the wiki).
-- Murphy
On Oct 22, 2010, at 4:16 PM, Rohit Manohar wrote:
> Hey
>
> When i try to install libbo
For a current version, try:
git clone git://noxrepo.org/nox
The old noxcore repository is quite dated, but I believe it's still available
as noxcore_old if it's really what you want.
-- Murphy
On Oct 22, 2010, at 3:27 PM, Rohit Manohar wrote:
> Hey
>
> I am trying to download NOXCore using:
>
It's likely that's from the old master branch, which is now the
openflow-0.8.9 branch.
-- Murphy
On Tue, 2010-10-19 at 18:06 -0400, Niky Riga wrote:
> Hi all,
>
> We are currently debugging a problem at Clemson, they claim to be
> running nox:
>
> (Which is)
> NOX 0.8.0~full~beta (nox_core), c
I don't really suspect this is the problem, but are you pulling nox from the
openflow-1.0 branch or from zaku (the latter being the preferred answer).
I've tested that code and it seems to work fine here. I'm using zaku and Open
vSwitch. Obvious question: are you getting packets at all?
-- Mu
21:42, James "Murphy" McCauley wrote:
> I got the configure output off-list, and as expected, Python is disabled (and
> therefore discovery). In this case, it's because Twisted isn't available,
> which I have seen cause confusion before. When configuring with Pyt
I got the configure output off-list, and as expected, Python is disabled (and
therefore discovery). In this case, it's because Twisted isn't available,
which I have seen cause confusion before. When configuring with Python *not
disabled*, we should probably make that actually stop configure ra
Fixed (hopefully!) in the main branch.
-- Murphy
On Oct 16, 2010, at 1:27 AM, Niky Riga wrote:
> Thanks, should I switch to the destiny branch, or this is fixed at the head
> of the tree?
>
> --niky
>
> James "Murphy" McCauley wrote:
>> Hopefull
Hopefully it's fixed in the repository now.
-- Murphy
On Oct 15, 2010, at 8:27 PM, Niky Riga wrote:
> Hi,
>
> Given that this bug is blocking one of the Gec9 plenary demos, I would like
> to start debugging it.
> Do you have an idea where should I start looking? In which file do you
> believe
Are you sure this is NOX 0.6.0? Where/how did you get the code? What does
"grep ^VERSION Makefile" (in your build directory) say?
.. I just want to be sure we know what we're dealing with here.
-- Murphy
On Oct 15, 2010, at 3:01 PM, Chui-Hui Chiu wrote:
> Hi, all,
>
> I have encountered a w
In the "Monitor module crashes" thead, I mentioned that I thought the
"controller" looked like it was doing weird stuff, but to be clear, I meant
FlowVisor and not NOX. It looks to me like FlowVisor is sending some things at
weird times (for example, sending something weird during handshaking i
believe that the authenticator failed to compile.
>> I think that g++ faced problems while trying to compile it and in the end
>> all the reported errors were about that.
>>
>> I know that this is probably not all that helpful :-) I will try and
>> reproduce it and s
>From the log, it looks like the controller (FlowVisor?) is doing some weird
>stuff, and I don't know what's up with that. As KK suggested, you might want
>to look at a trace.
BUT, this shouldn't crash NOX, and I do think it points out a bug:
In src/builtin/nox.cc, the line immediately followin
If it ended up seeming to work, I think the chances are good that it's fine.
But I'm interested in whatever the problem may have been if you care to help me
understand it a bit more.
Nothing stuck out at me after a quick glance at your attachments, and those
warnings are generally going to be
I don't know much of anything about this configuration, but I think you are
missing "config interface" lines for the other ports in your
/etc/config/network file. You have one for eth0.0 and eth0.4, but I think you
need it for your additional ports as well.
Alternately, if you removed ports et
Nope, sorry. The zaku branch only supports OpenFlow 1.0. If I recall, Mininet
supports OpenFlow 1.0, but if you're stuck with some 0.8.9 configuration, you
are pretty much stuck with the openflow-0.8.9 branch of NOX.
-- Murphy
On Sep 18, 2010, at 1:05 AM, duong nguyen wrote:
> Hi,
>
> I'm u
The openflow-0.9 branch is not very actively maintained and has probably never
been built on a 64 bit platform (I'm guessing you're on one). This bug is
fixed in other branches by simply removing the offending code because it's not
actually used anyway.
BUT, none of that actually matters. Ope
This is a destiny-specific bug and was introduced in commit
58547d74330eb0511cdddbbeb4f3017278a50d53.
I am not set up for commits here, but I've attached a patch. I think there are
actually a number of improvements that could be made to the socket-based
logging, but that's a project for anothe
ed state: INSTALLED
>Dependencies:
>
> 00214|nox|DBG:built-in DSO deployer:
>Current state: INSTALLED
> Required state: INSTALLED
>Dependencies:
>
> 00215|nox|DBG:storage common:
>Current state: INSTALLED
>Required state: INST
The easiest way is to switch to xerces 2.
Both of these problems are addressed in the destiny branch, by the way
(the former with a macro, the latter by removing xerces and switching to
json for configuration files).
-- Murphy
On Tue, 2010-08-10 at 09:51 +0800, 陈文龙 wrote:
> noxcore]$ autoreconf
00, Romain Lenglet wrote:
> Hi James,
>
> Thanks for your comments. My replies are inline below.
>
> On 2010-08-07 02:17, James "Murphy" McCauley wrote:
> > It mostly stands as "it doesn't seem worth it to get into it". We were
> > intere
It mostly stands as "it doesn't seem worth it to get into it". We were
interested in improving modularity some (and the idea of replacing the build
system wholesale did come up), but it became clear that it was going to be a
lot of effort to do something that wasn't necessary to achieve our mor
len);
> > worked for me.
> > Can someone with write permissions push the change to the destiny branch
> > main repository?
> > Thanks,
> > Nikhil
> >
> >
> > On Thu, Aug 5, 2010 at 6:30 PM, James "Murphy" McCauley
> > wrote:
> >>
I've built on Debian lenny using g++ 4.4.4 or 4.4.5 pulled from sid
without running into this. When you installed g++ 4.4.4, did you also
get the updated C++ libraries and STL?
You might try changing json-util.cc line 50 to:
jo = new json_object((const uint8_t *)str.get(), len);
-- Murphy
On Th
Are you running swig >= 1.3.37? If so, the easiest thing is probably to
downgrade to 1.3.36.
What Linux distribution are you on? I didn't think anyone had actually
switched to 1.3.37 for exactly this reason...
-- Murphy
On Thu, 2010-08-05 at 11:07 +0100, Kiani, Parham wrote:
> HI
> I am trying
This is a bug in NOX. Furthermore, it's a bug in SWIG -- it's lying to
you. The number of arguments is fine, but the code it generates to
check the types in order to distinguish between the two overloaded
variants of the function doesn't work, and the error message it gives
you as a result is jus
check if the
> openflow hooks are being ignored/overrided by other hooks running on my
> system. Do you think this is what it could be?
>
> thanks in advance
> Iain
>
> On Jul 15 2010, James Murphy McCauley wrote:
>
> > Since this hasn't been quickly resolved,
Since this hasn't been quickly resolved, I thought it might be worth
seeing if this is nothing to do with your NOX code, but to do with your
network configuration instead.
If you run ./nox_core with no components specified, do all your packets
from NEIGHBOR go through? They *should* all die, but
You've found a bug.
The flow_removed event was introduced in OpenFlow 0.9.0 as a replacement
for flow_expired. As the master branch of the repository is for
OpenFlow 0.8.9, it should still be flow_expired here, but the new name
seems to have been accidentally committed along with an unrelated bug
it checkout openflow-1.0
>> ./boot.sh
>> mkdir build
>> ../configure --with-python=yes --enable-ndebug
>> make
>>
>>
>>
>> From: James "Murphy" McCauley [jam...@nau.edu]
>> Sent: 13 July 2010 14:52
>> To: Kiani, Parham
>> Cc: nox-de
take a look at
> it.( attached file)
> git clone git://noxrepo.org/nox
> cd nox
> git checkout openflow-1.0
> ./boot.sh
> mkdir build
> ../configure --with-python=yes --enable-ndebug
> make
>
>
> ____
> From: James "
Looks like a simple version mismatch. The version of Open vSwitch
you're using supports OpenFlow 1.0 (wire protocol 0x01). The version of
NOX you're using supports OpenFlow 0.8.9 (wire protocol 0x97).
So somehow you need to get your versions matched up. I have no idea how
FlowVisor factors in
I think this problem is just due to nox 0.5 (in the noxcore repo) not
supporting xerces 3. This was addressed in nox 0.6. And in the future,
the dependency on xerces will be removed. So any way you slice it --
yes, this has been resolved.
If for some reason you really need nox 0.5, you can just
I am guessing this is a bug in the autoconf boost detection code. I'd
try the following:
First, apt-get install libboost-all-dev
If that doesn't work, try manually setting the boost paths with the
appropriate configure options (--with-boost= and friends).
If that still doesn't work, could you post
g directory `/usr/src/packages/BUILD/nox/src/nox/lib'
> make[4]: *** [install-recursive] Error 1
> make[4]: Leaving directory `/usr/src/packages/BUILD/nox/src/nox'
> make[3]: *** [install] Error 2
> make[3]: Leaving directory `/usr/src/packages/BUILD/nox/src/nox'
>
work however.
>
> They are symlinks to .so files in the same directory.
>
> Jad.
>
> On Sun, Jul 4, 2010 at 5:19 AM, James "Murphy" McCauley
> wrote:
> > What do you get if you try to link it using -lcrypto instead of -lssl?
> >
> > And are tho
Duh, of course my suggestion won't work. I'm too used to installing
from source...
If you like living on the edge, I got it running with something along
the lines of:
1) Install all the dependencies you can
2) Install libdb4.6 (it'll be a dependency later)
3) Grab and install packages from Karmi
r/tmp/build-root/usr/lib/libcrypto*
> /var/tmp/build-root/usr/lib/libcrypto.a
> /var/tmp/build-root/usr/lib/libcrypto.so
> /var/tmp/build-root/usr/lib/libcrypto.so.0.9.8
>
> where /var/tmp/build-root is the chroot root dir. Adding -L/usr/lib to
> the gcc options didn'
That error message isn't actually indicative of the problem.
My first guess is that there's a problem with your libcrypto (possibly a
bad symlink?).
Can you check that /usr/lib/libcrypto.so (or some versioned filename)
exists, and that any/all libcrypto symlinks are okay?
You could also just try
I have zero experience installing NOX/OpenFlow/SNAC from packages, but
personally, I'd give the following a shot...
apt-get install libboost-filesystem1.40.0 libboost-serialization1.40.0
apt-get install libboost-test1.40.0 python2.6
.. and then try installing the SNAC packages again.
I have no i
ipv4.py's parse() grabs the IP headers and passes the rest of its input on to
some next layer (which may be TCP, UDP, ICMP, or just raw data, depending).
Sounds good, but… there are times when the rest of its input isn't actually all
IP payload. Specifically, when the ethernet frame has been p
re. Thanks!
On Sun, Jan 24, 2010 at 5:56 PM, James "Murphy" McCauley > wrote:
Hey, DK.
Hopefully I'm not introducing a big leak here, but give this a try:
Index: pycontext.cc
===
--- pycontext.cc(revision 2)
+++
Hey, DK.
Hopefully I'm not introducing a big leak here, but give this a try:
Index: pycontext.cc
===
--- pycontext.cc(revision 2)
+++ pycontext.cc(working copy)
@@ -132,6 +132,7 @@
if(sfe.python_arg){
py
81 matches
Mail list logo
