We Keep Coding

Connecting to Teradata using teradatasql module in Python

I am trying to connect to Teradata using teradatasql module in Python. The code is running fine on localhost, but once deployed on the server as part of the server code, it is throwing the error.
the code:
import teradatasql
try:
host, username, password = 'hostname', 'username', '****'
session = teradatasql.connect(host=host, user=username, password=password, logmech="LDAP")
except Exception as e:
print(e)
Error I am getting on server:
[Version 16.20.0.60] [Session 0] [Teradata SQL Driver] Failure receiving Config Response message header↵ at gosqldriver/teradatasql.
(*teradataConnection).makeDriverError TeradataConnection.go:1101↵ at gosqldriver/teradatasql.
(*teradataConnection).sendAndReceive TeradataConnection.go:1397↵ at gosqldriver/teradatasql.newTeradataConnection TeradataConnection.go:180↵ at gosqldriver/teradatasql.(*teradataDriver).
Open TeradataDriver.go:32↵ at database/sql.dsnConnector.Connect sql.go:600↵ at database/sql.(*DB).conn sql.go:1103↵ at database/sql.
(*DB).Conn sql.go:1619↵ at main.goCreateConnection goside.go:275↵ at main.
_cgoexpwrap_212fad278f55_goCreateConnection _cgo_gotypes.go:240↵ at runtime.call64 asm_amd64.s:574↵ at runtime.cgocallbackg1 cgocall.go:316↵ at runtime.cgocallbackg cgocall.go:194↵ at runtime.cgocallback_gofunc asm_amd64.s:826↵ at runtime.goexit asm_amd64.s:2361↵Caused by read tcp IP:PORT->IP:PORT: wsarecv: An existing connection was forcibly closed by the remote host

The root cause of this error is outlined here by tomnolan:
The stack trace indicates that a TCP socket connection was made to the database, then the driver transmitted a Config Request message to the database, then the driver timed out waiting for a Config Response message from the database.
In other words, the driver thought that it had established a TCP socket connection, but the TCP socket connection was probably not fully successful, because a failure occurred on the initial message handshake between the driver and the database.
The most likely cause is that some kind of networking problem prevented the driver from properly connecting to the database.
I had this issue today and resolved it by altering my host. I am also on a VPN and found that the actual host name in DNS didn't work, but the ALIAS available did. For example on Windows:
C:\WINDOWS\system32>nslookup MYDB-TEST # <-- works
Server: abcd.domain.com
Address: <OMITTED>
Name: MYDB.domain.com # <-- doesn't work
Address: <OMITTED>
Aliases: mydb-test.domain.com # <-- works
I recognize this may be a specific solution option that may not work for everyone, but the root of the problem is confirmed to be a TCP connection issue from my experience.

Python 3.8 TLSv1.3 socket close result in ConnectionResetError or ConnectionAbortedError

Client side:
data = b'\xff' * 1000000
ssock = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
#context is created by ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
ssock = context.wrap_socket(ssock, server_hostname='xd1337sv')
ssock.connect((SERVERADDR, SERVERPORT))
ssock.sendall(data)
#time.sleep(3)
ssock.close()
If I just use regular non-SSL socket, everything works correctly with the server receiving exact amount of data. If I use TLS socket, the behavior then depends on the version.
If I run either the server or client on Python 3.6 and therefore the TLSv1.2 will be used, there's no problem.
Problem arises only when TLSv1.3 is used and depends on the size of data and how soon client ssocket.close() line is executed.
If I put a right amount of time.sleep before ssocket.close() depending on the size of data, then I get no error. Otherwise, the server will get ConnectionResetError [WinError 10054] An existing connection was forcibly closed by the remote host and receive only part of the data, or throw ConnectionAbortedError [WinError 10053] An established connection was aborted by the software in your host machine and receive no data.
I'm testing both the server and client on my local machine with local address 192.168.1.2.

The difference is caused by TLS 1.3 sending a session ticket after the TLS handshake while with previous TLS versions the session ticket is send inside the TLS handshake. Thus, with TLS 1.3 data from the server (the session ticket) will arrive after the ssock.connect(...) is done. Since your application does not read any data after the connect it closes the socket while unread data are still inside the socket buffer of the underlying TCP socket. This will cause RST send to the server and cause there the connection reset error.
This is a known problems with applications which never attempt to read from the server. If the application would expect a response from the server and use recv to get it this would implicitly also read the session ticket.
To fix this situation when you don't expect the server to return any application data do a proper SSL shutdown of the socket before closing it. Since this will read the servers SSL shutdown message it will also implicitly read the session ticket send before by the server.
try:
ssock = ssock.unwrap()
except:
True
ssock.close()
For more information see also this issue and this documentation.

I was getting a similar problem when the application was running through gunicorn with certificates. The jsondecodeerror problem randomly came to the client, i.e. the response was empty. The only thing that TLS 1.2 was used.
The solution was simple, I deployed the application on uwsgi and the problem went away

Paramiko module using python for a long time without operation causes SSHException: Server connection dropped error

I tried to use flask and paramiko to display some log information to the browser, and now I can display the log message to the browser. However, if flask is not operated for a long time, an error will be reported --paramiko.ssh_exception.Can you provide some ways to keep SSH connected?
I tried adding a timeout parameter, but it didn't work
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(host['host_124']['hostname'], host['host_124']['port'],host['host_124']['username'], host['host_124']['password'],compress=True, timeout='65536')
sftp_client = client.open_sftp()
I want to keep SSH connected all the time, but now I get an error in 2 minutes.

P4 python connection broken SSL error

I'm already using P4V client and everything is fine, no connection error.
Error:
I've got some SSL errors when I try to execute p4 command from Python.
And it's random, If i re run the script, error isnt thrown everytime
From the client, the output is :
SSL receive failed.\nread: Operation succeed : WSAECONNRESET
From the server side logs, i've got :
Connection from 90.XX.XX.93:53929 broken. SSL receive failed. read:
Connection reset by peer: Connection reset by peer
After le P4 Connection with p4.connect(), I run a p4.run_trust() command and the result seems ok
Trust already established
This error is trown doing a p4 fetch, of p4 edit myfile
Configuration
I'm starting my python script from the same computer running the P4V client. I'm using the same configuration ( user, workspace, url+port > ssl:p4.our-url.domain:1666 ). The SSL error happened with or without the P4V client started.
The SSL certificate was generated during the Perforce Server installation and configuration.
There is no apache server behind our subdomain p4.our-domain, so I can't test the SSL certificate using online SSL checker ( my network knowledge reach its limit there )
When i do a p4 info there is a "peer address", basically my IP with a random generated port (53929). What is this port ? Do i need to set a fixed port and redirect to my computer runing the script ?
Do you have any ideas where that error come from ? Is that a bad server configuration ( weird cause every p4v client in the office works).
Do i need to establish and distribute a new certificate to all users of the P4Python script ?
Python 3.5.4
PyOpenssl 18.0.0
P4Python 2017.2.1615960
Thanks a lot for any advice.
ANSWER suggested by Sam Stafford
Sam was right, It seems I got a timeout. I was opening the P4 connection and connecting to the server on the script launch, then processing was launched to generate files before using p4 fetch/add/submit. Here is a workaround to reconnect in case on disconnection from the server
# self.myp4 = P4() was created on init, files are added
submited = False
maxTry = 5
while not submited and maxTry > 0:
try:
reslist = self.p4.run_submit(ch)
except P4Exception as p4e:
print(str(self.p4.errors))
self.myp4.disconnect()
maxTry -= 1
self.myp4.connect()
submited = reslist is not None and len(reslist) > 0
That works if you want to keep the connection open. I guess the best way to avoid timeout is to call P4.connect() method just before any P4.run_*method*() and close it after. Instead of wating for timeout to restart the connection.

"Connection reset by peer" is a TCP error.
What does "connection reset by peer" mean?
Maybe your script is holding its connection open longer than P4V does, and a transient network failure during that period causes the connection to be reset? The best fix is probably to have the script catch the error, open a new connection, and pick up where it left off.

connection refused from server unit I reset client machine

Below is the code I am running within a service. For the most part the script runs fine for days/weeks until the script hiccups and crashes. I am not so worried about the crashing part as I can resolve the cause from the error logs an patch appropriately. The issue I am facing is that sometimes when the service restarts and tries to connect to the server again, it gets a (10061, 'Connection refused') error, so that the service is unable to start up again. The bizarre part is that there is no python processes running when connections are being refused. IE no process with image name "pythonw.exe" or "pythonservice.exe." It should be noted that I am unable to connect to the server with any other machine as well until I reset computer which runs the client script. The client machine is running python 2.7 on a windows server 2003 OS. It should also be noted that the server is coded on a piece of hardware of which I do not have access to the code.
try:
EthernetConfig = ConfigParser()
EthernetConfig.read('Ethernet.conf')
HOST = EthernetConfig.get("TCP_SERVER", "HOST").strip()
PORT = EthernetConfig.getint("TCP_SERVER", "PORT")
lp = LineParser()
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
reader = s.makefile("rb")
while(self.run == True):
line = reader.readline()
if line:
line = line.strip()
lp.parse(line)
except:
servicemanager.LogErrorMsg(traceback.format_exc()) # if error print it to event log
s.shutdown(2)
s.close()
os._exit(-1)

Connection refused is an error meaning that the program on the other side of the connection is not accepting your connection attempt. Most probably it hasn't noticed you crashing, and hasn't closed its connection.
What you can do is simply sleep a little while (30-60 seconds) and try again, and do this in a loop and hope the other end notices that the connection in broken so it can accept new connections again.

Turns out that Network Admin had the port closed that I was trying to connect to. It is open for one IP which belongs to the server. Problem is that the server has two network cards with two separate IP's. Issue is now resolved.