[Richard Sharpe <realrichardsharpe@xxxxxxxxx>]

On Sun, Dec 30, 2018 at 7:58 PM ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
>
> 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.

OK, but in my case there was packet loss before the frame that
contained the signature and some loss within the next SMB segment.
However, the loss was only of data segments so I also needed to insert
some random data.

However, I think maybe I have discovered how to prevent that. Increase
the buffer size given to dumpcap (2GB or more.)

We will see.

> 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
> ___________________________________________________________________________
> 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



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)