[pox-dev] send packet from controller

[Silvia Fichera]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20130722/55f8d5e2/attachment-0002.htm>