Dear Murphy,
I found the mistake! Of course that was a snapshot of the code and not all,
anyway I found the problem.
I was binding the socket with the tuple ('127.0.0.1',12345). When I changed
to ('', 12345) it worked. I guessed the host would have had 127.0.0.1 as
default loopback IP interface, but probably it is not because of the
mininet layer.
Thanks for your support!2013/7/22 Murphy McCauley <[email protected]> > Hm. > Okay, so if you run "netcat -u -l 12345" on say... h1, you see the data > (it works). > .. but with your python code on h1, you don't? > > If the code you pasted below is your real code, then it may be the > problem, since it has at least two bugs. > Try the following complete Python program: > import socket > s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) > s.bind(('',12345)) > data = s.recv(10) > print len(data), data > > -- Murphy > > On Jul 22, 2013, at 2:14 AM, Silvia Fichera wrote: > > If you mean the field eth_packet.dst yes, I've set it as 00:00:00:00:00:01 > the mac address of the host h1. > > > 2013/7/22 Murphy McCauley <[email protected]> > >> Are you setting the ethernet destination address correctly? >> >> On Jul 21, 2013, at 3:23 PM, Silvia Fichera wrote: >> >> Dear Murphy, >> I am still experiencing problems to send packets from controller to host. >> I tried to send UDP packet via packet_out and they are correctly sent and >> received from the host (I can see using tcpdump from receiving host) but if >> I try to open a socket with python to read the data, I receive nothing in >> the socket even if tcpdump keeps seeing the packets. >> >> Then I tried to communicate from host to host (opening two xterm from >> mininet). If I use netcat listening for data communication is perfect. If I >> try to receive data with python sockets I receive the following tcpdump >> output (python or netcat send, tcpdump and python listen): >> >> IP 10.0.0.2.12345 > 10.0.0.1.12345: UDP, length 14 >> IP 10.0.0.1 > 10.0.0.2: ICMP 10.0.0.1 udp port 12345 unreachable, length >> 50 >> >> I can see the process listening to the port by lsof -i :12345 >> If I put netcat listening to the port, the packet arrives correctly. >> I also tried to change the ports but same result. >> >> Is it maybe a problem of the low-level python socket binding? I am using >> simply >> s= socket.socket(socket.AF_INET, soket.SOCK_DGRAM) >> s.bind((host,port)) >> data, addr = sock.recv(10) >> >> Eventually, I tried in both my ubuntu+mininet installation and in the >> virtual machine of mininet (mininet 2.0 with ubuntu 12.10 64 bit) without >> success. >> >> Thanks for support >> >> regards >> >> >> >> >> 2013/7/21 Murphy McCauley <[email protected]> >> >>> If you have any switches, then you'll have received a ConnectionUp event >>> when they connect. You can save a reference to the Connection object into >>> your own variable at this point. Lots of the example components do this >>> (e.g., l2_learning more or less does it). >>> >>> You can also get the connections later from the OpenFlow nexus, e.g., >>> using the core.openflow.connections collection which holds a Connection for >>> each connected switch (you can either enumerate it, or you can get >>> connections by their DPID). There's also the related >>> core.openflow.sendToDPID(dpid, data) method if you know the DPID you want >>> to send to. >>> >>> -- Murphy >>> >>> On Jul 20, 2013, at 3:57 PM, Silvia Fichera wrote: >>> >>> Thanks for the summary. >>> I was planning to use the packet_out but I am missing the connection >>> object (I saw this is usually taken from an event). Can I create a >>> connection object (to link controller and a switch) starting the >>> communication from the controller? >>> >>> >>> 2013/7/20 Murphy McCauley <[email protected]> >>> >>>> Let me try restating. >>>> >>>> Imagine you have a hardware switch. It has some ports which connect it >>>> to other switches and hosts and stuff -- it makes a network (call this the >>>> "data network" for lack of a better term). >>>> >>>> So if it's an OpenFlow switch, where is the controller in this picture? >>>> >>>> One type configuration, the controller can be anywhere on the data >>>> network. It communicates with the switch over IP, so why not? You have >>>> OpenFlow mixed with normal traffic all over your network. (This is often >>>> called "in band control") >>>> >>>> In another type of configuration (out of band control), you set aside >>>> one port on each switch as "special", and use this port to connect to the >>>> controller. The special port is *not* a part of the data network. You >>>> might say it's part of a control or management network. No normal >>>> forwarding ever takes place over this port -- *only* OpenFlow. >>>> >>>> >>>> If your setup looks like the first configuration, a controller can >>>> easily send arbitrary traffic over the data network using plain old socket >>>> programming. But if your configuration is similar to the second option, >>>> there's no direct way for the controller to send to or receive from the >>>> data network. The only way it can do it is over OpenFlow -- by instructing >>>> one of the switches to send data (via a packet out) and having the switch >>>> send data to the controller (via packet in). >>>> >>>> Of course, even in the second configuration, you could run a cable >>>> between a second interface on the controller and a normal port on the >>>> switch. That way you have two cables between switch and controller -- one >>>> on the management network and one on the data network. >>>> >>>> >>>> Hope that helps. >>>> >>>> -- Murphy >>>> >>>> On Jul 20, 2013, at 8:49 AM, Silvia Fichera wrote: >>>> >>>> > In which case, there's no way to send except via a datapath or a >>>> host which actually is. >>>> Can you clarify this sentence? >>>> >>>> Am I following the right way to send packets from the controller to >>>> hosts through switches, so using my network, or do I miss something? >>>> >>>> >>>> 2013/7/20 Murphy McCauley <[email protected]> >>>> >>>>> If I'm understanding correctly, the problem is that the controller >>>>> isn't necessarily *on* the data network. In Mininet, for example, it is >>>>> often the case that the controller and the datapaths are linked >>>>> essentially >>>>> by a separate management network, and this is not an unusual case in the >>>>> real world either. In which case, there's no way to send except via a >>>>> datapath or a host which actually is. >>>>> >>>>> Hope that helps. >>>>> >>>>> -- Murphy >>>>> >>>>> On Jul 19, 2013, at 3:39 PM, Silvia Fichera wrote: >>>>> >>>>> Hello, >>>>> I am having trouble sending packets from l3_learning controller to >>>>> host. >>>>> I would like to send UDP packets but if I try to use normal socket >>>>> from controller I see no traffic (I minotired it with wireshark on all >>>>> switches) unless I send to itself (127.0.0.1). I was also trying to make >>>>> a >>>>> switch sending the controller generated packet in this way: >>>>> >>>>> http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/2012-October/000281.html >>>>> >>>>> Although I have no traffic too. >>>>> I guess the problem is that I am missing something like >>>>> >>>>> self.connection.send(msg) >>>>> >>>>> but I don't have any datapath connection with any switch since I want >>>>> to start the communication from the controller. >>>>> Is there an easier way to send these udp packets? >>>>> >>>>> thanks >>>>> >>>>> -- >>>>> Silvia Fichera >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Silvia Fichera >>>> >>>> >>>> >>> >>> >>> -- >>> Silvia Fichera >>> >>> >>> >> >> >> -- >> Silvia Fichera >> >> >> > > > -- > Silvia Fichera > > > -- Silvia Fichera
