Re: [nox-dev] Problems installing nox zaku on Ubuntu
If it ended up seeming to work, I think the chances are good that it's fine. But I'm interested in whatever the problem may have been if you care to help me understand it a bit more. Nothing stuck out at me after a quick glance at your attachments, and those warnings are generally going to be benign if things do end up compiling and linking (I don't know of any cases off the top of my head where different versions of XSI have DIFFERENT values/semantics depending on the version, though there may be some). Can you say more about how installation failed the first time? Did it fail to build? Did make install fail to copy things to their intended destinations? Something else? -- Murphy On Oct 13, 2010, at 10:01 PM, Niky Riga wrote: Hi, I am running FV 0.6 beta 4 and the zaku release for nox. I have been having some problems with nox, and I decided to make a clean installation before posting on the list. Trying a clean install on a machine running Ubuntu K, didn't go smoothly so I though I would ask to verify that the problems I am seeing is not due to installation problems. I followed all the instructions as listed in : http://noxrepo.org/noxwiki/index.php/NOX_Installation The first time the installation failed. There were several warning of the type : In file included from /usr/include/python2.6/Python.h:8, from ../../../src/lib/fault.cc:33: /usr/include/python2.6/pyconfig.h:1028:1: warning: _POSIX_C_SOURCE redefined In file included from /usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39, from /usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243, from /usr/include/c++/4.4/string:40, from ../../../src/include/fault.hh:21, from ../../../src/lib/fault.cc:19: /usr/include/features.h:158:1: warning: this is the location of the previous definition In file included from /usr/include/python2.6/Python.h:8, from ../../../src/lib/fault.cc:33: /usr/include/python2.6/pyconfig.h:1037:1: warning: _XOPEN_SOURCE redefined In file included from /usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39, from /usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243, from /usr/include/c++/4.4/string:40, from ../../../src/include/fault.hh:21, from ../../../src/lib/fault.cc:19: I ran make -j again and this time it's succeeded. Is that fine? I attach the output of the ../configure command and of the make -j the time that it succeeded. Thanks, niky make.outconfig.out___ 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
Re: [nox-dev] Monitor module crashes
From the log, it looks like the controller (FlowVisor?) is doing some weird stuff, and I don't know what's up with that. As KK suggested, you might want to look at a trace. BUT, this shouldn't crash NOX, and I do think it points out a bug: In src/builtin/nox.cc, the line immediately following 1148 (do_exit(EINVAL)) should probably be a return; Try throwing that in there and see if it helps your crashes. -- Murphy On Oct 13, 2010, at 10:26 PM, kk yap wrote: Hi Niky, You should take a look at the tcpdump and see why message type 17 (OFPT_STATS_REPLY) is being received during a handshake. That should help to debug the problem. Regards KK On 13 October 2010 22:20, Niky Riga nr...@bbn.com wrote: Hi, Using the installation described on my previous email, I tried running the monitor module of nox, both times I tried running it, it aborted. Before it aborted there were many instances of this WARN message : 08163|nox|DBG:Success receiving in 'receiving features reply' 08164|nox|WARN:Received unsupported message type during handshake (17) 08165|nox|DBG:Success receiving in 'receiving features reply' 08166|nox|WARN:Received unsupported message type during handshake (17) 08167|nox|DBG:Success receiving in 'receiving features reply' 08168|nox|WARN:Received unsupported message type during handshake (17) 08169|openflow-event|DBG:received stats reply from 0012e27831f5 Attached are the output files of both runs. Any idea what might be wrong? (running nox zaku and FV 0.6 beta4) Thanks, niky ___ 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
Re: [nox-dev] Monitor module crashes
Thanks, I will try that. I am in the process of getting wireshark up and running to look at a tcpdump, if I get more info I will forward them to you. --niky James Murphy McCauley wrote: From the log, it looks like the controller (FlowVisor?) is doing some weird stuff, and I don't know what's up with that. As KK suggested, you might want to look at a trace. BUT, this shouldn't crash NOX, and I do think it points out a bug: In src/builtin/nox.cc, the line immediately following 1148 (do_exit(EINVAL)) should probably be a return; Try throwing that in there and see if it helps your crashes. -- Murphy On Oct 13, 2010, at 10:26 PM, kk yap wrote: Hi Niky, You should take a look at the tcpdump and see why message type 17 (OFPT_STATS_REPLY) is being received during a handshake. That should help to debug the problem. Regards KK On 13 October 2010 22:20, Niky Riga nr...@bbn.com wrote: Hi, Using the installation described on my previous email, I tried running the monitor module of nox, both times I tried running it, it aborted. Before it aborted there were many instances of this WARN message : 08163|nox|DBG:Success receiving in 'receiving features reply' 08164|nox|WARN:Received unsupported message type during handshake (17) 08165|nox|DBG:Success receiving in 'receiving features reply' 08166|nox|WARN:Received unsupported message type during handshake (17) 08167|nox|DBG:Success receiving in 'receiving features reply' 08168|nox|WARN:Received unsupported message type during handshake (17) 08169|openflow-event|DBG:received stats reply from 0012e27831f5 Attached are the output files of both runs. Any idea what might be wrong? (running nox zaku and FV 0.6 beta4) Thanks, niky ___ 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
Re: [nox-dev] Problems installing nox zaku on Ubuntu
The usual cause for this is that you're out of memory. Any possibility that's the case here? Also explains why sometimes it succeeds and sometimes it fails without you changing anything obvious. -- Murphy On Oct 14, 2010, at 12:39 AM, Niky Riga wrote: Hi, Attached is the output of a failed build effort. At some point you will see the error : mv -f .deps/authenticator_la-user_event.Tpo .deps/authenticator_la-user_event.Plo mv -f .deps/authenticator_la-host_event.Tpo .deps/authenticator_la-host_event.Plo g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. make[9]: *** [authenticator_la-authenticator_util.lo] Error 1 gcc version : nr...@kriti:~/test/nox/build$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) Hope this helps, Niky Niky Riga wrote: Basically I believe that the authenticator failed to compile. I think that g++ faced problems while trying to compile it and in the end all the reported errors were about that. I know that this is probably not all that helpful :-) I will try and reproduce it and send you the output. Thanks, Niky James Murphy McCauley wrote: If it ended up seeming to work, I think the chances are good that it's fine. But I'm interested in whatever the problem may have been if you care to help me understand it a bit more. Nothing stuck out at me after a quick glance at your attachments, and those warnings are generally going to be benign if things do end up compiling and linking (I don't know of any cases off the top of my head where different versions of XSI have DIFFERENT values/semantics depending on the version, though there may be some). Can you say more about how installation failed the first time? Did it fail to build? Did make install fail to copy things to their intended destinations? Something else? -- Murphy On Oct 13, 2010, at 10:01 PM, Niky Riga wrote: Hi, I am running FV 0.6 beta 4 and the zaku release for nox. I have been having some problems with nox, and I decided to make a clean installation before posting on the list. Trying a clean install on a machine running Ubuntu K, didn't go smoothly so I though I would ask to verify that the problems I am seeing is not due to installation problems. I followed all the instructions as listed in : http://noxrepo.org/noxwiki/index.php/NOX_Installation The first time the installation failed. There were several warning of the type : In file included from /usr/include/python2.6/Python.h:8, from ../../../src/lib/fault.cc:33: /usr/include/python2.6/pyconfig.h:1028:1: warning: _POSIX_C_SOURCE redefined In file included from /usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39, from /usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243, from /usr/include/c++/4.4/string:40, from ../../../src/include/fault.hh:21, from ../../../src/lib/fault.cc:19: /usr/include/features.h:158:1: warning: this is the location of the previous definition In file included from /usr/include/python2.6/Python.h:8, from ../../../src/lib/fault.cc:33: /usr/include/python2.6/pyconfig.h:1037:1: warning: _XOPEN_SOURCE redefined In file included from /usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39, from /usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243, from /usr/include/c++/4.4/string:40, from ../../../src/include/fault.hh:21, from ../../../src/lib/fault.cc:19: I ran make -j again and this time it's succeeded. Is that fine? I attach the output of the ../configure command and of the make -j the time that it succeeded. Thanks, niky make.outconfig.out___ 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-build.rtf ___ nox-dev
[nox-dev] Problem with stat requests and reply
Hi, I am using nox zaku and FV 0.4 beta4. I have been having problems with a module that pokes periodically the switches for statistics. In an effort to debug this, I made a clean installation of nox (zaku release) and run the default monitoring module of nox. And the problems persisted. Basically I was seeing errors in the controller of the type : 8163|nox|DBG:Success receiving in 'receiving features reply' 08164|nox|WARN:Received unsupported message type during handshake (17) I tried to run it with wireshark to be able to debug a little bit further but by the time I have set up my environment, the switches that were causing that had dropped of my FV. I was still seeing some errors from the remaining switches : 00112|openflow-event|ERR:received Openflow error packet from dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data 00146|openflow-event|ERR:received Openflow error packet from dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data 00151|openflow-event|ERR:received Openflow error packet from dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data Running wireshark, the only thing I noticed was periodic messages of : 04:14:14 Warn Dissector bug, protocol OFP, in packet 20286: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:14 Warn Dissector bug, protocol OFP, in packet 20345: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20461: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20475: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20608: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20627: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:15:23 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:2916: failed assertion (guint)hfindex gpa_hfinfo.len Most of these, if not all, are in the stats reply for table stats. After a while more switches have dropped from the FV (there can be only one:-)) ) Any ideas what might be wrong? Niky ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Adding flow entry
Hi Sachin If you are looking to just create entries without writing any NOX code, then you need to use dpctl. Please do following: $ git clone git://openflowswitch.org/openflow.git $ cd openflow $ git checkout -b of1.0 origin/release/1.0.0 $ ./boot.sh; ./configure; make $ cd utilities $ ./dpctl --help (To see list of commands) $ ./dpctl command tcp:switch:listener_port ...where the OpenVSwitch datapath was started with ptcp:listener_port option. You can use this command to write entries (add-flow) Srini. On Thu, Oct 14, 2010 at 2:19 AM, sachin sharma sharon_sac...@yahoo.co.in wrote: Dear All, I have connected one nox (version number 0.6) to two openVswitch ( Version 1.0). I am interested to create centralized nox where it can add or delete flow entries to both the switches. Now for this initial phase, I am interested to write entries related to each switch manually without any control plane algorithm. So, how can I do this? Is there a specific command to do that or I would have to write a code in nox related to each switch? Many thanks in advance for the answer! Best Regards, Sachin Sharma ___ 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
Re: [nox-dev] [openflow-discuss] Problem with stat requests and reply
Nicky: are you by chance using envi as well? There was a problem with table stats and envi, because envi was packing its own packets and was not updated properly for openflow 1.0. The result was that table stats messages were 2 (4? I forget) bytes shorter than they should be.If you're using envi, let me know and I can point you to the patch. If you're not using envi, it's entirely possible that this is the same bug in nox somewhere. Let us know, - Rob . On Thu, Oct 14, 2010 at 1:39 AM, Niky Riga nr...@bbn.com wrote: Hi, I am using nox zaku and FV 0.4 beta4. I have been having problems with a module that pokes periodically the switches for statistics. In an effort to debug this, I made a clean installation of nox (zaku release) and run the default monitoring module of nox. And the problems persisted. Basically I was seeing errors in the controller of the type : 8163|nox|DBG:Success receiving in 'receiving features reply' 08164|nox|WARN:Received unsupported message type during handshake (17) I tried to run it with wireshark to be able to debug a little bit further but by the time I have set up my environment, the switches that were causing that had dropped of my FV. I was still seeing some errors from the remaining switches : 00112|openflow-event|ERR:received Openflow error packet from dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data 00146|openflow-event|ERR:received Openflow error packet from dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data 00151|openflow-event|ERR:received Openflow error packet from dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data Running wireshark, the only thing I noticed was periodic messages of : 04:14:14 Warn Dissector bug, protocol OFP, in packet 20286: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:14 Warn Dissector bug, protocol OFP, in packet 20345: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20461: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20475: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20608: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20627: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:15:23 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:2916: failed assertion (guint)hfindex gpa_hfinfo.len Most of these, if not all, are in the stats reply for table stats. After a while more switches have dropped from the FV (there can be only one:-)) ) Any ideas what might be wrong? Niky ___ 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
Re: [nox-dev] [openflow-discuss] Problem with stat requests and reply
[dropped openflow-discuss from the CC line; it's mostly overlap in membership in any case] So, I'm confused. Your original mail said your errors from wireshark were for table stats messages, but you yourself are not using table stats? If the table stats messages are not coming from you, why are they in your trace? - Rob . On Thu, Oct 14, 2010 at 1:29 PM, Niky Riga nr...@bbn.com wrote: No, I am not using envi and actually I am not even using table stats, this was just the standard monitor module of nox. I am seeing similar errors in my monitor module as well, which i don't believe there were there before, and I am not doing table stats. --niky On 10/14/10 2:19 PM, Rob Sherwood wrote: Nicky: are you by chance using envi as well? There was a problem with table stats and envi, because envi was packing its own packets and was not updated properly for openflow 1.0. The result was that table stats messages were 2 (4? I forget) bytes shorter than they should be.If you're using envi, let me know and I can point you to the patch. If you're not using envi, it's entirely possible that this is the same bug in nox somewhere. Let us know, - Rob . On Thu, Oct 14, 2010 at 1:39 AM, Niky Riganr...@bbn.com wrote: Hi, I am using nox zaku and FV 0.4 beta4. I have been having problems with a module that pokes periodically the switches for statistics. In an effort to debug this, I made a clean installation of nox (zaku release) and run the default monitoring module of nox. And the problems persisted. Basically I was seeing errors in the controller of the type : 8163|nox|DBG:Success receiving in 'receiving features reply' 08164|nox|WARN:Received unsupported message type during handshake (17) I tried to run it with wireshark to be able to debug a little bit further but by the time I have set up my environment, the switches that were causing that had dropped of my FV. I was still seeing some errors from the remaining switches : 00112|openflow-event|ERR:received Openflow error packet from dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data 00146|openflow-event|ERR:received Openflow error packet from dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data 00151|openflow-event|ERR:received Openflow error packet from dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data Running wireshark, the only thing I noticed was periodic messages of : 04:14:14 Warn Dissector bug, protocol OFP, in packet 20286: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:14 Warn Dissector bug, protocol OFP, in packet 20345: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20461: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20475: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20608: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20627: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:15:23 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:2916: failed assertion (guint)hfindex gpa_hfinfo.len Most of these, if not all, are in the stats reply for table stats. After a while more switches have dropped from the FV (there can be only one:-)) ) Any ideas what might be wrong? Niky ___ 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
Re: [nox-dev] Problem with stat requests and reply
In the Monitor module crashes thead, I mentioned that I thought the controller looked like it was doing weird stuff, but to be clear, I meant FlowVisor and not NOX. It looks to me like FlowVisor is sending some things at weird times (for example, sending something weird during handshaking is where your crash was coming from... and that bug had been in NOX for quite some time without it ever coming up, apparently). Did you build the wireshark module from the OpenFlow tarball? I think that table stats reply dissecting is broken in the tarball, so my guess is that's why you're getting those errors in wireshark. You should build it from the git repository. -- Murphy On Oct 14, 2010, at 1:39 AM, Niky Riga wrote: Hi, I am using nox zaku and FV 0.4 beta4. I have been having problems with a module that pokes periodically the switches for statistics. In an effort to debug this, I made a clean installation of nox (zaku release) and run the default monitoring module of nox. And the problems persisted. Basically I was seeing errors in the controller of the type : 8163|nox|DBG:Success receiving in 'receiving features reply' 08164|nox|WARN:Received unsupported message type during handshake (17) I tried to run it with wireshark to be able to debug a little bit further but by the time I have set up my environment, the switches that were causing that had dropped of my FV. I was still seeing some errors from the remaining switches : 00112|openflow-event|ERR:received Openflow error packet from dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data 00146|openflow-event|ERR:received Openflow error packet from dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data 00151|openflow-event|ERR:received Openflow error packet from dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data Running wireshark, the only thing I noticed was periodic messages of : 04:14:14 Warn Dissector bug, protocol OFP, in packet 20286: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:14 Warn Dissector bug, protocol OFP, in packet 20345: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20461: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:15 Warn Dissector bug, protocol OFP, in packet 20475: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20608: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20627: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:14:16 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:1389: failed assertion (guint)hfindex gpa_hfinfo.len 04:15:23 Warn Dissector bug, protocol OFP, in packet 20639: proto.c:2916: failed assertion (guint)hfindex gpa_hfinfo.len Most of these, if not all, are in the stats reply for table stats. After a while more switches have dropped from the FV (there can be only one:-)) ) Any ideas what might be wrong? Niky ___ 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
