Connection reset by peer when sending from hardware (GPRS module) but fine when send from PC

Question

tl;dr

• Sending the same data from PC and Quectel GPRS module
• When send from Quectel, server raises an exception Connection reset by peer
• But Quectel works in production environment which has the same EC2-micro instance and a load balancer.
• Except for Quectel, another GPRS module - Neoway M680 - works with this EC2 instance.

Setup

Local - Setup
I have a Quectel M66 , a GPRS module that I'm using to connect to the server ( AWS EC2 ) and transfer some data.
I also have a python script I've made to connect and send the same data using a PC. Here below is the python script

import socket
import sys
from io import open
from time import sleep

'''
Python script to send data to remote server
'''
#replace address with the remote server address
HOST, PORT = '127.0.0.1', 3000 

if len(sys.argv) < 2:
    error = "Error:"
    print("{} {}".format(error, "Pass in the file to be send"))
    exit(1)

filename = sys.argv[1]

with open(filename, "r", newline="\r") as f:
    lines = f.readlines()

data = "".join(lines)

# Create a socket (SOCK_STREAM means a TCP socket)
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
    # Connect to server and send data
    sock.connect((HOST, PORT))
    sock.sendall(bytes(data, "utf-8"))

    # Receive data from the server and shut down
    received = r"{}".format(sock.recv(1024))
    sock.close()

print("Received: {}".format(received))

Remote - Setup
I'm running an EC2-micro instance that's running a python script that just listens to a port and prints the data it received, also send a response which is hard-coded. Here is the script

#!/usr/bin/env python3

'''
Python code running on EC2-micro
'''

import socket
import errno
from datetime import datetime

print(datetime.now().strftime('%Y-%m-%d %H:%M:%S'))

HOST = '0.0.0.0'  # Standard loopback interface address (localhost)
PORT = 3000       # Port to listen on (non-privileged ports are > 1023)

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen()
    conn, addr = s.accept()
    with conn:
        print('Connected by', addr)
        while True:
            try:
                data = r"{}".format(conn.recv(1024))
                print("Received: {}".format(data))
                #respond back with $E0A0
                conn.sendall(bytes("$E0A0:8B\r$E0FF\r", "utf-8"))
                conn.close()
                s.close()
                break
            except socket.error as e:
                if e.errno != errno.ECONNRESET:
                    raise
                if e.errno == errno.ECONNRESET:
                    printf("Connection reset by peer error again")
                    raise #it is failing here
                pass

Testing

Quectel GPRS Module

When I try sending data using the Quectel module the using the AT Commands , what I see from the hardware (quectel) side is that the connection has been CLOSED

17:29:05.652 [Tx] AT+QIOPEN="TCP","127.0.0.1",3000\r
17:29:05.672 [Rx] \r\nOK\r\n\r\nCONNECT OK\r\n
17:29:07.699 [Tx] AT+SEND=1\r
17:29:07.718 [Rx] >
17:29:08.603 [Tx] A
17:29:08.647 [Rx] \r\nSEND OK\r\n
17:29:09.446 [Rx] CLOSED

And the code running on EC2 crashes with:

Connection reset by peer error again
Traceback (most recent call last):
  File "./server.py", line 22, in <module>
    data = r"{}".format(conn.recv(1024))
ConnectionResetError: [Errno 104] Connection reset by peer

But this doesn't happen when I test using the python script (the first code given above)

Running python script from PC

$ python client.py data
Received: b'$E0A0:8B\r$E0FF\r'

Some more observations:

• This hardware (quectel) is being used in production environment and it works there as expected. Only in this new independent instance (with no load balancing ) it fails with Connection reset by peer
• I learned that this could be because of (from here )
  • Resource limitation at server side
  • High traffic
    
• But this new instance doesn't do anything else. I have also checked CloudWatch and no spike in CPU usage was seen .

Question

1. Do you think this is an issue at the server side?
   • Since the Quectel module responded with SEND OK , from the documentation we can be sure that the data has left the module. And TCP promises delivery of data
   • But clearly, before data could be received/read we get Connection reset by peer
2. Is it a performance/infrastructure issue?
   • All I could find which sounded reasonable was that the server might be less on memory or other resources

Answer 1

This was a backend issue. A port white-listing issue.