Greetings to the list. We loaded 3.1.5b1 into 4 LOCO M2's. These units do not see anything and do not mesh with each other when set for channel 0 and 5 MHz bandwidth. However, on channel -2 they behave as expected. The same thing happened when we loaded the older style Nanobridge M2. So perhaps there is an issue with the firmware for channel 0. Has anyone else succeeded in getting channel 0 working on M2's?
Thanks and 73.
Rick (VE3CVG)
Confirmed. I tested between a Bullet M2 and a Nanostation M2. Thanks for finding this. No doubt a lot of folks are jumping right down to -2. Probably a '0' testing as false in the code somewhere instead of a true--but a wild guess. We'll take a look at this.
See http://bloodhound.aredn.org/products/AREDN/ticket/114
Joe AE6XE
That link does not work for me. Maybe I am too early.
Apart from this little glitch, channel 0 may not be much use anyway in busy areas like ours in downtown Ottawa, this is truly a break through development. The ability to go to 5 MHz and to go to new quiet channels, is such a dramatic improvement!
Thanks to all of you for this work!
73.
Rick (VE3CVG)
Weirdness on the URL link. If you copy and paste the address into the browser it is working. Maybe a cache issue?
Do post any results of your testing on ch -2 for everyone. How much improvement is it? Anyway to quantify?
Joe AE6XE
Wasn't there some particular order sensitivity to selecting BW and channel, or visa versa? In any case I tried both, and rechecked the settings after reboot, and were correct, but units didn't mesh on Ch. 0, even about 3 feet apart.
Another minor anomaly though probably not worth a ticket at this point, is that Wifi scan sometimes shows Ch. -2 as Ch. 254. As long as people remember this modulo thing with these new channels, no a big deal.
Going right to Ch. -2 is a good idea as for 5/10MHz avoids any overlap with Ch. 1 Wifi. Ch -1 and Ch. 0 will have varying degrees of overlap (up to 100% for Ch 0 at 5MHz) .
This is a great step forward, going around Wifi interference rather than brute-force competing with it, which works only in some cases.
Dave
If you find Ch 254 showing again, go to the Administration page in setup and click on the "Download support data" link at the bottom and send to <mycallsign> @ soara.org . This looks to be something in the out-of-box OpenWRT "iw" program, but need to confirm. The code may have an 8-bit variable rolling over somewhere, but intermittant is odd. I'm looking for the output of the command "iw wlan0 station dump" to isolate when this condition exists.
I've checked two nodes over the last few days but have not seen Ch. 254 again, though
Rick mentioned he had seen it; and will report if I do.
I SSH'ed to the node and executed "iw wlan0" command to see what it reported. Signal strength
was shown but I didn't see channel numbers, though assume the full dump will provide that.
Dave
ch 254 showing in wifi scan has been reproduced. We know where the root cause is. The developers who originally created these linux wifi tools and kernel never expected there to be channels <1. Conrad is working through to find these areas to make the appropriate code changes. We have to change unsigned integers ( 0 - 2 = 254 ) to a signed integer (0 -2 = -2). We have to find all test conditions to return that ch 0 is a valid channel (an integer '0' evaluates to false).
Good to hear...I agree that moving away from ISM channels is going to be a big improvement in operationalizing our mesh networks. Keep experimenting!