nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Code Issues Projects Releases Wiki Activity
0e3082ee89
putty-source/windows/winhsock.c

351 lines
9.7 KiB
C
Raw Normal View History

Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
/*
* General mechanism for wrapping up reading/writing of Windows
* HANDLEs into a PuTTY Socket abstraction.
*/
#include <stdio.h>
#include <assert.h>
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
#include <limits.h>
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
#define DEFINE_PLUG_METHOD_MACROS
#include "tree234.h"
#include "putty.h"
#include "network.h"
typedef struct Socket_handle_tag *Handle_Socket;
struct Socket_handle_tag {
const struct socket_function_table *fn;
/* the above variable absolutely *must* be the first in this structure */
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
HANDLE send_H, recv_H, stderr_H;
struct handle *send_h, *recv_h, *stderr_h;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* Freezing one of these sockets is a slightly fiddly business,
* because the reads from the handle are happening in a separate
* thread as blocking system calls and so once one is in progress
* it can't sensibly be interrupted. Hence, after the user tries
* to freeze one of these sockets, it's unavoidable that we may
* receive one more load of data before we manage to get
* winhandl.c to stop reading.
*/
enum {
UNFROZEN, /* reading as normal */
FREEZING, /* have been set to frozen but winhandl is still reading */
FROZEN, /* really frozen - winhandl has been throttled */
THAWING /* we're gradually releasing our remaining data */
} frozen;
/* We buffer data here if we receive it from winhandl while frozen. */
bufchain inputdata;
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
/* Data received from stderr_H, if we have one. */
bufchain stderrdata;
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
int defer_close, deferred_close; /* in case of re-entrance */
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
char *error;
Plug plug;
};
static int handle_gotdata(struct handle *h, void *data, int len)
{
Handle_Socket ps = (Handle_Socket) handle_get_privdata(h);
if (len < 0) {
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
plug_closing(ps->plug, "Read error from handle", 0, 0);
return 0;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
} else if (len == 0) {
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
plug_closing(ps->plug, NULL, 0, 0);
return 0;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
} else {
Fix multiple bugs in freeze/thaw of Windows handle-sockets. Firstly, I had asserted that data would never arrive on a handle socket in state FREEZING, which is just an error, because FREEZING is precisely the state of not being quite frozen _yet_ because one last read is still expected to arrive from the winhandl.c reading subthread which it's too late to cancel. I meant to assert that it wasn't FROZEN. Secondly, when the handle socket was in state FREEZING, I failed to actually _set_ it to FROZEN. And thirdly, when the handle socket starts thawing again (i.e. there's now outgoing buffer space so we can start sending our backlogged data), I forgot to ever call bufchain_consume, so that the same block of data would get sent repeatedly. I can only assume that nothing I've ever done has actually exercised this code!
2017-02-15 19:19:38 +00:00
assert(ps->frozen != FROZEN && ps->frozen != THAWING);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
if (ps->frozen == FREEZING) {
/*
* If we've received data while this socket is supposed to
* be frozen (because the read winhandl.c started before
* sk_set_frozen was called has now returned) then buffer
* the data for when we unfreeze.
*/
bufchain_add(&ps->inputdata, data, len);
Fix multiple bugs in freeze/thaw of Windows handle-sockets. Firstly, I had asserted that data would never arrive on a handle socket in state FREEZING, which is just an error, because FREEZING is precisely the state of not being quite frozen _yet_ because one last read is still expected to arrive from the winhandl.c reading subthread which it's too late to cancel. I meant to assert that it wasn't FROZEN. Secondly, when the handle socket was in state FREEZING, I failed to actually _set_ it to FROZEN. And thirdly, when the handle socket starts thawing again (i.e. there's now outgoing buffer space so we can start sending our backlogged data), I forgot to ever call bufchain_consume, so that the same block of data would get sent repeatedly. I can only assume that nothing I've ever done has actually exercised this code!
2017-02-15 19:19:38 +00:00
ps->frozen = FROZEN;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* And return a very large backlog, to prevent further
* data arriving from winhandl until we unfreeze.
*/
return INT_MAX;
} else {
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
plug_receive(ps->plug, 0, data, len);
return 0;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
}
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
static int handle_stderr(struct handle *h, void *data, int len)
{
Handle_Socket ps = (Handle_Socket) handle_get_privdata(h);
if (len > 0)
log_proxy_stderr(ps->plug, &ps->stderrdata, data, len);
return 0;
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
static void handle_sentdata(struct handle *h, int new_backlog)
{
Handle_Socket ps = (Handle_Socket) handle_get_privdata(h);
Windows handle sockets: fix error handling in sentdata(). In the sentdata callback function given to handle_output_new, the 'new_backlog' parameter can be negative, and if so, it represents a Windows error code and not a backlog size at all. handle_sentdata was not checking for this before passing it on to plug_sent.
2017-02-22 21:57:04 +00:00
if (new_backlog < 0) {
/* Special case: this is actually reporting an error writing
* to the underlying handle, and our input value is the error
* code itself, negated. */
plug_closing(ps->plug, win_strerror(-new_backlog), -new_backlog, 0);
return;
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
plug_sent(ps->plug, new_backlog);
}
static Plug sk_handle_plug(Socket s, Plug p)
{
Handle_Socket ps = (Handle_Socket) s;
Plug ret = ps->plug;
if (p)
ps->plug = p;
return ret;
}
static void sk_handle_close(Socket s)
{
Handle_Socket ps = (Handle_Socket) s;
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
if (ps->defer_close) {
ps->deferred_close = TRUE;
return;
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
handle_free(ps->send_h);
handle_free(ps->recv_h);
CloseHandle(ps->send_H);
if (ps->recv_H != ps->send_H)
CloseHandle(ps->recv_H);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
bufchain_clear(&ps->inputdata);
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
bufchain_clear(&ps->stderrdata);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
sfree(ps);
}
static int sk_handle_write(Socket s, const char *data, int len)
{
Handle_Socket ps = (Handle_Socket) s;
return handle_write(ps->send_h, data, len);
}
static int sk_handle_write_oob(Socket s, const char *data, int len)
{
/*
* oob data is treated as inband; nasty, but nothing really
* better we can do
*/
return sk_handle_write(s, data, len);
}
static void sk_handle_write_eof(Socket s)
{
Handle_Socket ps = (Handle_Socket) s;
handle_write_eof(ps->send_h);
}
static void sk_handle_flush(Socket s)
{
/* Handle_Socket ps = (Handle_Socket) s; */
/* do nothing */
}
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
static void handle_socket_unfreeze(void *psv)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
Handle_Socket ps = (Handle_Socket) psv;
void *data;
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
int len;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* If we've been put into a state other than THAWING since the
* last callback, then we're done.
*/
if (ps->frozen != THAWING)
return;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
/*
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
* Get some of the data we've buffered.
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
*/
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
bufchain_prefix(&ps->inputdata, &data, &len);
assert(len > 0);
/*
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
* Hand it off to the plug. Be careful of re-entrance - that might
* have the effect of trying to close this socket.
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
*/
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
ps->defer_close = TRUE;
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
plug_receive(ps->plug, 0, data, len);
Fix multiple bugs in freeze/thaw of Windows handle-sockets. Firstly, I had asserted that data would never arrive on a handle socket in state FREEZING, which is just an error, because FREEZING is precisely the state of not being quite frozen _yet_ because one last read is still expected to arrive from the winhandl.c reading subthread which it's too late to cancel. I meant to assert that it wasn't FROZEN. Secondly, when the handle socket was in state FREEZING, I failed to actually _set_ it to FROZEN. And thirdly, when the handle socket starts thawing again (i.e. there's now outgoing buffer space so we can start sending our backlogged data), I forgot to ever call bufchain_consume, so that the same block of data would get sent repeatedly. I can only assume that nothing I've ever done has actually exercised this code!
2017-02-15 19:19:38 +00:00
bufchain_consume(&ps->inputdata, len);
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
ps->defer_close = FALSE;
if (ps->deferred_close) {
A small pile of Windows compiler-warning fixes. These include an unused variable left over from the command-line refactoring; an explicit referencing of the module handle for sspicli.dll which we really do deliberately load and then don't (directly) use; a missing pointer-type cast in the Windows handle socket code; and two 32/64 bit integer size mismatches in the types of functions I was importing from system API DLLs. The last of those are a bit worrying, and suggest to me that after going to all that trouble to add type-checking of those runtime imports in commit 49fb598b0, I might have only checked the resulting compiler output in a 32-bit build and not a 64-bit one. Oops!
2017-12-10 09:19:15 +00:00
sk_handle_close((Socket)ps);
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
return;
}
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
if (bufchain_size(&ps->inputdata) > 0) {
/*
* If there's still data in our buffer, stay in THAWING state,
* and reschedule ourself.
*/
queue_toplevel_callback(handle_socket_unfreeze, ps);
} else {
/*
* Otherwise, we've successfully thawed!
*/
ps->frozen = UNFROZEN;
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
handle_unthrottle(ps->recv_h, 0);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
}
}
static void sk_handle_set_frozen(Socket s, int is_frozen)
{
Handle_Socket ps = (Handle_Socket) s;
if (is_frozen) {
switch (ps->frozen) {
case FREEZING:
case FROZEN:
return; /* nothing to do */
case THAWING:
/*
* We were in the middle of emptying our bufchain, and got
* frozen again. In that case, winhandl.c is already
* throttled, so just return to FROZEN state. The toplevel
* callback will notice and disable itself.
*/
ps->frozen = FROZEN;
break;
case UNFROZEN:
/*
* The normal case. Go to FREEZING, and expect one more
* load of data from winhandl if we're unlucky.
*/
ps->frozen = FREEZING;
break;
}
} else {
switch (ps->frozen) {
case UNFROZEN:
case THAWING:
return; /* nothing to do */
case FREEZING:
/*
* If winhandl didn't send us any data throughout the time
* we were frozen, then we'll still be in this state and
* can just unfreeze in the trivial way.
*/
assert(bufchain_size(&ps->inputdata) == 0);
ps->frozen = UNFROZEN;
break;
case FROZEN:
/*
* If we have buffered data, go to THAWING and start
* releasing it in top-level callbacks.
*/
ps->frozen = THAWING;
queue_toplevel_callback(handle_socket_unfreeze, ps);
}
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
static const char *sk_handle_socket_error(Socket s)
{
Handle_Socket ps = (Handle_Socket) s;
return ps->error;
}
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
static char *sk_handle_peer_info(Socket s)
{
Log the client process ID for Windows named pipes too. Turns out it didn't take much googling to find the right API function.
2015-05-18 15:00:13 +00:00
Handle_Socket ps = (Handle_Socket) s;
ULONG pid;
static HMODULE kernel32_module;
DECL_WINDOWS_FUNCTION(static, BOOL, GetNamedPipeClientProcessId,
(HANDLE, PULONG));
if (!kernel32_module) {
kernel32_module = load_system32_dll("kernel32.dll");
Coverity build fixes. Like every other toolchain I've tried, my Coverity scanning build has its share of random objections to parts of my Windows API type- checking system. I do wonder if that bright idea was worth the hassle - but it would probably cost all the annoyance all over again to back out now...
2017-06-20 18:02:48 +00:00
#if (defined _MSC_VER && _MSC_VER < 1900) || defined __MINGW32__ || defined COVERITY
Condition out some API type-checks in the MinGW build. A couple of the functions for which I was already turning off the type check for old Visual Studio turn out to also need it turning off for MinGW.
2017-04-15 17:13:47 +00:00
/* For older Visual Studio, and MinGW too (at least as of
* Ubuntu 16.04), this function isn't available in the header
Coverity build fixes. Like every other toolchain I've tried, my Coverity scanning build has its share of random objections to parts of my Windows API type- checking system. I do wonder if that bright idea was worth the hassle - but it would probably cost all the annoyance all over again to back out now...
2017-06-20 18:02:48 +00:00
* files to type-check. Ditto the toolchain I use for
* Coveritying the Windows code. */
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
GET_WINDOWS_FUNCTION_NO_TYPECHECK(
kernel32_module, GetNamedPipeClientProcessId);
#else
GET_WINDOWS_FUNCTION(
kernel32_module, GetNamedPipeClientProcessId);
#endif
Log the client process ID for Windows named pipes too. Turns out it didn't take much googling to find the right API function.
2015-05-18 15:00:13 +00:00
}
/*
* Of course, not all handles managed by this module will be
* server ends of named pipes, but if they are, then it's useful
* to log what we can find out about the client end.
*/
if (p_GetNamedPipeClientProcessId &&
p_GetNamedPipeClientProcessId(ps->send_H, &pid))
return dupprintf("process id %lu", (unsigned long)pid);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
return NULL;
}
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
Socket make_handle_socket(HANDLE send_H, HANDLE recv_H, HANDLE stderr_H,
Plug plug, int overlapped)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
static const struct socket_function_table socket_fn_table = {
sk_handle_plug,
sk_handle_close,
sk_handle_write,
sk_handle_write_oob,
sk_handle_write_eof,
sk_handle_flush,
sk_handle_set_frozen,
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
sk_handle_socket_error,
sk_handle_peer_info,
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
};
Handle_Socket ret;
int flags = (overlapped ? HANDLE_FLAG_OVERLAPPED : 0);
ret = snew(struct Socket_handle_tag);
ret->fn = &socket_fn_table;
ret->plug = plug;
ret->error = NULL;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
ret->frozen = UNFROZEN;
bufchain_init(&ret->inputdata);
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
bufchain_init(&ret->stderrdata);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
ret->recv_H = recv_H;
ret->recv_h = handle_input_new(ret->recv_H, handle_gotdata, ret, flags);
ret->send_H = send_H;
ret->send_h = handle_output_new(ret->send_H, handle_sentdata, ret, flags);
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
ret->stderr_H = stderr_H;
if (ret->stderr_H)
ret->stderr_h = handle_input_new(ret->stderr_H, handle_stderr,
ret, flags);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
ret->defer_close = ret->deferred_close = FALSE;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
return (Socket) ret;
}
Reference in New Issue Copy Permalink