Precondition: the port where ZNC is trying to connect to, is closed, so connection should be refused.
If the port is closed you won't get any kind of reply from it.
If the port is closed with normal firewall, all traffic to it is dropped so you don't know about the firewall. * Alternatively the firewall can be configured to reject traffic in which case it tells you "Connection refused."
This is unusual though, because it usually makes no sense to inform attacker or network scanner that there A) is the firewall. B) the host exists.
I use this with port 113/TCP to not have to wait for ident checks to timeout at IRC on hosts which don't have identd.
> Precondition: the port where ZNC is trying to connect to, is closed, so connection should be refused.
- If the port is closed you won't get any kind of reply from it.
- If the port is closed with normal firewall, all traffic to it is dropped so you don't know about the firewall. \* Alternatively the firewall can be configured to reject traffic in which case it tells you "Connection refused."
- This is unusual though, because it usually makes no sense to inform attacker or network scanner that there A) is the firewall. B) the host exists.
- I use this with port 113/TCP to not have to wait for ident checks to timeout at IRC on hosts which don't have identd.
<!-- github-comment-id:137646992 -->
There is a difference between not sending anything in response, sending RST response and sending SYN-ACK response.
Not sending anything: connection should time out.
Sending RST: connection is actively refused.
Sending SYN-ACK: connection is established, client should proceed with ACK and data.
I've checked that socat installation on the same cygwin reports "connection refused" as expected, so RST packet is received by client. But ZNC interprets it wrong for some reason.
ZNC is enabled in firewall.
There is a difference between not sending anything in response, sending RST response and sending SYN-ACK response.
Not sending anything: connection should time out.
Sending RST: connection is actively refused.
Sending SYN-ACK: connection is established, client should proceed with ACK and data.
I've checked that socat installation on the same cygwin reports "connection refused" as expected, so RST packet is received by client. But ZNC interprets it wrong for some reason.
<!-- github-comment-id:137661287 -->
So the socket (fd 7) comes back as both readable and writable from select and thus Csocket thinks that the connection is now successfully established. Third last line:
Detecting failed connects is done using exception list of select(2)
On Unix, a failed connect will return an error upon reading or writing from the socket,
and select() will mark the socket as notified. The exception list in select(2) is used for
detecting OOB data. On Windows, not the read or write lists but rather the exception
list is used for detecting failed connects.
On Windows failed connects, reads and writes still return WSAEWOULDBLOCK
Reads or writes to the socket will return a WSAEWOULDBLOCK even if connection failed.
The errno is available via getsockopt with SO_ERROR.
Thus, the connection failed and this would be signalled via the third fd_set in select(), but Csocket does not ask for this information. Instead it expects recv() and write() to return this information, but apparently they just fail with EAGAIN on Cygwin in this case.
This is a bug in Csocket. As explained in the above link, something needs to use getsockopt() to get the error. I think that this would also work on Linux, but I am not sure.
So the socket (fd 7) comes back as both readable and writable from `select` and thus Csocket thinks that the connection is now successfully established. Third last line:
```
85 16080927 [main] znc 1688 __set_winsock_errno: recv_internal:1601 - winsock error 10035 -> errno 11
```
10035 is WSAWOULDBLOCK according to Google.
So the socket is readable, but there is nothing to read from it? Weird.
Google finds: http://itamarst.org/writings/win32sockets.html
```
Detecting failed connects is done using exception list of select(2)
On Unix, a failed connect will return an error upon reading or writing from the socket,
and select() will mark the socket as notified. The exception list in select(2) is used for
detecting OOB data. On Windows, not the read or write lists but rather the exception
list is used for detecting failed connects.
On Windows failed connects, reads and writes still return WSAEWOULDBLOCK
Reads or writes to the socket will return a WSAEWOULDBLOCK even if connection failed.
The errno is available via getsockopt with SO_ERROR.
```
Looking at the source, the exception list is always empty and thus ignored: https://github.com/jimloco/Csocket/blob/master/Csocket.cc#L3696
Thus, the connection failed and this would be signalled via the third fd_set in `select()`, but Csocket does not ask for this information. Instead it expects `recv()` and `write()` to return this information, but apparently they just fail with `EAGAIN` on Cygwin in this case.
This is a bug in Csocket. As explained in the above link, `something` needs to use `getsockopt()` to get the error. I _think_ that this would also work on Linux, but I am not sure.
<!-- github-comment-id:137676526 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Precondition: the port where ZNC is trying to connect to, is closed, so connection should be refused.
It happens for both IPv6 and IPv4, I also tried to compile with --disable-ipv6, the result is the same.
Commit
0211b34a09strace follows:
ZNC is enabled in firewall.
There is a difference between not sending anything in response, sending RST response and sending SYN-ACK response.
Not sending anything: connection should time out.
Sending RST: connection is actively refused.
Sending SYN-ACK: connection is established, client should proceed with ACK and data.
I've checked that socat installation on the same cygwin reports "connection refused" as expected, so RST packet is received by client. But ZNC interprets it wrong for some reason.
So the socket (fd 7) comes back as both readable and writable from
selectand thus Csocket thinks that the connection is now successfully established. Third last line:10035 is WSAWOULDBLOCK according to Google.
So the socket is readable, but there is nothing to read from it? Weird.
Google finds: http://itamarst.org/writings/win32sockets.html
Looking at the source, the exception list is always empty and thus ignored: https://github.com/jimloco/Csocket/blob/master/Csocket.cc#L3696
Thus, the connection failed and this would be signalled via the third fd_set in
select(), but Csocket does not ask for this information. Instead it expectsrecv()andwrite()to return this information, but apparently they just fail withEAGAINon Cygwin in this case.This is a bug in Csocket. As explained in the above link,
somethingneeds to usegetsockopt()to get the error. I think that this would also work on Linux, but I am not sure.