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
