Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stream packets have incorrect destination address with bridge network interfaces #832

Open
henriquesimoes opened this issue Oct 31, 2023 · 1 comment
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

Comments

@henriquesimoes
Copy link
Contributor

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:

    1. Connect the camera to a sub-network other than the host's;
    2. Create a Docker bridge network (or any other software bridge) in the host;
  • In a Aravis-based program:

    1. Connect to the camera through its IP address;
    2. Have bridge interface be the first one to answer back; This can be done by hijacking Aravis to query only the bridge interface. In my case, it was naturally the first interface whose response came.
    3. Attempt an acquisition: (no stream packets should come-up);

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:

  • Manufacturer: Basler
  • Model: acA1300-75-gm (version 106755-13)
  • Interface: Ethernet

Platform description:

  • Aravis version: 0.8.30
  • OS: Ubuntu 22.04
  • Hardware: x86_64
@EmmanuelP
Copy link
Contributor

I'm not sure how it is possible to configure the streaming automatically in this case, without probing all the interfaces. Do you have an idea about how to implement what you need ?

Meanwhile, it should be possible to set the correct stream destination IP by manually setting GevSCDA feature before starting the acquisition.

@EmmanuelP EmmanuelP added 1. Enhancement Issues that propose improvements to existing features 5. Gige Issue in the GigEVision implementation 2. Needs informations Needs an acceptable design solution to be identified 2. Needs design Needs an acceptable design solution to be identified and removed 2. Needs informations Needs an acceptable design solution to be identified labels Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

2 participants