On Tue, 20 Nov 2001, Guy Harris wrote:
> There are actually two choices:
>
> 1) use a heuristic dissector, which might be a pain (you'd have
> to figure out the heuristic, *and*, if not strict enough, it
> might end up causing your dissector to grab stuff that's not,
> in fact, MS SQL traffic);
Given that there are only 8 bytes in the header and four of them are
garbage this could be a challenge. Luckily, I could verify the length
field against the actually packet length (minus tcp overhead). The last
fragment indicator can only have values of 0 or 1, and the type field has
a finite set of values as well.
I could also dig into the TDS login packet to establish that it is a valid
netlib stream and stash the IP and port number(s) somewhere to validate
against later packets. Any pointers on where to get/stash this info?
I have a basic netlib dissector going now...I think I'll take a stab at
the heuristics before going on to TDS proper. BTW, what is the best way
to pass a value (netlib packet type) from a lower level dissector to a
sub-dissector?
> 2) let the user specify the port to be used, as a preference,
> which means that if it's not using the default port, the user
> has to go in and tweak things.
In my environment we have dozens of servers all on different ports. This
would be a real pain. Is there a method to select a undissected stream
from the main window and then do a one time association with a particular
protocol?
> > Is there any documentation on this?
>
> Not really. Search for "heur_dissector_add()" and look at the modules
> in which it's called, for examples of heuristic dissectors. See, for
> example, the Quake dissector for an example of user-settable ports.
I'll document my trial and error with the heuristics and submit it then.
Cheers,
Brian
