Stream packets have incorrect destination address with bridge network interfaces #832
Labels
1. Enhancement
Issues that propose improvements to existing features
2. Needs design
Needs an acceptable design solution to be identified
5. Gige
Issue in the GigEVision implementation
Stream destination address register is written based on the network discovery done through a probe control packet. This procedure, however, does not takes into account any packet forwarding done by network bridges. Thus, a network interface may forward the probe packet to another interface (whose IP address is completely different), which can make it be still be received by the camera, and answer forwarded back (since the bridge configuration will be applicable).
However, when a stream packet is later attempted to be sent by the camera hardware, it will be destined to the original (internal) bridge address, which will eventually be dropped, since the gateway (and no other router) will not know how to route them.
Note that the problem here basically consists in the fact that sending a control packet successfully does not necessarily mean that stream packets can be destined directly to that IP address.
I've experienced this issue with Docker network bridges, which typically use addresses in 172.x.0.0/16 sub-networks.
To Reproduce
Network and host setup:
In a Aravis-based program:
Expected behavior
Aravis should configure the camera to send stream packets using a host IP address that can be routed by the network.
Camera description:
Platform description:
The text was updated successfully, but these errors were encountered: