Netonix Forums

lligetfa wrote:

Stephen wrote:Please delete the previous file wispswitch-1.5.6.bin and re-download it from the forum's...

Stephen, why does it still show the old release date?

Latest Stable Release: v1.5.6
Click HERE to download firmware v1.5.6 - Released 9/12/2020

Because I missed it. Just corrected it - thanks for the catch!

So this post:

viewtopic.php?f=17&t=240#p848

in my browser today still reads:

Latest Stable Release: v1.5.6

Click HERE to download firmware v1.5.6 - Released 9/12/2020

Is that supposed to be 9/16/2020 also? Is your edit maybe not taking?

Thank you JustJoe, check it now - should be fixed.

JustJoe wrote:Is your edit maybe not taking?

Maybe, did the edit for that section around the time my ISP like's doing maintenance. Just refreshed though and it should be fixed. Let me know if it still didn't take.

FYI: there is still old Copyright 2014-2019 Netonix

Will fix that on the next RC.

Stephen wrote:Thank you JustJoe, check it now - should be fixed.

JustJoe wrote:Is your edit maybe not taking?

Maybe, did the edit for that section around the time my ISP like's doing maintenance. Just refreshed though and it should be fixed. Let me know if it still didn't take.

Looks good now. :)

Just a thought ... Firmware update copies can get bounced around into different filesystems on different management PCs that techs take out to remote locations. That means the file stored date can change too. For them to easily make sure that have the correct (newest) copy, what if the file name contained the release date, example:

wispswitch-1.5.6-20200916.bin

That's a good idea but I don't think it's necessary. This is the final change for this version. The next release will be 1.5.7rc1 to prevent any such confusion.

Stephen,
Maybe you could post the MD5 checksum which would not only disambiguate but would also validate a download did not corrupt.

Stephen wrote:That's a good idea but I don't think it's necessary. This is the final change for this version. The next release will be 1.5.7rc1 to prevent any such confusion.

I agree, definitely not needed for 1.5.6 now that it's out (just used the number as an example), but then I suggest

wispswitch-1.5.7rc1-2020mmdd.bin

I know Netonix is focused on their current version numbers and the here & now 24/7, because that is what you do.

But WISPs have a much bigger picture with bunches of different components to coordinate between their staff and contractors over years and months, and in their jobs they can't be bothered with reading Netonix forums on a daily basis just to maintain one product. Also, not all WSs will ever be accessible for remote network update.

lligetfa also has a good idea for maintaining & verifying checksums at our NOCs when something starts going wrong. But that is too complicated to expect someone in a truck at a remote location to use.

So I'm just asking for something quick & dirty for someone to be proactive and instantly recognize and compare the date in the filename before they load it into the switch on the ladder in front of them. :)

Hey Stephen,

I had this issue pop up again from here. viewtopic.php?f=17&t=5816&start=90#p32887

This time it was facing a Cisco 3560-X. The Cisco device was acting like a router, no other connections go through it. I had access to the Cisco via a console cable at the time, it did not register any spanning-tree loops or issues. No VLANs were blocked for violations.

The tower feeding port 1 just came back from having the power out.

Sep 22 18:11:37 STP: MSTI0: New root on port 1, root path cost is 80000, root bridge id is 31488.3C-28-6D-5A-A7-83
Sep 22 18:11:37 STP: msti 0 set port 12 to discarding
Sep 22 18:11:39 STP: msti 0 set port 12 to learning
Sep 22 18:11:42 STP: msti 0 set port 12 to discarding
Sep 22 18:11:44 STP: msti 0 set port 12 to learning
Sep 22 18:11:44 STP: msti 0 set port 12 to discarding
Sep 22 18:11:53 STP: msti 0 set port 12 to learning
Sep 22 18:11:56 STP: msti 0 set port 12 to forwarding
<cut>
<this is me flapping the port, no change>
Sep 22 18:24:41 Port: link state changed to 'down' on port 12
Sep 22 18:27:49 Port: link state changed to 'up' (1G) on port 12
Sep 22 18:27:49 STP: msti 0 set port 12 to discarding
Sep 22 18:27:52 STP: msti 0 set port 12 to learning
Sep 22 18:27:52 STP: msti 0 set port 12 to forwarding
Sep 22 18:27:54 STP: msti 0 set port 12 to discarding
Sep 22 18:27:57 STP: msti 0 set port 12 to learning
Sep 22 18:27:58 STP: msti 0 set port 12 to discarding
Sep 22 18:28:03 STP: msti 0 set port 12 to learning
Sep 22 18:28:04 STP: msti 0 set port 12 to discarding
Sep 22 18:28:07 STP: msti 0 set port 12 to learning
Sep 22 18:28:08 STP: msti 0 set port 12 to discarding
Sep 22 18:28:49 STP: msti 0 set port 12 to learning
Sep 22 18:28:50 STP: msti 0 set port 12 to discarding
Sep 22 18:28:55 STP: msti 0 set port 12 to learning
Sep 22 18:28:58 STP: msti 0 set port 12 to discarding
Sep 22 18:29:18 STP: msti 0 set port 12 to learning
Sep 22 18:29:18 STP: msti 0 set port 12 to discarding
Sep 22 18:29:54 STP: msti 0 set port 12 to learning
Sep 22 18:29:57 STP: msti 0 set port 12 to forwarding
Sep 22 18:29:58 STP: msti 0 set port 12 to discarding
Sep 22 18:30:00 STP: msti 0 set port 12 to learning
Sep 22 18:30:00 STP: msti 0 set port 12 to discarding
Sep 22 18:30:15 STP: msti 0 set port 12 to learning
Sep 22 18:30:16 STP: msti 0 set port 12 to discarding
Sep 22 18:30:45 STP: msti 0 set port 12 to learning
Sep 22 18:30:46 STP: msti 0 set port 12 to discarding

<snip>


At this point I got into the Netonix and turned off spanning tree. Things started to pass traffic again. Things were also fine after re-enabling it. I've only seen this so far happening on 1.5.5 and 1.5.6.