ExtremeWireless (Identifi)

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

 

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

-Doug

That is awesome !!! Thx

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.

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.

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.

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. ;-)

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)

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.

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.

Thanks Ron

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.

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

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

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.

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 ??

10.41.02.0014 is out!

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

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.

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.

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.

Hi Martin,

It didn't seem right that nothing could connect to the a radio at all.

We've not experienced this in the past, only since going to 10.41. We did rollback pretty sharpish so unable to confirm your thoughts.

v10.41.02 support ExtremeLocation on AP39xx but the ExtremeLocation release notes don't list the AP as a supported device.
Or is it supported in the next ExtremeLocation version - if that is the case which version is it and what is the release date for that version.

Thanks,
Ron

from the V10.41.02 release notes....

Integration of ExtremeWireless™ AP3900 series with ExtremeLocation 1.1 system.