back to

{{{ Yes, I consider our mesh quite stable (actually, extremely stable compared to what others on the list are going through). We really only have to reboot after making deliberate changes to the nodes. Qcode provides for a way to save all settings specific to that node locally. This includes "block node" so when a node is rebooted all previous settings remain intact. We still deal with the issue of having to power cycle a node once in a while (the Qcode software hasn't taken care of that) but it has been 3 or 4 weeks since we have had to do even that.We also run a full time webcam thru one of our Qnodes and another portable Qnode and meshcam that we set up for different events in town (Our annual Fire Truck Christmas parade last Friday night, for example). The main webcam has been up on our courthouse roof almost a year with no problems.

Contact Qorvus for specifics about their other clients/meshes and your concerns about their relationship w/Locustworld. They have always been extremely responsive to any inquiries I have had. Although I have answered those questions for myself, you may come to different conclusions.

Mike... I think the software is around $100 per node downloaded. Check out the website - its pretty good.

So you would describe your mesh as 'very stable'? How often do you have to reboot one or more nodes? We haven't gotten set up yet, and the reports I've been seeing are frightening, to the extent that I am researching other options.

> I've only heard good news about Qorvus, but the question is on what scale are they deployed? Eleven nodes is pretty respectable.

> What if LocustWorld cuts them off from the codebase, for reselling? Are they dead in the water?

>>We have a very dense 11 node mesh here along the Columbia River in SW >>Washington providing free public access wireless to visitors as a city promotional tool. We have been using the Qorvus Qcode mesh management >>software now for a number of months as I have posted to the list before. Many of the problems discussed on the list associated with mesh >>management via Wiana and SSH (such as "block Node") have been dealt with in the Qorvus software. I highly recommend anyone working with meshAP >>deployment take the time to look at their product to see if it will save you the kind of time and frustration it did us. The question really >>is... what do you want to be doing - dicking around with frustrating >>and sometimes broken code or expanding and promoting you mesh?

>>BTW - We paid for all our Qorvus product in case anyone thinks I have an ulterior motive for promoting them.

>>>I am seeing the exact same problem with my network. It was not much of >>>a problem at first but has become a major problem as the network has >>>grown (26 active nodes now). This would not be so much of a problem if >>>there was an easier way to block unwanted nodes automatically right now >>>every time a node reboots I have to manually shell in and block unwanted >>>routes. My current solution is to put in another gateway on a separate >>>channel and different ssid and segregating the network to help eliminate >>>some of the work. I am currently on dev 90 but have had this same >>>problem on dev 81 85 and 88 I did not have this problem on dev 76 but >>>the network was much smaller back then too. I may try >>>reverting everything back to dev 76 before the line for the new >>>gateway goes in next week. I will keep you posted if I find a GOOD >>>solution to this problem. >>>

>>> I'm having a performance problem with some of my repeater nodes >>> after the second hop. I'm using Dev 88. I clear all blocknodes and >>> let the MeshAP mesh. I then create blocknodes for MeshAP that have >>> poor quality (both MeshAP gets a blocknode to each other.) This, >>> believe or not, stabilizes the network so that I can ping and ssh >>> between each MeshAP. >>> >>> I having a problem with some of my repeater getting messages every >>> *minute*, such as: >>> >>> Broadcast Message from root@meshbox <mailto:root@meshbox> >>> (somewhere) at 19:04 ... >>> >>> Attempting to connect gateway 1.x.x.x >>> >>> New gateway found at 172.x.x.x >>> >>> New gateway found at 172.x.x.x >>> >>> Attempting to connect gateway 1.x.x.x >>> >>> Attempting to connect gateway 1.x.x.x >>> >>> after each attempting to connect message I check reporter and I also >>> get a new message "*Searching for a gateway to use..."* . >>> This happens after every attempt to connect to gateway. >>> >>> When i try to do a *leechtest* either the performance is extremely >>> slow or it doesn't work; however, I can ssh into the MeshAP and the >>> ping time are actually very good. I have extremely strong radio >>> signals between each MeshAP. >>> >>> In Wiana I'm not sure what constitutes a broadcast into noisy or >>> clean but I have issue a command change the fragmentation "*iwconfig >>> wlan0 frag 1000*" which is currently not supported by Wiana. >>> >>> Wiana has indicated over 30 different AP so I figure it would be >>> noisy? I'm currently on Channel 1 and all of the different AP are >>> either on 6 or higher. >>> >>> I have remove the preferred gateway setting in Wiana to see if there >>> is much difference. The answer is it doesn't make that much >>> difference in my environment. >>> >>> When I ssh into distant gateway I also get a hiccup. The screen >>> freezes momentarily then comes back. This only happens on distant >>> nodes. >>> >>> Unfortunately to get the network stabilized I have to make it >>> linear. Such that A is the gateway. First my nodes are represented >>> by A,B,C, and D. There topology is linear. A is the gateway MeshAP >>> and D the last repeater. >>> >>> A Links to B which links to C then to D. >>> >>> C and A can see each other but I have stabilized this network by >>> using a combination of blocknode on A and C ensuring that C goes >>> through B then to A. >>> >>> Also D has blocknode to 2 other MeshAP ensuring that it goes through C. >>> >>> Ping time are very good. 10 -14 ms from D to A >>> >>> leechtest on A and B is good. >>> >>> leechtest on C and D is bad. >>> >>> On Each MeshAP: >>> - Signal strength is excellent. >>> - Line of site is excellent >>> - Fresnel Zone is excellent >>> >>> A - 200 mW with 8 dbi antenna >>> B- 100 mW with 8 dbi antenna >>> C - 200 mW with 8 dbi antenna with 10 degree down tilt built into >>> the antenna >>> D - 200 mW with 8 dbi antenna >>> I have two other nodes E and F that can mesh with B, and D. I >>> currently using blocknode to prevent them from meshing! >>> >>> I have asked a number of people to help me with this problem and it >>> seems that many of us are having something similar. >>> >>> Is this a problem with dev 88? or do other dev have the same problem? >>> >>> I guess I finding it frustrating when I deploy a MeshAP that it >>> getting such problems. I always think it a hardware or placement >>> problem. >>> >>> Is anyone having the same experience? }}}