I'm still getting up to speed on using Radio Management to manage subscribers using the built-in WiFi, but there are some implementation details I'm running into that seem to be totally at odds with actually using the feature to manage a large fleet of distributed subscribers in an enterprise environment. I'm wondering if anyone else here is in the same boat, or has had success using WiFi in a larger deployment.
Specifically, these limitations are proving problematic:
This one isn't all that surprising for an early feature release -- the radio would need to be able to manage a certificate trust store and all the baggage that comes with PKI. I would hope that they support certificates in the radio eventually, but for now, I imagine that most administrators will just use a PSK mode and move on with life.
This one just seems nuts to me. The DNS-SD requirement means that any radio that's going to be programmed by the RM device programmer needs to be on the same wireless LAN or VLAN as the programmer, *and* that wireless network has to support passing Layer 2 multicast traffic. Anyone who's worked with larger wireless networks probably knows that mDNS traffic is one of the things that will quickly saturate an AP unless it is either prohibited or strictly managed. Thus, in many larger deployments, it's usually easier to just turn it off entirely (guess which boat I'm in).
This also means that the RM programmer agent either needs to be split out from the server and presented on the wireless LAN(s) that subscribers participate in, or the RM server (if RM device programmer isn't split out) needs to become a client of the wireless network -- which is a real PITA if you're trying to run the infrastructure applications inside a VM, like any modern IT shop would. You'd need to get your IT shop to present the wireless network segment to a vNIC on the VM, which is a pretty exotic request in a lot of environments.
I'm just in the architecture planning phase in my deploymeny thus far, so I've done close to zero testing. But I'd be very interested to know if anyone has been able to get these things to see each other over IP, or across LANs, not using mDNS (like almost every other IP-capable device in existence). It boggles the mind that these things can acquire an IP using DHCP, but can't use IP to be located and programmed by Radio Management. The "locality" requirement of getting all the radios in the same LAN / VLAN to be programmed is just about the exact opposite of the distributed-infrastructure design goals of IPSC and LCP...
Specifically, these limitations are proving problematic:
- Radios don't support WPA Enterprise security
This one isn't all that surprising for an early feature release -- the radio would need to be able to manage a certificate trust store and all the baggage that comes with PKI. I would hope that they support certificates in the radio eventually, but for now, I imagine that most administrators will just use a PSK mode and move on with life.
- According to the TRBO System Planner, the subscribers use *only* DNS-SD (mDNS) to communicate with the RM device programmer.
This one just seems nuts to me. The DNS-SD requirement means that any radio that's going to be programmed by the RM device programmer needs to be on the same wireless LAN or VLAN as the programmer, *and* that wireless network has to support passing Layer 2 multicast traffic. Anyone who's worked with larger wireless networks probably knows that mDNS traffic is one of the things that will quickly saturate an AP unless it is either prohibited or strictly managed. Thus, in many larger deployments, it's usually easier to just turn it off entirely (guess which boat I'm in).
This also means that the RM programmer agent either needs to be split out from the server and presented on the wireless LAN(s) that subscribers participate in, or the RM server (if RM device programmer isn't split out) needs to become a client of the wireless network -- which is a real PITA if you're trying to run the infrastructure applications inside a VM, like any modern IT shop would. You'd need to get your IT shop to present the wireless network segment to a vNIC on the VM, which is a pretty exotic request in a lot of environments.
I'm just in the architecture planning phase in my deploymeny thus far, so I've done close to zero testing. But I'd be very interested to know if anyone has been able to get these things to see each other over IP, or across LANs, not using mDNS (like almost every other IP-capable device in existence). It boggles the mind that these things can acquire an IP using DHCP, but can't use IP to be located and programmed by Radio Management. The "locality" requirement of getting all the radios in the same LAN / VLAN to be programmed is just about the exact opposite of the distributed-infrastructure design goals of IPSC and LCP...
