MSSQL17 ODBC can't connect, how do I debug?

Help
1

I’m trying to make pyodbc work with mssql17 odbc, but it’s failing as documented in this bug msodbc17: TCP Provider: Error code 0x10 · Issue #235407 · NixOS/nixpkgs · GitHub

I would like to try and tackle this until the maintainer of the package is heard back from, but I’m not sure where to start. Right now, I’m testing with iusql which is a generic CLI for making connections to an SQL database using unixODBC. Basically, unixodbc is a library that dynamically loads the mssql17 ODBC library. When it tries to establish a connection with the port that docker opened to the mssql server, it fails.
This is only the case with the library packaged by nix
Outside of nix, the connection is established fine.

The nix package does some patchelf magic nixpkgs/default.nix at e7603eba51f2c7820c0a182c6bbb351181caa8e7 · NixOS/nixpkgs · GitHub . It’s not clear to me how to check if that failed besides running ldd, but that looks OK

ldd output 
$ ldd /nix/store/m72z6pjjgy2d4m3fsipl4jx18i2bwamx-msodbcsql17-17.7.1.1-1/lib/libmsodbcsql-17.7.so.1.1
        linux-vdso.so.1 (0x00007ffc310f4000)
        libdl.so.2 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libdl.so.2 (0x00007f47a6410000)
        librt.so.1 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/librt.so.1 (0x00007f47a640b000)
        libodbcinst.so.2 => /nix/store/x156lay2m0gcvwxflr8xfsii081gmy7i-unixODBC-2.3.11/lib/libodbcinst.so.2 (0x00007f47a63ec000)
        libkrb5.so.3 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libkrb5.so.3 (0x00007f47a6312000)
        libgssapi_krb5.so.2 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libgssapi_krb5.so.2 (0x00007f47a62bd000)
        libstdc++.so.6 => /nix/store/7ls5xhx6kqpjgpg67kdd4pmbkhna4b6c-gcc-12.2.0-lib/lib/libstdc++.so.6 (0x00007f47a5bda000)
        libm.so.6 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libm.so.6 (0x00007f47a5afa000)
        libgcc_s.so.1 => /nix/store/7ls5xhx6kqpjgpg67kdd4pmbkhna4b6c-gcc-12.2.0-lib/lib/libgcc_s.so.1 (0x00007f47a629c000)
        libpthread.so.0 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libpthread.so.0 (0x00007f47a6297000)
        libc.so.6 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libc.so.6 (0x00007f47a5914000)
        libk5crypto.so.3 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libk5crypto.so.3 (0x00007f47a6266000)
        libcom_err.so.3 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libcom_err.so.3 (0x00007f47a625f000)
        libkrb5support.so.0 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libkrb5support.so.0 (0x00007f47a6250000)
        libkeyutils.so.1 => /nix/store/yzqwq9gd0r62n97ab51qdsb3gg1vq7aa-keyutils-1.6.3-lib/lib/libkeyutils.so.1 (0x00007f47a6249000)
        libresolv.so.2 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libresolv.so.2 (0x00007f47a6234000)
        /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007f47a6417000)

My next step will be to use wireshark to monitor the traffic and see if any packets are making it to the port from the program, but since it’s working from outside of docker, it’s my suspicion that the problem is within the packaged lib…

strace seems like overkill and it’s very noisy, so I wouldn’t know what to be looking for.

What other things could I try?

2

Wireshark did help out. Observed DNS requests being made to name I gave to ODBC internally, instead of ODBC trying to contact the configured server. That led to checking the odbc.ini documentation to end up on pyodbc, where I found out MS doesn’t even Servername, but uses Server :roll_eyes:

Once that was done, msodbc started failing because it couldn’t find an ancient openssl (1.1) in the library path. After that was applied, it worked. Details are in the link issue on github.