[onvif-util] add support of non-default port instead of hardcoded 80 (with patch)

[lazutov]

now onvif port is hardcoded as 80, so it makes onvif-util unusable for devices with custom port.

xaddrs << "http://" << wanted << ":80/onvif/device_service";

Please find out a patch adding support of custom port via optional cli option -P 10000

addport.patch

Example:

 ./onvif-util -u admin -p xx -P 10000 192.168.24.34
  successfully connected to host
    name: cam
    serial: 123456

> dump
....
Capabilities.Device.XAddr=http://192.168.24.34:10000/onvif/device_service

i`m not a c++ developer an this is my first real-world cpp code. Cpp is faraway outside my stack

I assume this code lacks strict checking of ipv4 port range and even numeric typing,

Thanks.

[sr99622]

Thank you for your input, the effort is greatly appreciated. I investigated the issue and made some changes to the file based on your suggestions. One thing I would point out is that the onvif port is hardcoded in the sense that it is in a fallback path of execution that is only activated in the case that the primary onvif discovery method is unsuccessful. In normal operation, the program will use the onvif discovery method to query the camera for its connection string. This will succeed in most cases where a camera is onvif compliant and able to receive UDP packets. There are cases where the camera may not be able to receive UDP packets, most notably if it is not residing on the local network, in which case the fallback path will be activated. There may be other scenarios where the fallback path is activated as well, camera behavior can be difficult to predict.

Having said all that, it would still be nice to be able control the port in the fallback path, but I would prefer not to add it to the main menu selection, as it represents a corner case that the vast majority of users will not ever see. For this reason, I added a text message that is shown in the fallback path that informs the user that the program is using the default port 80, and informs the user that the query can be run using full IP:port notation e.g. 10.1.1.1:8080.

During testing, I found that there was a missing call to GetTimeOffset which is needed for proper password hashing, and this has been added to the code, along with an authorization retry routine that will work around some Daylight Savings Time issues that sometimes occur.

[lazutov]

Thanks for detailed response and quick fix. I confirm that this fix solves my use case.

My use case is to check connectivity to camera behind NAT (RTSP+OVFIF ports are forwarded + ACL hardened). Long-ago curl -I -v http://x:[email protected]:10055/ showing any http-status was good enough. But later any requests outside curl -I -v http://x:[email protected]:10055/onvif/ were just closing the connection now some cameras close connection in the same way if they do not receive something "WSDL-ish/SOAP-y" like curl -v http://x:[email protected]:10080/onvif/device_service -d '<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><GetCapabilities xmlns="http://www.onvif.org/ver10/device/wsdl"/></s:Body></s:Envelope>' the test solution became more complex and far away from simple bash oneliner,

so i came to using onvif-utils for the purpose of checking WSDL endpoint availability behind NAT.

Thanks again for onvif-utils utility, which was found not only easy to use, but even to modify,