cancel
Showing results for 
Search instead for 
Did you mean: 
SamPirok
Community Manager Community Manager
Community Manager

IQVA 21.1.21.11 has been released!

 

You can view the release notes here

 

The downloadable files can be found on the Extreme Portal, under Products: 

3 Comments
daniel1
Contributor

It seems you guys didn’t consider all parts of deactivating TLS 1.0 and TLS 1.1 (https://docs.aerohive.com/330000/docs/help/english/ng/Content/reference/virtual-appliance-release-no...).

Transport Layer Security (TLS) 1.0 and 1.1 Deprecation

SSL TLS 1.0 and TLS 1.1 have been disabled in IQ Virtual Appliance and are no longer available in the user interface. TLS 1.2 is now the default supported cipher.

 

Now my APs with IQ Engine 10.0r10b cannot connect anymore to IQVA as a PPSK radsec proxy:

2021-07-21 08:53:45 err     radsecproxy[30081]: tlsconnectnonblock failed
2021-07-21 08:53:45 err radsecproxy[30081]: tlsconnectnonblock: TLS: error:14090086:lib(20):func(144):reason(134)
2021-07-21 08:53:45 warn radsecproxy[30081]: verify error: num=19:self signed certificate in certificate chain:depth=2:/CN=Aerohive/ST=CA/C=US/O=Aerohive Networks, Inc./OU=Engineering
2021-07-21 08:53:45 warn radsecproxy[30081]: connecttcphostlist: TCP connection to <censored> port 2083 up
2021-07-21 08:53:45 warn radsecproxy[30081]: connecttcphostlist: trying to open TCP connection to <censored> port 2083

With means: PPSK is broken after the upgrade!!!

daniel1
Contributor

For others running in this issue, this is the fix:

 

With regards to the certificate change, you will need to refresh the certificate on the AP. Go to device>select all>actions>reset idm client certificate.

 

Our recommendation is to perform a complete update on the APs whenever the IQVA is updated in order to avoid issues such as this certificate issue.

systemscsn
Valued Contributor
Hi Daniel.  

I was trying to figure out how to PM you, but it doesnt seem to be an option.

I wanted to let you know that our new SE found out why wifi0 was disabled.  Turns out that even though our Network Policy had LLDP enabled, it wasnt making it into the actual config.  He went into our Network Policy, disabled LLD, then Enabled it, and BOOM, the LLDP commands made it into the config.  How fricken weird is that.  So, after he saw it was now in the config, i had to do through all 162 AP's and push a full config to them - on going -.  That was another reason we were seeing "at" instead of "af" or the other way around.  

So, put that in memory if you ever come across this issue again.

I want to thank you (and Sam) for always trying to help, I do appreciate it a lot. 

As soon as all of of the complete updates pushed, ill be enabling high Density, monitor it for a bit, and then enabling DFS.


Have a happy day,
Jason.
GTM-P2G8KFN