How does the pymssql library fall back on the named pipe port when port 1433 is closed?

Question

I'm trying to remove pymssql and migrate to pyodbc on a python 3.6 project that I'm currently on. The network topology involves two machines that are both on the same LAN and same subnet. The client is an ARM debian based machine and the server is a windows box. Port 1433 is closed on the MSSQL box but port 32001 is open and pymssql is still able to remotely connect to the server as it somehow falls back to using the named pipe port (32001).

My question is how is pymssql able to fall back onto this other port and communicate with the server? pyodbc is unable to do this as if I try using port 1433 it fails and doesn't try to locate the named pipe port. I've tried digging through the pymssql source code to see how it works but all I see is a call to dbopen which ends up in freetds library land. Also just to clarify, tsql -LH returns the named pip information and open port which falls in line with what I've seen using netstat and nmap. I'm 100% sure pymssql falls back to using the named pipe port as the connection to the named pipe port is established after connecting with pymssql.

Any insight or guidance as to how pymssql can do this but pyodbc can't would be greatly appreciated.

Answer 1

Removing the PORT= parameter and using the SERVER=ip\instance in the connection string uses the named pipes to do the connection instead of port 1433. I'm still not sure how the driver itself knows to do this but it works and resolved my problem.