(after-installation) checks

  • 3
  • Idea
  • Updated 3 years ago
I love the tools like VLAN probing and server access tests. They helped me out many times.
I would love to be able to use them for semi-automatic 'health' checks.

After an installation, it would be nice to be able to generate a report that states if:

- Every VLAN configured for the device in the network policy is available to the AP (tagged/untagged)
- Every AP is able to connect to the radius server and perform a succesfull authentication
- There is no unusual amount of interference (Spectrum analysis), and if there is, what it could be causing it (interference area maybe even plotted on the maps based on AP locations)
- Maybe a couple more tests.

In this way, an integrator can easily check if the wired network is configured the right way, and hand over the report to the customer. this especially comes in handy at large roll-outs.

It would be really nice if these tests are performed on a regular basis and a report is automatically being generated. For example: It occasionally happened to me that the company that is managing the wired network decided to plug the AP's into another switchport that did not have the proper tagged VLAN's configured.
Photo of Sjoerd de Jong

Sjoerd de Jong, Employee

  • 97 Posts
  • 20 Reply Likes

Posted 3 years ago

  • 3
Photo of David Coleman

David Coleman, Official Rep

  • 209 Posts
  • 164 Reply Likes
That is an excellent idea.  PDF reports specific to some of the diagnostic tools.  I will forward this idea to the HiveManager NG team
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Checking RADIUS server availability is challenging as HiveOS does not currently have the ability to act as an TLS-based EAP client, so it is not acting as a supplicant would be making it a non representative test.

If you probe with plain PAP, CHAP or CHAPv2, you are not actually validating that clients will be able to perform an authentication successful, merely that the RADIUS server is available. (Of course the two do often go hand-in-hand but there is a difference.)

The ability to use TLS-based EAP for things like CWP auth, MAC address auth and RADIUS server availability probing is definitely something that I would like to see baked in to HiveOS down the line.
Photo of David Coleman

David Coleman, Official Rep

  • 209 Posts
  • 164 Reply Likes
Totally agree with you Nick, although the original intent was simply to verify back-end RADIUS communications, adding the functionally that you seek would greatly enhance the diagnostic tool. I also would like to see the ability for RADIUS test tool to test multiple AP communications with the RADIUS server at the same time as opposed to only checking one AP at a time.
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Sorry to nit pick! :)

Hmm, yes, that is almost certainly likely to have been the original intent but HM-NG does now state something different to that about the testing feature, not mentioning the authentication method that it will use to test or allowing one to be chosen, and it inaccurately states that it is testing as if it were a valid supplicant when that is not the case as a supplicant would, of course, be using TLS-based EAP:



(For the benefit of anybody else who may be reading, there is no such thing as a RADIUS supplicant, rather the AP is acting as a RADIUS client.
Supplicant refers to the 802.1X part, not the RADIUS backend communication that may-and-usually goes on.)

There may be no user account on the RADIUS server itself, HM-NG should instead state credentials that will be accepted on the RADIUS authentication server.
(Edited)
Photo of Sjoerd de Jong

Sjoerd de Jong, Employee

  • 97 Posts
  • 20 Reply Likes
Yes, that's the method I hope to be implemented as well. I wouldn't enable mschapv2 on my NPS/Radius server in most cases anyway.