[pox-dev] event parsed error
Hi all, I want to manually set a flow for test. The switch sends a packet_in message to pox controller. This is the code: from pox.core import core import pox.openflow.libopenflow_01 as of from pox.lib.revent import * from pox.lib.addresses import IPAddr, EthAddr from collections import namedtuple from pox.lib.util import str_to_bool, dpid_to_str from pox.lib.packet.ipv4 import ipv4 from pox.lib.packet.ethernet import ethernet from pox.lib.packet.tcp import * from pox.lib.packet.udp import * import os log = core.getLogger() class Test_output_port (EventMixin): def __init__ (self): self.listenTo(core.openflow) def _handle_ConnectionUp (self, event): packet = event.parsed msg = of.ofp_flow_mod() msg.match = of.ofp_match.from_packet(packet, event.port); msg.buffer_id = event.ofp.buffer_id msg.idle_timeout = 10 msg.idle_timeout = 30 msg.actions.append(of.ofp_action_output(port = 1)) msg.data = event.ofp event.connection.send(msg), def launch (): ''' Starting the Firewall module ''' core.registerNew(Test_output_port) When test, it shows the following error. If anybody knows the reason, and can give some help, I will appreciate. POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al. DEBUG:core:POX 0.2.0 (carp) going up... DEBUG:core:Running on CPython (2.7.3/Sep 26 2013 20:03:06) DEBUG:core:Platform is Linux-3.2.0-58-generic-x86_64-with-Ubuntu-12.04-precise INFO:core:POX 0.2.0 (carp) is up. DEBUG:openflow.of_01:Listening on 0.0.0.0:6633 WARNING:openflow.of_01:class 'pox.openflow.PacketIn' raised on dummy OpenFlow nexus INFO:openflow.of_01:[00-00-00-00-00-01 1] connected ERROR:core:Exception while handling OpenFlowNexus!ConnectionUp... Traceback (most recent call last): File /home/guest/controller/pox/pox/lib/revent/revent.py, line 231, in raiseEventNoErrors return self.raiseEvent(event, *args, **kw) File /home/guest/controller/pox/pox/lib/revent/revent.py, line 278, in raiseEvent rv = event._invoke(handler, *args, **kw) File /home/guest/controller/pox/pox/lib/revent/revent.py, line 156, in _invoke return handler(self, *args, **kw) File /home/guest/controller/pox/pox/misc/test_flow_miss.py, line 25, in _handle_ConnectionUp packet = event.parsed AttributeError: 'ConnectionUp' object has no attribute 'parsed'
Re: [pox-dev] event parsed error
Yes, just now I change the event to like that
def _handle_PacketIn (event):
packet = event.parsed
msg = of.ofp_flow_mod()
msg.match = of.ofp_match.from_packet(packet, event.port);
msg.buffer_id = event.ofp.buffer_id
msg.idle_timeout = 10
msg.idle_timeout = 30
msg.actions.append(of.ofp_action_output(port = 1))
msg.data = event.ofp
event.connection.send(msg)
def launch ():
'''
Starting the Firewall module
'''
core.openflow.addListenerByName(PacketIn, _handle_PacketIn)
log.info(test miss flow)
It seems it can work. However, pox still gives this warning:
INFO:packet:(udp parse) warning UDP packet data shorter than UDP len: 96 962
INFO:packet:(udp parse) warning UDP packet data shorter than UDP len: 96 962
Can you give some guidance, why it has this warning.
This is my packet_in message
void get_header(struct request *req, struct ofp_packet_in *pi)
{
char *header;
struct rte_mbuf *pkt = req-pkt;
header = (char *)(rte_pktmbuf_mtod(pkt, unsigned char *));
memcpy(pi-data, header, OFP_DEFAULT_MISS_SEND_LEN);
}
static int make_packet_in(int xid, int buffer_id, char *buf)
{
struct ofp_packet_in *pi;
struct request *req;
int len;
pi = (struct ofp_packet_in *)buf;
pi-header.version = OFP_VERSION;
pi-header.type = OFPT_PACKET_IN;
pi-header.xid = htonl(xid);
req = (struct request *)ring_peek(to_channel, buffer_id);
if (req == NULL) {
fprintf(stderr, req NULL pointer.\n);
return 0;
}
else {
pi-in_port = req-in_port;
pi-buffer_id = htonl(req-buffer_id);
pi-reason = OFPR_NO_MATCH;
pi-pad = 0;
get_header(req, pi);
}
len = sizeof(*pi) + OFP_DEFAULT_MISS_SEND_LEN;
pi-header.length = htons(len);
pi-total_len = htons(len);
return len;
}
Whehter the len is not correct?
At 2014-08-20 04:10:54, Murphy McCauley murphy.mccau...@gmail.com wrote:
It seems like you want to be listening to the PacketIn event, not the
ConnectionUp event.
-- Murphy
On Aug 19, 2014, at 12:35 PM, zhang...@126.com wrote:
Hi all,
I want to manually set a flow for test. The switch sends a packet_in message
to pox controller.
This is the code:
from pox.core import core
import pox.openflow.libopenflow_01 as of
from pox.lib.revent import *
from pox.lib.addresses import IPAddr, EthAddr
from collections import namedtuple
from pox.lib.util import str_to_bool, dpid_to_str
from pox.lib.packet.ipv4 import ipv4
from pox.lib.packet.ethernet import ethernet
from pox.lib.packet.tcp import *
from pox.lib.packet.udp import *
import os
log = core.getLogger()
class Test_output_port (EventMixin):
def __init__ (self):
self.listenTo(core.openflow)
def _handle_ConnectionUp (self, event):
packet = event.parsed
msg = of.ofp_flow_mod()
msg.match = of.ofp_match.from_packet(packet, event.port);
msg.buffer_id = event.ofp.buffer_id
msg.idle_timeout = 10
msg.idle_timeout = 30
msg.actions.append(of.ofp_action_output(port = 1))
msg.data = event.ofp
event.connection.send(msg),
def launch ():
'''
Starting the Firewall module
'''
core.registerNew(Test_output_port)
When test, it shows the following error. If anybody knows the reason, and
can give some help, I will appreciate.
POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.
DEBUG:core:POX 0.2.0 (carp) going up...
DEBUG:core:Running on CPython (2.7.3/Sep 26 2013 20:03:06)
DEBUG:core:Platform is
Linux-3.2.0-58-generic-x86_64-with-Ubuntu-12.04-precise
INFO:core:POX 0.2.0 (carp) is up.
DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
WARNING:openflow.of_01:class 'pox.openflow.PacketIn' raised on dummy
OpenFlow nexus
INFO:openflow.of_01:[00-00-00-00-00-01 1] connected
ERROR:core:Exception while handling OpenFlowNexus!ConnectionUp...
Traceback (most recent call last):
File /home/guest/controller/pox/pox/lib/revent/revent.py, line 231, in
raiseEventNoErrors
return self.raiseEvent(event, *args, **kw)
File /home/guest/controller/pox/pox/lib/revent/revent.py, line 278, in
raiseEvent
rv = event._invoke(handler, *args, **kw)
File /home/guest/controller/pox/pox/lib/revent/revent.py, line 156, in
_invoke
return handler(self, *args, **kw)
File /home/guest/controller/pox/pox/misc/test_flow_miss.py, line 25, in
_handle_ConnectionUp
packet = event.parsed
AttributeError: 'ConnectionUp' object has no attribute 'parsed'
[pox-dev] pox app multi-thread or single-thread, why buffer_id in controller side sometimes is not sequence
Hi all, I want to know for the application eg l2_learning. If we run this component, l2_learning is single thread or multi-thread? My simple test: def _handle_PacketIn (event): packet = event.parsed msg = of.ofp_flow_mod() msg.match = of.ofp_match.from_packet(packet, event.port); msg.buffer_id = event.ofp.buffer_id log.info(buffer_id %i, msg.buffer_id); msg.idle_timeout = 10 msg.hard_timeout = 30 msg.actions.append(of.ofp_action_output(port = 0)) msg.data = event.ofp event.connection.send(msg) When I print out the buffer_id message, sometimes it is not sequence. I got the result like that: INFO:packet:(udp parse) warning UDP packet data shorter than UDP len: 96 962 INFO:misc.test_flow_miss:buffer_id 0 INFO:openflow.of_01:[00-00-00-00-00-01 2] connected INFO:packet:(udp parse) warning UDP packet data shorter than UDP len: 96 962 INFO:misc.test_flow_miss:buffer_id 2 This makes me very confused. At first, I thought just one single thread for the app. app processed the requests according to FIFO mode. Can anybody give some help and explain some reason for my result? Another question: In pox wiki, when we want to install a flow entry: if the tcp port is 8080, why in python code, we do not need to do htons translation. However, the switch side receives the port is network endian.
Re: [pox-dev] pox app multi-thread or single-thread, why buffer_id in controller side sometimes is not sequence
Thank you very much for your reply! See below. At 2014-08-20 02:48:33, Murphy McCauley murphy.mccau...@gmail.com wrote: On Aug 19, 2014, at 8:22 PM, 张伟 zhang...@126.com wrote: Hi all, I want to know for the application eg l2_learning. If we run this component, l2_learning is single thread or multi-thread? Single threaded. My simple test: def _handle_PacketIn (event): packet = event.parsed msg = of.ofp_flow_mod() msg.match = of.ofp_match.from_packet(packet, event.port); msg.buffer_id = event.ofp.buffer_id log.info(buffer_id %i, msg.buffer_id); msg.idle_timeout = 10 msg.hard_timeout = 30 msg.actions.append(of.ofp_action_output(port = 0)) msg.data = event.ofp event.connection.send(msg) When I print out the buffer_id message, sometimes it is not sequence. I got the result like that: INFO:packet:(udp parse) warning UDP packet data shorter than UDP len: 96 962 INFO:misc.test_flow_miss:buffer_id 0 INFO:openflow.of_01:[00-00-00-00-00-01 2] connected INFO:packet:(udp parse) warning UDP packet data shorter than UDP len: 96 962 INFO:misc.test_flow_miss:buffer_id 2 This makes me very confused. At first, I thought just one single thread for the app. app processed the requests according to FIFO mode. Can anybody give some help and explain some reason for my result? The buffers come from the switches. How the switches decide on buffer IDs is not specified. Are you sure your switch is sending buffer IDs that increment by one? Have you snooped the control connection to confirm this? Another possibility is that a higher priority packet-in handler is getting the event first and eating it. If all you're running is l2_learning (and not, say, discovery) this shouldn't be the case, though. Yes, I am sure that the switch sends the buffer IDs that increment by one. Actually the buffer ID starts from 0. On my above component, from the log.info I can see that the buffer id starts from 0. However, on the switch side, when receiving the flow_mod message, the first buffer_id is always UINT32_MAX. On the controller side, I only run my own component. So this repsents other component sends the flow_mod message with buffer_id is UINT32_MAX. Do you think where can send this message? Another question: In pox wiki, when we want to install a flow entry: if the tcp port is 8080, why in python code, we do not need to do htons translation. However, the switch side receives the port is network endian. Because it would be awful if you had to do it yourself and POX takes care of it for you. Can you help to point out where in pox do the translation? -- Murphy
[pox-dev] wirshark plugin install error
Hi all,
According to Murphy guidance, I want to install wireshark openflow plugin to
inspect the packets. After installing and run wireshark, I met this error:
Couldn't load module /home/guest/.wireshark/plugins/openflow.so
/home/guest/.wireshark/plugins/openflow.so undefined symbol:try_val_to_str
ls -l /usr/lib/wireshark/libwireshark1/plugins/
-rwxr-xr-x 1 root root 142851 Jun 24 22:46 openflow.so
-rw-r--r-- 1 root root 188763 Aug 23 08:45 packet-openflow.so
In openflow packet_openflow.c file, I have added
#define NO_STRINGS NULL
modify this function:
void proto_reg_handoff_openflow()
{
openflow_handle = create_dissector_handle(dissect_openflow, proto_openflow);
//dissector_add(TCP_PORT_FILTER, global_openflow_proto, openflow_handle);
dissector_add_unit(TCP_PORT_FILTER, global_openflow_proto, openflow_handle);
}
Does anybody meet this problem and can give me some suggestions?
Re: [pox-dev] wirshark plugin install error
My wireshark version is 1.6.7. I follow this link to configure
http://networkstatic.net/installing-wireshark-on-linux-for-openflow-packet-captures/
By default, the wireshark does not have openflow.so and packet-openflow.so
plugins. So I think the official wireshark version I used does not support the
openflow. I will learn your build method and try it.
At 2014-08-24 06:46:28, Murphy McCauley murphy.mccau...@gmail.com wrote:
Wireshark is adding official support for OpenFlow. You may already have it.
This might explain why you have both openflow.so and packet-openflow.so, which
seems strange to me offhand. The point being that you may not need to build an
OpenFlow dissector yourself at all.
If you do want/need to build a dissector yourself, you probably don't want to
use the one from the actual OpenFlow reference. The last time I built the
original dissector, it was from this updated version:
https://bitbucket.org/barnstorm/of-dissector
You might find more help on the openflow-discuss list.
-- Murphy
On Aug 23, 2014, at 6:01 AM, 张伟 zhang...@126.com wrote:
Hi all,
According to Murphy guidance, I want to install wireshark openflow plugin to
inspect the packets. After installing and run wireshark, I met this error:
Couldn't load module /home/guest/.wireshark/plugins/openflow.so
/home/guest/.wireshark/plugins/openflow.so undefined symbol:try_val_to_str
ls -l /usr/lib/wireshark/libwireshark1/plugins/
-rwxr-xr-x 1 root root 142851 Jun 24 22:46 openflow.so
-rw-r--r-- 1 root root 188763 Aug 23 08:45 packet-openflow.so
In openflow packet_openflow.c file, I have added
#define NO_STRINGS NULL
modify this function:
void proto_reg_handoff_openflow()
{
openflow_handle = create_dissector_handle(dissect_openflow, proto_openflow);
//dissector_add(TCP_PORT_FILTER, global_openflow_proto, openflow_handle);
dissector_add_unit(TCP_PORT_FILTER, global_openflow_proto, openflow_handle);
}
Does anybody meet this problem and can give me some suggestions?
Re: [pox-dev] wirshark plugin install error
Hi Rahul,
Thank you very much for your blog! I have made wireshark working on ubuntu
platform.
However, for my bug, I still have not yet figured out why this happens.
I want to give a description, can you help to look at it? I have sent the email
to Murphy.
My problem is :
On the switch side: I sent packet_in packets to pox controller. These packet_in
packets only buffer_id is different, others are the same. Buffer id starts from
0. use wireshark to capture the pacekts, I can find that on pox side, buffer id
also starts from 0. The attachment test_new.pcap I checked the capture result.
pox.txt is my test app pox log file. The following is my test app, you can see
I print out the buffer id. The buffer id starts not from 0, every test time the
buffer id starts differently. At the beginning, there are some warning
messages. If the buffer id starts from 263. The warning lines is 263 lines. I
do not why always some packet_in packets do not deliver to my test app. I have
no any idea how to track this problem deeply. Now I am waiting Murphy's reply.
I am newer to POX. Can you also help to look at it?
def _handle_PacketIn (event):
packet = event.parsed
msg = of.ofp_flow_mod()
msg.match = of.ofp_match.from_packet(packet, event.port);
msg.buffer_id = event.ofp.buffer_id
log.info(buffer_id %i, msg.buffer_id);
msg.idle_timeout = 10
msg.hard_timeout = 30
msg.actions.append(of.ofp_action_output(port = 0))
msg.data = event.ofp
event.connection.send(msg)
def launch ():
'''
Starting the Firewall module
'''
core.openflow.addListenerByName(PacketIn, _handle_PacketIn)
log.info(test miss flow)
在 2014-08-25 02:26:37，Rahul Sharma rahulsharma...@gmail.com 写道：
Hi Zang,
You can follow the steps which I have written for ubuntu:
https://rahulait.wordpress.com/2014/08/02/installing-openflow-dissector-plugin-for-wireshark-in-ubuntu/
I have used the same bitbucket code as mentioned by Murphy. I hope it helps.
Regards
Rahul
On Sun, Aug 24, 2014 at 2:27 PM, Murphy McCauley murphy.mccau...@gmail.com
wrote:
Right, yours is pretty old. The last build I did (on Mac OS) was against
1.10.7, but this version seems to be pretty easy and I believe basically just
works with the updated dissector
(https://bitbucket.org/barnstorm/of-dissector).
I'd suggest you may make your life easier by building Wireshark 1.10.7 from
source, then building the dissector against that.
-- Murphy
On Aug 23, 2014, at 7:01 PM, 张伟 zhang...@126.com wrote:
My wireshark version is 1.6.7. I follow this link to configure
http://networkstatic.net/installing-wireshark-on-linux-for-openflow-packet-captures/
By default, the wireshark does not have openflow.so and packet-openflow.so
plugins. So I think the official wireshark version I used does not support the
openflow. I will learn your build method and try it.
At 2014-08-24 06:46:28, Murphy McCauley murphy.mccau...@gmail.com wrote:
Wireshark is adding official support for OpenFlow. You may already have it.
This might explain why you have both openflow.so and packet-openflow.so, which
seems strange to me offhand. The point being that you may not need to build an
OpenFlow dissector yourself at all.
If you do want/need to build a dissector yourself, you probably don't want to
use the one from the actual OpenFlow reference. The last time I built the
original dissector, it was from this updated version:
https://bitbucket.org/barnstorm/of-dissector
You might find more help on the openflow-discuss list.
-- Murphy
On Aug 23, 2014, at 6:01 AM, 张伟 zhang...@126.com wrote:
Hi all,
According to Murphy guidance, I want to install wireshark openflow plugin to
inspect the packets. After installing and run wireshark, I met this error:
Couldn't load module /home/guest/.wireshark/plugins/openflow.so
/home/guest/.wireshark/plugins/openflow.so undefined symbol:try_val_to_str
ls -l /usr/lib/wireshark/libwireshark1/plugins/
-rwxr-xr-x 1 root root 142851 Jun 24 22:46 openflow.so
-rw-r--r-- 1 root root 188763 Aug 23 08:45 packet-openflow.so
In openflow packet_openflow.c file, I have added
#define NO_STRINGS NULL
modify this function:
void proto_reg_handoff_openflow()
{
openflow_handle = create_dissector_handle(dissect_openflow, proto_openflow);
//dissector_add(TCP_PORT_FILTER, global_openflow_proto, openflow_handle);
dissector_add_unit(TCP_PORT_FILTER, global_openflow_proto, openflow_handle);
}
Does anybody meet this problem and can give me some suggestions?
[pox-dev] open vswitch connects pox
Hi all, I want open vswitch connects pox and do some tests. My setting is: machineA: packet generator(promis mode) It will send packets to open vswitch, if miss flow table, open vswtich will connect to pox. packet generator port mac:90:e2:ba:2f:f2:e9 machineB: open vswitch mac address:90:e2:ba:4a:e8:09 I can see that there is a flow entry about my packets. cookie=0x0, duration=15.413s, table=0, n_packets=18734206, n_bytes=18659269176, idle_timeout=10,hard_timeout=30,priority=65535,udp,in_port=3,vlan_tci=0x,dl_src=90:e2:ba:2f:f2:e9,dl_dst=90:e2:ba:4a:e8:09,nw_src=192.168.1.1,nw_dst=0.0.0.0,nw_tos=0,tp_src=5678,tp_dst=1234 actions=output:3 However, when I monitor eth2(openflow port 3), I can not find any packet sending out. I can not find where is the problem? Does anybody know the reason and can give me some advices?
[pox-dev] openflow multipath
Hi all, I want to know does anybody know something about openflow multipath feature or use it before? Can anybody give some advices how to set it using command line that the flow entry with multipath feature?
[pox-dev] openvswitch tap device drop the packets?
Hi all, I have a question for the tap device attached to openvswitch bridge. My aim is to send the packets from tap device of physical machine A(physical IP:10.48.24.63) to tap device of physical machine B(physical IP:10.48.24.67) with vxlan setting. What I did is 1)Physical machine A (physical IP:10.48.24.63) step1: create a tap device and make it up #create tap device tunctl -t tap0 ifconfig tap0 192.168.5.63 up step2: create bridge, vxlan device and attach tap device #create bridge and add ports ovs-vsctl add-br ovs-br0 ovs-vsctl add-port ovs-br0 tap0 ovs-vsctl add-port ovs-br0 vxlan0 -- set interface vxlan0 type=vxlan options:local_ip=10.48.24.63 options:remote_ip=10.48.24.67 options:key=flow step3: #check port id in ovs bridge ovs-ofctl show ovs-br0 step4: #add flow entry from tap device to vxlan device and from vxlan device to tap device ovs-ofctl add-flow ovs-br0 in_port=1, actions=output:2 outgoing ovs-ofctl add-flow ovs-br0 in_port=2, actions=output:1 incoming On physical machine B, I did the similar operations. The tap device in physical machine B is 192.168.5.67 When I ping the tap device 192.168.5.67 of physical machine B from physical machine A, ping 192.168.5.67 I found that tap device droped alll of the packets on physical machine A. I did not know why. Can somebody give me some advice? The following is the output on my physical machine A. the ports statistical information, flow entries, the port id in openvswitch. ovs-ofctl dump-ports ovs-br0（ports statistical information） OFPST_PORT reply (xid=0x2): 3 ports port 1: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=8124, errs=0, coll=0 port 4: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 port LOCAL: rx pkts=6, bytes=468, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 ovs-ofctl dump-flows ovs-br0(flow entries) NXST_FLOW reply (xid=0x4): cookie=0x0, duration=50903.320s, table=0, n_packets=0, n_bytes=0, idle_age=50903, priority=2,in_port=1,dl_dst=ce:82:4a:f4:2d:f3 actions=output:4 cookie=0x0, duration=71137.959s, table=0, n_packets=5, n_bytes=378, idle_age=65534, hard_age=65534, priority=0 actions=NORMAL cookie=0x0, duration=1544.792s, table=0, n_packets=0, n_bytes=0, idle_age=1544, priority=2,in_port=4 actions=output:1 ovs-ofctl show ovs-br0(port information) OFPT_FEATURES_REPLY (xid=0x2): dpid:eafeac000142 n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE 1(tap0): addr:46:f1:26:89:45:88 config: 0 state: 0 current:10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 4(vxlan0): addr:0a:25:64:47:8b:f9 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(ovs-br0): addr:ea:fe:ac:00:01:42 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
