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
