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

Reboot detection triggered when client starts up first #162

Closed
louisvanv opened this issue Oct 8, 2020 · 3 comments
Closed

Reboot detection triggered when client starts up first #162

louisvanv opened this issue Oct 8, 2020 · 3 comments

Comments

@louisvanv
Copy link

louisvanv commented Oct 8, 2020

Good Day,

  • I am experiencing an issue where a reboot is detected when a client application starts up before a server application.

2020-09-06 22:35:32.491709 [info] SOME/IP routing ready.
2020-09-06 22:35:32.492918 [warning] Route "ff00::/8 if: enp1s0 gw: n/a" state changed: up
2020-09-06 22:35:32.493587 [info] io thread id from application: 1111 (someipTCPClient) is: 7f52e4671700 TID: 1719
2020-09-06 22:35:32.494689 [info] shutdown thread id from application: 1111 (someipTCPClient) is: 7f52e5673700 TID: 1717
2020-09-06 22:35:32.495335 [info] main dispatch thread id from application: 1111 (someipTCPClient) is: 7f52e5e74700 TID: 1716
2020-09-06 22:35:32.496467 [info] REQUEST(1111): [1234.0001:4.4294967295]
2020-09-06 22:35:32.498032 [info] Listening at /tmp/vsomeip-1111
2020-09-06 22:35:42.484977 [info] vSomeIP 3.1.16.1 | (default)
2020-09-06 22:35:43.709746 [info] REGISTER EVENT(1111): [1234.0001.5678:is_provider=false]
2020-09-06 22:35:43.710344 [info] SUBSCRIBE(1111): [1234.0001.5678:ffff:4]
2020-09-06 22:35:43.755183 [info] Reboot detected: IP=fd53:7cb8:383:3::101
2020-09-06 22:35:43.756489 [info] expire_services for address: fd53:7cb8:383:3::101 : delete service/instance 1234.0001 port [0,0] reliability=false

  • Furthermore, when the server reboot is detected the client expires its subscriptions to the service and according to the log the client re-subscribes, but after this it does not receive any event notifications from the server.

2020-09-06 22:35:43.697884 [info] REGISTER EVENT(1111): [1234.0001.5678:is_provider=false]
2020-09-06 22:35:43.698443 [info] SUBSCRIBE(1111): [1234.0001.5678:ffff:4]

  • From the server's side the re-subscription can be seen:

2020-09-06 22:35:46.827440 [info] SOME/IP routing ready.
2020-09-06 22:35:46.828390 [warning] Route "ff00::/8 if: enp1s0 gw: n/a" state changed: up
2020-09-06 22:35:46.828787 [info] io thread id from application: 2222 (someipTCPServer) is: 7f36874d5700 TID: 7158
2020-09-06 22:35:46.829971 [info] shutdown thread id from application: 2222 (someipTCPServer) is: 7f36884d7700 TID: 7156
2020-09-06 22:35:46.830941 [info] main dispatch thread id from application: 2222 (someipTCPServer) is: 7f3688cd8700 TID: 7155
2020-09-06 22:35:46.831526 [info] OFFER(2222): [1234.0001:1.0] (true)
2020-09-06 22:35:46.833844 [info] Listening at /tmp/vsomeip-2222
2020-09-06 22:35:46.736603 [info] REMOTE SUBSCRIBE(0000): [1234.0001.5678] from fd53:7cb8:383:3::100 :40737 reliable was accepted

  • I am running these applications on separate host machines. Upon an initial investigation it seems that the difficulties I am encountering originate in service_discovery_impl::is_reboot lines 599-602 (version 3.1.16.1):

if (its_old_reboot_flag && _reboot_flag
&& its_old_session >= _session) {
result = true;
}

  • I am also attaching my configuration files for reference.

Server
{
"unicast": "fd53:7cb8:383:3::101",
"logging": {
"console": "true",
"dlt": "true",
"level": "debug"
},
"tracing": {
"enable": "true",
"sd_enable": "true"
},
"applications": [
{
"id": "0x2222",
"name": "someipTCPServer",
"num_dispatchers": 4
}
],
"services": [
{
"events": [
{
"event": "0x5678",
"is_field": "false",
"is_reliable": "true"
}
],
"eventgroups": [
{
"eventgroup": "0x5678",
"events": [
"0x5678"
]
}
],
"instance": "0x0001",
"name": "Service",
"service": "0x1234",
"reliable": {
"port": "29180"
}
}
],
"routing": "someipTCPServer",
"service-discovery": {
"enable": "true",
"multicast": "ff14::4:0",
"port": "30490",
"protocol": "udp",
"initial_delay_min": "10",
"initial_delay_max": "100",
"repetitions_base_delay": "200",
"repetitions_max": "3",
"ttl": "16777215",
"cyclic_offer_delay": "1000",
"request_response_delay": "1500"
}
}

Client:

{
"unicast": "fd53:7cb8:383:3::100",
"logging": {
"console": "true",
"dlt": "true",
"level": "debug"
},
"tracing": {
"enable": "true",
"sd_enable": "true"
},
"applications": [
{
"id": "0x1111",
"name": "someipTCPClient",
"num_dispatchers": 4
}
],
"clients": [
{
"service": "0x1234",
"instance": "0x0001",
"reliable": []
}
],
"routing": "someipTCPClient",
"service-discovery": {
"enable": "true",
"multicast": "ff14::4:0",
"port": "30490",
"protocol": "udp",
"initial_delay_min": "10",
"initial_delay_max": "100",
"repetitions_base_delay": "200",
"repetitions_max": "3",
"ttl": "16777215",
"cyclic_offer_delay": "1000",
"request_response_delay": "1500"
}
}

Do you have any advice on what exactly the problem could be here?

@lutzbichler
Copy link
Collaborator

Could you check whether pull request #179 "Bug-Fixes regarding IPv6 Multicast and Multicast Endpoint Clean-up" helps?

@lutzbichler
Copy link
Collaborator

Fixed with v3.1.20.2

@sdunnagan
Copy link

This seems to still be an issue in v3.1.20.3.

2021-11-03 12:15:00.975838 [info] Reboot detected: IP=192.168.1.63

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants