Murphy, Andrew,
Thanks to both of you for your help, but I'm still having no luck.
Apparently there are (at least?) two ways to do it. Andrew suggested
using recv_port=OFPP_NONE and buffer=BUFFER_ID_NONE which is what I was
doing. Murphy's sample capture did it by settting the Recv_port=1
and output_port=OFPP_IN_PORT.
Murphy also suggested making sure that we have specified an output
action, but I was already doing that too.
Here's a wireshark dump of the message being sent to the controller. It
has a buffer_id=none, recv_port=none, and an output action going to
port 2. As far as I can tell it's OK (and the switch does not return
an error), but a wireshark connected to port 2 does not see anything.
Any suggestions are welcome!
=============================================================================
No. Time Source Destination Protocol Info
20 66.708269 NiciraNe_65:e7:2a LLDP_Multicast OFP+LLDP Packet
Out (CSM) (60B) => Chassis Id = 00:23:20:65:e7:2a Port Id = TTL = 5000
Frame 20: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: 3com_62:e4:5f (00:50:04:62:e4:5f), Dst: 20:aa:4b:3e:5f:33
(20:aa:4b:3e:5f:33)
Internet Protocol, Src: 192.168.1.10 (192.168.1.10), Dst: 192.168.1.1
(192.168.1.1)
Transmission Control Protocol, Src Port: 6633 (6633), Dst Port: 33732 (33732),
Seq: 77, Ack: 233, Len: 60
OpenFlow Protocol
Header
Version: 0x01
Type: Packet Out (CSM) (13)
Length: 60
Transaction ID: 0
Packet Out
Buffer ID: None
Frame Recv Port: None (not associated with a physical port)
Size of action array in bytes: 8
Output Action(s)
Action
Type: Output to switch port (0)
Len: 8
Output port: 2
Max Bytes to Send: 0
# of Actions: 1
Frame Data: 0180c200000e00232065e72a88cc02070400232065e72a04...
Ethernet II, Src: NiciraNe_65:e7:2a (00:23:20:65:e7:2a), Dst:
LLDP_Multicast (01:80:c2:00:00:0e)
Link Layer Discovery Protocol
0000 20 aa 4b 3e 5f 33 00 50 04 62 e4 5f 08 00 45 00 .K>_3.P.b._..E.
0010 00 64 e5 18 40 00 40 06 d2 1f c0 a8 01 0a c0 a8 .d..@.@.........
0020 01 01 19 e9 83 c4 8b 64 50 1c 9e 8d d7 0a 50 18 .......dP.....P.
0030 00 6c 83 b2 00 00 01 0d 00 3c 00 00 00 00 ff ff .l.......<......
0040 ff ff ff ff 00 08 00 00 00 08 00 02 00 00 01 80 ................
0050 c2 00 00 0e 00 23 20 65 e7 2a 88 cc 02 07 04 00 .....# e.*......
0060 23 20 65 e7 2a 04 05 02 00 00 00 02 06 02 13 88 # e.*...........
0070 00 00 ..
=============================================================================
On Fri, Feb 08, 2013 at 10:40:18AM -0800, Murphy McCauley wrote:
> On Feb 8, 2013, at 10:19 AM, Peter Fales wrote:
>
> > Can anyone supply a wireshark dump of a good packet-out message that
> > I could compare with ours to wee what might be different? Or, is
> > there anyway to look inside our Pantou/Openwrt switch to see what
> > it "dislikes" about our packet out message?
>
> Here's one.
>
> This was generated with POX's openflow.debug component, so it's not a real
> capture, but you can see the packet out message just fine. (Specifically, I
> generated it with "./pox.py misc.pong openflow.debug" and a ping in Mininet.)
>
> -- Murphy
>
--
Peter Fales
Alcatel-Lucent
Member of Technical Staff
1960 Lucent Lane
Room: 9H-505
Naperville, IL 60566-7033
Email: peter.fa...@alcatel-lucent.com
Phone: 630 979 8031
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
