Elevator-tool to preconfigure before you Elevate

New topic about Device Elevator:

https://community.cambiumnetworks.com/t5/ePMP-Elevate/Device-Elevator-a-powerful-tool-for-your-network-lifting/td-p/75871

13 Likes

HI team,

           I had received mail regarding this  I want to know more about this elevator tool. is this CLI based ?.please send me the exact documents Regarding this.

Quick question; if I leave the bridge_ipaddr and bridge_gateway entries blank, will these be retained from the existing SM configuration?

No, unfortunetly it doesn't work like this.

It will carry over the address only there is no any ePMP configuration file on the unit.

OK, no worries - glad I didn't try it out!

Is there a way to change the subnet in the sm.json?

Never mind I got it with a minor alteration to the script.

SyntaxEditor Code Snippet

"bridge_proto":	"1",
			"bridge_ipaddr":	"10.xxx.xxx.xxx",
			"bridge_netmask":   "255.255.255.xxx",
			"bridge_gateway":	"10.xxx.xxx.xxx"
2 Likes

This might save some people some time; here's a (cleaned out of actual values) copy of an sm.json file I made with an XW radio on 3.3 that has some useful settings broken out.

{
  "wireless": {
    "@pref_ap[0]": {
      "ssid": "ssid",
      "security_method": "0",
      "key": "key"
    },
    "@wifi-iface[0]": {
      "mode": "sta",
      "rssi_watermark_lower": "-95",
      "key": "key",
      "tdd_tx_pow": "tx-pow-db"
    },
    "wifi0": {
      "def_country": "CC"
    }
  },
  "network": {
    "mode": {
      "bridge_proto": "1",
      "bridge_ipaddr": "IPADDR",
      "bridge_gateway": "GW",
      "bridge_dns_primary": "DNS1",
      "bridge_dns_secondary": "DNS2",
      "bridge_mtu": "MTU"
    }
  },
  "devagent": {
    "main": {
      "cns_url": "your-cnmaestro"
    }
  },
  "system": {
    "@system[0]": {
      "hostname": "nameme",
      "timezone": "AEST-10",
      "pwr_factory_reset": "0",
      "config_id": "1"
    },
    "ntp": {
      "mode": "1",
      "server1": "IP"
    }
  },
  "acs": {
    "@wifi-iface[0]": {
      "acs_control": "0",
      "acs_state": "0"
    }
  },
  "lldpd": {
    "main": {
      "enable": "0"
    }
  },
  "mactelnet": {
    "main": {
      "enable": "0"
    }
  },
  "snmpd": {
    "public": {
      "community": "public"
    },
    "private": {
      "community": "private"
    },
    "@system[0]": {
      "sysName": "",
      "sysDescr": ""
    }
  }
}
4 Likes

Settings do not appear to work with ver 3.4.1

It worked fine with 3.3 

Is there anything special to make it work with 3.4.1?

Hi

I've made the attached script which uses the Elevator script from:-

https://github.com/m0sia/elevator

It adds a it in a GUI, and allows multiple IP address to be used, and can edit the JSON file to the IP address of the radio.

If you don't add a password and or JSON file it will not perform  that step.

Enjoy

1 Like

Hi NGL_Connection,

You have to specify firmware version with "-n" parameter if you are using elevator.py

I believe you have to use only first two digits(eg 3.4, not 3.4.1).

Dmitry

1 Like

Not sure what I'm doing wrong. I tried repeatedly to get this to elevate a radio with just enough settings for it to connect to the ePMP AP and have an IP address so I can reach it and configure it.  

I'm using the GUI tool.

A Nanostation M2 XM 6.0.3 

Elevate firmware 3.2.2 and tried 3.4.1

I just uploaded the elevate firmware to a NS M2 , configured it with just most basic settings, bridge, IP,  and SSID. I then save the config as test.json   I get another NS M2 that is configured like  one of my ubiquiti customer radios and I connect to it via ethernet (not doing this to a live radio on a tower)

I start the GUI via the batch file that comes with it. I enter the username/password for the radio, the version I just enter 3.2  (tried 3.2.2 and when using 3.4.1 I tried 3.4.1 and just 3.4)  I select the test.json I created with the elevated NS I select the elevated firmware and enter the IP of the radio.   The upgrade reports every setp via the command window and everything goes as expected. 

However when I'm done the the radio has been updated to the elevate firmware but all settings are at default... it can also only be accessed using the 192.168.0.2  the  169.254.1.1  doesn't work  (not sure if that is relevant)

Also of note, when I revert the firmware on the NS to the Ubiquiti 6.0.3 the radio has the customer settings back, it's not defaulted.

What am I doing wrong ?

2ghz devices are only supported on 3.4.1 3.2.2 wont stsrt the wireless interface. And xm devices are slow as mud, give it 15 minutes


2ghz devices are only supported on 3.4.1 3.2.2


Well that's good because that was the two versions I said I tried.




give it 15 minutes


15 minutes to do what ? The xm radio accepts the firmware, starts up just fine and tries to connect to the ePMP AP here by my office just like any defaulted ePMP radio will do it just can't actually connect because it's running on default settings. I just can't get the settings from the json file to take when it's being elevated.

3.4.1 should work just fine, however you'll need to specify the version number with -n 3.4 on the elevator.py command line.

I Elevated a radio with that configuration just yesterday. If you have a spare radio and test AP on-hand (and it sounds like you do) you can follow the manual steps to configure/retrieve the configuration file from the device as per this post's 2nd half

http://community.cambiumnetworks.com/t5/ePMP-FAQ/ePMP-Elevate-ePMP-Elevator-Tool-Configuration/m-p/72538

When you retrieve the config from the downgrade d device filesystem, it'll be called .configured_3.4 or similar - the number after .configured_ is what you need to pass to Elevator to make it work.

Hi!

That is right. Please specify version 3.4 instead of 3.4.1 for settings to be apllied.

Thanks,

Dmitry

Figured it out, I was using a json file I created with an elevated radio. I used the json file that came with the tool and just changed what I needed to in it and now at least the radio took the settings from the json file. 

I have had no luck using the Python version of the elevator.py script due to a bug in the Paramiko SSH client library. I've tried numerous versions of Python on Mac OS, Linux and Windows. All yield the same result and fail to connect via SSH due to some host_key error. I am sure others will probably experience this as well.

I have ported the elevator.py script into a shell script and have everything working except my pre-configuration file is not being applied. I could really use some help. I am using the correct format and uploading it to /etc/persistent/mnt/config/.configured_3.4

I know that the JSON format for the .configured_3.4 file is correct because I have managed to pass it into the elevator.exe that I did successfully get to work on Windows. The problem is that elevator.exe does not suit my needs. In fact, it fails to allow a custom SSH port be passed to it. It is an important pre-requisite that we can pass in our non-standard SSH port to connect to our UBNT radios for elevation.

If we can get some assistance to take this to the finish line, we will post the shell script back to this forum as I'm sure others will benefit from it.

Hi!


@mattorola wrote:

I have had no luck using the Python version of the elevator.py script due to a bug in the Paramiko SSH client library. I've tried numerous versions of Python on Mac OS, Linux and Windows. All yield the same result and fail to connect via SSH due to some host_key error. I am sure others will probably experience this as well.


Do you mind sharing the error you've got from paramiko?


I have ported the elevator.py script into a shell script and have everything working except my pre-configuration file is not being applied. I could really use some help. I am using the correct format and uploading it to /etc/persistent/mnt/config/.configured_3.4



Can you please check that you are uploading passwd as well?


I know that the JSON format for the .configured_3.4 file is correct because I have managed to pass it into the elevator.exe that I did successfully get to work on Windows. The problem is that elevator.exe does not suit my needs. In fact, it fails to allow a custom SSH port be passed to it. It is an important pre-requisite that we can pass in our non-standard SSH port to connect to our UBNT radios for elevation.


 

In the newest version available on github I've added support for the port option(-P/--port). You can download windows executable using the following link:

https://www.dropbox.com/s/w5twm9zfwy8pwwk/elevator-win32-0.3.2.zip?dl=0

1 Like

Dmitry, thank you! My failure to copy /etc/passwd to to /etc/persistent/mnt/config/passwd seems to fix the issue. I am able to successfully elevate now using my shell script port of elevator.py. I will clean up the script a little bit and will share it back to this thread.

For your reference, here is the error I received below. I researched all known workarounds and the documented workaround already seems to be in place on line 57: client.set_missing_host_key_policy(paramiko.AutoAddPolicy())

python3.6 elevator.py -u ubnt -p ubnt -P 22 -n 3.4 -v 192.168.1.20

Connecting to device 192.168.1.20

Username: ubnt

Password: ubnt

Traceback (most recent call last):

  File "elevator.py", line 62, in <module>

    password=password, port=port

  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/paramiko/client.py", line 348, in connect

    server_hostkey_name = "[%s]:%d" % (hostname, port)

TypeError: %d format: a number is required, not str