Hmm,
If I replace flow = extract_flow(packet) with
#flow = extract_flow(packet)
flow = {}
flow[core.DL_DST] = packet.dst;
I don't seem to encounter this issue. Any idea why? Sorry if I side tracked
this a little thread. I'm still having the ToS problem when my action is
this,
actions = [[openflow.OFPAT_SET_NW_TOS,
22],[openflow.OFPAT_SET_DL_DST,
"00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"],
[openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]]
Thanks,
Aaron
On Wed, Nov 17, 2010 at 9:53 PM, Aaron Rosen <aro...@clemson.edu> wrote:
> Hi Murphy,
>
> Ok so now I'm just pinging 130.127.39.206 from 130.127.48.212 and it does
> seem to set the correct ToS bit value in this case. Though not in the case
> before when [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT] is in the
> action list.
>
> Also, I just noticed that for some reason my controller doesn't seem to be
> handling arp correctly. For example, if i do arp -d (the gateways ip
> address). My computer will start arping for the gw and the following rule
> will be installed to the switch
>
>
> idle_timeout=5,hard_timeout=0,arp,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:17:df:2b:08:
>
> 00,dl_dst=00:22:fa:62:4a:de,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0x00,nw_proto=2,tp_src=0,tp_dst=0,actions=mod_nw_tos:0x10,output:2
>
> Though for some reason the arp response never gets back to it (note: all
> the entries in the flow seem to be correct).
>
> I've also seen the following errors from nox when this happens ( Though I
> only get one of these errors at a time,)
>
> (openflow typemap) py argument to Buffer must be of type str, instead
> received
> <nox.lib.packet.ethernet.ethernet instance at 0x14e2440>
>
> <nox.lib.packet.ethernet.ethernet instance at 0xed3a70>
> (openflow typemap) py argument to Buffer must be of type str, instead
> received
>
> Perhaps this is a bug in my controller? This does not seem to happen in
> mininet when I follow the same steps to reproduce this here.
>
> Is there any chance you could at this controller? Its a basic L2 learning
> switch that handles multiple dpids, I stripped out all the extra stuff I
> had.
>
> http://pastebin.com/SfgmzaqU
>
> Thanks,
>
> Aaron
>
>
> On Wed, Nov 17, 2010 at 9:01 PM, James "Murphy" McCauley
> <jam...@nau.edu>wrote:
>
>> As an experiment, why don't you try setting the ToS bits to 0x10 and see
>> if that actually comes out like you'd expect it to.
>>
>> -- Murphy
>>
>> On Wed, 2010-11-17 at 20:49 -0500, Aaron Rosen wrote:
>> > Hi Murphy,
>> >
>> > So here is the topology: I am pinging 130.127.39.206 (<- connected via
>> > pc-engine which is running the openflow switch )from 130.127.48.212
>> > (Non-Openflow). Then I install the following action for that flow.
>> >
>> > actions = [[openflow.OFPAT_SET_NW_TOS,
>> > 22],[openflow.OFPAT_SET_DL_DST,
>> > "00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"],
>> > [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]]
>> >
>> > This basically takes these icmp packets and forward them to
>> > 130.127.39.173 (Non, openflow) The DL_DST you see there is the gateway
>> > of 130.127.39.173.
>> >
>> > On 130.127.39.173, I see the ICMP request after the entry is
>> > installed. But the ToS bits are 0x00 and not (0x16 aka 22) as I they
>> > should be.
>> >
>> > Here is the information from dpctl for that flow (as you can see
>> > packets are being matched).
>> >
>> > cookie=0, duration_sec=484s, duration_nsec=531000000s, table_id=1,
>> > priority=32768, n_packets=484, n_bytes=47432,
>> >
>> idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16,
>> > mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT
>> >
>> >
>> > Also, 130.127.39.173 and 130.127.39.206 are on different subnets (the
>> > mask is 255.255.255.128) (just pointing that out so it makes sense
>> > why i'm doing OFPP_IN_PORT).
>> >
>> > Thanks,
>> >
>> > Aaron
>> >
>> >
>> > On Wed, Nov 17, 2010 at 5:55 PM, Murphy McCauley <jam...@nau.edu>
>> > wrote:
>> > Where are you sniffing with Wireshark? On the machine running
>> > the switch? Which interface are you sniffing? It needs to be
>> > an interface the packet *goes out on after having gone through
>> > the switch* or you won't see any difference since the switch
>> > hasn't actually gotten a chance to modify it yet. In
>> > particular, this means that if you're changing the TOS in both
>> > directions for the same connection, one interface will only
>> > show the altered TOS in one direction and *another* interface
>> > will show the altered TOS in the other direction.
>> >
>> >
>> > Also note that I've only tested with Open vSwitch and not with
>> > the reference switch.
>> >
>> >
>> > -- Murphy
>> >
>> >
>> > On Nov 16, 2010, at 1:03 PM, Aaron Rosen wrote:
>> >
>> >
>> > >
>> > > Yes,
>> > >
>> > >
>> > > See screenshot. In the terminal you can see the dump-flows
>> > > rule and the packets getting forwarded in wireshark. The
>> > > n_packets increment for each icmp packet received so it is
>> > > matching this flow. (Wireshark shows the tos bits being
>> > > 0x00).
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Aaron
>> > >
>> > > On Tue, Nov 16, 2010 at 3:39 PM, Murphy McCauley
>> > > <jam...@nau.edu> wrote:
>> > > So you are seeing that the switch receives the
>> > > action correctly (that is, with the ToS modify
>> > > action and the correct new ToS bits), but the
>> > > packets aren't being modified as you expect? Are
>> > > you sure the packets you want modified are matching?
>> > >
>> > >
>> > > -- Murphy
>> > >
>> > >
>> > > On Nov 16, 2010, at 12:09 PM, Aaron Rosen wrote:
>> > >
>> > > > Murphy,
>> > > >
>> > > > Unfortunately this patch does not actually change
>> > > > the ToS bits in the ip packet. Sorry I should have
>> > > > confirmed that before I told you it worked. I just
>> > > > checkout a fresh copy of nox destiny and confirmed
>> > > > this with wireshark.
>> > > >
>> > > > (I assumed it worked before, because of this "68,
>> > > > n_packets=37, n_bytes=3626,
>> > > >
>> idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16,mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT"
>> action being installed)
>> > > >
>> > > > Sorry,
>> > > >
>> > > > Aaron
>> > > >
>> > > >
>> > > > On Mon, Nov 15, 2010 at 8:19 PM, James "Murphy"
>> > > > McCauley <jam...@nau.edu> wrote:
>> > > > Great. Pushed to destiny.
>> > > >
>> > > > -- Murphy
>> > > >
>> > > >
>> > > > On Mon, 2010-11-15 at 20:11 -0500, Aaron
>> > > > Rosen wrote:
>> > > > > Awesome Murphy that seemed to work :D
>> > > > >
>> > > > > cookie=0, duration_sec=31s,
>> > > > duration_nsec=710000000s, table_id=0,
>> > > > > priority=32768, n_packets=32,
>> > > > n_bytes=3136,
>> > > > >
>> > > >
>> idle_timeout=5,hard_timeout=0,icmp,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:04,nw_src=10.0.0.2,nw_dst=10.0.0.4,icmp_type=8,icmp_code=0,actions=mod_nw_tos:0x28,output:3
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Aaron
>> > > > >
>> > > > >
>> > > > > On Mon, Nov 15, 2010 at 7:51 PM, James
>> > > > "Murphy" McCauley
>> > > > > <jam...@nau.edu> wrote:
>> > > > > >
>> > > > > > Try this patch.
>> > > > > >
>> > > > > > Also, your parameter for
>> > > > OFPAT_SET_NW_TOS ("44") should probably be
>> > > > > an
>> > > > > > integer (44).
>> > > > > >
>> > > > > > -- Murphy
>> > > > > >
>> > > > > > On Mon, 2010-11-15 at 15:30 -0500,
>> > > > Aaron Rosen wrote:
>> > > > > > > Thanks Niky,
>> > > > > > >
>> > > > > > >
>> > > > > > > Does anyone know how I would modify
>> > > > those ToS bits then? Or what
>> > > > > all I
>> > > > > > > would have to add to make,
>> > > > make_action_array be able to modify the
>> > > > > ToS
>> > > > > > > in the manor that I'm attempting?
>> > > > > > >
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > Aaron
>> > > > > > >
>> > > > > > > On Mon, Nov 15, 2010 at 3:20 PM,
>> > > > Niky Riga <nr...@bbn.com> wrote:
>> > > > > > > I am not 100% but I think
>> > > > the problem is that the
>> > > > > > > OFPAT_SET_NW_TOS action is
>> > > > not currently handled by the
>> > > > > > > function that creates the
>> > > > actions
>> > > > > > > for the python modules.
>> > > > > > >
>> > > > > > > If you look at the core.py
>> > > > (src/nox/lib/core.py) there is
>> > > > > a
>> > > > > > > function
>> > > > > > > make_action_array() that
>> > > > creates the actions string that
>> > > > > is
>> > > > > > > sent.
>> > > > > > >
>> > > > > > > This function covers all the
>> > > > cases but the
>> > > > > OFPAT_SET_NW_TOS
>> > > > > > > action.
>> > > > > > >
>> > > > > > > Hope this is helpful.
>> > > > > > >
>> > > > > > > --niky
>> > > > > > >
>> > > > > > > Aaron Rosen wrote:
>> > > > > > >
>> > > > > > > Hello,
>> > > > > > >
>> > > > > > > I'm trying to change
>> > > > the ToS bits in IP packets
>> > > > > but
>> > > > > > > nox is telling me
>> > > > invalid action type 8.
>> > > > > > >
>> > > > > > > Here is the blurb of
>> > > > code that I'm trying:
>> > > > > > >
>> > > > > > > attrs =
>> > > > extract_flow(packet)
>> > > > > > > outport =
>> > > > self.data[dpid, mac_to_str(packet.dst)]
>> > > > > > > actions =
>> > > > [[openflow.OFPAT_SET_NW_TOS, "44"],
>> > > > > > >
>> > > > [ openflow.OFPAT_OUTPUT, [0, outport]]]
>> > > > > > >
>> > > > self.install_datapath_flow( dpid , attrs,
>> > > > 5, 0,
>> > > > > > > actions, bufid,
>> > > > openflow.OFP_DEFAULT_PRIORITY,
>> > > > > inport,
>> > > > > > > packet)
>> > > > > > >
>> > > > > > > Could anyone point
>> > > > out where I'm going wrong?
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > Aaron
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Aaron O. Rosen
>> > > > > > > Masters Student -
>> > > > Network Communication
>> > > > > > > 306B Fluor Daniel
>> > > > > > > 843.425.9777
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > >
>> ------------------------------------------------------------------------
>> > > > > > >
>> > > > > > >
>> > > >
>> _______________________________________________
>> > > > > > > nox-dev mailing list
>> > > > > > > nox-dev@noxrepo.org
>> > > > > > >
>> > > > >
>> > > >
>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Aaron O. Rosen
>> > > > > > > Masters Student - Network
>> > > > Communication
>> > > > > > > 306B Fluor Daniel
>> > > > > > > 843.425.9777
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > >
>> _______________________________________________
>> > > > > > > nox-dev mailing list
>> > > > > > > nox-dev@noxrepo.org
>> > > > > > >
>> > > >
>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Aaron O. Rosen
>> > > > > Masters Student - Network Communication
>> > > > > 306B Fluor Daniel
>> > > > > 843.425.9777
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Aaron O. Rosen
>> > > > Masters Student - Network Communication
>> > > > 306B Fluor Daniel
>> > > > 843.425.9777
>> > > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Aaron O. Rosen
>> > > Masters Student - Network Communication
>> > > 306B Fluor Daniel
>> > > 843.425.9777
>> > >
>> > >
>> > > <tos.png>
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Aaron O. Rosen
>> > Masters Student - Network Communication
>> > 306B Fluor Daniel
>> > 843.425.9777
>> >
>>
>>
>>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
> 843.425.9777
>
>
--
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
843.425.9777
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
