Messages after "failed negotiation" show as "Handshake" in some cases

[JeremyWhaling]

Full disclosure - this is a bit of an edge case, and I apologize in advance for any sighing or shaking of heads with my request below. But I think there may be other similar cases, so please read on. :)

Background: I have a PCAP where the the vehicle specified only support for ISO 15118-2 Ed1, and the station only supported DIN 70121, thus resulting in a "failed - no negotiation" response from the EVSE. The EV seems to not handle this well and sends a few SessionSetupReq messages after this. This PCAP should be attached to this issue for your review.

My issue: I'm getting inconsistent response from the decoder. If I have the decoder preference (V2GTP under protocols section in the preferences dialog box) set to ISO1, sometimes I will get the first two messages as undecoded, but the following erroneous messages from the EV (the SessionSetupReq) will be decoded. Upon reloading the Lua plugin with a CTRL+SHIFT+L, or reopening the file, I will sometimes get the opposite, where the two session setup req/res messages will decode, but the rest will be listed as "Handshake".

It seems like there is inconsistent behavior of using the preference of forcing ISO1 decoding, vs the detection of session setup request. If I change the preferences from DIN to ISO1, save pref, then do a CTRL+SHIFT+L, I get the session setup messages decoded. A subsequent CTRL+SHIFT+L or reloading the file. will occasionally result in the second behavior where the two session setup req/res messages will decode, but not the rest. I've also reloaded the file with no changes in preferences (still on ISO1) and will sometimes get one or the other upon startup.

Ultimately, for the PCAP at hand I was able to work around this but I think there may be something up with how the preferences are being pushed to the Lua decoder, or how supportedAppProtocol is triggering the rest of the decode? Could have ramifications for other PCAPs or live captures where we truly want to force everything to one of the three decoding paths (DIN, ISO1, ISO2), which might not be consistently respected in the current logic. failedNegotiation2.zip

[JeremyWhaling]

Ah, I have found that the second case is due to me having two of the same decoder, for development - I have "V2GTP_TEST" for working on the new tweaks for this codebase. Disabling that results in seeing, apparently, the V2GTP lua decoder fail to start(?). You can trigger this by hitting CTRL-SHIFT-L a few times in a row, and you should get no protocols (just UDP and TCP) occasionally.

[JeremyWhaling]

Confirmed with another collogue that if they leave the decoder preferences to auto that they don't have this issue and the decoding looks like below every time even if they reset the lua plugin multiple times. If they change the preferences to ISO1 they occasionally get no decoding as I showed in my second message. Both systems are running Windows 10.

[jhart-cpi]

Since the addition of recent Lua dissector changes and the change from OpenV2G to libcbv2g, I'm not seeing any shift in behavior, at least, not on MacOS (aarch64) and Wireshark 4.2 as the base. The decoder can't identify the secondary grammar so leaves everything as Handshake consistently and setting decoding manually to ISO2 results in the SessionSetup decoded as expected.