The issue with WPA is, where we already have an active ePMP sector (which isn't using the default WPA key) and a UBNT sector covering the same area. When we elevate the UBNT clients, there not going to be able to connect to the ePMP sector unless we change the WPA key to the default - but if we do that, it will take down all of the customers that are already on the sector. I think what everyone is looking for is a way to avoid that.
I think that the simplest way would be to just enable "Open" (under the wireless security options) by default - that way, we could just enable open on all of the existing clients and set the AP to open while were converting UBNT clients. Once everything is reconfigured with the proper key, it would just be a matter of switching WPA2 back on on the AP and everything would be set.
They are of course NOT real WPA2 keys but they are different and BOTH AP's have customers on them. So, now you upgrade your Ubiquiti subscribers to migrate them over. My understanding is that the new radio only looks for your default Cambium... WPA2 key so we are out of luck. If I change it to that default key now the problem is ANYBODY with a Cammbium radio can connect to the AP.
We want to help you guys and your feedback is important. Lot of chatter about the WPA but I am not entirely following the mixed network situation. Assuming you have an ePMP sector serving ePMP SMs. If you have UBNT SMs that you want to convert to elevate and attach then at the time they must be connnected to another UBNT AP somewhere, right? Am I missing something?
Sakid
You should have included the plain 802.11n mode support for the CPE.
That way, current ubnt cpes could be remotely elevated and instantly attached to the same UBNT AP. (Airmax turned off)
After that, config of each CPE could be done remotely while still connected to the UBNT AP.
Wow, wonder who that "somebody" might be. That would be a workable solution I would think and allow for easy migration to the new system on a client by client basis without providing any interruption to any other clients on either of the systems.
Make sure if somebody writes that tool it would save the congifuration at well so that if we mass push it out and then for one reason or anoither the radio is rebooted it would not lose these changes.
Could you also look at the option of adding the Management VLAN in a pre-config, mentioned this a few times in the threads and no one has spoken about this.
We have a very large network and it is all VLAN off. Without a Management VLAN on the SM we can not access it.
Yes, I would say if you are going to go this route then make a LOT of options configurable by preloading them in the Ubiquiti config file. This could potentially allow us the ability to do nearly hands aoff automated updates to the network which would be awesome. Things like network settings (NAT / PPPoE,...), Radius, cnMaestro,...
Is there any move on this pre-configuration process?
We would be glad to beta-test anything that is available.
It would speed us up enormously to be able to upload a 'User Provisioned Root Cert' and not have to switch APs away from Radius but any pre-configuration would help...
We've started to work on it. Its not trivial, so it won't be quick. We'll keep you posted.
Thanks,
Sriram
Rather than trying to use the ubiquiti file what about allowing us to use a known good backup file from a cambium running the same version?
Most of our network is running DHCP so with the exception of the customer's name the bulk of our customers have the same config. It also minimises how much you have to worry about UBNT changing the config file.
I would be interested in this as if you could load a cambium config file into the firmware a very useful feature request would be to allow us to do the same to normal firmware which means that even if a SM defaults it will have a known good config which will probably allow it onto the network at least long enough for its final config to be applied (hopefully negating a truck roll).
From what I understand this was one of the uses of custom scripts with UBNT. If the two sections can be separated (config from firmware, e.g. store the config in the .data section of an ELF binary) the hash checks of the firmware don't have to be compromised (and will remain consistent across all networks). Secondly its a config file nothing executable should be in it hence you should also be able to avoid UBNT's current security issues.
If they would just enable "open" by default on ePMP Elevate, the need for being able to pre-configure anything would be a complete non-issue for me.
All I would need to do would be to switch off WPA2 on the AP while I'm adding Elevate devices - then once I'm done and the new radios are all configured properly, turn WPA2 back on, and all is well. The only downtime involved would be the time it takes for all the existing customers to reconnect after turning WPA2 off.
Any other settings can be dealt with as part of the upgrade process on each device individually, but having it able to connect to the AP is kind of important. Is there really anything else that you actually need pre-configured other than the WPA2 key?
Wow, wonder who that "somebody" might be. That would be a workable solution I would think and allow for easy migration to the new system on a client by client basis without providing any interruption to any other clients on either of the systems.
Make sure if somebody writes that tool it would save the congifuration at well so that if we mass push it out and then for one reason or anoither the radio is rebooted it would not lose these changes.
1) Elevate an UBNT radio on the bench (you're going to want physical access to it)
2) once it's up and running with the ePMP elevate firmware, configure with all the necessary settings for a generic template that will be able to connect to your network, and save the settings (you could do this for each individual customer, if you have settings like PPPoE that are unique for every customer, but that would be very time consuming and doesn't make sense to me... you could probably also manually edit the config files for each customer, but I don't want to get into that - using a generic template seems simpler to me).
3) downgrade to UBNT firmware through the ePMP web interface (do not use the tftp method to get back to UBNT firmware, as that would erase everything).
4) Use an SCP client to get "/etc/persistent/mnt/.configured_3.2" file from the radio and use it as sm.json