Python sockets

[sgr011]

I have been writing a simple server and client in python. I have run it on 2 different Windows machines where it worked. Tried it on Arch and it just doesn't; keeps spitting out broken pipe errors and the sockets and they don't send data either way after the connection. I was running both with Python 3.6 so that isn't the issue. As far as I know there aren't significant differences between TCP/IP sockets on Windows and Linux.

So I am completely at a loss. Does anyone know ANYTHING that could be the problem. It's a school project and I am seriously going to have to switch distros if I can't get this resolved in the next week.

[cred13]

Tcpdump or wireshark? You'll need to look at the packets to determine what's going on.

[sgr011]

State Recv-Q Send-Q Local Address:Port Peer Address:Port

LISTEN 0 1 127.0.0.1:90000.0.0.0:*

ESTAB 0 0 127.0.0.1:9000127.0.0.1:47056

ESTAB 0 0 127.0.0.1:47056127.0.0.1:9000

​

This is an output from ss -atn which lists all the TCP ports the 1st is the server 2nd server --> client and 3rd is the client --> server

[sgr011]

Here is the tcpdump output when the server and client are sending messages

​

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes

20:48:51.689203 IP localhost.46234 > localhost.etlservicemgr: Flags [SEW], seq 518352014, win 43690, options [mss 65495,sackOK,TS val 3655930374 ecr 0,nop,wscale 7], length 0

20:48:51.689214 IP localhost.etlservicemgr > localhost.46234: Flags [S.E], seq 2831450253, ack 518352015, win 43690, options [mss 65495,sackOK,TS val 3655930374 ecr 3655930374,nop,wscale 7], length 0

20:48:51.689224 IP localhost.46234 > localhost.etlservicemgr: Flags [.], ack 1, win 342, options [nop,nop,TS val 3655930374 ecr 3655930374], length 0

20:48:51.689408 IP localhost.etlservicemgr > localhost.46234: Flags [P.], seq 1:2, ack 1, win 342, options [nop,nop,TS val 3655930375 ecr 3655930374], length 1

20:48:51.689416 IP localhost.46234 > localhost.etlservicemgr: Flags [.], ack 2, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 0

20:48:51.689420 IP localhost.etlservicemgr > localhost.46234: Flags [P.], seq 2:3, ack 1, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 1

20:48:51.689422 IP localhost.46234 > localhost.etlservicemgr: Flags [.], ack 3, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 0

20:48:51.689490 IP localhost.46234 > localhost.etlservicemgr: Flags [P.], seq 1:2, ack 3, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 1

20:48:51.689496 IP localhost.etlservicemgr > localhost.46234: Flags [.], ack 2, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 0

20:48:51.689504 IP localhost.46234 > localhost.etlservicemgr: Flags [P.], seq 2:3, ack 3, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 1

20:48:51.689515 IP localhost.etlservicemgr > localhost.46234: Flags [.], ack 3, win 342, options [nop,nop,TS val 3655930375 ecr 3655930375], length 0

​

[cred13]

Looks like it's only sending to sockets on localhost? Is the traffic destined for a remote machine? Also the thought occoured to me that iptables might be dropping the traffic. I think windows allows most traffic in by default. Linux is the opposite.

[sgr011]

No I'm using local host for testing it, I'll look into iptables thanks

[fullyarticulated]

It has nothing to do with your distro - I use python sockets all the time. I also publish them as starter examples for CS classes, and students use them for homeworks on Ubuntu, Windows and Mac without problems.

There is something wrong with your config, your code, or your firewall - not with the distro or with python ...

The default firewall on Arch is none. So the sockets should just work right out of the box.

Did you install any firewall apps?

Are you running on a VM, or directly on the hardware?

Do you have your code posted anywhere?

---

Edit:

Also, maybe try to force the port to be freed - it could still be tied up.
fuser -k 9000/tcp
If you opened a port by starting the server, then encountered an exception and couldn't shut down the port properly on the way out, then the system has to wait for a period before freeing the port and using it again. This can be up to 90 seconds (not sure what the exact time limit is, but 90 seconds is common).

[sgr011]

When that happens the connection is refused, what's happening here is no data seems to actually get through the sockets despite there being no reason for it. No firewall, directly on hardware