That is a really good idea, but instead of you having to manually
search for where the next pdu starts, it would be possible to teach
wireshark to do this automatically.
We already track the PDU boundaries for SMB as well as a bunch other
protocols so we know where a pdu starts/stops, most of the time.
Except in your situation where we have lost so many packets that we no
longer have any knowledge of pdu boundaries.
In that situation the only thing that can bring wireshark back on
track is to find a frame where the start of the SMB pdu is at the
start of the tcp segment.
We could do a lot better here especially for SMB since we can fairly
strong heusirsitics :
i.e. we can verify that the 4-byte length looks sane, we can verify
that the 'S' 'M' 'B' 0xff/0xfe/0xfd signature is there, we can check
that the command opcode is sane
and even check that the sessionid matches sessions from before the gap
in packets.
Hypothetically we could add a mechanism where a protocol could
register a callback to the tcp dissector and say
"if you have lost track of the pdu boundaries, and the attempt to call
the dissector at tcp segment offet 0 was also rejected then
call this special 'serach the whole segment to find a new PDU start' callback."
That should make it possible to automatically find those headers and
also dissect them.
On Mon, Dec 31, 2018 at 12:58 PM Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
>
> Hi folks,
>
> I recently had to perform some surgery on a packet capture that had
> dropped packets.
>
> I was capturing a GbE link that was operating at capacity and a few
> packets were dropped in the area I was interested in.
>
> I was chasing the reason that the current Mac OS X smbfs would
> disconnect from the server on some occasions.
>
> I was interested in the SMB headers and had no interest in the data
> carried in SMB writes or reads, and fortunately, none of the dropped
> packets in the area I was interested in covered SMB headers.
>
> Using wireedit, mergecap and Wireshark's ability to export packets
> from a point in the capture I was able to put together a new capture
> that showed me all the SMB info, by:
>
> 1. Exporting a singe frame where the NetBIOS/SMB header was in the
> middle of a TCP segment,
> 2. Remove the portion from before the NetBIOS header and adjust the
> sequence number (that is, essentially split the segment into two),
> 3. Merge the adjusted packet with the packets from after its position
> in the capture,
> 4. Make up the missing few packets/segments by saving the packet from
> before the missing segment, duplicating the data and adjusting the
> sequence numbers.
>
> This worked quite well and I was able to determine that the Mac OS X
> smbfs was sometimes not sending an SMB request and thus causing
> crediting issues.
>
> That lead me to think of the following changes that would be useful:
>
> 1. It would be useful to have a right-mouse-button menu item that
> allows you to split a frame into two TCP segments at the point where
> the mouse is pointing.
>
> This would possibly allow Wireshark to correctly dissect the data
> starting at that point, especially if you save the capture from the
> new frame forward.
>
> 2. It would also be useful if you could tell Wireshark: Please insert
> a TCP segment with random data to cover the missing segments that it
> so conveniently warns you about.
>
> Perhaps these could be handled by adding some sort of pcap-ng
> annotation to the frames specifying additional actions.
>
> Anyway, can anyone think of other ways to achieve what I want and
> other ideas like these?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
