Hi,
I've completed preliminary work on the outer TDS protocol (netlib). Next
up is the TDS protocol proper.
They need to be registered in register[-static].c as well, but the major
stuff can be found in:
http://www.freetds.org/ethereal/packet-netlib.c
http://www.freetds.org/ethereal/packet-netlib.h
I'd appreciate any testers who might want to give it a try. If you
want to try it out, but don't have Microsoft SQL Server or Sybase, you
can grab FreeTDS (http://www.freetds.org) and hit Sybase's public JDBC
testing server. What is the process to get these included in the tree?
Let me know if you want diffs against CVS, but the changes to register.c
are rather trivial.
I've also added the following to packet-iscsi.c near the
beginning of dissect_iscsi(). It seems that the iSCSI stuff is a little
agressive in claiming netlib's packets as its own. I'm not really happy
with this solution as it is particular to avoiding the clash with netlib.
A better solution would probably be to tighten up iSCSI's criteria to be
more cautious, but I don't know iSCSI that well to do this.
/* check for netlib size field, so we don't step on TDS */
if (packet_len == tvb_get_ntohs(tvb, 2)) {
return FALSE;
}
Brian
On Tue, 20 Nov 2001, Guy Harris wrote:
> > If the port is 1433, or I've seen a login packet come through with the
> > port, I can be assured (well as good as it gets) that the thing at IP
> > address X and port Y is a SQL Server and I can automatically decode it.
>
> Then what you'd want to do if you see a login packet is to create a
> conversation for the source and destination addresses and ports (I'm
> assuming this is TCP rather than UDP, so you don't get requests from IP
> address C to IP address S1 and replies coming back to IP address C from
> IP address S2), and make the netlib dissector be the conversation
> dissector for that conversation.
