O driver ODBC iSeries da IBM não envia nenhum tráfego quando invocado via isql ou de outra forma, obtendo [08S01] [unixODBC] e [ISQL] ERRO: Não foi possível SQLConnect

2

Nota: Eu substituí os endereços IP, nomes de banco de dados e usuários do servidor por exemplos. Isso não deve afetar nada.

A configuração

Instalei o unixODBC ( yum install unixODBC ) e o driver ODBC iSeries oficial da IBM ( yum install ibm-iaccess-1.1.0.5-1.0.x86_64.rpm , RPM baixado das áreas de login da IBM). A instalação adicionou com sucesso os drivers a /etc/odbcinst.ini :

[IBM i Access ODBC Driver]
Description             = IBM i Access for Linux ODBC Driver
Driver          = /opt/ibm/iaccess/lib/libcwbodbc.so
Setup           = /opt/ibm/iaccess/lib/libcwbodbcs.so
Driver64                = /opt/ibm/iaccess/lib64/libcwbodbc.so
Setup64         = /opt/ibm/iaccess/lib64/libcwbodbcs.so
Threading               = 0
DontDLClose             = 1
UsageCount              = 1

[IBM i Access ODBC Driver 64-bit]
Description             = IBM i Access for Linux 64-bit ODBC Driver
Driver          = /opt/ibm/iaccess/lib64/libcwbodbc.so
Setup           = /opt/ibm/iaccess/lib64/libcwbodbcs.so
Threading               = 0
DontDLClose             = 1
UsageCount              = 1

Os arquivos de biblioteca referenciados existem e estão corretamente vinculados (verificados via ldd , sem links perdidos).

Meu arquivo ~/.odbc.ini é assim:

[Foo]
Driver          = IBM i Access ODBC Driver
DATABASE        = FooDB
SYSTEM          = 123.45.67.8
HOSTNAME        = 123.45.67.8
PORT            = 446
PROTOCOL        = TCPIP

O problema

Quando executo isql Foo USER PASSWORD -v , obtenho essa saída após aproximadamente um minuto ou mais:

[email protected] [~]# isql FooDB USER PASSWORD -v
[08S01][unixODBC]
[ISQL]ERROR: Could not SQLConnect

Solução de problemas

Parece que está expirando, certo?

ping 123.45.67.8 retorna:

[email protected] [~]# ping 123.45.67.8
PING 123.45.67.8 (123.45.67.8) 56(84) bytes of data.
64 bytes from 123.45.67.8: icmp_seq=1 ttl=63 time=29.8 ms
64 bytes from 123.45.67.8: icmp_seq=2 ttl=63 time=29.8 ms
64 bytes from 123.45.67.8: icmp_seq=3 ttl=63 time=29.8 ms
64 bytes from 123.45.67.8: icmp_seq=4 ttl=63 time=31.0 ms
64 bytes from 123.45.67.8: icmp_seq=5 ttl=63 time=29.9 ms

telnet 123.45.67.8 446 retorna:

[email protected] [~]# telnet 123.45.67.8 446
Trying 123.45.67.8...
Connected to 123.45.67.8.
Escape character is '^]'.
foobar
^]
telnet> quit
Connection closed.

Ativar o log ODBC com Trace e TraceFile em /etc/odbcinst.ini produz saída como esta:

[ODBC][22093][1454628360.104274][__handles.c][450]
                Exit:[SQL_SUCCESS]
                        Environment = 0x13a4750
[ODBC][22093][1454628360.104316][SQLAllocHandle.c][364]
                Entry:
                        Handle Type = 2
                        Input Handle = 0x13a4750
[ODBC][22093][1454628360.104339][SQLAllocHandle.c][482]
                Exit:[SQL_SUCCESS]
                        Output Handle = 0x13a5080
[ODBC][22093][1454628360.104363][SQLConnect.c][3614]
                Entry:
                        Connection = 0x13a5080
                        Server Name = [FooDB][length = 4 (SQL_NTS)]
                        User Name = [USER][length = 7 (SQL_NTS)]
                        Authentication = [*******][length = 7 (SQL_NTS)]
                UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

                DIAG [08S01]

[ODBC][22093][1454628423.118602][SQLConnect.c][3982]
                Exit:[SQL_ERROR]
[ODBC][22093][1454628423.118628][SQLError.c][430]
                Entry:
                        Connection = 0x13a5080
                        SQLState = 0x7fff9a5bd7b0
                        Native = 0x7fff9a5bd5a8
                        Message Text = 0x7fff9a5bd5b0
                        Buffer Length = 500
                        Text Len Ptr = 0x7fff9a5bd5ae
[ODBC][22093][1454628423.118656][SQLError.c][467]
                Exit:[SQL_SUCCESS]
                        SQLState = 08S01
                        Native = 0x7fff9a5bd5a8 -> 10060
                        Message Text = [[unixODBC]]
[ODBC][22093][1454628423.118685][SQLError.c][430]
                Entry:
                        Connection = 0x13a5080
                        SQLState = 0x7fff9a5bd7b0
                        Native = 0x7fff9a5bd5a8
                        Message Text = 0x7fff9a5bd5b0
                        Buffer Length = 500
                        Text Len Ptr = 0x7fff9a5bd5ae
[ODBC][22093][1454628423.118704][SQLError.c][467]
                Exit:[SQL_NO_DATA]
[ODBC][22093][1454628423.118722][SQLError.c][510]
                Entry:
                        Environment = 0x13a4750
                        SQLState = 0x7fff9a5bd7b0
                        Native = 0x7fff9a5bd5a8
                        Message Text = 0x7fff9a5bd5b0
                        Buffer Length = 500
                        Text Len Ptr = 0x7fff9a5bd5ae
[ODBC][22093][1454628423.118739][SQLError.c][547]
                Exit:[SQL_NO_DATA]
[ODBC][22093][1454628423.118765][SQLFreeHandle.c][279]
                Entry:
                        Handle Type = 2
                        Input Handle = 0x13a5080
[ODBC][22093][1454628423.118784][SQLFreeHandle.c][330]
                Exit:[SQL_SUCCESS]
[ODBC][22093][1454628423.118827][SQLFreeHandle.c][212]
                Entry:
                        Handle Type = 1
                        Input Handle = 0x13a4750

Ele aloca com êxito um identificador, em seguida, ele tenta se conectar ao banco de dados, falha com um SQL_ERROR genérico, tenta fazer algo com o erro (não sabe o quê?) e desaloca o identificador.

Meu último recurso foi verificar o tráfego da rede diretamente. Aqui está o teste inicial, usando telnet :

[root@host /opt/ibm/iaccess]# tshark -i tun0 -x
Running as user "root" and group "root". This could be dangerous.
Capturing on tun0
0.000000000   10.10.1.10 -> 123.45.67.8  TCP 60 42054 > ddm-rdb [SYN] Seq=0 Win=13660 Len=0 MSS=1366 SACK_PERM=1 TSval=1992917110 TSecr=0 WS=128

...PACKETS...

2.316931937   10.10.1.10 -> 123.45.67.8  TCP 60 42054 > ddm-rdb [PSH, ACK] Seq=1 Ack=1 Win=13696 Len=8 TSval=1992919427 TSecr=4147650000

0000  45 10 00 3c f1 b3 40 00 40 06 73 d2 0a 0a 01 0a   E..<..@[email protected].....
0010  ac 10 1e 02 a4 46 01 be e0 f5 71 c8 1d a8 3b 71   .....F....q...;q
0020  80 18 00 6b f5 9b 00 00 01 01 08 0a 76 c9 89 83   ...k........v...
0030  f7 38 1d d0 66 6f 6f 62 61 72 0d 0a               .8..foobar..

...PACKETS...

Nós vemos alguns pacotes TCP, um dos quais contém foobar , exatamente como esperávamos.

Agora, aqui está o teste com isql :

[root@host /opt/ibm/iaccess]# tshark -i tun0 -x
Running as user "root" and group "root". This could be dangerous.
Capturing on tun0
^C0 packets captured

Sem tráfego!?

Honestamente, estou um pouco preso aqui. Não tenho certeza sobre o que tentar em seguida. Alguma opinião sobre o que poderia estar dando errado ou como solucionar essa situação difícil?

Observe que a configuração do servidor está bem. Consigo me conectar sem problemas usando os drivers iSeries ODBC da IBM para Windows.

    
por Agop 05.02.2016 / 00:51

1 resposta

0

Tudo bem, finalmente descobri. Que doozy.

Primeiro de tudo, faça um favor e pegue um dos drivers iSeries mais antigos da IBM, não os mais novos do iAccess. Quando você efetuar login, vá para IBM Software > Downloads > No-charge products, tools, and toolkits e, em seguida, pesquise odbc . Você deve ver drivers como IBM i Access for Linux (V7R1) . Pegue um desses.

Agora, com esses drivers mais antigos, você recebe uma mensagem de erro adequada:

[08S01][unixODBC][IBM][System i Access ODBC Driver]Communication link failure. comm rc=10060 - CWBCO1048 - A firewall blockage or time-out occurred trying to connect to the IBM i

Nice! Pelo menos agora podemos estar absolutamente, positivamente, com 120% de certeza de que o problema é algum tipo de bloqueio.

Mas qual é o bloqueio? O índice de documentação maravilhosamente bem organizado da IBM para o resgate: link

Tabela do artigo reproduzido aqui:

PC Function                   Port (non-SSL) SSL Port
Server Mapper                 449            449
License Management (see Note) 8470           9470
RPC/DPC (Remote Command)      8475           9475
Sign-On Verification          8476           9476
Database Access               8471           9471

Desbloqueamos a porta 8471 ("Database Access") e voila! Tudo começou a funcionar!

Atualização 08/03/2016: Por alguma razão, o Windows precisa de mais portas abertas do que o Linux. Para fazer isso funcionar no Windows, também precisávamos das Server Mapper e Sign-On Verification ports.

Nota lateral, aqui está outro parágrafo importante do artigo:

These port numbers (other than the Server Mapper) can be configured and, while the defaults are listed above, the actual values on a system may vary. The ports are retrieved from the service table. Determine these ports using the WRKSRVTBLE command on the system in question to determine if the ports have been modified from the default values.

    
por 08.02.2016 / 22:23