vSomeip Version
v3.4.10,v3.6.2
Boost Version
1.71
Environment
QNX
Describe the bug
On cold boot, routingmanagerd (vsomeip 3.4.10) fails to receive REMOTE SUBSCRIBE from remote host.
Scenario : The routing application in QNX side is started before actual IP Address is up.
Root Cause :
At cold boot, vlanXX (the real network interface carrying someip communication) is not yet up when routingmanagerd starts (~00:00:04 uptime). vsomeip reads unicast: ip from vsomeip.json and calls IP_ADD_MEMBERSHIP(XX7.1X.0.1) — a one-time kernel socket operation — on whichever interface currently holds 1XX.3X.1X.X.
If that is loopback (lo0), the multicast socket is permanently bound to lo0. When vlanXXX2 later comes up (minutes later), the multicast group membership is never migrated — it stays on lo0 for the lifetime of the process. No SD traffic flows on the real network. No REMOTE SUBSCRIBE is ever received.
cyclic_offer_delay: 2000 in vsomeip.json only resends SD offers on the existing (wrong) socket — it provides no rejoin/rewire mechanism.
The only fix is to restart routingmanagerd after vlanXXX2 is up, so it rebinds multicast to the correct interface.
Question: vsomeip 3.4.10 has no built-in mechanism to re-bind UDP sockets when a network interface appears later — is this fixed in any newer stack version, including at QNX level?
My Observation:
v3.5.8 (Oct 13, 2025) for linux OS:
external communication: "Fix automatic multicast rejoin operations at startup" — explicitly fixes the startup binding scenario where multicast was joined on the wrong interface.
vsomeip's network-change-aware logic uses netlink to detect when the real interface with the configured unicast address comes up, then triggers an internal socket restart/rejoin. QNX has no netlink. Its equivalent mechanisms (PF_ROUTE socket, SIOCGIFCONF) are not used by vsomeip and there is no QNX-specific code path in the vsomeip source.
Tested version : vsomeip 3.4.10 & 3.6 — upstream is at 3.6.2 as of Feb 2026. Even the latest version does not fix this on QNX.
is there any fix planned for this kind of issue or should be handled in some other way ! suggestions welcome.
Reproduction Steps
Approach 01 : Delay routingmanagerd launch until vlanXX42 is up. [ cannot be done due to boot KPI ]
Result: Failed — other services depending on vsomeip IPC timed out before vlanXX42 was ready.
Approach 02 — Loopback Pre-Assign, No Restart
Detect vlanXX42 not yet up at boot
Pre-assign IP as an alias on lo0
Start routingmanagerd — it binds to lo0:XX.3X.1X.X
Once vlanXX42 comes up, remove the lo0 alias
Result: Failed — IP_ADD_MEMBERSHIP is a kernel-level binding. Removing the lo0 alias does not migrate the multicast socket. The socket stays on lo0 permanently. SD traffic never reaches the real network.
Approach 3: works but slay is causing an issue, some clients cannot register to vsomeip.
At start_vsomeip call site, check if vlanXX42 already has IP assigned:
- If yes (sleep/wakeup): skip lo0 alias — routingmanagerd binds directly to vlanXX42
- If no (cold boot): assign lo0 alias so routingmanagerd can start without waiting
Once VLANs are up, check if lo0 still carries IP
- If yes (cold boot confirmed): remove alias → slay → restart on real interface
- If no (sleep/wakeup): skip restart silently
Expected behaviour
without slaying routingmanagerd any solution can be done.
Logs and Screenshots
No response
vSomeip Version
v3.4.10,v3.6.2
Boost Version
1.71
Environment
QNX
Describe the bug
On cold boot, routingmanagerd (vsomeip 3.4.10) fails to receive REMOTE SUBSCRIBE from remote host.
Scenario : The routing application in QNX side is started before actual IP Address is up.
Root Cause :
At cold boot, vlanXX (the real network interface carrying someip communication) is not yet up when routingmanagerd starts (~00:00:04 uptime). vsomeip reads unicast: ip from vsomeip.json and calls IP_ADD_MEMBERSHIP(XX7.1X.0.1) — a one-time kernel socket operation — on whichever interface currently holds 1XX.3X.1X.X.
If that is loopback (lo0), the multicast socket is permanently bound to lo0. When vlanXXX2 later comes up (minutes later), the multicast group membership is never migrated — it stays on lo0 for the lifetime of the process. No SD traffic flows on the real network. No REMOTE SUBSCRIBE is ever received.
cyclic_offer_delay: 2000 in vsomeip.json only resends SD offers on the existing (wrong) socket — it provides no rejoin/rewire mechanism.
The only fix is to restart routingmanagerd after vlanXXX2 is up, so it rebinds multicast to the correct interface.
Question: vsomeip 3.4.10 has no built-in mechanism to re-bind UDP sockets when a network interface appears later — is this fixed in any newer stack version, including at QNX level?
My Observation:
v3.5.8 (Oct 13, 2025) for linux OS:
external communication: "Fix automatic multicast rejoin operations at startup" — explicitly fixes the startup binding scenario where multicast was joined on the wrong interface.
vsomeip's network-change-aware logic uses netlink to detect when the real interface with the configured unicast address comes up, then triggers an internal socket restart/rejoin. QNX has no netlink. Its equivalent mechanisms (PF_ROUTE socket, SIOCGIFCONF) are not used by vsomeip and there is no QNX-specific code path in the vsomeip source.
Tested version : vsomeip 3.4.10 & 3.6 — upstream is at 3.6.2 as of Feb 2026. Even the latest version does not fix this on QNX.
is there any fix planned for this kind of issue or should be handled in some other way ! suggestions welcome.
Reproduction Steps
Approach 01 : Delay routingmanagerd launch until vlanXX42 is up. [ cannot be done due to boot KPI ]
Result: Failed — other services depending on vsomeip IPC timed out before vlanXX42 was ready.
Approach 02 — Loopback Pre-Assign, No Restart
Detect vlanXX42 not yet up at boot
Pre-assign IP as an alias on lo0
Start routingmanagerd — it binds to lo0:XX.3X.1X.X
Once vlanXX42 comes up, remove the lo0 alias
Result: Failed — IP_ADD_MEMBERSHIP is a kernel-level binding. Removing the lo0 alias does not migrate the multicast socket. The socket stays on lo0 permanently. SD traffic never reaches the real network.
Approach 3: works but slay is causing an issue, some clients cannot register to vsomeip.
At start_vsomeip call site, check if vlanXX42 already has IP assigned:
Once VLANs are up, check if lo0 still carries IP
Expected behaviour
without slaying routingmanagerd any solution can be done.
Logs and Screenshots
No response