port scan with nmap -sT causes REP socket to abort
Description
A running program utilizing a REP socket(bind is "tcp://*:50001") will abort when port scanned using the command: nmap -sT localhost -p <port> (ex. nmap -sT localhost -p 50001). This program is also using czmq calls, not zmq, however, the console displays this upon failure:
Transport endpoint is not connected (ip.cpp:137) zsh: abort (core dumped) ./server
Edit: Also, it sometimes has taken me two port scans to make the program crash. Edit(12-18-2013): The issue seems to affect zeromq 4.x since this commit: https://github.com/zeromq/zeromq4-x/commit/d65231be1ced9f6411427a1be971525e7f19f5e9#diff-63ef31c922ae7e73acd8695ae4d9be06 The problem seems to be that if a TCP connection is closed before getpeername() is called, then it will fail with ENOTCONN, forcing the whole program to abort. Our testing showed that only nmap opens and closes a TCP connection fast enough to cause this issue. We tried connecting to the socket with netcat and a python script without causing the program to abort. A patch is included that seems to fix the issue.
Environment
Arch Linux 3.11.6-1 x86_64 GNU/Linux, Debian 3.7.2-0+kali8 x86_64
A running program utilizing a REP socket(bind is "tcp://*:50001") will abort when port scanned using the command: nmap -sT localhost -p <port> (ex. nmap -sT localhost -p 50001). This program is also using czmq calls, not zmq, however, the console displays this upon failure:
Transport endpoint is not connected (ip.cpp:137)
zsh: abort (core dumped) ./server
Since, I found this source file: https://github.com/zeromq/zeromq4-x/blob/master/src/ip.cpp
I decided that this is a bug that affects libzmq, not just czmq.
Edit: Also, it sometimes has taken me two port scans to make the program crash.
Edit(12-18-2013):
The issue seems to affect zeromq 4.x since this commit: https://github.com/zeromq/zeromq4-x/commit/d65231be1ced9f6411427a1be971525e7f19f5e9#diff-63ef31c922ae7e73acd8695ae4d9be06
The problem seems to be that if a TCP connection is closed before getpeername() is called, then it will fail with ENOTCONN, forcing the whole program to abort. Our testing showed that only nmap opens and closes a TCP connection fast enough to cause this issue. We tried connecting to the socket with netcat and a python script without causing the program to abort. A patch is included that seems to fix the issue.