Wired Intelligent Edge

Hello everyone,

I recently started playing around with the rather newer REST API of the ArubaOS-Switch devices. It is the first time for me programming in python, but thanks to the French How-To-Guides from Aruba Employee alegall and Google Translate, I was able to get a basic setup running.

However I've encountered two problems so far, that unfortunately I cannot solve by myself.

1. On the factory-default configuration without a username and password, I'm able to create a specific VLAN on the Switch without generating a cookie.

But I'm not able to delete that VLAN. Is that an intended behavior?

url = "http://192.168.1.10/rest/v1/vlans"
delete_vlan = requests.delete(url, data=json.dumps({"vlan_id": 10}))

2. I was unable to get the file-transfer working. As far as I understood that function, I should be able to upload a firmware to the switch. The primary file transfer method in the past was TFTP, so I assumed that one.

url = "http://192.168.1.10/rest/v2/file-transfer"
fw = {
    "file_type": "FTT_FIRMWARE",
    "action": "FTA_DOWNLOAD",
    "url": "<path to TFTP>",
    "boot_image": "BI_PRIMARY_IMAGE"
 }
firmware_update = requests.post(url, data=json.dumps(fw))

 I appreciate any help or further reading material.

Hi AirMart,

Please see comments below :

1. When you want to delete a VLAN, you need to specify its ID in the URI. So in your case, you need to use the following code :

url = "http://192.168.1.10/rest/v1/vlans/10"
delete_vlan = requests.delete(url)

2. FileTransfer URI only uses HTTP/HTTPS remote server. So your binary needs to be hosted on a Web Server, and the URL key will have to be the complete URL to your file (ex : "http://192.168.1.1/depot/WC_16_06_0006.swi") :

Thank you very much for your answer, the delete VLAN function is now working fine. I just wasn't aware that the id needs to be placed in the URI. But for the file-transfer, the switch is still returning Code 404. So it seems that the switch cannot find the resource.

Switch shows these lines in the debug console:

rest RestSrv-2:Method = POST, URI = /rest/v2/file-transfer
rest RestSrv-2:status = 404, reason = Not Found

EDIT: Found the problem. Seems that my first testing switch an 2620 is just not having the file-transfer resource. I switched to an 2540 and now it's working.

Great - Thanks for the update.

Enjoy your automation journey :-)

---

@AirMart wrote:

 

Switch shows these lines in the debug console:

rest RestSrv-2:Method = POST, URI = /rest/v2/file-transfer
rest RestSrv-2:status = 404, reason = Not Found

 

 

---

Need API v3 for file-transfer ? (

In a way you are correct. After further testing it appers to me that "v2/file-transfer" works only since 16.04, although it has been documented since 16.02.

Is there any explanation for that?

Hi AirMart,

Actually, the File-Transfer appeared in 16.02, but only with only 1 supported type of transfer - This API has been enhanced in 16.03, especially in order to support more transfer types.

In the REST API and JSON schema in 16.02, in "device-rest-api -> schema -> common -> FileTransferType.json", you'll get this : 

{
"$schema":"http://json-schema.org/draft-04/schema#",
"description":"File types to transfer (FTT_)",
"title": "FileTransferType",
"enum":
[
"FTT_FIRMWARE"
]
}

So the only supported type is FTT_FIRMWARE.

For the same FileTransferType,json file, but in 16.03, you'll get this :

{
"$schema":"http://json-schema.org/draft-04/schema#",
"description":"File types to transfer (FTT_)",
"title": "FileTransferType",
"enum":
[
"FTT_CONFIG",
"FTT_FIRMWARE",
"FTT_EVENT_LOGS",
"FTT_CRASH_FILES",
"FTT_SYSTEM_INFO",
"FTT_SHOW_TECH",
"FTT_DEBUG_LOGS"
]
}

So 16.03 brought the support of config/event_logs/crash_files/system_info/show_tech/debug_logs file transfers.

Hoping that helps.

This is perfecly clear. But my problem is that my code is perfectly working with 16.04 but with 16.02 the response of the switch is always 404.

My Code:

fw = {
    "file_type": "FTT_FIRMWARE",
    "action": "FTA_DOWNLOAD",
    "url": "http://192.168.1.1/YA_16_02_0014.swi",
    "boot_image": "BI_PRIMARY_IMAGE"
    }
firmware_update = requests.post(http://192.168.1.10/rest/v2/file-transfer", data=json.dumps(fw))
print(firmware_update.json())

OK, I didn't understand that you we're working on the Firmware side.

Which version of 16.02 are you using ?

Perhaps I wasn't clear regarding this. I'm using YA.16.02.0014 at the moment.

Edit: Same result with YA.16.02.0025

Please try with "http://192.168.1.10/rest/v1/file-transfer", instead of v2.

Still error 404... Here's the debug log of the Switch:

0000:01:19:58.50 rest tHttpd:Received REST POST request
0000:01:19:58.56 rest tHttpd:(http_state:)http_process_post END
0000:01:19:58.63 rest tHttpd:REST request redirected to REST server
0000:01:19:58.70 rest tHttpd:Send REST request message to REST control task
0000:01:19:58.79 rest tHttpd:tHttpd is unblocked with necessary cleanup
0000:01:19:58.86 rest mrest_ctrl:Request for parse header
0000:01:19:58.92 rest mrest_ctrl:Request for parse header after method POST
0000:01:19:59.00 rest mrest_ctrl:uri len = 22
0000:01:19:59.05 rest mrest_ctrl: PARSE header Cookie  value : (null)
0000:01:19:59.13 rest mrest_ctrl:Validate operation:  operation is allowed 2
0000:01:19:59.21 rest mrest_ctrl:Rest valid Operation.
0000:01:19:59.27 rest RestSrv-2:Method = POST, URI = /rest/v1/file-transfer
0000:01:19:59.35 rest RestSrv-2:status = 404, reason = Not Found
0000:01:19:59.41 rest mrest_ctrl:read len 146
0000:01:19:59.46 rest mrest_ctrl:bytes_pending 0, nsent 146
0000:01:19:59.53 rest mrest_ctrl:read len 38
0000:01:19:59.57 rest mrest_ctrl:bytes_pending 0, nsent 38
0000:01:19:59.64 rest mrest_ctrl:read len 0
0000:01:19:59.68 rest mrest_ctrl:REST response is sent
0000:01:19:59.74 rest mrest_ctrl:REST request processed successfully

OK.

So, several things :

- Are you authenticated when you make you're request ? (Meaning, do you use a header/cookie - I don't see it in you POST) ?

- Do you have any issue with another API on this platform/version ?

- Can you upgrade your platform ? (Maybe an issue with this release)

Thanks.

1. Yes was unauthenticated, but also with authentication it's the same result:

0000:01:33:12.39 rest tHttpd:Received REST POST request
0000:01:33:12.45 rest tHttpd:(http_state:)http_process_post END
0000:01:33:12.52 rest tHttpd:REST request redirected to REST server
0000:01:33:12.59 rest tHttpd:Send REST request message to REST control task
0000:01:33:12.67 rest tHttpd:tHttpd is unblocked with necessary cleanup
0000:01:33:12.75 rest mrest_ctrl:Request for parse header
0000:01:33:12.81 rest mrest_ctrl:Request for parse header after method POST
0000:01:33:12.89 rest mrest_ctrl:uri len = 22
0000:01:33:12.94 rest mrest_ctrl: PARSE header Cookie  value :
   sessionId=jFbTpMktZQKAVFkc9IcVoXGEVUXrhu6IeuMOaK0BmbJgfq3ClodjZS6mpruagyL
0000:01:33:13.08 rest mrest_ctrl:Validate operation:  operation is allowed 2
0000:01:33:13.17 rest mrest_ctrl:Rest valid Operation.
0000:01:33:13.22 rest RestSrv-2:Method = POST, URI = /rest/v2/file-transfer
0000:01:33:13.30 rest RestSrv-2:status = 404, reason = Not Found
0000:01:33:13.37 rest mrest_ctrl:read len 146
0000:01:33:13.42 rest mrest_ctrl:bytes_pending 0, nsent 146
0000:01:33:13.49 rest mrest_ctrl:read len 38
0000:01:33:13.53 rest mrest_ctrl:bytes_pending 0, nsent 38
0000:01:33:13.60 rest mrest_ctrl:read len 0
0000:01:33:13.64 rest mrest_ctrl:REST response is sent
0000:01:33:13.70 rest mrest_ctrl:REST request processed successfully

2. I didn't test all the API's. Just tested to create and delete VLAN's and this is working.

3. Yes It is possible for me to upgrade the version. I tried now several versions YA.16.02.0014, YA.16.02.0025 and YA.16.03.0007. It's the same error code with all of these versions. The only version I get that to work with is YA_16_04_0013. Does that mean that file transfer is just working correctly with REST V4?

I've tried with release 16.03 if I remember, and no issues...

I'll try to test if possible.

Hi Airmart,

In addition to Arnaud's great help here, I'd like to point out some Python REST API framework that we have posted on our public GitHub, located here: https://github.com/aruba/arubaos-switch-api-python

These workflows show examples for configuring (and unconfiguring) multiple things for the AOS-Switch.  Note that as you've run into already, many REST calls require later versions of software, such as 16.04.

Also, I'd like to point you to a brand new Airheads Developer Community group where we discuss topics such as REST, Python, and other automation frameworks and tools, such as Ansible and the Network Analytics Engine.  This Developer Community is located here: https://community.arubanetworks.com/t5/Developer-Community/gp-p/NetworkAbstraction

Cheers,

Alvin

Hi Alvin,

thank you for pointing me to the new forum, perhaps the thread should then be moved to the Developer Community forum?

Regarding the transfer-file API:

Perhaps this API is bugged in 16.02 & 16.03? Because "/rest/v1/file-transfer" is perfectly working with 16.04 for me...