vsomeip icon indicating copy to clipboard operation
vsomeip copied to clipboard

Use IP_RECVDSTADDR in absence of IP_PKTINFO

Open danielfr-haleytek opened this issue 1 year ago • 5 comments

On FreeBSD-like network stacks, the socket option IP_PKTINFO is unavailable, but the option IP_RECVDSTADDR can be used instead.

This enables vsomeip for the new io-sock network stack on QNX 7.1+.

Co-author: Eric Sjöström [email protected] @EriComic

danielfr-haleytek avatar Oct 03 '24 08:10 danielfr-haleytek

@danielfr-haleytek can you rebase this? the value that you mentioned (IP_PKTINFO) that was hardcoded was just added to be able to build on QNX. if it makes sense for you to remove it, please make that change also on this PR

duartenfonseca avatar Oct 07 '24 16:10 duartenfonseca

@duartenfonseca: I just uploaded a new version with 3.5.1 merged.

danielfr-haleytek avatar Oct 08 '24 09:10 danielfr-haleytek

@danielfr-haleytek can we just merge this one for now, for us to do some more internal testing? while keeping the SO_BINDTODEVICE part as is right now. I also added a question on the other PR

duartenfonseca avatar Oct 08 '24 14:10 duartenfonseca

@duartenfonseca From our side, you can absolutely merge this PR, but we would recommend doing some basic testing (running your test suite) first as good practice. Please also note in particular:

  • We don't run 3.5.1, the PRs were tested on an older versions and the changes forward-ported. We have not tested the PRs with 3.5.1.
  • After applying this PR, I expect vsomeip to fail compiling on QNX with io-sock. This is due to SO_BINDTODEVICE not being defined (→ solved in #773). For other platforms, compilation and functionality should not be affected.
  • We don't think defining SO_BINDTODEVICE yourself is a solution. Doing so while not patching the endpoint implementations will try to set an undefined socket option, which, in the best case, will just have no effect. It does not bring back the desired functionality.

danielfr-haleytek avatar Oct 08 '24 14:10 danielfr-haleytek

@danielfr-haleytek yes we will first test both PR's internally, and then decide merging or not. I think it would make more sense like this. thanks for all your input (and EriComic).

duartenfonseca avatar Oct 08 '24 15:10 duartenfonseca