Wireshark-dev: Re: [Wireshark-dev] Using find_conversation with multiple conversations conducte
> graham.bloice@xxxxxxxxxxxxx wrote:
>
> Kelvin,
>
> From your description I think you have multiple concurrent
> "conversations" from the RTU's via the gateway. Unfortunately
as I
> understand it the conversation support in wireshark expects the
> conversations to be sequential. I struggled to get this part
of the
> dissector working so will need a greater mind than mine to suggest
a
> solution. I presume something could be done with the RTU address
as
> an additional identifying parameter for the conversation, so maybe
> conversation support could be extended to allow searching existing
> conversations with additional info other than the IP\port combo.
>
> BTW, how does the dissector cope with fragmented messages over UDP
> or does your gateway always send complete data link packets?
>
> I think you should raise a bug on bugzilla (https://
> bugs.wireshark.org/bugzilla/) noting that it's the conversation
> support that's lacking and attach a pcap file illustrating the problem.
What is the best way to handle this scenario? Should
I have a look at the find_conversation() code to try and extend it to allow
inclusion of addresses / identifier of higher-level protocols that sit
on top of TCP or UDP?
I have this same sort of problem for a range of industrial
protocols where traffic from a network of multi-dropped serial devices
is going through a gateway device. In this way you might have 5 or
6 'conversations' running concurrently across the same TCP or UDP stream.
Do people think I'm heading the right direction to
investigate extending find_conversation() et. al. or is there a better
approach?
Regards,
Kelvin Proctor
