#60 sqsh -S <host>:<port> syntax does not work with sqsh 2.4 and freetds 0.91

[Stephen Marshall]

In my configuration, the sqsh -S <host>:<port> syntax does not work. This syntax allows connection to a server without having to predefine the host and port in a configuration file. I've compiled sqsh 2.4 against the freetds 0.91 library on Mac OS X 10.8.5. I'm using this software to connect to a Sybase ASE server 15.7.

The <host>:<port> syntax is only semi-documented, but the code contains several references to it, so I think it should work. This syntax is important to me because I am trying to fit sqsh into an existing application configuration framework that expects database servers hosts and ports to be specified as separate parameters.

I think I've found where the problem lies, but I'm not sure how a fix should be implemented so it does not have side effects in other compilation environments, e.g. using native Sybase CTLIB.

I've found that the problem comes down to one conditionally-compiled block of code. If the following code block is disabled, the -S <host>:<port> syntax works.

From sash-2.4/src/cmd_connect.c:

#if defined(CS_SERVERADDR)
    if(server && (cp = strchr(server, ':'))) {
        if(*cp)
            *cp = ' ';

    /* fprintf(stderr, "Using %s for CS_SERVERADDR\n", server);*/

    if (ct_con_props( g_connection,
                      CS_SET,
                      CS_SERVERADDR,
                      (CS_VOID*)server,
                      CS_NULLTERM,
                      (CS_INT*)NULL
                ) != CS_SUCCEED)
        goto connect_fail;
    }
#endif

I simply put the following line of code above this block, recompiled, and the -S <host>:<port> syntax worked without error.

#undef CS_SERVERADDR

This works because FreeTDS supports the <host>:<port> syntax as a fallback case when a server name cannot be found in the configuration file. See freetds file src/tds/config.c, parse_server_name_for_port function for details.</port></host>

This strikes me are more of a bug in FreeTDS than sqsh, but it is not entirely clear since I'm not in a position to test the code against client libraries other than FreeTDS. CS_SERVERADDR is an optional connection feature in the TDS protocol. If the support for CS_SERVERADDR in FreeTDS is incomplete, either the CS_SERVERADDR macro should be disabled in FreeTDS or the handling of this option should be fixed. However, if the problem is that sqsh does not make the appropriate calls to use the CS_SERVERADDR feature, the bug is in sqsh. The distinction comes down to whether this feature works properly when sqsh is linked against client libraries other than FreeTDS.

One simple way to side step this problem would be to provide an option to disable the CS_SERVERADDR macro in the sqsh configure script. This would allows users to disable CS_SERVERADDR at compile time if they want to use the <host>:<port> syntax.</port></host>

Any guidance on how this problem should be fixed so it work with all client libraries would be greatly appreciated.

Steve

[Martin Wesdorp]

Hi Steve,

Thank you for this bug report and your thorough analysis. I am able to reproduce your findings and I believe this is a bug in FreeTDS. FreeTDS does support the CS_SERVERADDR property with the ct_con_props call and sets the hostname and portnumber somewhere in its internal structures. However, ct_connect fails to use this information correctly and starts to complain:

freesqsh -Slocalhost:4100
Open Client Message
Layer 0, Origin 0, Severity 78, Number 44
Server name not found in configuration files.
Open Client Message
Layer 0, Origin 0, Severity 78, Number 45
Unknown host machine name.

However, when you just skip the ct_con_props call in FreeTDS it works fine, while ct_connect follows a different code path in this case. I can simply work around this issue to check if the code is compiled for FreeTDS or Sybase OpenClient. In the first case the CS_SERVERADDR code will be omitted and the host:port syntax will work in FreeTDS as well. In the long run, FreeTDS should be fixed to solve this problem.

In the mean time I am also making some changes in this area to be able to specify a filter like host:port:ssl to enable secure connections without using an interfaces file entry. However, this will only work with native Sybase OpenClient only. I will incorporate a fix in the new sqsh-2.5 release scheduled for somewhere in January.

Best regards,
Martin.

[Stephen Marshall]

Martin,

Thanks for your efforts in diagnosing the problem. I also appreciate your
suggestion for additional error handling to work around the problem.

I have submitted the issue as a bug to the FreeTDS project. More info
found here:
http://lists.ibiblio.org/pipermail/freetds/2014q1/028751.html

If you are looking for someone to test sqsh features against FreeTDS, I
would be happy to do so.

Yours,
Steve

On Wed, Dec 18, 2013 at 3:01 PM, Martin Wesdorp mwesdorp@users.sf.netwrote:

• assigned_to: Martin Wesdorp
• Group: v2.4 --> v2.5

---

• [bugs:#60] http://sourceforge.net/p/sqsh/bugs/60/ sqsh -S
  <host>:<port> syntax does not work with sqsh 2.4 and freetds 0.91*</port></host>

Status: open
Created: Mon Dec 16, 2013 05:00 PM UTC by Stephen Marshall
Last Updated: Wed Dec 18, 2013 08:00 PM UTC
Owner: Martin Wesdorp

In my configuration, the sqsh -S <host>:<port> syntax does not work. This
syntax allows connection to a server without having to predefine the host
and port in a configuration file. I've compiled sqsh 2.4 against the
freetds 0.91 library on Mac OS X 10.8.5. I'm using this software to connect
to a Sybase ASE server 15.7.</port></host>

The <host>:<port> syntax is only semi-documented, but the code contains
several references to it, so I think it should work. This syntax is
important to me because I am trying to fit sqsh into an existing
application configuration framework that expects database servers hosts and
ports to be specified as separate parameters.</port></host>

I think I've found where the problem lies, but I'm not sure how a fix
should be implemented so it does not have side effects in other compilation
environments, e.g. using native Sybase CTLIB.

I've found that the problem comes down to one conditionally-compiled block
of code. If the following code block is disabled, the -S <host>:<port>syntax works.</port></host>

From sash-2.4/src/cmd_connect.c:

if defined(CS_SERVERADDR)

if(server && (cp = strchr(server, ':'))) {
    if(*cp)
        *cp = ' ';

/* fprintf(stderr, "Using %s for CS_SERVERADDR\n", server);*/

if (ct_con_props( g_connection,
                  CS_SET,
                  CS_SERVERADDR,
                  (CS_VOID*)server,
                  CS_NULLTERM,
                  (CS_INT*)NULL
            ) != CS_SUCCEED)
    goto connect_fail;
}#endif

I simply put the following line of code above this block, recompiled, and
the -S <host>:<port> syntax worked without error.</port></host>

undef CS_SERVERADDR

This works because FreeTDS supports the : syntax as a fallback case when a
server name cannot be found in the configuration file. See freetds file
src/tds/config.c, parse_server_name_for_port function for details.

This strikes me are more of a bug in FreeTDS than sqsh, but it is not
entirely clear since I'm not in a position to test the code against client
libraries other than FreeTDS. CS_SERVERADDR is an optional connection
feature in the TDS protocol. If the support for CS_SERVERADDR in FreeTDS is
incomplete, either the CS_SERVERADDR macro should be disabled in FreeTDS or
the handling of this option should be fixed. However, if the problem is
that sqsh does not make the appropriate calls to use the CS_SERVERADDR
feature, the bug is in sqsh. The distinction comes down to whether this
feature works properly when sqsh is linked against client libraries other
than FreeTDS.

One simple way to side step this problem would be to provide an option to
disable the CS_SERVERADDR macro in the sqsh configure script. This would
allows users to disable CS_SERVERADDR at compile time if they want to use
the : syntax.

Any guidance on how this problem should be fixed so it work with all
client libraries would be greatly appreciated.

Steve

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/sqsh/bugs/60/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Martin Wesdorp]

Workaround released in sqsh-2.5