A question about parser multiple DoIP header in single TCP frame

[6reend0g]

081f710d47f19ce89513ae01080045000056004d40003e06c4360a44c9a40a4499f23458d1c8005be3203cb04c085018832c1bbe000002fd80010000000f10010e8062f1ab6608265068202041****02fd80010000000f1d010e8062f1ab6608438372202042

Hi, jacob,

I found that some projects will combine two or more DoIP frames in a single TCP frame, just like I pasted above. https://github.com/jacobschaer/python-doipclient/issues/51 . This issue also mentioned about a similar question. It seems ISO 13400-2 also recognized about this case, and give out the resolvation in Page 38, Sector 9.2, NOTE 1.

But read_doip() can only read out one DoIP frame from rx_buffer , If I have a multi-DoIP frame, It may only take the first DoIP frame when I trying to call read_doip() .

Do you have any experience to handle this case? Maybe we need a flag to let us know if there still have DoIP frames haven`t been parsed in rx_buffer after calling the read_doip() through receive_diagnostic() and send_diagnostic_to_address(). So we can parse it more times manually.

[jacobschaer]

I don't see how the spec is implying that. It's possible that a a given doip frame could be fragmented so there may be less than one doip packet per read() call which we handle. My recollection is every doip packet needs to be ack'd so I don't see how a participant could move onto the next frame early. What service are you seeing bypass this rule?

[6reend0g]

As it says "For TCP-based data, the header separates the individual DoIP messages within the data stream", I think it do imply that we can combine more than one DoIP messages in one TCP data segment.

It didn`t bypass the rule of ack, In my project, there are two situation the tester will receive a multi-DoIP frame:

1. Tester make request to different DoIP entity through gateway, all of them will return an ack, but if their response return in a close time, the gateway will combine them to one TCP data segment, as you can see in my first mentioned case, they replies from different logical address.
2. Tester make request to a single DoIP entity, but it deploys more than one DoIP stack, maybe we should see it as two entity? Some of the case it will combine the response of all stack.
   So do you think this compliant with the specification? Or it just a special implementation?

And in my memory, the messages sent by a DoIP server to a client seems allowed to not reply an ack, I will check the protocol to confirm this.

Thank you for you time, have a good day!

[6reend0g]

BTW, some of the OEMs do will make a reverse design: they let the ECU be the DoIP client, and tester be the server, so the ECUs won`t reply an ack.

[jacobschaer]

I don't think those cases are appropriate for this library even if they do exist.
This isn't meant to be or support being a server.
There wasn't a direct intention to support talking to multiple logical addresses simultaneously from one client since you'd have to keep track of what specific acks you're looking for etc. The gateway in that case wouldn't necessarily be required to preserve order. If you want to talk to 2 logicals you should open two clients each with their own socket. This doesn't help for ecus that are socket limited but it's not a terrible sacrifice.

I'm sure there's plenty of OEM shenanigans out there but for those it's probably best to fork as needed. You'll need something synchronous for anything particularly fancy.

But you're welcome to post PCAPs.

[6reend0g]

Great, I was just about to ask if you’d be willing to let me upload my edited library.

Here is the PCAP, you can see the case in line 206-216
multi_DoIP.zip

[jacobschaer]

An example in that PCAP that stood out was frame 318

The ECU 10.68.201.164 was responding to the tester (0e80) with two DoIP packets:

1. UDS pending response from 1d86 regarding the transfer data (311)
2. Ack response from 1d02 regarding request transfer data (317)

Also packet number 200, 4 logicals behind 10.68.201.64 responded with Security Access simultaneously.

So this seems to just be the case of interleaving diagnostic sessions on a single transport which isn't something that udsoncan infrastructure supports really. It would be a large architecture change to support a shared DoIPClientConnector across multiple udsoncan clients. Not impossible, just not what was set out to be accomplished. I didn't see any examples of a given logical address responding with multiple DoIP frames per packet. Apply column "Source Address" and none had the same logical address multiple times.