Closed malsyned closed 1 year ago
It looks to me like the null byte is getting dropped in v2gexi.h:exi_add_characters()
, where a UCS string is converted into a C string before adding it to the tree. A null character will just cause the string to terminate early, and any character code >= 256 will have its high bits stripped off of it.
Wireshark's documentation has some guidance for how they'd like strings like these displayed at https://wiki.wireshark.org/Development/String-handling-in-dissectors#displayed-to-users but they don't mention any API calls that could be used to make that easier. The Wireshark function epan/dfilter/sttype-pointer.c:charconst_tostr()
looks like it gives a helpful template, though.
Sorry for all the spam on this ticket, I didn't realize that the work I was doing in my own repo would be reflected here.
Sorry for all the spam on this ticket, I didn't realize that the work I was doing in my own repo would be reflected here.
No problem, thank you for fixing this issue.
An EVCC I encountered during compatibility testing transmitted a
supportedAppProtocolReq
whoseProtocolNamespace
URNs all ended with�
. This is firstly an invalid XML entity, and then if a lenient parser translates it, it's still a null byte:However, wireshark-v2g displayed the ProtocolNamespace strings without any warning, error, or mention of the null character at the end of them:![image](https://user-images.githubusercontent.com/1999313/234930895-4e2528d4-2607-48f2-8689-2584e145a982.png)
Expected result: either some kind of error message about the invalid XML entity, or at least a '\0' or something at the end of the strings to indicate that they're unusual, like
[ProtocolNamespace: urn:din:70121:2012:MsgDef\0]
Actual result:
[ProtocolNamespace: urn:din:70121:2012:MsgDef]
Example pcap: null-in-protocolnamespace-strings.zip