Packet Size EOF Bug / Problem

[Alfa-Valor]

Currently I am using the ISO15118 software stack in a system that has an ethernet interface which cannot exceed 1500 MTU (Maximum transmission unit).

This means the interface can only receive a maximum of around 1500 bytes per packet.

I have found that when testing ISO15118-20 and certificates are sent between the EVCC and SECC that the packet(s) containing the certificate get split into for example two packets because of the size of the packets.

Only the first packet is read by the software stack and then rightfully so the Java codec complains about an unexpected EOF.

ERROR 2023-11-02 09:25:25,863 - iso15118.shared.comm_session (219): EXIDecodingError (Exception): Transformer Exception: java.io.EOFException: Premature EOS found while reading data.
Traceback (most recent call last):
File "/mnt/app_rw/data/SECC_SOFT_STACK/iso15118-master/iso15118/shared/exi_codec.py", line 292, in from_exi
exi_decoded = self.exi_codec.decode(exi_message, namespace)
File "/mnt/app_rw/data/SECC_SOFT_STACK/iso15118-master/iso15118/shared/exificient_exi_codec.py", line 63, in decode
raise Exception(self.exi_codec.get_last_decoding_error())
Exception: Transformer Exception: java.io.EOFException: Premature EOS found while reading data.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/mnt/app_rw/data/SECC_SOFT_STACK/iso15118-master/iso15118/shared/comm_session.py", line 201, in process_message
decoded_message = EXI().from_exi(
File "/mnt/app_rw/data/SECC_SOFT_STACK/iso15118-master/iso15118/shared/exi_codec.py", line 294, in from_exi
raise EXIDecodingError(
iso15118.shared.exceptions.EXIDecodingError: EXIDecodingError (Exception): Transformer Exception: java.io.EOFException: Premature EOS found while reading data.
ERROR 2023-11-02 09:25:25,871 - iso15118.shared.comm_session (220): EXI message (ns=urn:iso:std:iso:15118:-20:CommonMessages) where error occured: 8

TCPDUMP OUTPUT OF TWO PACKETS BEING SPLIT

10:01:29.612806 IP6 fe80::d60f:b2ff:fe07:359b.56906 > X Flags [.], seq 111:1539, ack 97, win 507, options [nop,nop,TS val 2107441199 ecr 184799943], length 1428
10:01:29.612954 IP6 X > fe80::d60f:b2ff:fe07:359b.56906: Flags [.], ack 1539, win 501, options [nop,nop,TS val 184804426 ecr 2107441199], length 0
10:01:29.615129 IP6 fe80::d60f:b2ff:fe07:359b.56906 > X Flags [P.], seq 1539:2297, ack 97, win 507, options [nop,nop,TS val 2107441199 ecr 184799943], length 758
10:01:29.615281 IP6 X > fe80::d60f:b2ff:fe07:359b.56906: Flags [.], ack 2297, win 501, options [nop,nop,TS val 184804428 ecr 2107441199], length 0

I am wondering if this is the intended behavior or if there is a proper way for me to receive these two fragments to combine into one message. I have already dabbled with introducing a kind of "Number of fragments" addition to the code however I have been unsuccessful in its execution so far because of lack of knowledge.

Has anyone had issues similar to mine?

Thank you.

[Alfa-Valor]

Okay so this is some very preliminary code. But this concept appears to resolve my issue. It is however not a very optimal solution

in iso15118/shared/comm_session.py rcv_loop()

message = await asyncio.wait_for(self.reader.read(7000), timeout)
message_len = len(message)

# Fragments are likely...
while (message_len > 1427): # TODO ENV MTU LIMIT, cap of 73 substracted from 1500 MTU for headers of packet
      append_msg = await asyncio.wait_for(self.reader.read(7000 - message_len), timeout)
      message = message + append_msg

      message_len = len(append_msg)

I would love to know, if I have just reinvented the wheel or if this is a new feature for this stack. Would it be worth it to create a pull request? Thank you.

[shalinnijel2]

Hmm...does replacing self.reader.read(7000) with self.reader.read() help?

[Alfa-Valor]

Hmm...does replacing self.reader.read(7000) with self.reader.read() help?

Trying this solution did not go very well. After trying for some time make it work I could not get the stack to show normal function. It appears to keep reading indefinitely after receiving the first message. Anyone other ideas?

@shalinnijel2