I’m not sure what exactly happened since when I originally set up remote access (direct port forwarded access) under this firmware it worked without a problem and I didn’t make any changes on the drive (in fact I never sshed in until I had this problem), but recently I disconnected the network cable from the drive and when I reconnected the cable, the drive would no longer access the drive remotely, only through a relay.
I tracked the problem down to an issue with the /usr/orion/communicationmanager/communicationmanager program not sending my external ip address along in the port forwarding test command to the wd2go.com web servers (I put a space between the .com and / to prevent the forum from clipping the link):
https://www.wd2go.com /api/1.0/rest/device_communication/######?format=xml&external_ip=&external_port=PORT&protocol=HTTP&device_auth=#######
The first ###### is the device id from the dynamicconfig.ini file. The second ###### is the authorization code. PORT is the 443 port forwarding port.
Since the “external_ip” parameter is blank, the request is invalid and the server responds with a 400 HTTP error with a description of " The request sent by the client was syntactically incorrect ()." This causes the communicationmanager program to always switch over to relay mode since it thinks the port forwarding check failed, when in truth port forwarding is set up correctly and working fine.
Since communicationmanager is a binary I can’t figure out why it’s leaving my external ip address out of the request, though when the communicationmanager is run, it outputs the following error a few times: “getaddrinfo() error : Name or service not known” so it’s possible the binary is failing to get my external ip address. The external ip address does get logged though.
I’ve worked around this issue by setting up my router to send the port forwarding commands whenever my WAN connection comes up (in case my external ip address changes) and then killing the communicationmanager program to stop it from switching to relay mode. That’s not an ideal work around though and I shouldn’t have to do it. I’ve emailed support, but have yet to receive a response.
Really though the external ip address shouldn’t even be necessary. The server should just try to connect to the ip address that the request comes from. The whole port forwarding set up is overly complicated. The only thing the server needs to know is the port numbers. The internal ip address and port numbers aren’t needed to access the box remotely and as stated the external ip address can be pulled from the request itself.
Is there any other logging I can do other than what I’ve already done to figure out why this isn’t working correctly?
