AREDN 3.17.1.0 Release Candidate 1 (RC1)

40 posts / 0 new

Fri, 04/14/2017 - 13:51

K5DLQ

In case you didn't see it on the home page...
http://www.aredn.org/content/aredn-announces-upcoming-features-and-devices
*** Edited by Moderator to show correct URL for the article ****

Fri, 04/14/2017 - 14:25

K5DLQ

(don't forget to "Upload Data

(don't forget to "Upload Data to AREDN Servers" after you update to update your map information)

Fri, 04/14/2017 - 15:43

k1ky

3.16.1.1 OTA Fixup

Is this needed before upgrading to take advantage of the OTA upgrade issues? What if nodes are upgrading from Dev 164, earlier Development and 3.16.1.0 versions???

Fri, 04/14/2017 - 17:34

(Reply to #3) #4

K5DLQ

Yes, the OTAFixup patch

Yes, the OTAFixup patch listed on the RC page is recommended for upgrading from 3.16.1.1. It is UNTESTED on nightly builds and only supported for 3.16.1.1, but, if you have an experimental node, give it a try. Worst case is that you may need to TFTP load 3.17.1.0RC1.

Fri, 04/14/2017 - 17:37

K5DLQ

I will add...

I will add...

Once you apply the patch, upon performing a firmware update, the "MESH" led (usually RED), will go into a "upgrade mode" state with a rapid flashing LED.
This is the same behavior that you will see in 3.17.1.0RC1 and beyond.

Sat, 04/15/2017 - 00:05

k1ky

Is there an AirRouter AREDN 3.17.1.0 Release Candidate 1 (RC1)?

I don't see the AirRouter listed in the categories - which version should we use?

Sat, 04/15/2017 - 09:19

(Reply to #6) #7

K5DLQ

oops. Corrected now. thanks

oops. Corrected now. thanks for letting us know.

Sat, 04/15/2017 - 10:23

k1ky

IPv6 numbers missing on 3.17.1.0RC1

I noticed that the IPv6 numbers are no longer displayed on the node status under the IPv4 addys. Is this gone forever or will they return? I track these numbers in my spreadsheet info on each node.

Sat, 04/15/2017 - 23:23

(Reply to #8) #9

K5DLQ

Since we were not yet using

Since we were not yet using IPv6, we removed it

Sun, 04/16/2017 - 14:11

#10

K7DXS

I'm getting a 404 on that

I'm getting a 404 on that link.

Sun, 04/16/2017 - 14:45

(Reply to #10) #11

WU2S

Apologies - Link Fixed

Apologies for the issue. An assistant editor mistakenly changed the URL when modifying the article content. The corrected link is now shown in K5DLQ's post aboved.

Sun, 04/16/2017 - 14:17

#12

K7DXS

Just curious, why was tunnel

Just curious, why was tunnel server compression disabled?

Sun, 04/16/2017 - 15:36

(Reply to #12) #13

KG6JEI

Performance, it utilized a

Performance, it utilized a sizable amount of ram for each tunnel connection active which would significantly degrade performance and in some cases exhaust resources of nodes running a number of connections.

Sun, 04/16/2017 - 17:06

(Reply to #13) #14

ZL2AQY

Running it here now and my

Running it here now and my nodes performance is noticeably improved.
Thanks

Sun, 04/16/2017 - 22:54

(Reply to #14) #15

K7DXS

Suggestion: Add an option to

Suggestion: Add an option to enable/disable it. Because on a slow connection with a node only serving 1 or 2 tunnels, compression could make it faster.

Sun, 04/16/2017 - 23:12

(Reply to #15) #16

KG6JEI

Feature Requests need to be

Feature Requests need to be submitted through Bloodhound for official consideration.

However before you do I would suggest referring to the various tickets around this issue first (all reachable in Bloodhound)

I will additionally note that tunnels, like the rest of AREDN, are not really intended for slow connections additionally they are not intended to be run long term either as part of a strong Auxcom network.

Also much traffic (depending on various factors) is already compressed or is incompressible and attempts to compress can slow it down/make it bigger (depending on various factors.)

Mon, 04/17/2017 - 13:56

(Reply to #16) #17

K7DXS

I don't see a way for a non

I don't see a way for a non-dev to create an account or a ticket on bloodhound. Am I missing something?

Mon, 04/17/2017 - 14:41

(Reply to #17) #18

KG6JEI

You should be able to log in

You should be able to log in with your existing AREDN.org username and password (same used to get into this forum.)

Mon, 04/17/2017 - 20:18

(Reply to #18) #19

K7DXS

Oh, I didn't realize you had

Oh, I didn't realize you had implemented SSO.

Mon, 04/17/2017 - 13:10

#20

KE6UPI

NanoStation XW

NanoStation XW
Does this update fix the two ports so we can use just one cable?

Thanks, David
KE6UPI

Mon, 04/17/2017 - 17:45

(Reply to #20) #21

K5DLQ

Mon, 04/17/2017 - 14:13

#22

kg7bz

Rocket M5 XW

Never mind... Wrong Image...

Thu, 04/20/2017 - 17:28

#23

K5DLQ

Any feedback on the 3.17.1

Any feedback on the 3.17.1.0RC1? We like it when it's quiet, but, want to make sure that nobody is running into any issues...

Thu, 04/20/2017 - 20:08

(Reply to #23) #24

k1ky

3.17.1.0RC1 looking good so far!

We have had great success with the RC1 upgrades. Our systems appear to be stable, we've performed over 50 upgrades so far. The only problem is that we have discovered the need to make sure that the WAN port on any units NOT SET TO STATIC! Make sure the WAN port is set to DHCP. Remove optional modules such as VTUN (Tunnel) and MeshChat just to be safe. Save settings and reboot your nodes before upgrading to guarantee a fresh start..

Thu, 04/20/2017 - 21:49

(Reply to #24) #25

N2MH

Looking good here also!

Around 8 nodes upgraded here. Some plain-jane nodes, some tunnel servers and some tunnel clients. A few nano-stations, a rocket and a few airrouters. All look good.

One nano-station was even upgraded on-the-fly on I-81 doing 65 mph (my wife Karen was driving :-). Upgraded started in Maryland and completed in Pennsylvania. No problems encountered.

Keep in mind Tom's advice above. If you have any nodes set to a static WAN address, change them over to a dhcp WAN address before upgrading. Otherwise, you node will go "stupid".

73, Mark

Fri, 04/21/2017 - 14:25

#26

AB4YY

12 nodes updated - all fine!

12 nodes updated. (11 OTA, 1 direct)
.....3 nodes from 3.16.1.0
.....9 nodes from 3.16.1.1

Process used for "from 3.16.1.0":
- Reboot; install 3.16.1.1; reboot; install 3.17.1.RC1
Process used for "from 3.16.1.1":
- Install "v3.16.1.1 OTA Fixup"; reboot; install 3.17.1.RC1

Two or three times it seemed like it would miss doing the update and be back at the old status screen. The 2nd attempt always worked.

It seemed (as I recall...) that going from 3.16.1.0 to 3.16.1.1 the Timezone would be reset to UTC.

All upgrades were successful!
As far as I can tell, everything is working fine.
The nodes referred to are all 2.4 GHz units and include Bullet, AirGrid and Rocket devices.
All services information was retained over the upgrades!
Good work guys!

73 - Mike ab4yy

Fri, 04/21/2017 - 17:57

#27

w6bi

Only 4 done here.

Have only done 4 here. A few issues getting them updated (took a couple tries in a couple of cases).
No operational issues observed.

Sat, 04/22/2017 - 00:18

#28

k4pwo

3.17RC on TP-Link CPE510...

The only failure I've had was on a CPE510. You end up with continuous reboots. I looked at the terminal dialog and it's getting a critical kernel failure due to failed watchdog initialization. Any success stories? I moved back to 3.16.1.1 via TFTP.

Tue, 05/02/2017 - 16:31

#29

K7OPA

For my understanding, for a

For my understanding, for a new Rocket M5 XW I need to backload the 5.5 sw shown on install page before loading the new beta 3.17.1?? The 5.5 software link show is good for all XW units - nano, rocket, etc?

Tue, 05/02/2017 - 16:59

(Reply to #29) #30

KG6JEI

Correct, Ubiquiti creates

Correct, Ubiquiti creates only one firmware file for all XM devices and one (different) firmware file for XW devices.

Thu, 05/04/2017 - 23:25

#31

KF6IDK

Rocket M5 XW

Updated 5/4/2017 10:25PM

I have a Rocket M5 XW .... Orginal OS XW v5.6.3,
I down graded to OS XW.v5.5.10-u2.28005.150723.1358.bin
AREDN UBoot Test is "Good & Good".
Uploaded Firmware AREDN-3.17.1.ORC1-ubnt-rocket-m-squashfs-factory.bin to node
Received an Orange Flag Notice " Firmware image check failed. Error code. -6 "

attempted a few more times with...no success

any Ideas ???

Thanks to the help of KG6JEI , I found that I had not scrolled all the way down the list of downloads to find the M5 XW software.
I then Successfully loaded 3.17.1.0RC1 onto a Rocket XW.

Thank You, for all your help.

Ken KF6IDK

Thu, 05/04/2017 - 23:47

(Reply to #31) #32

KG6JEI

You don't list the full file

You don't list the full file name of the AREDN file you are using, make sure it is the XW ROCKET image and not any of the other images.

Fri, 05/05/2017 - 00:41

(Reply to #32) #33

KG6JEI

The updated post confirms you

The updated post confirms you are not using the rocket-xw AREDN firmware image "AREDN-3.17.1.ORC1-ubnt-rocket-m-squashfs-factory.bin" is for XM
devices, you need to use the XW device firmware.

Fri, 05/05/2017 - 00:51

(Reply to #33) #34

KF6IDK

Ahhhh...found the error..

Ahhhh...found the error...Thank You Very Much

Fri, 05/05/2017 - 14:21

#35

AB4YY

Issue with Charts

There appears to likely be an issue with the Charts operation with the 3.17.1.0RC1 that does not exist in 3.16.1.1.

When selecting Charts, it defaults to Realtime and Strongest Signal device. The chart results however appear to be fictitious and do not match any of the nodes that can be selected. I can elaborate but the description is that simple and has been verified on various nodes on our network.

73 - Mike ab4yy

Fri, 05/05/2017 - 17:24

(Reply to #35) #36

AE6XE

MIke, good catch. The

MIke, good catch. The Signal value in use is also showing on the Node Status page since linksys days. The value is determined by the wireless driver and may not be the same across different drivers. The terminology in use comes from the linksys days. Ether linksys driver does it differently or this has been a bug since day one. I took a scan through the driver source code and if I followed the code correctly, in Ubiquiti this value is documented as:

/* Calculate average rssi from conntected stations */

We need to change the terminology to be consistent (or change where we pull the data from to ensure it is the strongest neighbor's signal). Also, I'll submit a ticket later to track unless you beat me to submitting it.

Joe AE6XE

Sat, 05/06/2017 - 16:54

(Reply to #36) #37

AE6XE

Ticket Created

http://bloodhound.aredn.org/products/AREDN/ticket/233#ticket

Mon, 05/08/2017 - 10:44

#38

k1ky

Archive Scan "sticks" on Loading... when no signals detected

If a node has "never" picked up a signal by connecting via RF to any nodes, an Archive Scan stays in a "Loading..." state and cannot be stopped by hitting the quit button. The only exit strategy seems to be either close the tab or hit the back button in the browser tab. Does this keep a process running on the node?? Does it ever "time out"?

Mon, 05/08/2017 - 12:57

(Reply to #38) #39

K5DLQ

This would be a new defect

This would be a new defect (ie. new ticket in bloodhound)

Mon, 05/08/2017 - 13:31

(Reply to #39) #40

k1ky

Already added to Ticket #233

I already posted this to ticket #233 - is there a way to "move" it or do you still want a new ticket??

Amateur Radio Emergency Data Network

Menu SF

You are here

AREDN 3.17.1.0 Release Candidate 1 (RC1)

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

AREDN 3.17.1.0 Release Candidate 1 (RC1)