On Jul 10, 2023, at 12:18 PM, Markku Leiniö <markku@xxxxxx> wrote:
> Anyway, to the point. In Zabbix protocol header (https://www.zabbix.com/documentation/current/en/manual/appendix/protocols/header_datalen) the normal data length is 4-byte unsigned integer ("uint32"). However, there is a flag for large packets, used in specific Zabbix proxy configurations where the configuration sizes are over 4 GB, and in those cases the data length is 8-byte unsigned integer ("uint64"). (Plus it uses compression, and the specified maximum uncompressed packet size is currently 16 GB.)
>
> In Wireshark the dissector functions use a signed integer ("gint", 32-bit, right?)
Right.
> as the length and start/offset parameters.
>
> Assuming that I would like to handle the full >2 GB protocol packets in Wireshark (I don't know how crazy or practical idea that would even be), how should that be done? For example, if I would like to give the user the possibility to right-click the huge JSON blob (in the Zabbix packet) and copy it to somewhere else for inspecting, what would I need to do to get past the 2 GB (signed 32-bit integer) limit?
You would need to change Wireshark:
1) not to use negative offsets to mean "offset from the end of the packet" (I don't know whether that's used anywhere) and not to use a length of -1 as meaning "to the end of the tvbuff" (there are already "to the end of the rebuff" APIs that should be used instead, although there may have to be more added) and not to use negative offsets or lengths for any other purposes;
2) to, having made the changes in 1), use 64-bit *unsigned* values as offsets within packets and lengths of packets.
This would still require reassembling packets into single chunks within the address space.