Skip to Content.
Sympa Menu

freetds - RE: [freetds] a REALLY wierd one

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] a REALLY wierd one
  • Date: Wed, 26 Mar 2003 17:26:45 -0500

> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: March 26, 2003 12:52 PM
>
> I've had reported a very wierd issue with FreeTDS. I am very
> One of our groups is converting some shell scripts which access the
> database.
> Previously these scripts were talking to a sybase database,
> and fired off
> "isql" sessions to retreive data from the databases.
> We are changing these scripts to use sqsh instead of isql.
> sqsh has been linked to FreeTDS (pretty much latest snapshot)

Hi Bill,

In the absence of real information, I thought I'd offer unwarranted
speculation?

One reason that Sybase would complain about receiving mixed-up packets would
be that it's receiving two sessions' logins on the same connection. That
is, perhaps for some reason FreeTDS is transmitting a login packet for a new
session using the TCP session of a pre-existing spid. Possible reasons:

1. We don't tear down the session correctly or completely, causing it to be
reused somehow.
2. A timing issue in libc, causing the socket descriptor to be reused.
(Close handle X, whose value is 7, open new handle Y, gets value 7 too,
which winds up connected to its old session.)

If you've got Ethereal or other network analysis tools, it should be
possible for someone trained in TCP to tell you if your login packets are
(incorrectly) sharing a TCP session. Definitely there are people here on
the list that could tell you that in an instant from a tcpdump trace. Then
it would "just" be a question of finding out why....

This is off the wall off the cuff stuff, probably not worth the paper it's
written on. But I haven't been able to dream up any other possibilities,
looking at it from the server side.

--jkl




> They are still accessing Sybase databases however, using TDS 5.0
>
> The shell script rapidly spawns many sqsh commands, although these are
> initiated serially.
>
> Occasionally one of the spawned sqsh commands fails with a
> strange error,
> although on other occasions it will work fine.
>
> I managed to capture TDSDUMP output for some of the failed
> sessions and I do
> not understand what is going on.
>
> Here is an example.
>
> <<error1.txt>>
> As you can see, I get a strange error complaing about the
> language name in
> the login record.
> I have compared the login packet sent in this failed session
> to a successful
> login packet, and the two are identical.
> I'm puzzled.
>
> Here's another error. This time we get a strange packet
> header back after
> the login record is sent....
>
> <<error2.txt>>
>
> Other examples seem to show packet headers getting jumbled
> and mixed up with
> TDS packets.


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.




  • [freetds] a REALLY wierd one, Thompson, Bill D (London), 03/26/2003
    • <Possible follow-up(s)>
    • RE: [freetds] a REALLY wierd one, Lowden, James K, 03/26/2003

Archive powered by MHonArc 2.6.24.

Top of Page