It is not clear to me what this patch is. From what I understand, it is because some switches does not completely strip VLAN tags. Is that what this is? Can't really comment on anything I do not understand, beyond I am unclear on what this is.
As for patches, I am particularly touchy on non-OpenFlow compliant and switch-specific ones. But I do not speak for everyone that has commit rights to NOX. Beyond, we are generally happy to take patches, esp. documented ones. Regards KK PS>> might be good to address to nox comitters in nox-dev and not openflow-discuss. On 9 November 2010 13:46, Rob Sherwood <rob.sherw...@stanford.edu> wrote: > nox-dev commiters: > > is there any reason why this patch shouldn't be pushed into the > repository? IIRC, this is not the first time Srini has proposed this > fix. > > > - Rob > . > > > > On Tue, Nov 9, 2010 at 1:41 PM, Srini Seetharaman <seeth...@stanford.edu> > wrote: >> Please try the attached patch. This pays attention to whether the LLDP >> packet has a VLAN tag in the pkt_in and handles it correctly. >> Hopefully, after git-apply of this patch, you shudn't see those >> errors. >> >> On Tue, Nov 9, 2010 at 1:28 PM, Srini Seetharaman <seeth...@stanford.edu> >> wrote: >>> Hi Chris >>> I assume all packets sent/received by the switch are VLAN tagged in >>> your case? Could you please mail us a copy of the control traffic (so >>> that we can look at the pkt_in for the LLDP msg). Ideally, the "match" >>> function in the discovery.py shud've already set a condition that only >>> packets with DL_TYPE of LLDP_TYPE will be sent to >>> lldp_input_handler(). So, it is unclear why this happened. >>> >>> Thanks >>> Srini. >>> >>> On Tue, Nov 9, 2010 at 12:16 PM, Christopher J. Tengi >>> <te...@cs.princeton.edu> wrote: >>>> Greetings All, >>>> In my efforts to get past the limitations of the current release of >>>> snac, >>>> I have decided to jump in with both feet to nox destiny territory and try >>>> to >>>> get both it and nox-gui.py running. My goal is to have nox make 3 HP >>>> switches using VLAN aggregation mode with tagged uplink ports act as >>>> learning switches. Currently, the switches are in a star topology, with >>>> the >>>> central switch running non-OpenFlow firmware, so there are no >>>> OpenFlow-to-OpenFlow switch links. I cloned nox from noxrepo.org and >>>> checked out the destiny branch. I built it with configure arguments of >>>> "--prefix=/var/local --with-python=yes --with-gnu-ld" and both the "make" >>>> and "make check" succeeded. >>>> >>>> >>>> Based on various things I've read, and with a self-proclaimed limited >>>> understanding of how some of this stuff glues together, I started nox with >>>> these commands: >>>> >>>> cd /var/local/src/nox/build/src >>>> ./nox_core -i ptcp:6633 pyswitch discovery lavi monitoring switchstats >>>> topology >>>> >>>> 'lsof' commands on both the flowvisor and nox machines, as well as fvctl, >>>> tell me that I have a connection between them for each of the 3 DPIDs in >>>> play. And while the laptop I am connecting to one of the switches appears >>>> to be working, for the most part, I get loads and loads of the following >>>> sent to the xterm window where I am running nox: >>>> >>>> >>>>> 00925|pyrt|ERR:unable to invoke a Python event handler: >>>>> Traceback (most recent call last): >>>>> File "./nox/lib/util.py", line 116, in f >>>>> event.total_len, buffer_id, packet) >>>>> File "./nox/netapps/discovery/discovery.py", line 163, in <lambda> >>>>> discovery.lldp_input_handler(self,dp,inport,reason,len,bid,packet), >>>>> File "./nox/netapps/discovery/discovery.py", line 250, in >>>>> lldp_input_handler >>>>> assert (packet.type == ethernet.LLDP_TYPE) >>>>> AssertionError >>>> >>>> I suspect that any client-side problems I am currently having are due to >>>> the lack of capabilities of the example pyswitch code, and I plan to >>>> investigate that further. However, with all of the errors streaming by >>>> concerning discovery, the logging is a bit too loud to see anything else >>>> that might be of use. I do see a number of other messages fly by amongst >>>> all of the python errors, and I figure that if I can get rid of the type of >>>> error listed above, I might actually be able to look into the other errors. >>>> >>>> So, given that I'm not a python programmer, can anybody give me a clue >>>> as >>>> to what might be going on here? Should I run tcpdump and grab a .pcap file >>>> or 2? Once I get past all of this, I also hope to get started with >>>> nox-gui.py. However, I suspect that it will never show me any topology >>>> information until nox_core is happy with discovery. >>>> >>>> Thanks, >>>> /Chris >>>> >>>> _______________________________________________ >>>> 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 >> >> > _______________________________________________ > 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_noxrepo.org
