oznu/docker-unms

Discovery Manager and Firmware Manager not functioning

Saik0Shinigami opened this issue · 14 comments

I'm running my image on an ASUS TinkerBoard. I'm running Pi-Hole and Unifi Controller on this same board which is why I chose a weird port.

Ports:
80/443 for lighttpd
8080/8443 for Unifi Controller
9080/9443 for UNMS

I do not believe I'm having an issue with firewalls/routing as I can get connection and view real-time information if I manually input the UNMS Key to the node.

Using this command to instantiate,

sudo docker run -d --name unms --restart unless-stopped -p 9443:443 -e PUBLIC_HTTPS_PORT=9443 -e PUBLIC_WS_PORT=9443 -v /etc/UNMS/config:/config oznu/unms:armhf

or this docker compose

version: '2' services: unms: image: oznu/unms:armhf restart: unless-stopped ports: - 9080:80 - 9443:443 volumes: - /etc/UNMS/config:/config environment: - TZ=America/Phoenix - PUBLIC_HTTPS_PORT=9443 - PUBLIC_WS_PORT=9443

Both methods of creating the image lead me to this same problem. Discovery Manager appears to be unable to find any host/node although I can manually add keys and communicate that way. Firmware Manager fails EVERY update to any node (Error: Device Upgrade has failed). When connecting to a device that I attempted to update the device says that something was uploaded but the image was blank (Firmware image check failed). So communication is happening but something is seriously borked.

Posting on your thread at https://community.ubnt.com/t5/UNMS-Beta/UNMS-in-Raspberry-Pi-3/m-p/2275583#M4959 yielded me another person who has the same issue.

Edit: Forgot to mention OS on the tinkerboard... Armbian 5.38 stable (Ubuntu 16.04.4 LTS 4.14.14-rockchip)

oznu commented

Hi @Saik0Shinigami,

I've refactored how this image works a bit, it's now more inline with how ubnt does things so should be easier to maintain and might fix this issue as well.

The previous setup made modifications to every unms startup script, using this new method no changes are required to any of the startup scripts.

You can try it out with the latest beta they are running:

docker run ... oznu/unms:0.12.0-beta.7-armhf

The Discovery Manager now functions as expected.

Firmware Manager still fails with the same error. Although I only have one node at the moment I can test it on and it's a little far away from me so I can't rule out other issues. I'll try to get a test node up sometime this week(hopefully this afternoon) to see if this issue has been fixed, but at the moment it's looking like it's not.

upgrade from firmware version to firmware version has failed because of error (Error: Downloading firmware from device has failed).

If there's anything I can give you that would help identify the issue let me know.

Thanks for the new image. One out of two ain't bad for 24 hour turn-around. Appreciate it.

The second part of my issues still persists. Device clear across network couldn't firmware update, and a fresh out of box ERX wouldn't take a firmware update as well. I will be trying a spare radio I have in the morning.

Edit: Tested more devices, with more firmwares... Literally none works. ER-x, antenna radios, switches... Definitely borked.

oznu commented

@Saik0Shinigami is there anything in the container logs that might help debug this?

Good day. I have the same issue as @Saik0Shinigami. 0.12.0 with 42 devices. Where are the container logs found?

oznu commented

The container logs can be viewed using the docker logs -f <container name or id> command.

Ah didn't see the previous pings in my email... sorry...
After initial POST to apply update this is the only thing of note.

"
2018/04/09 15:27:09 [error] 7848#7848: *443718 open() "/www/firmwares/ubnt/eswh-1.7.4.180403.stk" failed (2: No such file or directory), client: 10.0.0.130, server: , request: "GET /firmwares/1523316427/Z5XeKihePq5UPKzzlM03-g/ubnt/eswh-1.7.4.180403.stk HTTP/1.1", host: "10.10.0.100:9443"
"

Just in case it matters, here the POST

"
180409/222707.516, [response] http://cb8f67d209b5:8081: post /v2.1/devices/0345972a-8aab-4683-8400-576f7770bf73/upgrade-to-latest {} 200 (99ms)
"

oznu commented

Thanks @Saik0Shinigami - just what I needed.

I've pushed up a build, which should be ready soon, that I think fixes this.

Pulled new image, spent about 2 hours fixing a completely unrelated issue(default log2ram is wayyy too small for the shit I run on this machine with all the garbage I'm running). And now firmware upgrades are now working.

Thanks for the work, I'll close this as my issues are good to go.

Hey @Saik0Shinigami if this issue is fixed then can we remove it from the README?

Remove what? This issue is a year old and was resolved through a build update. Not sure what you think was resolved here that's in the Readme.

Edit: Oh, I see now... it was resolved for me... I don't see why it should stay. But that's not up to me :)

On the README it says

Device firmware upgrades initiated from UNMS may not work (#7).

yeah I ninja edited previous post.

I don't see how it's relevant anymore except as a word of caution I suppose. It's probably not relevant anymore.