FIND SERVICE sent during Main Phase

[manojkumarms1999]

Hello everyone, presenting a issue "FIND SERVICE are sent during Main Phase in SOME/IP-SD" that has occured while stress testing

As we know according to [PRS_SOMEIPSD_00408] Sending Find entries shall be stopped after receiving the corresponding Offer entries by jumping to the Main Phase in which no Find entries are sent.

From the below log we can observe particular service has entered the Main Phase with cyclic_offer_delay of 2 seconds

on logcat logs particular to the above timing no suspected log observed.

Environment : on Multiple sleep wakeup scenario between 2 ECU's which uses same SOMEIP Stack 3.1.20.3 Occurence of the issue : RARE ( 5 /100 )

let us know this kind of behaviour is usual / rare or can be ignored too. 👍

Refered docs :

https://www.autosar.org/fileadmin/standards/foundation/1-4/AUTOSAR_PRS_SOMEIPProtocol.pdf https://www.autosar.org/fileadmin/standards/classic/22-11/AUTOSAR_SWS_ServiceDiscovery.pdf

[manojkumarms1999]

[ UPDATE ] Please, let us know this kind of behaviour is usual/rare or it will raise any unexpected behavior in future, as for now no issues were raised in the application.

[k08eYLx]

can you attach your full pcap file?

[manojkumarms1999]

find after answer.zip @k08eYLx attached the pcap

[manojkumarms1999]

@k08eYLx attached the pcap

[JMRNunes1980]

Hi!

We've analyzed the pcap you've sent and there are a few puzzling issues. Independent of being in main phase or not, assuming that 237.61.0.1 is your multicast address, it is clearly visible that there is a set of repeated offers at 22:08:31,0267*** (I wonder why are there 3 offers sent from the same device with such a short time interval from the same device. Perhaps something is present in the app code forcing this) from the device 192.68.61.3 with the exact same services to which the device 192.168.61.1 is sending the finds. What is expected from the 192.168.61.1 device is to either subscribe to them or send no more than 1 find, while we do see 3 of them. This is an abnormal behavior to which we only see 2 possibilities: 1) either the device 192.168.61.1 is not being able to read messages from multicast address due to network issues 2) the apps with the service id 0x0021, 0x0024 and 0x0028 have some strange code forcing the finds, somehow. They can also be crashing.

About the claim of finds while being in the main phase, there are some issues that can cause this: The cycle repetition phase => main phase is related with the app cycle itself. If the app crashes and restarts, by any reason, there is a possibility of seeing their finds once again. If you have lazy load, there is a possibility of having the finds of that app when the DUT appears to be in the main phase, as they start only later on. In order to debug these issues, It is necessary to look at the dlt logs of the DUT and try to check its lifecycle. These may give hints on the reason for this behavior.

Just as a side note, we have actually tested both of these cases recently and weren't able to replicate them. As such, we did not found a vsomeip problem.