Re: [nox-dev] strange ethernet type returned by authenticator
One thing that I never got to doing is to change all the parsing to go through the openflow-pack library which will fix the byte order issue. If someone would do that, it would be a great service to people using NOX. Regards KK On 2 May 2011 10:48, Murphy McCauley wrote: > So I'm not sure if this is a bug or a feature. If NOX has a really coherent > strategy towards byte order, I've never really figured it out. :) But the > problem is just that your bytes are getting swapped. I'd say just call > ntohs() on event.flow_dl_type. (Equivalently, call htons() on whatever you're > comparing it with... this probably makes more sense, but may be slightly less > convenient.) > > -- Murphy > > On Monday, May 02, 2011 10:25:22 AM karim torkmen wrote: >> Hi, >> I am using the authenticator module. >> I registered to the flow in event : >> self.register_handler(Flow_in_event.static_get_name(),self.flow_in_call_bac >> k) When I try to get the EtherType of a flow through calling this >> parameter: type = event.flow.dl_type >> I get EtherType equal to "25480" which is "0x6388", however I am >> expecting to get a PPP type "34915 (0x8863)". >> Does any one have an idea about this, could it be a bug ? >> Thanks a lot for the help, >> Karim >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] strange ethernet type returned by authenticator
Thanks a lot, that worked perfectly :) On 05/02/2011 07:48 PM, Murphy McCauley wrote: So I'm not sure if this is a bug or a feature. If NOX has a really coherent strategy towards byte order, I've never really figured it out. :) But the problem is just that your bytes are getting swapped. I'd say just call ntohs() on event.flow_dl_type. (Equivalently, call htons() on whatever you're comparing it with... this probably makes more sense, but may be slightly less convenient.) -- Murphy On Monday, May 02, 2011 10:25:22 AM karim torkmen wrote: Hi, I am using the authenticator module. I registered to the flow in event : self.register_handler(Flow_in_event.static_get_name(),self.flow_in_call_bac k) When I try to get the EtherType of a flow through calling this parameter: type = event.flow.dl_type I get EtherType equal to "25480" which is "0x6388", however I am expecting to get a PPP type "34915 (0x8863)". Does any one have an idea about this, could it be a bug ? Thanks a lot for the help, Karim ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] strange ethernet type returned by authenticator
So I'm not sure if this is a bug or a feature. If NOX has a really coherent strategy towards byte order, I've never really figured it out. :) But the problem is just that your bytes are getting swapped. I'd say just call ntohs() on event.flow_dl_type. (Equivalently, call htons() on whatever you're comparing it with... this probably makes more sense, but may be slightly less convenient.) -- Murphy On Monday, May 02, 2011 10:25:22 AM karim torkmen wrote: > Hi, > I am using the authenticator module. > I registered to the flow in event : > self.register_handler(Flow_in_event.static_get_name(),self.flow_in_call_bac > k) When I try to get the EtherType of a flow through calling this > parameter: type = event.flow.dl_type > I get EtherType equal to "25480" which is "0x6388", however I am > expecting to get a PPP type "34915 (0x8863)". > Does any one have an idea about this, could it be a bug ? > Thanks a lot for the help, > Karim > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] strange ethernet type returned by authenticator
Hi, I am using the authenticator module. I registered to the flow in event : self.register_handler(Flow_in_event.static_get_name(),self.flow_in_call_back) When I try to get the EtherType of a flow through calling this parameter: type = event.flow.dl_type I get EtherType equal to "25480" which is "0x6388", however I am expecting to get a PPP type "34915 (0x8863)". Does any one have an idea about this, could it be a bug ? Thanks a lot for the help, Karim ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] some explanations about pyrouting memebers
I wouldn't call myself an expert on the routing component, but... If you're not using nat_enforcer/pass False for check_nat, I think setup_flow() is basically just a flow_mod, possibly followed by a packet_out if you supply a buffer and no buffer ID. You can specify extra actions, but it appends an output action to the specified outport. (Note that in the case where it does send a packet_out, this function is buggy. It *should* send the flow_mod, then a barrier, and then the packet_out, but the barrier is missing. Depending on your switch and whether you've got bufids, this may or may not be a problem. We're working on addressing this and some related but more problematic instances.) Again, if you're not using nat_enforcer, I think send_packet() pretty much just generates a packet_out. Again, you can specify extra actions, but it appends an output action to the specified port. In both cases, things are more complicated if you're using nat_enforcer, which I never have, and I couldn't tell you much about it without reading the code or asking someone else on the list. :) Hope that helps. -- Murphy On Monday, May 02, 2011 05:17:53 AM karim torkmen wrote: > Hi, > I need to know what does the following functions do, unfortuanately no > documnetation is provided for them: > > - setup_flow(self, flow, dp, outport, bid, buf, timeout,actions, check_nat) > - send_packet(self, dp, inport, outport, bid, buf, > actions, check_nat, flow) > > Can anyone explain it to me. > Thanks a lot, > Karim > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] NW_TOS can not work
You just want to check the TOS field value of a packet you got from a Python packet_in handler? In that case, all that matters is ipv4.py (from the Python packet parsing library), and I'm pretty sure the TOS field works fine in it. So if you're seeing packet.next.tos is 0, then... I suspect it is actually 0 on the wire (which is true most of the time...). I'd suggest you use wireshark or tcpdump or something to analyze the traffic. If you can find packets with those that have a nonzero TOS, but they're showing up in NOX as 0, please send a packet trace and your NOX code. -- Murphy On Monday, May 02, 2011 07:46:23 AM false wrote: > Hi, > > My NOX controller version is zaku. > > I recently wanted to know the tos field value, so I print > openflow.OFPFW_NW_TOS and packet.next.tos, but these results were so > strange like the following: openflow.OFPFW_NW_TOS = 2097152 > packet.next.tos=0 > Not only ping, but also ftp service, they were always the same results. > I surveyed nox-dev and tried to fix the problem according this post: > http://www.mail-archive.com/nox-dev@noxrepo.org/msg01708.html > but it's no use, and I found this post: > http://www.mail-archive.com/nox-dev@noxrepo.org/msg01396.html > > So, NW_TOS can not work now? > > Can anybody tell me how to solve this problem? > Any suggest will be helpful. Thank you! > > Yi-Shou ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] [openflow-discuss] OpenFlow Error (type=1, code=7) (type=1, code=8)
Hi Marwen I believe this is a problem with your NOX code. Could you please mail to the nox-dev list relevant pieces of your code and folks can help you figure out what is going wrong? Please drop openflow-discuss list from the future replies. Thanks Srini. On Mon, May 2, 2011 at 3:24 AM, marwen marwen wrote: > Hi Niky, > Thank you for your reply. > I verified that is a problem of sending two instruction to the switch with > the same buffer_id. and after that the buffer_id is changed to 'None' that's > why I have this error messages. > In my Nox application I put in the parameters of "install_datapath_flow" > function the same buffer_id received from the switchs. > But I don't know if this problem is related to Openflow switches or the Nox > application. and can I resolve this problem. > Best regards > Marwen > > 2011/5/1 Niky Riga >> >> Hi Marwen, >> According to the OpenFlow 1.0.0 specification doc >> (http://www.openflow.org/documents/openflow-spec-v1.0.0.pdf page 39) >> >> type=1 error is a bad request error (OFPET_BAD_REQUEST) and >> codes 7 and 8 mean buffer empty and buffer unknown >> (OFPBRC_BUFFER_EMPTY, /* Specified buffer has already been used. */ >> OFPBRC_BUFFER_UNKNOWN /* Specified buffer does not exist. */) >> >> Make sure that you only send one instruction to the switch for each >> bufferid, you >> can specify multiple actions in the same instruction. >> >> Hope this helps, >> Niky >> >> marwen marwen wrote: >>> >>> Hi all, >>> >>> I'm using OpenFlow 1.0 but I have this ERROR >>> >>> openflow-event|ERR: received Openflow error packet from >>> dpid=000d: type=1, code=7 >>> >>> and sometimes I have this ERROR >>> >>> openflow-event|ERR: received Openflow error packet from >>> dpid=000a: type=1, code=8 >>> >>> Please can you help me to resolve this problem >>> >>> Thank you >>> Best regards >>> Marwen >>> >>> >>> >>> ___ >>> openflow-discuss mailing list >>> openflow-disc...@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >> > > > ___ > openflow-discuss mailing list > openflow-disc...@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] NW_TOS can not work
Hi, My NOX controller version is zaku. I recently wanted to know the tos field value, so I print openflow.OFPFW_NW_TOS and packet.next.tos, but these results were so strange like the following: openflow.OFPFW_NW_TOS = 2097152 packet.next.tos=0 Not only ping, but also ftp service, they were always the same results. I surveyed nox-dev and tried to fix the problem according this post: http://www.mail-archive.com/nox-dev@noxrepo.org/msg01708.html but it's no use, and I found this post: http://www.mail-archive.com/nox-dev@noxrepo.org/msg01396.html So, NW_TOS can not work now? Can anybody tell me how to solve this problem? Any suggest will be helpful. Thank you! Yi-Shou ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] some explanations about pyrouting memebers
Hi, I need to know what does the following functions do, unfortuanately no documnetation is provided for them: - setup_flow(self, flow, dp, outport, bid, buf, timeout,actions, check_nat) - send_packet(self, dp, inport, outport, bid, buf, actions, check_nat, flow) Can anyone explain it to me. Thanks a lot, Karim ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
