How to auto-select TCP conversations the old way?

asked 2025-09-10 21:06:15 +0000

BtrieveBill
1 ●1 ●1 ●1

Recently, Wireshark's function for setting a display filter on a conversation has changed. When I right-click on a packet, select Conversation Filter and select TCP, I now get "tcp.stream eq 12". In previous versions, I would instead get the more complicated filter limiting the IP address and TCP port numbers selected.

While this is not a problem for doing quick trace analysis using a single capture file, this is completely unsuitable when working with multiple simultaneous traces, where one was taken at the workstation side, another was taken at the server side, and a third was taken at the core switch using port mirroring. Using the old format, once you found an "interesting" conversation on the client side, you could easily jump to the server-side trace, paste in the same filter expression, and see the same trace data on the server side, thus seeing the flip side of the conversation (and if any packets were lost or mangled across the wire). With this "new" solution, if you first filter in one trace and get "tcp.stream eq 12", you cannot just paste the filter text into the other two trace files -- you have to actually go and find at least ONE of the packets from the desired trace and then select a new conversation filter there, which will be completely different.

Yes, I know that I can type it all in manually, but I try to use my time efficiently, and typing in numeric address and port data is simply not my idea of using my time effectively, especially with my fat fingers.

I tried delving into the Preferences, but came up empty. I then started digging through Advanced settings, searching on "convers", "filter", "display" and even "TCP", but couldn't find anything there, either. The only thing I DID find was that if I went to the Statistics/Conversations screen and THEN right-clicked on the TCP stream 12, and then selected Prepare as filter/Selected/A<->B, then this DID use the old format, giving me the data I needed of "ip.addr==192.168.11.148 && tcp.port==50130 && ip.addr==192.168.10.33 && tcp.port==3351". However, that's an awful lot of steps when it was working so easily before.

Any idea how to change the operation back to the old/useful way?

edit retag flag offensive close merge delete

Comments

There's a discussion here, but the only suggested method is using the Conversations dialog as you mention: https://gitlab.com/wireshark/wireshar...

johnthacker ( 2025-09-10 22:17:35 +0000 )edit

I am not sure what you call recently. It took me a moment to fugure out how long ago I have gotten used to the follow stream.

hugo.vanderkooij ( 2025-09-11 09:14:27 +0000 )edit

The Conversations dialog is really not helpful, as when you have 100+ conversations in a trace file, you end up having to scroll through the list to find the right one. Sometimes this is easy, but in some cases, the first packet seen in a conversation is from the server (due to timing), so it flips the A and B sides, making the sorting on the conversation list somewhat useless.

As for "recently", I don't know exactly when it changed. In many cases, I am working with one trace at a time and it's not a big deal. However, I'm currently working with a client where packets are getting lost or damaged over the wire. I can easily see the conversation on the client side, but just copying the tcp.stream filter to the server-side trace doesn't work.

BtrieveBill ( 2025-09-11 17:22:27 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2025-09-11 18:12:38 +0000

Chuckc
3133 ●6 ●644 ●20

How to access fields in custom packet context menus?
1500: WSLUA: Add new lua function register_packet_menu()

(There is NO !!! error checking in this so anything other than a vanilla TCP packet will have issues)
You can kick the tires by copying the script below into the Wireshark gui Lua console then click "Evaluate" to add the menu entry.
The set_filter() is the "Prepare" step and the "apply_filter() applies so you could have a "Prepare Filter" and "Apply Filter". There is also a Lua copy_to_clipboard(text) that might save you a step before copying to another Wireshark instance.

local function tcp_conv_filter(...)
    local tcp_filter = ""
    local fields = {...};
    for i, field in ipairs( fields ) do
        if (field.name == 'tcp.port' or field.name == "ip.addr") then
            if (tcp_filter ~= "") then
                tcp_filter = tcp_filter .. " && "
            end
            tcp_filter = tcp_filter .. field.name .. " == " .. field.display
        end
    end
    set_filter(tcp_filter)
    apply_filter()
end

register_packet_menu("XXX  My Conversation Filters  XXX/TCP", tcp_conv_filter, "tcp.port");

edit flag offensive delete link

Comments

That worked perfectly, as you suspected, and placed the selection on a single right-click menu, so it is even 1 click shorter than delving into the Conversation Filter/TCP menu. However, that new function goes away after closing and re-opening WS, so it doesn't seem to be any better in the long run.

BtrieveBill ( 2025-09-11 19:26:37 +0000 )edit

Welcome to extending Wireshark with Lua. :-)
How Lua fits into Wireshark
WSDG: Chapter 12. Lua Support in Wireshark

Save the script to a text file with a .lua extension.
Place it in the "Personal Lua Plugins" folder (B.4. Plugin folders).
The menu pick should then be available after restarting Wireshark.

Chuckc ( 2025-09-11 19:47:32 +0000 )edit

add a comment

answered 2025-09-10 22:18:06 +0000

SYN-bit

18600 ●9 ●364 ●255 https://SYN-b.it

Any idea how to change the operation back to the old/useful way?

The only way to have the old behavior back is to have the code reverted or to add code to give an option to choose between the two ways to filter the conversation. Please do realize that using the tcp.stream way is more precise (in case of reused ports), but indeed local to one file.

A workaround would be to enable the calculation of the CommunityID. This can be done by going to Analyze -> Enabled Protocols and then enable it. The CommunityID is a hash of the 5-tuple designed to create an ID for each session that can be used across different Applications. So also between two Wireshark instances with different files.

Once the CommunityID protocol is enabled, each packet will contain this ID and it can be used to filter out a specific TCP or UDP session and the filter can be copied to other Wireshark instances and/or files :-)

edit flag offensive delete link

Comments

I can concur with this -- adding CommunityID seems to allow for a workable solution. This is great on my own system while I am digging through customer-side traces. However, when sending the results of the trace analysis to the client, they often want to see the same thing I am seeing, and now I have to tell them how to enable CommunityID, too, since this is DISABLED by default. (I expect this is also a bit slower.)

So,in short, there are a lot of workarounds, but none are as quick as the old right-click was. I understand that tcp.stream is more accurate, but perhaps the gitlab discussion is appropriate here -- adding back the filter on address/port to the right-click menu as a different option would provide the best of both worlds.

BtrieveBill ( 2025-09-11 17:39:05 +0000 )edit

add a comment