Hi Ikf, I am assuming you are running wireshark on the control channel. Then the following behavior is correct:
> From the packet dumps it appears that the packets are being dropped, because > after the first http packet in "Dump command on" no others arrive. However > in "Dump command off" you can see others. With the flow_mod, the switch will match the subsequent packets and none of them will hit the controller anymore. They are just being forwarded. Without the flow_mod, each new packet will not be matched and thus sent up. Can you check if there is any packet_out sent too? I do not quite comprehend the rest, so I will refrain from commenting. Regards KK On 14 July 2010 06:33, <i...@cs.nott.ac.uk> wrote: > Hi, > > Sorry for the late reply. I better explain my set-up first. I am connected > to the university of Nottingham by my main computer named Zeus. Zeus has two > interfaces. One connected to the university network its IP is 128.243.18.33. > The other interface is connected to my other computer (NEIGHBOR). The > interface on Zeus has IP 192.168.1.2 . The interface of NEIGHBOR has IP > 192.168.1.1 . > > Zeus acts as a gateway to the Internet/Uni Network for NEIGHBOR. I am > running NOX and openflow on Zeus. So I have run two tests with NOX using > packetdump. First the prior mentioned component is run normally. Second I > comment out send_openflow_command so no flow command is being sent. > > I have cut and pasted the relevant information from the packet dump into the > two attached files. "Dump command on" is when the command is being sent and > vice versa for "Dump command off". > > From the packet dumps it appears that the packets are being dropped, because > after the first http packet in "Dump command on" no others arrive. However > in "Dump command off" you can see others. > > However even when I run the component normally, NEIGHBOR still gets the http > file. I have also run wireshark, while the command is on and I can see > multiple HTTP packets to and from NEIGHBOR. Any ideas? > > Thanks in advance > Iain > > PS the attached files are just standard text files > > On Jul 12 2010, kk yap wrote: > >> Hi Iain, >> >> Would you might looking at the control traffic dump to let us know if >> you keeping receiving more packet-in after inserting the flow rule? >> >> Also, is there any reason not to set the vlan_pcp? >> >> Regards >> KK >> >> On 12 July 2010 07:20, <i...@cs.nott.ac.uk> wrote: >> > Hi guys, >> > >> > I don't think I made it clear in the previous post. The code in the > >> > previous post only gets called when the flow is identified as HTTP. > Then >> > I >> > am trying to block that particular flow. I know it would make > more sense >> > to write general rule and send the command from the install > method. I am >> > just doing this initially to see if I can get any packets > dropped. >> > >> > Thanks Again >> > Iain >> > >> > On Jul 12 2010, i...@cs.nott.ac.uk wrote: >> > >> >> Hi Everyone, >> >> >> >> I am running NOX and openflow on the same machine. I am coding the >> >> >> NOX controller in C++. I am trying to write code to selectively drop >> >> >> packets. For a quick test I tried to write code that would drop HTTP >> >> >> (i.e. tcp dst port 80) packets. >> >> >> >> The code correctly identifies the HTTP packet and it calls the >> >> >> send_openflow_command with no action. However the packets are not >> >> >> getting >> >> dropped. Below is initialisation of the openflow mod >> structure. Which >> >> is >> >> sent in the command. >> >> >> >> // setup the header ofm.header.version = OFP_VERSION; >> >> >> ofm.header.type = OFPT_FLOW_MOD; ofm.header.length = >> >> >> htons(sizeof ofm); // no extended action data >> >> >> >> // match the flow - therefore no wild-cards! >> >> >> ofm.match.wildcards = htonl(0); ofm.match.in_port = >> >> >> htons(flow.in_port); ofm.match.dl_vlan = flow.dl_vlan; >> >> >> memcpy(ofm.match.dl_src,flow.dl_src.octet,sizeof ofm.match.dl_src); >> >> >> memcpy(ofm.match.dl_dst,flow.dl_dst.octet,sizeof >> ofm.match.dl_dst); >> >> ofm.match.dl_type = flow.dl_type; >> ofm.match.nw_src = >> >> flow.nw_src; ofm.match.nw_dst = >> flow.nw_dst; >> >> ofm.match.nw_proto = flow.nw_proto; >> ofm.match.tp_src = >> >> flow.tp_src; ofm.match.tp_dst = >> flow.tp_dst; >> >> >> >> // add an entry - initalise entry housekeeping variables (see >> >> >> page 28 of OF spec) ofm.command = htons(OFPFC_ADD); >> >> >> ofm.buffer_id = htonl(packetid); ofm.idle_timeout = >> >> >> htons(OFP_FLOW_PERMANENT); ofm.hard_timeout = >> >> >> htons(OFP_FLOW_PERMANENT); >> >> >> >> ofm.priority = htons(OFP_DEFAULT_PRIORITY); >> >> ofm.flags = OFPFF_CHECK_OVERLAP; >> >> >> >> When I run dpctl dump-flows on the switch I get >> >> >> cookie=14431522174269325312, duration_sec=15s, >> >> >> duration_nsec=832000000s, >> >> table_id=0, priority=65535, n_packets=3, >> n_bytes=222, >> >> >> idle_timeout=0,hard_timeout=0,tcp,in_port=1,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:07:e9:ae:04:c7,dl_dst=00:13:d3:c0:46:f2,nw_src=192.168.1.1,nw_dst=91.189.88.31,nw_tos=0x00,tp_src=58891,tp_dst=80,actions= >> >> >> >> >> >> Any ideas on what I am doing wrong? >> >> >> >> thanks in advance >> >> Iain >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> nox-dev mailing list >> >> nox-dev@noxrepo.org >> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> >> > >> > _______________________________________________ >> > nox-dev mailing list >> > nox-dev@noxrepo.org >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> > > _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
