> 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.
What would you do if it doesn't match?
I.e., what is the purpose for doing so?
> 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?
Set "pinfo->private_data" to point to the value (which must be a single
variable, so if you have more than one value to pass, put them in a
structure), and have the sub-dissector fetch the value from
"pinfo->private_data".
You might want to save the old value of "pinfo->private_data" before
setting it, and restore it after the subdissector returns.
> > 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?
Yes, you can use the "Decode As..." menu item for that. (It doesn't
select streams, it selects a packet, and lets you specify whether to
dissect the source or destination port number as the protocol in
question.)
You'd have to register your dissector as a "conversation dissector" for
TCP in order to make that available (and it'd have to be the netlib
dissector, i.e. a dissector for something that runs directly atop TCP).
