Good work guys!
I upgraded 5 nodes fine this morning. All but one were OTA upgraded. To be safe I first removed MeshChat that was on all and iperf that was installed on some. As usual, MeshChat does not seem to completely uninstall but I reinstalled so it makes no difference. I did notice the Timezone (EST) was not retained and it reverted to UTC. I also remembered to Push (upload) to AREDN to reflect the new version on the kml for each node.
The Charts info is so much faster now!
73 - Mike
One thing I forgot to mention... One node was running the older pre-beta (the last Release 3.15.1 I believe). Anyway, that node had refused to be upgraded to the last beta. Several direct tries and many OTA tries. Sometimes it would get to the 99% mark then reboot. Well this morning, upgrading to the new release went OTA nicely.
Also I figured out my Mesh Chat uninstall issue: After "Remove Package", I had to manually delete the Advertised Service for Mesh Chat. No problem. I guess I was spoiled by the install automatically setting up the advertised service. :)
73 - Mike
If the question stems from not wanting to hassle with the upgrades... I would go ahead and do them. While I can't think of anything that will cause you real grief... I can tell you it's a bad practice... and there were several pesky little issues we weren't happy releasing until resolved. I'm betting that something will rear it's ugly head if you don't... Murphy will see to that ;-)
Early AM I managed to upgrade 4 of our 5 'production' radios.
I'm glad I left the one 3 GHz in town alone, it now has the only still working MeshChat on this side of the Mtn.
The two OTA'd Rockets and the 2.4 GHz NSM on the Mtn are all quite happy though one Rocket and the NSM here at home have stale Meshchat advertisements.
'll experiment on the NSM here in the QTH, , removing the advertisement, rebooting and then re-installing Trevor's current Meshchat (0b05?). Once Meshchat is back on a Mtn top Roket I'll remove it from the two Gth NSMs we've had it on. I'll probably suggest we limit Meshchat to just Mtn tops till we get experience w/RasPi installs.
Is it just the reporting or is the TtxMbs data rate slightly faster with the Production Release than it was between pairs of 3.16.1.0b02?
It will be a while till I'll be able to do any meaningful throughput testing so I'm very curious,
Gentlemen of the Dev Team, thank you one and all !!!
73, ...dan wl7coo
"Is it just the reporting or is the TtxMbs data rate slightly faster with the Production Release than it was between pairs of 3.16.1.0b02?"
The reporting algorithm is different -- defined in the node's help. In summary this is now, (the actual 802.11n protocol rate selected for this neighbor) * (the % success rate of packets/frames getting through, as measured within the driver with ack coming back).
Thanks Joe, is that the same calculation that 0b02 used ?
Curious whether it is something environmental or in the code that is causing higher highs than I've been seeing so far.
I haven't yet formed an opinion about the lowest throughput between any two radios and I haven't learned enough yet to set up any kind of low impact real time monitoring and logging.
Haven't I seen something about an SNMP/MIB development activity or am I just wishing that?
As Joe indicated, the reporting algorithm is different. It isn't as easy as it sounds to determine the throughput... there are so many ways to look at and a fair number of assumptions to be made. We settled on this method (documented in the Help file) as the most reasonable.
SNMP works today... and there are quite a few meaningful stats to be collected. If you do a "walk" you'll see them all. We have defined additional stats, but a MIB has not yet been written. It's on the list.
The 3.16.1.0b2 TxMbs algorithm was what the driver is using to determine the optimal 802.11 rate to select (in real time). While it is doing this job well, it turned out to not do a very good job of actually characterizing the throughput. There souce code has a hard coded average packet size in the calculations and when comparing the values across different channel widths, we started seeing some impossible values.
With the current approach, which is still not exact, it is doing a much better job. You can see the full Mbps possible rate under the right conditions.
Follow the URL link within the node's help page to see more history behind what the 802.11 driver is doing.
I started getting interested when I noticed a definite substantial increase in the indicated TxMbps after any given RF link was upgraded to 3.16.1.0 on both ends. I had a process watching the Mesh Status pages' TxMbs of the second radio in that link from as soon as it appeared back on the MESH coming back after the update till the Status page completed and was stable. There likely would be more traffic in the first minute or two on a quiet network, yes?
All of our island is still in the learn, test, install, ,learn morel phase and we haven't pushed any significant traffic yet.
I think it takes substantialy more than the 2.5 minutes shown for the OTA upgraded node to get back on line after the upgrade and unlike the upgrade to 0b02, none have actually 'come back' even after 10 minutes. I\ve had to manually reconnect to every one of them.
I have remotely upgraded one site 35 miles away to 3.16.1.0, Nanostation M2, Nanobridge M5, Airgrid M5, and AirRouter AR. Plus another AirGrid M5HP at my next site. No hitches so far. One request for future would be the ability to retain the past signal History Archive - I hate to lose that data.
Looks like the indicated signal strength on the AirGrid M5HP has improved a few db..?? Could be the weather.
Yup, that works, but somehow future updates to AREDN pages have to somehow tickle a reload of the page. Not many folks (unless I am further behind than I think) would know to clear cache.
I've updated my non HP AirRouter from b02 to production and getting the LAN on the WAN port and nothing else. Just tried again by TFTP with 3.16.1.0 factory. LAN and DTD Ports are not working.
EDIT Nevermind I grabbed the wrong BIN. Works Great !! :)
Just to log one failure. I tried to do OTA upgrade of an airGrid by way of an airRouter HP and it did not "take" - got up to 93% I think. I upgraded the airRouter to 3.16.1.0 and then repeated the OTA on the AG. This time it got up to 99% indicated progress, but never showed the usual screens and came back again as beta02. Next - on a hunch - I rebooted my Win7-64 PC and then tried the AG again. This time it displayed all the correct screens except it came back in that mode where it is on 192.168.1.1, but does not have any usable interfaces. So a TFTP of the "factory" image was required. Fortunately you can do a long-button reboot remotely using the Ubiquiti POE (!)
The AG was already running beta 02 so I felt that it was pretty much ready to go.
But I honestly do not remember if I ever did the slow-mo patch to that one.
I guess we will never know now ;-)
3.1.16.0 release
I did two more OTA sysupgrades, this time being careful to be sure I loaded the extended time-out patch first.
I did a NS5 and it worked fine.
Then I did an M5 and it failed.
What I noticed in this failure (and a previous one that failed) was that, after telling it go upload the new firmware, you do not get the next screen - the one with all the red warnings on it. It is as if some mistake is being made very early in the process. You just sit on the upgrade screen until you lose connectivity with the page and then - when you get tired of waiting and go look - will find the node in the "preconfiguration" state requiring you to do a hard reset and TFTP upload of the bin file.
I am trying to update a bullet m2. I am using the sysupgrade.bin file in the firmware upgrade section but when I click on upload I lose connection with a message indicating that the connection was reset. What am I missing? Thanks Barney K3 LA
Used this new version to do my new Ubiquity titanium HPM2 bullet
Looks to be working fine. I did have some trouble connecting to the bullet after I flashed it (I did run the test program to be sure the OS returned "GOOG/GOOD" before I flashed it). As the bullet has only one ethernet jack, it turns out it's a LAN jack and once I did an ipconfig on a command box on my PC to see what the IP address really was, then I could connect to it. This looks to be a "gap" in the installation guide at http://bloodhound.aredn.org/products/AREDN/wiki/HowTo/FlashUbiquiti (or I didn't see it) to tell one to expect the IP address to be what its LAN DHCP would assign, and to do the ipconfig to find out what it is. Took me a while and enough loud cursing before I figured this out... I'd add "If it's a bullet or another single ethernet port box, you'll need to find out via ipconfug what the new IP address (the gateway one) is. Then enter that IP address with :8080 in your browser to get into it".
Took another look, found my "gap". I have Win 7 and the thing I need to click on in the status window is called "Details", not "Support tab". There I can find out what I need. Duh...
I'd like some clarification regarding what is meant by "802.11n has been added to the RF protocol". I just upgraded a nanostation M2 to 3.16.1 and I'm not noticing any configuration options regarding 802.11n vs g support. And since one of the selling points of AREDN has been its compatibility with BBHN... which in turn maintains support for Linksys routers, I would assume that means that means still supports 802.11g.
So... does that mean 3.16.1 is operating in mixed mode? And if so... how does the presence or absence of a Linksys router in the mesh affect the overall mesh performance?
good question Dave.
the node negotiates the best connection to each neighbor node. So, if NODE1 (on 3.16.1.0) connects to NODE2 (on 3.16.1.0), it has the potential to use 802.11n MCS rates for that connection. If NODE1 also sees NODE99 (BBHN 3.1.0), it has the potential to use 802.11g MCS rates for that connection.
In essence, yes, it is running in mixed mode (per connection).
To clarify, "Mixed mode" works fine, but only with nodes using the same BW (and SSID, of course). Nodes using different BW's won't even show up on the radar.
*Update- I found the slider under the antenna selection and now have a working Mesh Node. Please update the guide to include this step. Thanks for all the help and your time and effort into this project!
After installing the 3.16.1.0 firmware I am getting the "Configuration NOT saved!" Error along with "Invalid distance value" under the basic setup. What am I doing wrong? I am following the directions on the Bloodhound wiki "NodeSetup" guide.
The distance value must be set to a non-zero number before saving. Use the slider under the "meters" box to select a suitable distance.You will see the values in the miles, kilometers and meters box change to reflect your chosen distance.
Good work guys!
I upgraded 5 nodes fine this morning. All but one were OTA upgraded. To be safe I first removed MeshChat that was on all and iperf that was installed on some. As usual, MeshChat does not seem to completely uninstall but I reinstalled so it makes no difference. I did notice the Timezone (EST) was not retained and it reverted to UTC. I also remembered to Push (upload) to AREDN to reflect the new version on the kml for each node.
The Charts info is so much faster now!
73 - Mike
One thing I forgot to mention... One node was running the older pre-beta (the last Release 3.15.1 I believe). Anyway, that node had refused to be upgraded to the last beta. Several direct tries and many OTA tries. Sometimes it would get to the 99% mark then reboot. Well this morning, upgrading to the new release went OTA nicely.
Also I figured out my Mesh Chat uninstall issue: After "Remove Package", I had to manually delete the Advertised Service for Mesh Chat. No problem. I guess I was spoiled by the install automatically setting up the advertised service. :)
73 - Mike
Andre, K6AH
Thanks - Vance - kc8rgo
If the question stems from not wanting to hassle with the upgrades... I would go ahead and do them. While I can't think of anything that will cause you real grief... I can tell you it's a bad practice... and there were several pesky little issues we weren't happy releasing until resolved. I'm betting that something will rear it's ugly head if you don't... Murphy will see to that ;-)
Andre, K6AH
Did you know that O'Tool lives at my place? His law states that Murphy was an optimist.
Thanks to the team for a great product!
I'm glad I left the one 3 GHz in town alone, it now has the only still working MeshChat on this side of the Mtn.
The two OTA'd Rockets and the 2.4 GHz NSM on the Mtn are all quite happy though one Rocket and the NSM here at home have stale Meshchat advertisements.
'll experiment on the NSM here in the QTH, , removing the advertisement, rebooting and then re-installing Trevor's current Meshchat (0b05?). Once Meshchat is back on a Mtn top Roket I'll remove it from the two Gth NSMs we've had it on. I'll probably suggest we limit Meshchat to just Mtn tops till we get experience w/RasPi installs.
Is it just the reporting or is the TtxMbs data rate slightly faster with the Production Release than it was between pairs of 3.16.1.0b02?
It will be a while till I'll be able to do any meaningful throughput testing so I'm very curious,
Gentlemen of the Dev Team, thank you one and all !!!
73, ...dan wl7coo
The reporting algorithm is different -- defined in the node's help. In summary this is now, (the actual 802.11n protocol rate selected for this neighbor) * (the % success rate of packets/frames getting through, as measured within the driver with ack coming back).
Joe AE6XE
Curious whether it is something environmental or in the code that is causing higher highs than I've been seeing so far.
I haven't yet formed an opinion about the lowest throughput between any two radios and I haven't learned enough yet to set up any kind of low impact real time monitoring and logging.
Haven't I seen something about an SNMP/MIB development activity or am I just wishing that?
TIA, 73
..dan wl7coo
As Joe indicated, the reporting algorithm is different. It isn't as easy as it sounds to determine the throughput... there are so many ways to look at and a fair number of assumptions to be made. We settled on this method (documented in the Help file) as the most reasonable.
SNMP works today... and there are quite a few meaningful stats to be collected. If you do a "walk" you'll see them all. We have defined additional stats, but a MIB has not yet been written. It's on the list.
Andre
With the current approach, which is still not exact, it is doing a much better job. You can see the full Mbps possible rate under the right conditions.
Follow the URL link within the node's help page to see more history behind what the 802.11 driver is doing.
Joe AE6XE
I started getting interested when I noticed a definite substantial increase in the indicated TxMbps after any given RF link was upgraded to 3.16.1.0 on both ends. I had a process watching the Mesh Status pages' TxMbs of the second radio in that link from as soon as it appeared back on the MESH coming back after the update till the Status page completed and was stable. There likely would be more traffic in the first minute or two on a quiet network, yes?
All of our island is still in the learn, test, install, ,learn morel phase and we haven't pushed any significant traffic yet.
I think it takes substantialy more than the 2.5 minutes shown for the OTA upgraded node to get back on line after the upgrade and unlike the upgrade to 0b02, none have actually 'come back' even after 10 minutes. I\ve had to manually reconnect to every one of them.
Thanks again
73, ...dan wl7coo
Did I miss something?
Thanks
I've updated my non HP AirRouter from b02 to production and getting the LAN on the WAN port and nothing else. Just tried again by TFTP with 3.16.1.0 factory. LAN and DTD Ports are not working.
EDIT Nevermind I grabbed the wrong BIN. Works Great !! :)
(Setup/Administration/Download Support Data)
Used the wrong bin. It works now.
Just to log one failure. I tried to do OTA upgrade of an airGrid by way of an airRouter HP and it did not "take" - got up to 93% I think. I upgraded the airRouter to 3.16.1.0 and then repeated the OTA on the AG. This time it got up to 99% indicated progress, but never showed the usual screens and came back again as beta02. Next - on a hunch - I rebooted my Win7-64 PC and then tried the AG again. This time it displayed all the correct screens except it came back in that mode where it is on 192.168.1.1, but does not have any usable interfaces. So a TFTP of the "factory" image was required. Fortunately you can do a long-button reboot remotely using the Ubiquiti POE (!)
By chance did you try to go 3.15.1.0 then the sysupgrade patch (http://downloads.aredn.org/firmware/ubnt/patch-sysupgrade3.tgz) then 3.16.1.0?
The AG was already running beta 02 so I felt that it was pretty much ready to go.
But I honestly do not remember if I ever did the slow-mo patch to that one.
I guess we will never know now ;-)
3.1.16.0 release
I did two more OTA sysupgrades, this time being careful to be sure I loaded the extended time-out patch first.
I did a NS5 and it worked fine.
Then I did an M5 and it failed.
What I noticed in this failure (and a previous one that failed) was that, after telling it go upload the new firmware, you do not get the next screen - the one with all the red warnings on it. It is as if some mistake is being made very early in the process. You just sit on the upgrade screen until you lose connectivity with the page and then - when you get tired of waiting and go look - will find the node in the "preconfiguration" state requiring you to do a hard reset and TFTP upload of the bin file.
Which model of an M5 failed?? (Rocket, Bullet, NanoLoco, etc)
Rocket M5 or, to be more specific, Rocket M5-GPS
What it displayed was quite similar to the airGrid, as best I can recall.
k5dlq@aredn.org
Looks to be working fine. I did have some trouble connecting to the bullet after I flashed it (I did run the test program to be sure the OS returned "GOOG/GOOD" before I flashed it). As the bullet has only one ethernet jack, it turns out it's a LAN jack and once I did an ipconfig on a command box on my PC to see what the IP address really was, then I could connect to it. This looks to be a "gap" in the installation guide at http://bloodhound.aredn.org/products/AREDN/wiki/HowTo/FlashUbiquiti (or I didn't see it) to tell one to expect the IP address to be what its LAN DHCP would assign, and to do the ipconfig to find out what it is. Took me a while and enough loud cursing
before I figured this out... I'd add "If it's a bullet or another single ethernet port box, you'll need to find out via ipconfug what the new IP address (the gateway one) is. Then enter that IP address with :8080 in your browser to get into it".
Took another look, found my "gap". I have Win 7 and the thing I need to click on in the status window is called "Details", not "Support tab". There I can find out what I need. Duh...
as an alternative to browsing to it by http://<IP>:8080
You can always use: http://localnode:8080
;-)
So... does that mean 3.16.1 is operating in mixed mode? And if so... how does the presence or absence of a Linksys router in the mesh affect the overall mesh performance?
Thanks
Dave
the node negotiates the best connection to each neighbor node. So, if NODE1 (on 3.16.1.0) connects to NODE2 (on 3.16.1.0), it has the potential to use 802.11n MCS rates for that connection. If NODE1 also sees NODE99 (BBHN 3.1.0), it has the potential to use 802.11g MCS rates for that connection.
In essence, yes, it is running in mixed mode (per connection).
To clarify, "Mixed mode" works fine, but only with nodes using the same BW (and SSID, of course). Nodes using different BW's won't even show up on the radar.
Dave
*Update- I found the slider under the antenna selection and now have a working Mesh Node. Please update the guide to include this step. Thanks for all the help and your time and effort into this project!
After installing the 3.16.1.0 firmware I am getting the "Configuration NOT saved!" Error along with "Invalid distance value" under the basic setup. What am I doing wrong? I am following the directions on the Bloodhound wiki "NodeSetup" guide.
Steve