Open padraic-padraic opened 4 years ago
Linux User? It sounds like an OS restriction.
Yep, necessary context: This is in a docker container based on debain buster. Testing on the server is slightly annoying as system python is stuck at 3.6....
Docker containers do not support ipv6 by default. https://docs.docker.com/config/daemon/ipv6/
First check if you can bind to your specific address and port:
python3 -m http.server 4840 --bind localhost
python3 -m http.server 4840 --bind 127.0.0.1
Also, binding to localhost won't get you anywhere if you want to access from outside. I don't know if this is good practice, but binding to 0.0.0.0 and publising the port always works.
My question then I guess is about the resulting endpoints, which have addresses like 172.x.x.x and a discovery url of 0.0.0.0. Would this potentially cause issues when connecting with a client? For example, we're using the National Instruments client and it seems to use the endpointURL to verify the server certificate as part of opening a session.
Would this potentially cause issues when connecting with a client?
Yes. https://github.com/FreeOpcUa/python-opcua/issues/680 https://github.com/FreeOpcUa/python-opcua/pull/687
The working solution is replying to the client with the address that is (or should be) included in the client's own discovery request. This also works over VPN etc. The complicated part is to keep a list of certificates at server side for each of the IP's where the server can be contacted.
Hello,
I am trying to setup an OPC-UA server and I'm not quite clear on the behaviour of
Server.set_endpoint
. If I try to use anything other than0.0.0.0
, I get an error from asyncio that it cannot bind to the address. For example, using localhost givesAnd a similar error, with the public IPv4 addres substituted for
::1
, if using the server IP.Am I not using this correctly?