linuxipv6vsomeip

vsomeip-library - different behavior between IPv4 and IPv6 when using service discovery


Setup:

Observations:

Question

Does anyone know why the nodes do not communicate? Is there anything specific for IPv6 that I need to set?

Appendix: json configuration files and log of node 1

My json file for node 1:

{
"unicast" : "4242::1",
"logging" :
{
"level" : "trace",
"console" : "true",
"file" : { "enable" : "true", "path" : "/usr/cppPlayground/requestResponse2DevicesIpv6/node1.log" },
"dlt" : "false"
},
"applications" :
[
{
"name" : "request-response",
"id" : "0x1"
}
],
"services" :
[
{
"service" : "0x4433",
"instance" : "0x2211",
"unreliable" : "30510"
}
],
"routing" : "request-response",
"service-discovery" :
{
"enable" : "true",
"multicast" : "ff0e::1",
"port" : "30490",
"protocol" : "udp",
"initial_delay_min" : "10",
"initial_delay_max" : "100",
"repetitions_base_delay" : "200",
"repetitions_max" : "10",
"ttl" : "3",
"cyclic_offer_delay" : "2000",
"request_response_delay" : "1500"
}
}

My json file for node 2:

{
"unicast" : "4242::2",
"logging" :
{
"level" : "trace",
"console" : "true",
"file" : { "enable" : "true", "path" : "/usr/CppPlayground/requestResponseMirrored2DevicesIpv6/node2.log" },
"dlt" : "false"
},
"applications" :
[
{
"name" : "request-response-mirrored",
"id" : "0x9"
}
],
"services" :
[
{
"service" : "0x1234",
"instance" : "0x5678",
"unreliable" : "30509"
}
],
"routing" : "request-response-mirrored",
"service-discovery" :
{
"enable" : "true",
"multicast" : "ff0e::1",
"port" : "30490",
"protocol" : "udp",
"initial_delay_min" : "10",
"initial_delay_max" : "100",
"repetitions_base_delay" : "200",
"repetitions_max" : "10",
"ttl" : "3",
"cyclic_offer_delay" : "2000",
"request_response_delay" : "1500"
}
}

The log file for node 1 (started AFTER node 2):

2023-09-15 15:35:21.279421 [info] Using configuration file: "vsomeip-local_IPv6.json".
2023-09-15 15:35:21.281261 [info] Parsed vsomeip configuration in 2ms
2023-09-15 15:35:21.281666 [info] Configuration module loaded.
2023-09-15 15:35:21.282017 [info] Initializing vsomeip (3.3.8) application "request-response".
2023-09-15 15:35:21.282568 [info] Instantiating routing manager [Host].
2023-09-15 15:35:21.283269 [info] create_routing_root: Routing root @ /tmp/vsomeip-0
2023-09-15 15:35:21.283987 [info] Service Discovery enabled. Trying to load module.
2023-09-15 15:35:21.285998 [info] Service Discovery module loaded.
2023-09-15 15:35:21.286556 [info] Application(request-response, 0001) is initialized (11, 100).
2023-09-15 15:35:21.287161 [info] Starting vsomeip application "request-response" (0001) using 2 threads I/O nice 255
2023-09-15 15:35:21.287993 [info] Client [0001] routes unicast:4242::1, prefix:24
2023-09-15 15:35:21.287908 [info] main dispatch thread id from application: 0001 (request-response) is: 7f6d7edde700 TID: 1378
2023-09-15 15:35:21.288016 [info] shutdown thread id from application: 0001 (request-response) is: 7f6d7e5dd700 TID: 1379
2023-09-15 15:35:21.289400 [info] Watchdog is disabled!
2023-09-15 15:35:21.290087 [info] REQUEST(0001): [1234.5678:255.4294967295]
2023-09-15 15:35:21.290180 [info] io thread id from application: 0001 (request-response) is: 7f6d7d5db700 TID: 1381
2023-09-15 15:35:21.290169 [info] io thread id from application: 0001 (request-response) is: 7f6d7fedcec0 TID: 1375
2023-09-15 15:35:21.290694 [info] create_local_server: Listening @ /tmp/vsomeip-1
2023-09-15 15:35:21.292821 [info] OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:21.293393 [info] vSomeIP 3.3.8 | (default)
2023-09-15 15:35:21.293815 [info] Network interface "eno1" state changed: up
2023-09-15 15:35:21.294766 [info] Route "ff00::/8 if: eno1 gw: n/a" state changed: up
2023-09-15 15:35:21.295200 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30490
2023-09-15 15:35:21.295432 [debug] **Joining to multicast group ff0e::1 from 4242::1**
2023-09-15 15:35:21.295805 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30510
2023-09-15 15:35:21.295976 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30490
2023-09-15 15:35:21.296000 [info] SOME/IP routing ready.
2023-09-15 15:35:22.293609 [info] OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:22.294419 [warning] routing_manager_impl::handle_local_offer_service: Application: 0001 is offering: [4433.2211.0.0] offered previously by itself.
2023-09-15 15:35:23.294958 [info] OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:23.295723 [warning] routing_manager_impl::handle_local_offer_service: Application: 0001 is offering: [4433.2211.0.0] offered previously by itself.
*[... all the same as the two messages before...]*
2023-09-15 15:35:29.039199 [info] STOP OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:29.039906 [info] RELEASE(0001): [1234.5678]
2023-09-15 15:35:30.304243 [info] Stopping vsomeip application "request-response" (0001).

I did analogous steps for IPv6 as I performed for IPv4.

  1. Route multicast address to the ethernet device: sudo ip -6 route add ff0e::1 dev eno1
  2. Start the respective application on both nodes: env VSOMIP_CONFIGURATION...

This way, I was expecting the same behavior as with IPv4. Of course, I tried a lot of other stuff related to network configurations, but nothing to exciting differently than the mentioned approach.


Solution

  • It's a bug in vsomeip 3.3.8. It does not support service discovery with IPv6. A pull-request was opened some time ago. Unfortunately, the github search did not highlight the pull-request when I searched for relevant keywords...