aravis
aravis copied to clipboard
AravisProject
Allow overriding interface IP address of ArvStream
I am connecting to a camera which is on different subnet (from a Docker container on Windows host, not my choice); there is a bridge device between the container VM and the actual network which is relaying UDP traffic.
Controlling the device works fine (I have to connect using its IP as UDP broadcast will not work) but image transmission does not. The reason (as I understand) is that the device uses the in-container's IP in GevSCDA which is unreachable from the device. I tried changing it by hand (via set_integer_feature_value) but it gets re-set to the in-container IP when acquisition starts (I think this is done by Aravis internally), and changing it while the acquisition is running has no effect, as it seems from wireshark.
I was checking the sources, the arv_gv_stream_new ctor (https://github.com/AravisProject/aravis/blob/3499bb7ca7f32c06d128ed4b2e1b4e564ceed1ed/src/arvgvstream.c#L1011) takes the interface_address as argument though it is called from https://github.com/AravisProject/aravis/blob/1744c3c0741203c49e76bdc809776ff9370a5dac/src/arvgvdevice.c#L1206 and the address is obtained from gv_device->priv->io_data. That one is assigned https://github.com/AravisProject/aravis/blob/1744c3c0741203c49e76bdc809776ff9370a5dac/src/arvgvdevice.c#L1206 and can be passed as argument to arv_device_new. But then... I am lost :)
How can I call arv_device_new myself, without a corresponding camera object? Camera interface does not let me set my own IP address.
What is the correct way to achieve this?
I am using recent (git minus a few months) code. I am debugging the connection with python, but the actual code is c(++) which I guess makes no difference.
now I see this was discussed extensively under #204 (same use-case) but it seems suggestion 5 under https://github.com/AravisProject/aravis/issues/204#issuecomment-430503138
- Provide a way for the user of the library to specify the interface address. My software already knows which interface it is on because we have our own camera discovery.
was not implemented in that particular PR #210.
I got a bit futher in understanding how it works (I think).
One is the camera IP, as described above. The camera would not actually send out image packets to its NIC (to the cable) as the recipient is out of its NIC subnet, and by default, there is no gateway defined. I am able to work around that by setting camera's default gateway, be it a good solution or not. (I will be talking to the manufacturer
The other part is that there is _set_socket_filter (specifying basically that it only cares about GevCurrentIPAddress:GevSCSP → GevSCDA:GevSCPHostPort) which will discard packets rewritten by the NAT. When I comment _set_socket_filter out, the images get delivered.
Hope it makes sense.
One is the camera IP, as described above. The camera would not actually send out image packets to its NIC (to the cable) as the recipient is out of its NIC subnet, and by default, there is no gateway defined. I am able to work around that by setting camera's default gateway, be it a good solution or not.
That seems reasonable to require from the user to correctly configure the camera network parameters.
The other part is that there is _set_socket_filter (specifying basically that it only cares about GevCurrentIPAddress:GevSCSP → GevSCDA:GevSCPHostPort) which will discard packets rewritten by the NAT. When I comment _set_socket_filter out, the images get delivered.
Completely disable the packet filtering is not an option, we don't want to handle any random incoming packet. I guess a correct solution would be to detect the translated IP address and use it in the set_socket_filter call.
That seems reasonable to require from the user to correctly configure the camera network parameters.
:)) Agreed.
Completely disable the packet filtering is not an option, we don't want to handle any random incoming packet. I guess a correct solution would be to detect the translated IP address and use it in the set_socket_filter call.
How about using the destination IP (as sent by the camera) of some prior GVCP packet as GevSCDA? Or is it precisely that destination IP which gets lost in translation?
Is filtering by destination IP/port actually necessary? The packet gets to the interface and socket bound to that port -- so the destination condition is fulfilled automatically. Am I missing something?
Is filtering by destination IP/port actually necessary? The packet gets to the interface and socket bound to that port -- so the destination condition is fulfilled automatically. Am I missing something?
When the packet socket is uses, the socket is only bound to the interface address. It is the filter that selects packet using the stream port and device address.
https://github.com/AravisProject/aravis/blob/4bd13ecbb090d7bd3586045df818189f4c82d1c8/src/arvgvstream.c#L976-L992