Re: [nox-dev] using scapy with nox
Javier, while not directly related to its use in NOX, you may want to have a look at oftest, 1.0 test suites do use scapy for a number of tests... Keep posting updates on your research, regards, Christian On Thu, Oct 13, 2011 at 20:25, Javier Liendo jav...@liendo.net wrote: you are absolutely right...thanks for the tip... On Thu, Oct 13, 2011 at 6:18 PM, Murphy McCauley jam...@nau.edu wrote: From the second listing, I think line 7 can be something like: e = Ether(packet.arr.tostring()) (which is much more efficient and straightforward) -- Murphy On Oct 13, 2011, at 3:48 PM, Javier Liendo wrote: hi experts... i know it is of really bad etiquette answering over you own email, but as soon i sent this mail i did the following test which seems to be working...just wanted to share it and see if anybody sees anything wrong with this approach... i defined an hex-string to an hex-binary-blob function inside packet_utils.py (conversion method taken from Brian@stackoverflow) 1 def octstr_to_hexbinary(octstr): 2 hexdigits = [int(x,16) for x in octstr] 3 blob = ''.join(struct.pack('B',(high4) + low) for high,low in zip(hexdigits[::2], hexdigits[1::2])) 4 return blob then on my controller program i did the following 1 from scapy.all import * 2 ... 3 def arping_me(self, dpid, inport, packet, buf, bufid): 4 If arping one of my own IPs respond 5 log.debug(+++ inside arping_me) 6 print array_to_octstr(packet.arr) 7 e=Ether(octstr_to_hexbinary(array_to_octstr(packet.arr))) 8 e.show() in (6) i'm printing the hex string representation of the packet... in (7) i'm calling octstr_to_hexbinary to get a binary blob that i could use with scapy... in (8) i get a variable 'e' which can be scapy-manipulated... does this sounds right? regards, javier On Thu, Oct 13, 2011 at 4:40 PM, Javier Liendo jav...@liendo.net wrote: hi experts, a) is there a way to decode/parse a receiving packet inside nox using scapy? b) is it possible to craft a packet using scapy and then use it (i.e. send_openflow) inside nox? regards, javier ___ 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 -- Christian ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Getting Actions From Events in Python
Hi Derek, did you succeed in implementing the to_python() for the action list in flow_stats? Does someone have a patch for this issue? Thanks, Christian On Fri, Jan 28, 2011 at 11:51, James Murphy McCauley jam...@nau.edu wrote: Yeah, I think this looks like the right direction. I probably wouldn't have bothered writing a to_python for ofp_action_header since we know it's not used anywhere else, and would have just handled it in the one for Flow_stats itself, but this is not really here nor there. This is a fine use for reinterpret_cast (except for the last one which you probably noticed needs a little work ;) ). I don't think that the length of the actions are checked anywhere (I could be wrong on this), so it might be nice to make sure that the length field of an action actually matches the size of the struct you're casting it to. Really we should handle this gracefully (e.g., log it and don't Pythonize it), but personally, I'd be okay with just doing an assert, since I would not expect to ever actually see it, but an assert is better than a segfault if it does pop up. :) Of course, there's also the argument that we should be validating them earlier. Whatever. Up to you what (if anything) you want to do about it in any case. -- Murphy On Fri, 2011-01-28 at 16:50 +0900, Derek Cormier wrote: Without minding the typos, that is... On 01/28/2011 04:46 PM, Derek Cormier wrote: Ok I'll give it a try and submit a patch when I'm finished. Could you please tell me if the following is the right approach? template PyObject* to_python(const ofp_action_header a) { PyObject* dict = PyDict_New(); if (!dict) { return 0; } uint16_t type = ntohs(a.type); pyglue_setdict_string(dict, type, to_python(type)); pyglue_setdict_string(dict, length, to_python(ntohs(a.len)); /* depending on the action type, cast to the appropriate * action struct to get its fields. */ if (type == OFPAT_OUTPUT) { const ofp_action_output ao = reinterpret_castofp_action_output(a); uint16_t port = ntohs(ao.port); pyglue_setdict_string(dict, port, to_python(port)); /* max_len only has meaning when the destination port is the controller */ if (port == 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 */ } else if (type == OFPAT_SET_VLAN_VID) { const ofp_action_vlan_vid av = 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 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 whatever. It's not provably a safe thing to do. However, the Flow_stats struct actually explicitly has the actions wrapped up into a vector, so it IS possible to safely pull them out of that. It just hasn't been done. The to_python() for Flow_stats should: Step one, convert the fields from the ofp_flow_stats struct itself into dict, which is done by just calling the to_python() for ofp_flow_stats. Step two, unpack v_actions from the Flow_stats struct into a list of dicts and throw it into dict too. Except instead of step two, we have /* XXX actions */. :) You should be able to just go ahead and implement it there. -- Murphy On Fri, 2011-01-28 at 14:50 +0900, Derek Cormier wrote: Hello, I was looking at pyglue.cc and it looks like actions are never included in python events. A comment says to use Flow_stats, but flow stats contains a vector ofp_action_header's. Since actions are variable-length, won't this cut off data when the action is longer than the header? (For example, ofp_action_dl_addr). So, is there any way to get actions in events like flow stats in? If not, how could we go about implementing this? Thanks, Derek ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org -- Christian ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] routing module
Hi Linbo, if you want to do traditional IP routing and forwarding on OpenFlow networks you may want to have a look at RouteFlow: https://sites.google.com/site/routeflow/ The second tutorial we are about to release demonstrates a four router network running OSPF: https://sites.google.com/site/routeflow/documents/tutorial2-four-routers-with-ospf You can look in the code to see how IP forwarding rules are installed in the OpenFlow switches. -Christian On Fri, Sep 2, 2011 at 02:30, linbo li...@csnet1.cs.tsinghua.edu.cn wrote: ** Hi,Srini Seetharaman : Thank you for your help ! You are so warm-hearted,I will read the paper you provided. I have checked the mail list ,but unfortunately I didn't found anybody write that code. 2011-09-02 -- linbo -- *发件人:* Srini Seetharaman *发送时间:* 2011-09-02 13:22:18 *收件人:* linbo *抄送:* nox-dev *主题:* Re: Re: [nox-dev] routing module Thank you Srini Seetharaman ! Besides conventional IP routing,which type of communication does nox support? Basic NOX comes with MAC learning switch and shortest path routing. How the nox decide a path from a source host to the destination host? If you used the routing module, it uses the shortest path algorithm described in http://www.dis.uniroma1.it/~demetres/docs/dapsp-full.pdf Are all the experiments until now in the same subnet or didn't use conventional IP routing? I can't speak for all the experimenters using NOX. It's possible there are others who wrote code for conventional IP routing. !DSPAM:1,4e60680a32083662284889! __ Information from ESET Smart Security, version of virus signature database 6428 (20110901) __ The message was checked by ESET Smart Security. http://www.eset.com ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev -- Christian ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] Announcing RouteFlow: IP Routing Services in OpenFlow Networks
Dear OpenFlow community, we are glad to announce the official start of the RouteFlow project: http://www.openflowhub.org/display/routeflow/RouteFlow+Home How to provide innovative IP routing approaches in OpenFlow networks? This is the question that triggered our work at CPqD resulting in RouteFlow (formerly QuagFlow), our modest contribution to the OpenFlow community. The main goal of RouteFlow is to develop an open-source framework (Apache-licensed) to provide virtualized IP routing services over OpenFlow networks. RouteFlow aims at a commodity routing architecture that combines the line-rate performance of OpenFlow-enabled devices with the flexibility of open-source routing stacks (such as Quagga) running on general purpose computers. RouteFlow is far from being a complete solution but it provides a general framework to combine OpenFlow with traditional IP routing protocols (e.g. OSPF, BGP, IS-IS) running in Linux-based virtual environments. There are several uses cases and modes of operation that experimenters/developers may think of, starting from traditional virtual routers to more elaborated mapping of logical router engines to OpenFlow-enabled resources with different options with regard to how routing protocol messages flow between the virtual and physical planes. For further information, check the project documentation and install instructions: https://sites.google.com/site/routeflow/documents This 4-page paper summarizes the RouteFlow architecture and design objectives: https://sites.google.com/site/routeflow/documents/routeflow-virtual-ip-sdn-CFI-2011.pdf?attredirects=0 There is also a step-by-step tutorial: Your first RouteFlow network: https://sites.google.com/site/routeflow/documents/first-routeflow Download RouteFlow from github: https://github.com/CPqD/RouteFlow The RouteFlow project looks forward for your comments and contributions! We welcome you to use and watch the OpenFlowHub-based Features and Bug tracking system: http://bugs.openflowhub.org/browse/RouteFlow Feel free to use the RouteFlow Forum to post your comments, suggest new features, or discuss anything you want: http://forums.openflowhub.org/forum.php In addition, you can subscribe to the mailing-list (http://groups.google.com/group/routeflow-discuss?hl=en_US) and ask questions via: routeflow-disc...@googlegroups.com Cheers, Christian (on behalf of the RouteFlow team) -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 est...@cpqd.com.br www.cpqd.com.br ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Res: Nox Application with dijkastra
Agree with KK! May be Ricardo meant OSPF-like shortest path computation. With regard to the RouteFlow (former QuagFlow) project, it has finally taken off: https://sites.google.com/site/routeflow/ While the code (Apache-licensed) and initial documentation are already up, the official release will be only next week once we fix some pending issues like the new logo and further documentation / tutorial material. Regards, Christian -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 est...@cpqd.com.br www.cpqd.com.br On Thu, May 19, 2011 at 13:41, kk yap yap...@stanford.edu wrote: Hi, I am not sure what is meant by OSPF here. Routing_module uses the method described in A New Approach to Dynamic All Pairs Shortest Paths by C. Demetrescu. A little more description can be found in the documentation: http://noxrepo.org/~yapkke/doc/classvigil_1_1applications_1_1Routing__module.html#_details Regards KK On 19 May 2011 07:45, fernando farias fer...@yahoo.com.br wrote: Hi Marwen There is a project called initially of QuagFlow and now RouteFlow that is able to use route protocols (OSPF, BGP, RIP ...) together with NOX. http://chesteve.wordpress.com/2010/07/07/quagflow-the-softrouter-reloaded-or-partnering-quagga-with-openflow/ Thx Fernando N. N. Farias Electrical Engineer PhD. Student Member of the Research Group on Computer Networks and Multimedia Communications - GERCOM/UFPA Optical Research Team - GERCOM Federal University of Pará Primeiro eles o ignoram. Depois, riem de você. Chega um ponto em que lutam contra voce. Ate o dia em que você vence. Gandhi De: Ricardo Bennesby ricardo.benne...@gmail.com Para: marwen mechtri mechtri.mar...@gmail.com Cc: nox-dev@noxrepo.org Enviadas: Quinta-feira, 19 de Maio de 2011 9:57:21 Assunto: Re: [nox-dev] Nox Application with dijkastra Hi Marwen. Nox routing implements OSPF protocol and It is based on Dijkstra algorithm (also called SPF). In this algorithm, the component knows the data of all nodes in the network. Hope it helped. Best Regards. 2011/5/19 marwen mechtri mechtri.mar...@gmail.com Hi all, I'm exploring routing, sample_routing and switch module of Nox but when I configure a partial mesh network this modules don't give any result. Could you tell me if this modules use dijkstra to calculate Path between source and destination. And if not, do you know a module that use dijkstra or any kind of method to calculate source to destination Path, could you please give me its name. Thinks Best regards Marwen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev -- Ricardo Bennesby da Silva Ciência da Computação - UFAM LabCIA - Laboratório de Computação Inteligente e Autonoma ___ 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 -- Christian ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev