[nox-dev] Python API buffer_id None problems

2012-01-17 Thread Peter Peresini
Hi developers.
 It seems that there is an inconsistency in python API (destiny branch) for
using buffer_id. Namely, send_openflow documentation states that
buffer_id -1 should be used to indicate no buffer but in the fact it tests
for None.
But apart from that, if you supply None to this function the call will fail
with the following error:

 (openflow typemap) py argument to Buffer must be of type str, instead
received
nox.lib.packet.ethernet.ethernet instance at 0x7fbe65001b90

as far as I can tell, the problem occurs inside the call
   self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions,
inport)
in the send_openflow_packet() function.

Any idea what might be the problem? I can debug it even more if you tell me
where to find the implementation of context.

Kind regards
  Peter Peresini
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev


Re: [nox-dev] Python API buffer_id None problems

2012-01-17 Thread Murphy McCauley
Can you please show us the code you are using to call send_openflow()?

-- Murphy

On Jan 17, 2012, at 1:40 AM, Peter Peresini wrote:

 Hi developers.
  It seems that there is an inconsistency in python API (destiny branch) for 
 using buffer_id. Namely, send_openflow documentation states that buffer_id 
 -1 should be used to indicate no buffer but in the fact it tests for None.
 But apart from that, if you supply None to this function the call will fail 
 with the following error:
 
  (openflow typemap) py argument to Buffer must be of type str, instead 
 received
 nox.lib.packet.ethernet.ethernet instance at 0x7fbe65001b90
 
 as far as I can tell, the problem occurs inside the call
self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions, 
 inport)
 in the send_openflow_packet() function.
 
 Any idea what might be the problem? I can debug it even more if you tell me 
 where to find the implementation of context.
 
 Kind regards
   Peter Peresini
 
 ___
 nox-dev mailing list
 nox-dev@noxrepo.org
 http://noxrepo.org/mailman/listinfo/nox-dev

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev


Re: [nox-dev] Python API buffer_id None problems

2012-01-17 Thread Murphy McCauley
You're right about the documentation and the implementation being mismatched.  
The implementation is correct, the documentation is outdated.

The error you see when you pass None as the buffer ID is almost certainly in 
your code and not in NOX.  The error message is not that clear, but it's 
telling you that the packet argument must be a str, and you are passing an 
ethernet object from the packet library.  You need to either convert this to a 
string (packet.tostring()), or try to use the original buffer (packet.arr or 
packet.arr.tostring(); I can't remember).

Hope that helps.

-- Murphy

On Jan 17, 2012, at 5:31 AM, Peter Peresini wrote:

 I can reproduce it with following simple command, packet is the packet 
 received in packet_in_callback, actions is a combination of setting ToS and 
 forwarding to a single port.
 
 self.send_openflow(datapath_id, None, packet, actions, inport=inport)
 
 Kind regards
   Peter
 
 
 On Tue, Jan 17, 2012 at 11:42 AM, Murphy McCauley jam...@nau.edu wrote:
 Can you please show us the code you are using to call send_openflow()?
 
 -- Murphy
 
 On Jan 17, 2012, at 1:40 AM, Peter Peresini wrote:
 
 Hi developers.
  It seems that there is an inconsistency in python API (destiny branch) for 
 using buffer_id. Namely, send_openflow documentation states that buffer_id 
 -1 should be used to indicate no buffer but in the fact it tests for None.
 But apart from that, if you supply None to this function the call will fail 
 with the following error:
 
  (openflow typemap) py argument to Buffer must be of type str, instead 
 received
 nox.lib.packet.ethernet.ethernet instance at 0x7fbe65001b90
 
 as far as I can tell, the problem occurs inside the call
self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions, 
 inport)
 in the send_openflow_packet() function.
 
 Any idea what might be the problem? I can debug it even more if you tell me 
 where to find the implementation of context.
 
 Kind regards
   Peter Peresini
 
 ___
 nox-dev mailing list
 nox-dev@noxrepo.org
 http://noxrepo.org/mailman/listinfo/nox-dev
 
 

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev


Re: [nox-dev] Python API buffer_id None problems

2012-01-17 Thread Peter Peresini
Hi Murphy,
 thanks a lot, packet.arr helped. But the documentation could be improved
and at least hint that packet argument is actually packet.arr

Best wishes
 Peter

On Tue, Jan 17, 2012 at 3:30 PM, Murphy McCauley jam...@nau.edu wrote:

 You're right about the documentation and the implementation being
 mismatched.  The implementation is correct, the documentation is outdated.

 The error you see when you pass None as the buffer ID is almost certainly
 in your code and not in NOX.  The error message is not that clear, but it's
 telling you that the packet argument must be a str, and you are passing
 an ethernet object from the packet library.  You need to either convert
 this to a string (packet.tostring()), or try to use the original buffer
 (packet.arr or packet.arr.tostring(); I can't remember).

 Hope that helps.

 -- Murphy

 On Jan 17, 2012, at 5:31 AM, Peter Peresini wrote:

 I can reproduce it with following simple command, packet is the packet
 received in packet_in_callback, actions is a combination of setting ToS and
 forwarding to a single port.

 self.send_openflow(datapath_id, None, packet, actions, inport=inport)

 Kind regards
   Peter


 On Tue, Jan 17, 2012 at 11:42 AM, Murphy McCauley jam...@nau.edu wrote:

 Can you please show us the code you are using to call send_openflow()?

 -- Murphy

 On Jan 17, 2012, at 1:40 AM, Peter Peresini wrote:

 Hi developers.
  It seems that there is an inconsistency in python API (destiny branch)
 for using buffer_id. Namely, send_openflow documentation states that
 buffer_id -1 should be used to indicate no buffer but in the fact it tests
 for None.
 But apart from that, if you supply None to this function the call will
 fail with the following error:

  (openflow typemap) py argument to Buffer must be of type str, instead
 received
 nox.lib.packet.ethernet.ethernet instance at 0x7fbe65001b90

 as far as I can tell, the problem occurs inside the call
self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions,
 inport)
 in the send_openflow_packet() function.

 Any idea what might be the problem? I can debug it even more if you tell
 me where to find the implementation of context.

 Kind regards
   Peter Peresini

 ___
 nox-dev mailing list
 nox-dev@noxrepo.org
 http://noxrepo.org/mailman/listinfo/nox-dev





___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev


[nox-dev] 'Monitoring' component status

2012-01-17 Thread Joe Stringer
Hi all,

I'm currently writing an SNMP subagent to interface with NOX to fetch
openflow statistics from NOX. To this end, I was thinking of fetching
the statistics via JSON messages. I noticed that netapps/monitoring in
the destiny branch caches stats about connected datapaths, and it
looks like it could be useful for my project.

What is the current status of the monitoring component in the destiny branch?
- Is the interface likely to change much?
- What information does it expose?
- Are there any scripts like src/scripts/nox-console.py that have
examples of how to structure messages to get certain types of replies?

Cheers,
Joe
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev


[nox-dev] NOX on IRC

2012-01-17 Thread Kyriakos Zarifis
The nox-dev mailing list is still the best way discuss NOX or ask for help,
but there is now also a IRC channel where NOX users and developers can
hangout for a more real-time type of interaction.

Join us on #noxcontroller on freenode servers.

(For instant web-based access: http://webchat.freenode.net/ )
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev


Re: [nox-dev] 'Monitoring' component status

2012-01-17 Thread Kyriakos Zarifis
Hi Joe,

That's right, monitoring periodically queries switches for statistics and
exposes that info.
The interface is probably not going to chance any time soon. It has been
used and tested to some extent, and has been proven ok for what it used so
far.
It exposes information like table_stats, port_stats, aggregate_stats
I'm not aware of scripts that demonstrate its usage, but the GUI interacts
with monitoring to display some switch statistics etc.
So if you wanted to delve into the code there you could find an example of
how to use the API. (It's probably more complicated than you need since,
'messenger' is used between the GUI and monitoring for their communication.
You probably don't care about interfacing with an external program like
that)


On Tue, Jan 17, 2012 at 5:58 PM, Joe Stringer joestrin...@google.comwrote:

 Hi all,

 I'm currently writing an SNMP subagent to interface with NOX to fetch
 openflow statistics from NOX. To this end, I was thinking of fetching
 the statistics via JSON messages. I noticed that netapps/monitoring in
 the destiny branch caches stats about connected datapaths, and it
 looks like it could be useful for my project.

 What is the current status of the monitoring component in the destiny
 branch?
 - Is the interface likely to change much?
 - What information does it expose?
 - Are there any scripts like src/scripts/nox-console.py that have
 examples of how to structure messages to get certain types of replies?

 Cheers,
 Joe
 ___
 nox-dev mailing list
 nox-dev@noxrepo.org
 http://noxrepo.org/mailman/listinfo/nox-dev

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev