[unixODBC-support] Communication closed during authentication, Connection reset by peer, SQL state 28000

Daniel Kasak d.j.kasak.dk at gmail.com
Mon Jan 30 00:05:53 GMT 2017


If the Postgres driver is logging these errors, then you're attempting
to connect to SQL Server with the wrong driver. Post details of your
ODBC configuration.

Dan

On Fri, Jan 27, 2017 at 11:56 PM, marco ardito <ardito at apiform.to.it> wrote:
> update: it doesn't seems to be related to MSSQL, apparently...
>
> - I created a copy of the teiid virtual database, excluding any MSSQL server
> from its models
> - changed the web server config to load, through unixodbc, the new virtual
> database
> - it happens again... same message: " [unixODBC]Communication closed during
> authentication; Connection reset by peer., SQL state 28000 in SQLConnect"
>
> I looked for unixodbc logs, and found that this error is reported in many
> psqlodbc*.log files (I guess this name comes from the postgres driver usage)
>
> And this is how it appears there (there are many files like this): there's a
> first connection try that fails with the error, then another one that
> succedes... (no timings, though...?)
>
> can you spot any interesting info here?
>
> =================
> DSN info:
> DSN='dsnname',server='x.y.z.w',port='xxxxx',dbase='vdbname',user='user',passwd='xxxxx'
>
> onlyread='No',protocol='7.4',showoid='No',fakeoidindex='No',showsystable='No'
>           conn_settings='', conn_encoding='(null)'
>           translation_dll='',translation_option=''
> conn = 0x8058d3c8, PGAPI_Connect(DSN='dsnname', UID='user', PWD='xxxxx')
> Driver Version='09.02.0100,201306020000'
> Global Options: fetch=10000, socket=4096, unknown_sizes=0,
> max_varchar_size=255, max_longvarchar_size=8190
>                 disable_optimizer=0, ksqo=0, unique_index=1,
> use_declarefetch=0
>                 text_as_longvarchar=1, unknowns_as_longvarchar=0,
> bools_as_char=1 NAMEDATALEN=64
>                 extra_systable_prefixes='dd_;', conn_settings=''
> conn_encoding=''
> CONN ERROR: func=original_CC_connect, desc='', errnum=210,
> errmsg='Communication closed during authentication'
>             ------------------------------------------------------------
>             henv=0x8058c2b8, conn=0x8058d3c8, status=0, num_stmts=16
>             sock=0x8058b160, stmts=0x80589280, lobj_type=-999
>             ---------------- Socket Info -------------------------------
>             socket=38, reverse=0, errornumber=10, errormsg='Connection reset
> by peer.'
>             buffer_in=2153300704, buffer_out=2153316120
>             buffer_filled_in=0, buffer_filled_out=0, buffer_read_in=0
> CONN ERROR: func=PGAPI_Connect, desc='Error on CC_connect', errnum=210,
> errmsg='Communication closed during authentication'
>             ------------------------------------------------------------
>             henv=0x8058c2b8, conn=0x8058d3c8, status=0, num_stmts=16
>             sock=0x8058b160, stmts=0x80589280, lobj_type=-999
>             ---------------- Socket Info -------------------------------
>             socket=38, reverse=0, errornumber=10, errormsg='Connection reset
> by peer.'
>             buffer_in=2153300704, buffer_out=2153316120
>             buffer_filled_in=0, buffer_filled_out=0, buffer_read_in=0
> DSN info:
> DSN='dsnname',server='x.y.z.w',port='xxxxx',dbase='vdbname',user='user',passwd='xxxxx'
>
> onlyread='No',protocol='7.4',showoid='No',fakeoidindex='No',showsystable='No'
>           conn_settings='', conn_encoding='(null)'
>           translation_dll='',translation_option=''
> conn = 0x8058d9c8, PGAPI_Connect(DSN='dsnname', UID='user', PWD='xxxxx')
> Driver Version='09.02.0100,201306020000'
> Global Options: fetch=10000, socket=4096, unknown_sizes=0,
> max_varchar_size=255, max_longvarchar_size=8190
>                 disable_optimizer=0, ksqo=0, unique_index=1,
> use_declarefetch=0
>                 text_as_longvarchar=1, unknowns_as_longvarchar=0,
> bools_as_char=1 NAMEDATALEN=64
>                 extra_systable_prefixes='dd_;', conn_settings=''
> conn_encoding=''
>     [ PostgreSQL version string = '8.1.4' ]
>     [ PostgreSQL version number = '8.1' ]
> conn=0x8058d9c8, query='select oid, typbasetype from pg_type where typname =
> 'lo''
>     [ fetched 1 rows ]
>     [ Large Object oid = 14939 ]
>     [ Client encoding = 'UTF8' (code = 6) ]
> conn=0x8058d9c8, PGAPI_Disconnect
> =================
>
> Il 27/01/2017 09:24, marco ardito ha scritto:
>
> Thanks all for replying, and infos.
> From what you all wrote, it seems that the cause of the error can only be a
> connection to a Microsoft SQL server, isn't it?
>
> If it is so, I could restrict the field of investigation... my virtual
> database on teiid server has two different MSSQL servers behind, with a
> slightly different network path, too. I could try disabling one of them,
> temporarily. And maybe the really short lifespan of the issue (a simple
> retry then works) should point towards a transient network issue... instead
> of a dirver or configuration issue.
>
> I was in doubt about what subsystem was reporting the error (I thought to
> ask here because it was labelled by "[unixodbc]") because, as I said before,
> on my web server unixodbc uses only postgresql driver towards teiid (it is
> the only "db" unixodbc sees, and connects to), which in turn has several
> jdbc connections towards different databases on different web servers (two
> MSSQL, one Mysql server) and also other resources.
>
> If it is so, if it is really due to a connection towards a MSSQL server, it
> should be a problem better "visible" from Teiid, and its logs, since it's
> doing the real connection to those remote MSSQL servers... and unixodbc is
> only reporting the remote error transparently.
>
> I will soon contact teiid support team about this, but any further
> consideration you could add about the above will help me to better
> understand this matter, quite new to me...
>
> Thanks a lot.
>
> Il 26/01/2017 02:27, Daniel Kasak ha scritto:
>
> I'm not a heavy user, but I've done a little testing, here and there,
> against most of the freebie versions of SQL Server, ... You could try
> turning on ODBC tracing, examining SQL Server logs, etc. Good luck :)
>
> Dan
>
> On Thu, Jan 26, 2017 at 4:54 AM, Edouard Gaulué <listes at e-gaulue.com> wrote:
>
> Hi,
>
> In my case, I've observed those kind of unpredictable error after moving
> from SQL2008 to SQL2012.
>
> Any change on the SQL Server side?
>
>
> --
> Marco
>
>
>
> --
> Marco Ardito
> Responsabile Servizi Informatici
>
> Api Formazione s.c.r.l.
> Via Pianezza 123, 10151 - TORINO
> Tel: +39-0114513123
> Fax: +39-0114551150 - +39-0114515075
> Mail : ardito at apiform.to.it
> Web : http://www.apiform.to.it
>
> ------------------- [Ai sensi e per gli effetti della Legge sulla tutela
> della privacy (L. 196/2003), questa mail è destinata unicamente alle persone
> sopra indicate e le informazioni in essa contenute sono da considerarsi
> strettamente riservate. E' proibito leggere, copiare, usare o diffondere il
> contenuto della presente mail senza autorizzazione. Se avete ricevuto questo
> messaggio per errore, siete pregati di rispedire la stessa al mittente.
> Grazie]
>
>
> _______________________________________________
> unixODBC-support mailing list
> unixODBC-support at mailman.unixodbc.org
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
>


More information about the unixODBC-support mailing list