topic RE: 10.41 feature discussion in ExtremeWireless (Identifi)

10.41 feature discussion

Ronald_Dvorak — Tue, 10 Oct 2017 22:49:00 GMT

Let's discuss some of the new functions of v10.41.

I've upgraded yesterday but I already love the AP remote shell feature - thanks guys, now I don't need to search for the AP IP and open another window to ssh to the AP.

I've a question about the http AP image upgrade function - does this now solve the issue for AP software upgrades if the controller is behind a NAT device ?

https://extremeportal.force.com/ExtrArticleDetail?an=000091402

Cheers,
Ron

RE: 10.41 feature discussion

Doug — Tue, 10 Oct 2017 22:54:00 GMT

Yes but the ap has to be on 10.41 or greater to support it. So any future upgrades should be ok.

-Doug

RE: 10.41 feature discussion

Ronald_Dvorak — Tue, 10 Oct 2017 22:54:00 GMT

That is awesome !!! Thx

RE: 10.41 feature discussion

Ostrovsky__Yury — Tue, 10 Oct 2017 22:54:00 GMT

Ronald , when AP is behind NAT make sure you enable secure connection (control) , in this case there should be no issue with AP upgrade even before 10.41 - we fixed that in early v9 release . It would be much slower then http since even with ipsec it was still tftp in use (although inside the tunnel) but you should be able to upgrade any number of AP's behind the NAT. Btw, just FYI , we do not officially support when Controller is behind NAT - only AP's are behind NAT.

RE: 10.41 feature discussion

Ronald_Dvorak — Tue, 10 Oct 2017 22:54:00 GMT

I've raised that issue in v9.12.01 - the issue was that the AP used the NAT inside IP of the controller instead of the outside NAT IP for the TFTP session.
ticket# 01066066

Or was that a too early v9 release.

RE: 10.41 feature discussion

Ostrovsky__Yury — Tue, 10 Oct 2017 22:54:00 GMT

I believe 9.21 when we fixed it, few years ago. I might be wrong. The time when we come up with Private Cloud initiative.

RE: 10.41 feature discussion

Steve_Ballantyn — Tue, 10 Oct 2017 22:54:00 GMT

I am about to perform this upgrade myself, and I am a victim of the "TFTP behind NAT" issue. I am pleased to hear that this is resolved. Although, I will likely still pre-upgrade my AP's. I'm not sure that I have the courage to upgrade my system after hours in the hopes that all my remote sites (scattered all over the place) will be okay. Ron - please fall on that sword for me and let me know how it goes. 😉

RE: 10.41 feature discussion

Steve_Ballantyn — Tue, 10 Oct 2017 22:54:00 GMT

Well I got busy and put this upgrade on the back burner. I finally got around to doing it this evening, and I confirmed that the TFTP issue is indeed resolved. This was the first time I was able to perform up upgrade without having to preload the software to the AP's at my remote sites.That certainly speeds up my upgrade process. Thank you Extreme software engineers!!

** NOTE: I was already at 10.41 ** (don't try it if you are running anything older)

RE: 10.41 feature discussion

Anonymous — Mon, 16 Oct 2017 15:58:00 GMT

Agree, that remote shell feature is great!

Have another feature discussion..... presently experience issues where DFS channels had been carefully chosen based on a site survey, but on many sites, if not all, the AP channels would all slowly but surley move to non-DFS channels.

I believe this version is now meant to help with this by automatically moving the channel back when their are no clients associated to the AP.

Is this correct? Is this on automatically or could anyone please elaborate where and how its configured?

Still, it leaves me open as to what should I do i.e. this feature seems a great idea but if APs keep regularly receiving DFS events then this might be more disruptive because of the channel change.

I'm left with deciding to use non-DFS channels only, where things might be more stable or use this feature that might ultimately give me better performance. Just at the mercy of DFS, which must be legitimate events, but what I have no idea what. Be nice if there was an easy means to work that out?

Many thanks.

RE: 10.41 feature discussion

Ronald_Dvorak — Mon, 16 Oct 2017 15:58:00 GMT

It's work auto ....

After 30 min timer for “Requested Channel” expires,AP will return to the original DFS channel under the following conditions:

– There are “ZERO” clients

– If associated clients >0, change to original “Requested Channel” is not done and is retried on regular 5 min interval until no clients on the radio or unti radio is reset.

RE: 10.41 feature discussion

Anonymous — Mon, 16 Oct 2017 15:58:00 GMT

Thanks Ron

RE: 10.41 feature discussion

Ronald_Dvorak — Tue, 07 Nov 2017 18:46:00 GMT

Just upgraded my lab controller with some remote APs behind a NAT firewall and there where no issues.
It was pretty fast via the http file transfer - thanks for the function.

RE: 10.41 feature discussion

Ronald_Dvorak — Tue, 07 Nov 2017 18:46:00 GMT

just to make it clear you'd need 10.41 on the AP first - I've upgraded from 10.41.01.0080 to 10.41.01.0082

RE: 10.41 feature discussion

Steve_Ballantyn — Tue, 07 Nov 2017 18:46:00 GMT

Thanks Ron - good to know! This will certainly make my next upgrade easier.

RE: 10.41 feature discussion

Ronald_Dvorak — Wed, 08 Nov 2017 18:56:00 GMT

FYI,

I can't recommend a upgrade to v10.41.01 because of some major flaws with ACS / channel width - fix is planned for 10.41.02.

RE: 10.41 feature discussion

M_Nees — Wed, 08 Nov 2017 18:56:00 GMT

Is this maybe already fixed in 10.41.01.0082 - wns0019430:

Addressed issue after an upgrade where if auto channel selection is used, it would rerequest a new channel and channel width. The expected behavior has been corrected
to preserve previous channel and channel width. Also adjusted UI logic when channel
is set to ‘Auto’ to only allow channel widths of ‘Auto’ or ‘20MHz’.

Or do you have another issue ??

RE: 10.41 feature discussion

M_Nees — Wed, 08 Nov 2017 18:56:00 GMT

10.41.02.0014 is out!

wns0018546:
Adjust default configuration template to 20 Mhz channel width for AP radios

RE: 10.41 feature discussion

Ronald_Dvorak — Wed, 08 Nov 2017 18:56:00 GMT

I've tested the software for about 60min and the result is .... unuseable.

1) If you set the 5GHz radio channel to auto also the channel width is changed to auto and there is nothing you'd do about it (802.11ac APs).

You are only able to change the width to 40 if you set a static channel.

2) AP3825e
Default AP setting channel width is set to 40 but a new AP comes up with auto.

RE: 10.41 feature discussion

Ian_Broadway — Thu, 09 Nov 2017 19:22:00 GMT

i dont know whether this is related to Ronald's caution to the 10.41.01.0082 code above but since we upgraded to it we started to see issues with the a/5ghz radio on the APs at random times.

rebooting the APs would resolve for a period of time but likely having to reboot again.

the AP would report a blank channel or report the channel as "auto". no issue was seen with the g radio but clients would not associate

we are in the process of rolling back to 10.31.07.0002.

we noticed in the release notes an issue with MFP and WPA2-PSK WLANs but disabling made no difference.

We noticed that when the controllers were running the 10.41 code but we left the APs on the 10.31 code for a period of time, this was stable. it was only when we started upgrading the APs to the 10.41 code that we noticed the issue. Its very erratic and have had to take the decision to roll back.

RE: 10.41 feature discussion

Anonymous — Thu, 09 Nov 2017 19:22:00 GMT

Hi Ian,

Wonder if this is related to a DFS event? You may have already rolled back now, but you could have enabled DFS event notification and see if the two are related:

https://extremeportal.force.com/ExtrArticleDetail?an=000080837

Thanks.