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. I
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
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
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:
...
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
in the packet_in event.
Any idea?
Thanks,
Aaron
On Tue, Mar 1, 2011 at 3:51 PM, James Murphy McCauley
jam...@nau.edu wrote:
You're not doing anything wrong here. You seem to be doing
something
wrong elsewhere. Specifically, you seem to have constructed
33 win 12 nop,nop,timestamp 9797038 46103242
Thanks,
Aaron
On Tue, Mar 1, 2011 at 5:39 PM, James Murphy McCauley
jam...@nau.edu wrote:
Looks like the problem
, 2011 at 6:48 PM, James Murphy McCauley jam...@nau.edu
wrote:
Yeah, that's a bug too.
Change line 78 in tcp.py to like...
print '(tcp_opt to_bytes) warning, unknown option type ' +
str(self.type)
.. I'd actually be interested in knowing which option it is, because
maybe we should
.
Thanks,
Aaron
On Tue, Mar 1, 2011 at 7:28 PM, James Murphy McCauley
jam...@nau.edu wrote:
I didn't just add the + str(self.type). I also switched it
to a print
from a call to self.msg() (which doesn't exist because the TCP
option
class isn't
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
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.
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
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
=
reinterpret_castofp_action_output(a);
Is this the proper use of reinterpret cast? I've never had to use it
before...
-Derek
On 01/28/2011 03:20 PM, James Murphy McCauley wrote:
I believe the issue is that with the to_python() for ofp_flow_stats, we
have no idea
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
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:
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*
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
.. 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 version
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
)
Sorry,
Aaron
On Mon, Nov 15, 2010 at 8:19 PM, James Murphy
McCauley jam...@nau.edu wrote:
Great. Pushed to destiny
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
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:
,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
jam...@nau.edu wrote:
Try this patch.
Also, your
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
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
jam...@nau.edu wrote:
Rob and Nick, the System Description TLV seems like both
overkill
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 there
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
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
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:
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
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),
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 the
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:
Hopefully it's fixed in the repository now.
-- Murphy
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
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 weird
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
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 following
were about that.
I know that this is probably not all that helpful :-) I will try and
reproduce it and send you
the output.
Thanks,
Niky
James Murphy McCauley wrote:
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
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 is
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
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
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.
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
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
:
'messenger' ran into an error:
Ssl_config initialization
failed: Protocol not available
From: James Murphy McCauley [jam...@nau.edu]
Sent: 06 August 2010 01:22
To: Kiani, Parham
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 more
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
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
permissions push the change to the destiny branch
main repository?
Thanks,
Nikhil
On Thu, Aug 5, 2010 at 6:30 PM, James Murphy McCauley jam...@nau.edu
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
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
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
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, I thought it might be worth
seeing if this is nothing to do with your NOX code
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
)
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 Murphy McCauley [jam...@nau.edu]
Sent: 13 July 2010 14:52
To: Kiani, Parham
Cc: nox-dev
to stoped by hand. i was wondering if you could 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 Murphy McCauley
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
directory `/usr/src/packages/BUILD/nox/src'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.7ZBfCM (%install)
On Sun, Jul 4, 2010 at 12:07 PM, James Murphy McCauley jam...@nau.edu
wrote:
I'd try skipping the check for MD5_Init, explicitly linking
/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't work either.
Any other ideas?
Thanks,
Jad.
On Sun, Jul 4, 2010 at 3:14 AM, James Murphy McCauley jam...@nau.edu
wrote:
That error
in the same directory.
Jad.
On Sun, Jul 4, 2010 at 5:19 AM, James Murphy McCauley jam...@nau.edu
wrote:
What do you get if you try to link it using -lcrypto instead of -lssl?
And are those actual files in /var/tmp/build-root/usr/lib, or are they
(possibly broken) symlinks? On my system, /usr
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
!
On Sun, Jan 24, 2010 at 5:56 PM, James Murphy McCauley jam...@nau.edu
wrote:
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
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){
65 matches
Mail list logo
