I am having issue getting images from the camera inside a docker container using bridge networking. I think my setup is exactly as described in arv_gv_interface_camera_locate() fails if docker service is running · Issue #204 · AravisProject/aravis · GitHub. However, I think the corresponding PR (#210) isn’t actually applicable to the situation since the camera’s network interface (10.90.90.X) isn’t visible inside the docker container (and so won’t be found by getifaddrs).
In Allow overriding interface IP address of ArvStream · Issue #232 · AravisProject/aravis · GitHub it’s been agreed upon that it’s reasonable to require from the user to correctly configure the camera network parameters. I’m wondering if such a change can fix connectivity issues with docker bridge mode? If so, would a PR implementing such a change be welcomed?
I’m not sure what change you are going to implement, but a PR that improves the use of aravis inside a docker is welcome.
Hi, I was the one with #232 — I persuaded the customer to install (virtual) Linux on the server instead of Windows and did not proceed any further there. The Docker container worked without issues under Linux (I assume you are running Windows, right?). I still think that the ability to optionally override the default
GevSCDA (and perhaps others) as in #232 would be a way forward for these cases. What the bridge under Windows does is NAT but it does not have the understanding of the GV protocol to rewrite the IP addresses in the payload (similar to how NATs must have understanding of FTP which also uses two connections and they must be modified in a consistent manner IIRC).
I’m using Ubuntu both inside and outside docker. I was thinking of trying to override the interface_address used by arv_gv_device_new (if that makes sense to try), but I can try overriding the GevSCDA too. Any advice on how to make the library work under docker bridge mode would be appreciated.
OIC, sorry for misunderstanding. Can you use host network driver in Docker instead? That is the one I was using and it was flawless (no-hassle setup and running continuously for months). Though I certainly agree that there should be (at some point) a way for network quirks of this type in Aravis so that even bridged networking works, if necessary (such as in Docker under Windows).