ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] tshark option for reassembled fragment output

From: Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx>
Date: Sun, 3 Mar 2013 06:14:54 +0000
BTW, some output from that bug's pcap with your filter:

./tshark -r testcapture.pcapng -R 'ip.src == 10.90.130.69 && ip.dst == 10.90.130.66 && tcp.flags.push == 1'
  5 0.001054000 0.000050000 10.90.130.69 -> 10.90.130.66 HTTP/XML POST /urreq/rrurreq.dll/?soaprequest HTTP/1.1 

./tshark -r testcapture.pcapng -R 'ip.src == 10.90.130.69 && ip.dst == 10.90.130.66 && tcp.flags.push == 1' -2
  1 0.001054000 0.000000000 10.90.130.69 -> 10.90.130.66 HTTP/XML POST /urreq/rrurreq.dll/?soaprequest HTTP/1.1 

./tshark -r testcapture.pcapng -Y 'ip.src == 10.90.130.69 && ip.dst == 10.90.130.66 && tcp.flags.push == 1'
  4 0.001004000 0.000886000 10.90.130.69 -> 10.90.130.66 TCP [TCP segment of a reassembled PDU]
  5 0.001054000 0.000050000 10.90.130.69 -> 10.90.130.66 HTTP/XML POST /urreq/rrurreq.dll/?soaprequest HTTP/1.1 

Note that last one is what my patch is doing with the '-Y' mode.  If this replaces one of the current modes instead of being a new one, I'll make it stop printing the fragments out.  I couldn't decide if it seemed odd or not to print them, but I figured if it was a new option to do this reassembly thing anyway, that the user could just not use it if they were printing to stdout and din't want to see the fragments.

-hadriel


On Mar 2, 2013, at 10:50 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

> My instinct is to get rid of the 'read filter' concept entirely. I
> find it's behaviour in wireshark very confusing, especially in the
> reassembly cases we're considering. For example, take the capture from
> bug #8223 and run
> 
> ./wireshark -R "ip.src == 10.90.130.69 && ip.dst == 10.90.130.66 &&
> tcp.flags.push == 1" ~/testcapture.pcapng
> 
> You get a single frame (numbered frame 1) that displays as "2
> Reassembled TCP Segments (1765 bytes): #1(1460), #1(305)". There's no
> explanation in the UI as to why we now seem to have three different
> "frame 1"s floating around (I understand why, but I'm just saying it
> leads to a very confusing interface).
> 
> I would prefer to simplify by removing -R from wireshark, changing
> 2-pass analysis in tshark to not renumber the frames, and then not
> adding a new flag for the proposed feature. If someone really wants to
> do a 'read filter' style thing they can pipe two instances together,
> or save and reopen the filtered file.
> 
> Evan