[pox-dev] send packet from controller

Mon Jul 22 02:48:45 PDT 2013

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 <murphy.mccauley at gmail.com>

> 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 <murphy.mccauley at gmail.com>
>
>> 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 <murphy.mccauley at gmail.com>
>>
>>> 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 <murphy.mccauley at gmail.com>
>>>
>>>> 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 <murphy.mccauley at gmail.com>
>>>>
>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20130722/081f33f6/attachment-0001.htm>