[Question] How much time/effort to add -20 support?

[zezain]

Hello,

I'm more a user than a dev, but i can maybe be able to find contributors to this project. how much work do you estimate that is needed to add -20 on this project?

[chardin-cpi]

-20 should already be in the code - it just needs people to test and look for errors.

https://github.com/ChargePoint/wireshark-v2g/blob/v0.7.0/src/packet-v2giso2.c

That is the dissector for the 15118-20

[barsnick]

That's incorrect. You misunderstood OpenV2G. Their "iso2" codec is based on a preliminary draft (DIS) version of ISO 15118-2 Ed. 2 (or "2v2"), which was never finalized as FDIS. Instead, ISO went the 15118-20 path, but OpenV2G never implemented it (publicly). The author also explains that here.

The path you implemented with the "ISO2" code is basically not used for anything in the wild.

OpenV2G's project page says:

Note: the V2G implementation for ISO 15118-20:2022 will not be available as Open Source.

See also the clear remarks in this discussion thread.

(Disclaimer: I'm a co-author of an alternative open-source codec which also covers the proper ISO 15118-20.)

[jhart-cpi]

@barsnick you're right about the ISO15118-20 grammar support, we don't implement it, considering we're based solely on OpenV2G's generated codec.

This dissector is set up in two stages, the first is the SDP header dissection in Lua which then pivots into the C code to do the EXI processing.

So the scope of work for adding support is likely:

1. Implement the SDP packet header changes for ISO15118-20 support in the Lua
2. Add 15118-20 decoding support (simple, right...?)

There are numerous approaches to adding that support, it isn't necessarily limited to C or C++.

That said, if you have an OSS codec, we accept patches.

[jhart-cpi]

To clarify @zezain's original question: it will take some time to implement because we have to create and/or integrate a 15118-20 EXI decoder. EXI decoders are specific to the grammar and -20 has 5 unique grammars (wpt, acdp, ac, dc, common) in addition to xmldsig so there are more messages to consider, even if the payloads are simplified. For example, -20's schemas largely does away with the V2G_Message>Header>Body>MessageType wrapping the previous grammars did.

I would ballpark at minimum a few weeks to months, but as previously mentioned, we gladly accept patches.

[zezain]

Thanks @jhart-cpi for the explanation.

Did you take a look on this ?

Don't know how if it could be compatible with this dissector but interesting anyway to see how others open source projects are doing.

[jhart-cpi]

Did you take a look on this ?

First time I've seen that dissector, it looks like an interesting project. Under the covers they're using the project that @barsnick has mentioned, namely cbexigen. Theirs appears to be a pure Lua approach which would be compatible, assuming it was installed correctly and would just need to be integrated into the header parsing we already have.

Given that OpenV2G hides its EXI generation tooling, it seems like the more forward looking solution would be to use cbexigen's C output, so I imagine were we to adopt it, we would replace OpenV2G entirely in this codebase. As mentioned, if somebody were to take up this work, we happily accept patches and would integrate it.

That said, the timeline wouldn't change from my perspective, we update this tool as we have time to do so.