> the current SMB decode code, apart from not decoding everything, which I am
> working on, also has problems when it sees a NetBIOS continuation.
>
> This is where a NetBIOS message has been split across multiple TCP segments
> because the NetBIOS message was larger than MSS.
...which isn't unique to NetBIOS, either; ONC RPC-based services may
have the same problem when run over TCP (e.g., NFS-over-TCP), and have
similar problems with UDP (fragmented IPgrams).
> My next approach will be to implement a hash table of the NetBIOS messages
> we have seen,
...which, if I remember correctly (which I may not), you may also need
for decoding SMB "transaction" requests, as I *think* the reply doesn't
contain an indication of which particular type of "transaction" request
it is, so you need to know what type the request was in order to decode
the reply. (ONC RPC *definitely* has that problem.)
Note that "we have seen" appears to imply that at least some of the
capture-decoding needs to be done sequentially, i.e. needs to be done
before the user selects a summary line to get the detailed display.
That could also potentially be useful for continuations - if you know
that the frame you're looking at contains the beginning but not the end
of a NetBIOS Session Service "packet", you can infer that (the
non-retransmitted part of) the following segment includes a continuation
of the data in that "packet".
One possibility might be the Network Monitor-ish scheme I've mentioned,
where *all* the decoding is done, purely sequentially, when the capture
is read in, with a list of "property instances" being attached to the
frame for all of the fields in the frame, and with the detailed display
being constructed from the list of "property instances" for a frame when
the frame is clicked on.
This does mean more work has to be done when the file is read in, and
frames may be decoded even if the user never clicks on them in the
summary line. Most of the "property instances" won't, however, have to
have the actual packet *data* associated with them, just the offset in
the frame and the length, so at least the decoding won't have to pull
packet data out, at least for fields whose value isn't required by the
dissection code in order to figure out what to do next (for example, the
IP header "time to live" field isn't required for that, although the
"protocol" field is).
Some other things that scheme might buy you are
1) the ability to have the summary line for the packet reflect
stuff discovered whilst decoding the packet (e.g., you don't
know whether a BOOTP/DHCP packet is a BOOTP packet or a DHCP
packet until you see a DHCP Message Type option or get to the
end of the packet without seeing one; the summary line could
give the DHCP message type if there is one in the packet - we
don't currently do that, although we could make a special
case for BOOTP, so this scheme isn't necessary for that);
2) the ability to have a display filter that can select "all NFS
requests with a file handle of XXX" or "all SMB OPEN requests
with a pathname of YYY" (although that could also be done by
having the dissection code capable of being asked to check,
for fields it decodes, for specific values, and have "search
for a packet that match this filter" or "show me only packets
that match this filer" operations run sequentially through
the file dissecting each frame with the "check for a match"
option).
The disadvantages are
1) as indicated, it could make reading the file in take more
time;
2) more memory required to hold the property lists for all
packets.
