Sounds about right.

If you're not altering the incoming packet at all, I think this is probably 
very close to:

po = ofp_packet_out(data = event.data, action = ofp_action_output(port = 
out_port))
core.openflow.sendToDPID(dpid, po)

... where ...

"event" is the PacketIn event with the packet you want to resend
"dpid" is the DPID of the destination switch
"out_port" is the port on "dpid" you want to send out of

-- Murphy

On Jul 8, 2013, at 9:29 PM, Small, Christopher wrote:

> A little background on what Kavit is trying to do here is to build a 
> tunneling mechanism through the controller for a (very small!) number of 
> packets between hosts connected on two different OF switches connected to the 
> same controller. 
> The application is essentially just a learning switch except:
> 1) It builds a global L2 table spanning all connected switches that includes 
> DPID as well as MAC and port for all learned MAC addresses 
> 2) When a Multicast DNS packet is sent as a Packetin to the controller the 
> controller sends the received packet as a PacketOut to a different switch 
> based upon a DB lookup of "paired" source and dest MACs. It uses the global 
> L2 table to find the DPID of the dest MAC.  
> I took a quick look at the ofp_packet_out class in 
> pox/openflow/libopenflow_01.py and it looks like probably the easiest way to 
> do this is to use the ofp_packet_out to build a new packet and then pack the 
> data from the Packetin into the new PacketOut. 
> What Kavit is currently doing is sending the packet received by the 
> controller back out directly using sendToDPID.
> --Chris Small
> 
> ======
> 
> I think sendToDPID() just doesn't do what you think it does.  It is for 
> sending OpenFlow commands to a switch -- the same as connection.send(), 
> except it looks up the connection for you based on DPID.  I believe you're 
> trying to use it to send a packet out of some port on a switch.  There's an 
> obvious piece of information missing here -- sendToDPID takes a DPID, but how 
> would it know which port you want to send the packet out of?
> 
> What you need to do is create an ofp_packet_out() which has an output action 
> to the appropriate port and the data you want to send as the 'data' 
> attribute. This is similar to the flood() function in l2_learning which is in 
> your source.  There are even closer examples in other modules (e.g., 
> misc.dhcpd).  Then send *that* using sendToDPID(), or in your case -- just 
> use connection.send().
> 
> -- Murphy 
> 
> On Jul 5, 2013, at 12:52 PM, Kavit Shah wrote:
> 
> > Command line with log, my code and screen shot of the wireshrak are 
> > attached in the text and png files.
> > 
> > I am using HP Pro curve switch, i think it supports OF 1.0 spec.
> > 
> >  
> > #####################################
> > #####################################
> > 
> > Important part of my code in the attached file
> > 
> > #####################################
> > #####################################
> > 
> > Questions:
> > 
> > 1) sendToDPID function is not working the way I expect it to work. 
> > According to me if that function works I should see packet out in wireshark.
> > 
> > 2) Am I extracting dpid of the switch correctly ?
> > 
> > 3) What is the reason for getting an error while switch connects to the POX 
> > controller ?
> > 
> > ERROR:openflow.of_01:[00-16-b9-ce-2f-40|800 1] OpenFlow Error:
> > [00-16-b9-ce-2f-40|800 1] Error: header:
> > [00-16-b9-ce-2f-40|800 1] Error:   version: 1
> > [00-16-b9-ce-2f-40|800 1] Error:   type:    1 (OFPT_ERROR)
> > [00-16-b9-ce-2f-40|800 1] Error:   length:  20
> > [00-16-b9-ce-2f-40|800 1] Error:   xid:     7
> > [00-16-b9-ce-2f-40|800 1] Error: type: OFPET_BAD_REQUEST (1)
> > [00-16-b9-ce-2f-40|800 1] Error: code: OFPBRC_BAD_TYPE (1)
> > [00-16-b9-ce-2f-40|800 1] Error: datalen: 8
> > [00-16-b9-ce-2f-40|800 1] Error: 0000: 01 12 00 08 00 00 00 07              
> >               ........
> > 
> > 
> > <sendToDPID_question.txt><sendToDPID_wireshark.png>_______________________________________________
> > mininet-discuss mailing list
> > mininet-discuss at lists.stanford.edu
> > https://mailman.stanford.edu/mailman/listinfo/mininet-discuss
> 

Reply via email to