> Now, as I recall, Netmon simply punts, and displays the first as an SMB,
> and the rest as TCP data. It is probably looking for the \255SMB on the front.
Yes, NetMon, like many other packet decoders, doesn't handle "packets"
that take more than one frame - or, for that matter, multiple "packet"s
per frame. That deficiency (and "snoop"s similar deficiency) is one of
the things that got me interested in packet analyzer programs in the
first place....
> To treat these as continuation segments of the original SMB
> request/response, we need some state info (another reason :-). The state I
> would keep is:
>
> <SIP, DIP, SP, DP, Session Message Len, Start Sequence #>
>
> for each direction. Since there is no session ID in NetBIOS over TCP
For NBT, the reassembly of a NBT Session Service packet could be done,
in part, at the TCP layer (which could present to the layer above TCP
the non-duplicate data in the TCP stream, in sequential order - and show
partial or full retransmission with comments in the TCP decode), and, in
part, at the NBT layer (which would keep track of NBT Session Service
packet lengths, and decode the NBT Session Service header and hand the
full NBT packet - which would be made of one or more pieces of frames -
to SMB).
That might work better with a NetMon-like model of decoding, wherein the
dissector routine would add instances of "properties" to a frame; a
"property" would correspond to a particular field in a protocol, and an
instance of a property would be that field in a particular packet. With
that model, you wouldn't have to decode all of a frame at once.
(With that, you could also get NetMon's ability to, say, limit the
display only to, say, SMB requests of a particular type, or to requests
with a particular file name, or to search for packets of that sort.)
