github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/portfwd.c

1063 строки
32 KiB
C
Исходник Обычный вид История

Sprinkle some header comments in various files in an attempt to explain what they're for. [originally from svn r6639]
2006-04-23 22:26:03 +04:00
/*
* SSH port forwarding.
*/
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
#include <assert.h>
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
#include <stdio.h>
#include <stdlib.h>
#include "putty.h"
#include "ssh.h"
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
#include "sshchan.h"
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
/*
* Enumeration of values that live in the 'socks_state' field of
* struct PortForwarding.
*/
typedef enum {
SOCKS_NONE, /* direct connection (no SOCKS, or SOCKS already done) */
SOCKS_INITIAL, /* don't know if we're SOCKS 4 or 5 yet */
SOCKS_4, /* expect a SOCKS 4 (or 4A) connection message */
SOCKS_5_INITIAL, /* expect a SOCKS 5 preliminary message */
SOCKS_5_CONNECT /* expect a SOCKS 5 connection message */
} SocksState;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
typedef struct PortForwarding {
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
SshChannel *c; /* channel structure held by SSH connection layer */
ConnectionLayer *cl; /* the connection layer itself */
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
/* Note that ssh need not be filled in if c is non-NULL */
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
Socket *s;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
int input_wanted;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
int ready;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
SocksState socks_state;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
/*
* `hostname' and `port' are the real hostname and port, once
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
* we know what we're connecting to.
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
*/
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
char *hostname;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
int port;
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
/*
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
* `socksbuf' is the buffer we use to accumulate the initial SOCKS
* segment of the incoming data, plus anything after that that we
* receive before we're ready to send data to the SSH server.
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
*/
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
strbuf *socksbuf;
size_t socksbuf_consumed;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 11:29:33 +03:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
Plug plug;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
Channel chan;
} PortForwarding;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
struct PortListener {
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
ConnectionLayer *cl;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
Socket *s;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
int is_dynamic;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
/*
* `hostname' and `port' are the real hostname and port, for
* ordinary forwardings.
*/
char *hostname;
int port;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 11:29:33 +03:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
Plug plug;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
};
static struct PortForwarding *new_portfwd_state(void)
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
struct PortForwarding *pf = snew(struct PortForwarding);
pf->hostname = NULL;
pf->socksbuf = NULL;
return pf;
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
}
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
static void free_portfwd_state(struct PortForwarding *pf)
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
if (!pf)
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
return;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
sfree(pf->hostname);
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
if (pf->socksbuf)
strbuf_free(pf->socksbuf);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
sfree(pf);
}
static struct PortListener *new_portlistener_state(void)
{
struct PortListener *pl = snew(struct PortListener);
pl->hostname = NULL;
return pl;
}
static void free_portlistener_state(struct PortListener *pl)
{
if (!pl)
return;
sfree(pl->hostname);
sfree(pl);
Get rid of the fixed-size 'hostname' buffer in every port-forwarded connection, and replace it with sensible dynamically allocated storage. While I'm at it, get rid of the disgusting dual use between storing an actual hostname and storing an incoming SOCKS request; we now have a separate pointer variable for each. [originally from svn r9903]
2013-07-11 21:23:56 +04:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static void pfd_log(Plug *plug, int type, SockAddr *addr, int port,
Support for falling back through the list of addresses returned from a DNS lookup, whether they're IPv4, v6 or a mixture of both. [originally from svn r5119] [this svn revision also touched putty-wishlist]
2005-01-16 17:29:34 +03:00
const char *error_msg, int error_code)
{
/* we have to dump these since we have no interface to logging.c */
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static void pfl_log(Plug *plug, int type, SockAddr *addr, int port,
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
const char *error_msg, int error_code)
{
/* we have to dump these since we have no interface to logging.c */
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_close(struct PortForwarding *pf);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static void pfd_closing(Plug *plug, const char *error_msg, int error_code,
Make plug receive and closing functions return void instead of int. Nothing was paying attention to their return values any more anyway.
2016-06-03 01:03:24 +03:00
int calling_back)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct PortForwarding *pf =
container_of(plug, struct PortForwarding, plug);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Introduce a function sshfwd_unclean_close(), supplied by ssh.c to subsidiary network modules like portfwd.c. To be called when the subsidiary module experiences a socket error: it sends an emergency CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes the local side of the channel. (I've invented a new channel type in ssh.c called CHAN_ZOMBIE, for channels whose original local side has already been thrown away and they're just hanging around waiting to receive the acknowledging CHANNEL_CLOSE.) As a result of this and the last few commits, I can now run a port forwarding session in which a local socket error occurs on a forwarded port, and PuTTY now handles it apparently correctly, closing both the SSH channel and the local socket and then actually recognising that it's OK to terminate when all _other_ channels have been closed. Previously the channel corresponding to the duff connection would linger around (because of net_pending_errors never being called), and keep being selected on (hence chewing CPU), and inhibit program termination at the end of the session (because not all channels were closed). [originally from svn r9364]
2011-12-08 23:15:58 +04:00
if (error_msg) {
/*
* Socket error. Slam the connection instantly shut.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
if (pf->c) {
sshfwd_unclean_close(pf->c, error_msg);
Sebastian Kuschel reports that pfd_closing can be called for a socket error with pr->c NULL, in which case calling sshfwd_unclean_close on it will dereference NULL and segfault. Write an alternative error handling path for that possibility. (I don't know if it's the only way, but one way this can happen is if you're doing dynamic forwarding and the socket error occurs during SOCKS negotiation, in which case no SSH channel has been set up yet because we haven't yet found out what we want to put in the direct-tcpip channel open message.) [originally from svn r10018]
2013-08-15 10:42:36 +04:00
} else {
/*
* We might not have an SSH channel, if a socket error
* occurred during SOCKS negotiation. If not, we must
* clean ourself up without sshfwd_unclean_close's call
* back to pfd_close.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pfd_close(pf);
Sebastian Kuschel reports that pfd_closing can be called for a socket error with pr->c NULL, in which case calling sshfwd_unclean_close on it will dereference NULL and segfault. Write an alternative error handling path for that possibility. (I don't know if it's the only way, but one way this can happen is if you're doing dynamic forwarding and the socket error occurs during SOCKS negotiation, in which case no SSH channel has been set up yet because we haven't yet found out what we want to put in the direct-tcpip channel open message.) [originally from svn r10018]
2013-08-15 10:42:36 +04:00
}
Introduce a function sshfwd_unclean_close(), supplied by ssh.c to subsidiary network modules like portfwd.c. To be called when the subsidiary module experiences a socket error: it sends an emergency CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes the local side of the channel. (I've invented a new channel type in ssh.c called CHAN_ZOMBIE, for channels whose original local side has already been thrown away and they're just hanging around waiting to receive the acknowledging CHANNEL_CLOSE.) As a result of this and the last few commits, I can now run a port forwarding session in which a local socket error occurs on a forwarded port, and PuTTY now handles it apparently correctly, closing both the SSH channel and the local socket and then actually recognising that it's OK to terminate when all _other_ channels have been closed. Previously the channel corresponding to the duff connection would linger around (because of net_pending_errors never being called), and keep being selected on (hence chewing CPU), and inhibit program termination at the end of the session (because not all channels were closed). [originally from svn r9364]
2011-12-08 23:15:58 +04:00
} else {
/*
* Ordinary EOF received on socket. Send an EOF on the SSH
* channel.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
if (pf->c)
sshfwd_write_eof(pf->c);
Introduce a function sshfwd_unclean_close(), supplied by ssh.c to subsidiary network modules like portfwd.c. To be called when the subsidiary module experiences a socket error: it sends an emergency CHANNEL_CLOSE (not just outgoing CHANNEL_EOF), and immediately deletes the local side of the channel. (I've invented a new channel type in ssh.c called CHAN_ZOMBIE, for channels whose original local side has already been thrown away and they're just hanging around waiting to receive the acknowledging CHANNEL_CLOSE.) As a result of this and the last few commits, I can now run a port forwarding session in which a local socket error occurs on a forwarded port, and PuTTY now handles it apparently correctly, closing both the SSH channel and the local socket and then actually recognising that it's OK to terminate when all _other_ channels have been closed. Previously the channel corresponding to the duff connection would linger around (because of net_pending_errors never being called), and keep being selected on (hence chewing CPU), and inhibit program termination at the end of the session (because not all channels were closed). [originally from svn r9364]
2011-12-08 23:15:58 +04:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
static void pfl_terminate(struct PortListener *pl);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static void pfl_closing(Plug *plug, const char *error_msg, int error_code,
Make plug receive and closing functions return void instead of int. Nothing was paying attention to their return values any more anyway.
2016-06-03 01:03:24 +03:00
int calling_back)
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
{
struct PortListener *pl = (struct PortListener *) plug;
pfl_terminate(pl);
}
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
static SshChannel *wrap_lportfwd_open(
ConnectionLayer *cl, const char *hostname, int port,
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
Socket *s, Channel *chan)
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 15:57:45 +03:00
{
char *peerinfo, *description;
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 15:47:13 +03:00
SshChannel *toret;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
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 15:57:45 +03:00
peerinfo = sk_peer_info(s);
if (peerinfo) {
description = dupprintf("forwarding from %s", peerinfo);
sfree(peerinfo);
} else {
description = dupstr("forwarding");
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
toret = ssh_lportfwd_open(cl, hostname, port, description, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
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 15:57:45 +03:00
sfree(description);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
return toret;
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 15:57:45 +03:00
}
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
static char *ipv4_to_string(unsigned ipv4)
{
return dupprintf("%u.%u.%u.%u",
(ipv4 >> 24) & 0xFF, (ipv4 >> 16) & 0xFF,
(ipv4 >> 8) & 0xFF, (ipv4 ) & 0xFF);
}
static char *ipv6_to_string(ptrlen ipv6)
{
const unsigned char *addr = ipv6.ptr;
assert(ipv6.len == 16);
return dupprintf("%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x",
(unsigned)GET_16BIT_MSB_FIRST(addr + 0),
(unsigned)GET_16BIT_MSB_FIRST(addr + 2),
(unsigned)GET_16BIT_MSB_FIRST(addr + 4),
(unsigned)GET_16BIT_MSB_FIRST(addr + 6),
(unsigned)GET_16BIT_MSB_FIRST(addr + 8),
(unsigned)GET_16BIT_MSB_FIRST(addr + 10),
(unsigned)GET_16BIT_MSB_FIRST(addr + 12),
(unsigned)GET_16BIT_MSB_FIRST(addr + 14));
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static void pfd_receive(Plug *plug, int urgent, char *data, int len)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct PortForwarding *pf =
container_of(plug, struct PortForwarding, plug);
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
if (len == 0)
return;
if (pf->socks_state != SOCKS_NONE) {
BinarySource src[1];
/*
* Store all the data we've got in socksbuf.
*/
put_data(pf->socksbuf, data, len);
/*
* Check the start of socksbuf to see if it's a valid and
* complete message in the SOCKS exchange.
*/
if (pf->socks_state == SOCKS_INITIAL) {
/* Preliminary: check the first byte of the data (which we
* _must_ have by now) to find out which SOCKS major
* version we're speaking. */
switch (pf->socksbuf->u[0]) {
case 4:
pf->socks_state = SOCKS_4;
break;
case 5:
pf->socks_state = SOCKS_5_INITIAL;
break;
default:
pfd_close(pf); /* unrecognised version */
return;
}
}
BinarySource_BARE_INIT(src, pf->socksbuf->u, pf->socksbuf->len);
get_data(src, pf->socksbuf_consumed);
while (pf->socks_state != SOCKS_NONE) {
unsigned socks_version, message_type, reserved_byte;
unsigned reply_code, port, ipv4, method;
ptrlen methods;
const char *socks4_hostname;
strbuf *output;
switch (pf->socks_state) {
case SOCKS_INITIAL:
case SOCKS_NONE:
assert(0 && "These case values cannot appear");
case SOCKS_4:
/* SOCKS 4/4A connect message */
socks_version = get_byte(src);
message_type = get_byte(src);
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (socks_version == 4 && message_type == 1) {
/* CONNECT message */
int name_based = FALSE;
port = get_uint16(src);
ipv4 = get_uint32(src);
if (ipv4 > 0x00000000 && ipv4 < 0x00000100) {
/*
* Addresses in this range indicate the SOCKS 4A
* extension to specify a hostname, which comes
* after the username.
*/
name_based = TRUE;
}
get_asciz(src); /* skip username */
socks4_hostname = name_based ? get_asciz(src) : NULL;
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (get_err(src))
goto socks4_reject;
pf->port = port;
if (name_based) {
pf->hostname = dupstr(socks4_hostname);
} else {
pf->hostname = ipv4_to_string(ipv4);
}
output = strbuf_new();
put_byte(output, 0); /* reply version */
put_byte(output, 90); /* SOCKS 4 'request granted' */
put_uint16(output, 0); /* null port field */
put_uint32(output, 0); /* null address field */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
pf->socks_state = SOCKS_NONE;
pf->socksbuf_consumed = src->pos;
break;
}
socks4_reject:
output = strbuf_new();
put_byte(output, 0); /* reply version */
put_byte(output, 91); /* SOCKS 4 'request rejected' */
put_uint16(output, 0); /* null port field */
put_uint32(output, 0); /* null address field */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
pfd_close(pf);
return;
case SOCKS_5_INITIAL:
/* SOCKS 5 initial method list */
socks_version = get_byte(src);
methods = get_pstring(src);
method = 0xFF; /* means 'no usable method found' */
{
int i;
for (i = 0; i < methods.len; i++) {
if (((const unsigned char *)methods.ptr)[i] == 0 ) {
method = 0; /* no auth */
break;
}
}
}
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (get_err(src))
method = 0xFF;
output = strbuf_new();
put_byte(output, 5); /* SOCKS version */
put_byte(output, method); /* selected auth method */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
if (method == 0xFF) {
pfd_close(pf);
return;
}
pf->socks_state = SOCKS_5_CONNECT;
pf->socksbuf_consumed = src->pos;
break;
case SOCKS_5_CONNECT:
/* SOCKS 5 connect message */
socks_version = get_byte(src);
message_type = get_byte(src);
reserved_byte = get_byte(src);
if (socks_version == 5 && message_type == 1 &&
reserved_byte == 0) {
reply_code = 0; /* success */
switch (get_byte(src)) {
case 1: /* IPv4 */
pf->hostname = ipv4_to_string(get_uint32(src));
break;
case 4: /* IPv6 */
pf->hostname = ipv6_to_string(get_data(src, 16));
break;
case 3: /* unresolved domain name */
pf->hostname = mkstr(get_pstring(src));
break;
default:
pf->hostname = NULL;
reply_code = 8; /* address type not supported */
break;
}
pf->port = get_uint16(src);
} else {
reply_code = 7; /* command not supported */
}
if (get_err(src) == BSE_OUT_OF_DATA)
return;
if (get_err(src))
reply_code = 1; /* general server failure */
output = strbuf_new();
put_byte(output, 5); /* SOCKS version */
put_byte(output, reply_code);
put_byte(output, 0); /* reserved */
put_byte(output, 1); /* IPv4 address follows */
put_uint32(output, 0); /* bound IPv4 address (unused) */
put_uint16(output, 0); /* bound port number (unused) */
sk_write(pf->s, output->u, output->len);
strbuf_free(output);
if (reply_code != 0) {
pfd_close(pf);
return;
}
pf->socks_state = SOCKS_NONE;
pf->socksbuf_consumed = src->pos;
break;
}
}
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
/*
* We come here when we're ready to make an actual
* connection.
*/
When starting a SOCKS connection in dynamic forwarding, freeze the local socket _before_ calling the SSH setup functions. This makes no difference to ssh.c itself, but it makes portfwd.c easier to reuse for other purposes (e.g. as a component of a standalone SOCKS server), because now ssh_send_port_open() can itself call pfd_confirm() without the freeze and unfreeze happening in the wrong order. [originally from svn r8500]
2009-04-23 21:33:42 +04:00
/*
* Freeze the socket until the SSH server confirms the
* connection.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
sk_set_frozen(pf->s, 1);
When starting a SOCKS connection in dynamic forwarding, freeze the local socket _before_ calling the SSH setup functions. This makes no difference to ssh.c itself, but it makes portfwd.c easier to reuse for other purposes (e.g. as a component of a standalone SOCKS server), because now ssh_send_port_open() can itself call pfd_confirm() without the freeze and unfreeze happening in the wrong order. [originally from svn r8500]
2009-04-23 21:33:42 +04:00
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
pf->c = wrap_lportfwd_open(pf->cl, pf->hostname, pf->port, pf->s,
&pf->chan);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
if (pf->ready)
sshfwd_write(pf->c, data, len);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static void pfd_sent(Plug *plug, int bufsize)
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct PortForwarding *pf =
container_of(plug, struct PortForwarding, plug);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
if (pf->c)
sshfwd_unthrottle(pf->c, bufsize);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 09:03:46 +03:00
static const PlugVtable PortForwarding_plugvt = {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 11:29:33 +03:00
pfd_log,
pfd_closing,
pfd_receive,
pfd_sent,
NULL
};
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_chan_free(Channel *chan);
static void pfd_open_confirmation(Channel *chan);
static void pfd_open_failure(Channel *chan, const char *errtext);
static int pfd_send(Channel *chan, int is_stderr, const void *data, int len);
static void pfd_send_eof(Channel *chan);
static void pfd_set_input_wanted(Channel *chan, int wanted);
static char *pfd_log_close_msg(Channel *chan);
static const struct ChannelVtable PortForwarding_channelvt = {
pfd_chan_free,
pfd_open_confirmation,
pfd_open_failure,
pfd_send,
pfd_send_eof,
pfd_set_input_wanted,
pfd_log_close_msg,
chan_no_eager_close,
Devolve channel-request handling to Channel vtable. Instead of the central code in ssh2_connection_filter_queue doing both the job of parsing the channel request and deciding whether it's acceptable, each Channel vtable now has a method for every channel request type we recognise.
2018-09-26 19:34:20 +03:00
chan_no_exit_status,
chan_no_exit_signal,
chan_no_exit_signal_numeric,
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 20:02:33 +03:00
chan_no_request_response,
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
};
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
/*
called when someone connects to the local port
*/
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
static int pfl_accepting(Plug *p, accept_fn_t constructor, accept_ctx_t ctx)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
struct PortForwarding *pf;
struct PortListener *pl;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
Socket *s;
Colin's const-fixing Patch Of Death. Seems to build fine on Windows as well as Unix, so it can go in. [originally from svn r3162]
2003-05-04 18:18:18 +04:00
const char *err;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
pl = container_of(p, struct PortListener, plug);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pf = new_portfwd_state();
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
pf->plug.vt = &PortForwarding_plugvt;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
pf->chan.initial_fixed_window_size = 0;
pf->chan.vt = &PortForwarding_channelvt;
pf->input_wanted = TRUE;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pf->c = NULL;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
pf->cl = pl->cl;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
pf->s = s = constructor(ctx, &pf->plug);
Fix more "possible unintended assignment" warnings. [originally from svn r2459]
2003-01-05 16:04:04 +03:00
if ((err = sk_socket_error(s)) != NULL) {
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
free_portfwd_state(pf);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
return err != NULL;
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
pf->input_wanted = TRUE;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pf->ready = 0;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
if (pl->is_dynamic) {
pf->socks_state = SOCKS_INITIAL;
pf->socksbuf = strbuf_new();
pf->socksbuf_consumed = 0;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pf->port = 0; /* "hostname" buffer is so far empty */
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
sk_set_frozen(s, 0); /* we want to receive SOCKS _now_! */
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
} else {
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
pf->socks_state = SOCKS_NONE;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pf->hostname = dupstr(pl->hostname);
pf->port = pl->port;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
pf->c = wrap_lportfwd_open(pl->cl, pf->hostname, pf->port,
s, &pf->chan);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
return 0;
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 09:03:46 +03:00
static const PlugVtable PortListener_plugvt = {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 11:29:33 +03:00
pfl_log,
pfl_closing,
NULL, /* recv */
NULL, /* send */
pfl_accepting
};
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
/*
* Add a new port-forwarding listener from srcaddr:port -> desthost:destport.
*
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
* desthost == NULL indicates dynamic SOCKS port forwarding.
*
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
* On success, returns NULL and fills in *pl_ret. On error, returns a
* dynamically allocated error message string.
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
*/
Add some missing 'const' in pfl_listen.
2018-10-21 00:46:24 +03:00
static char *pfl_listen(const char *desthost, int destport,
const char *srcaddr, int port,
ConnectionLayer *cl, Conf *conf,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
struct PortListener **pl_ret, int address_family)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Colin's const-fixing Patch Of Death. Seems to build fine on Windows as well as Unix, so it can go in. [originally from svn r3162]
2003-05-04 18:18:18 +04:00
const char *err;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
struct PortListener *pl;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
/*
* Open socket.
*/
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pl = *pl_ret = new_portlistener_state();
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
pl->plug.vt = &PortListener_plugvt;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
if (desthost) {
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pl->hostname = dupstr(desthost);
pl->port = destport;
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
pl->is_dynamic = FALSE;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
} else
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
pl->is_dynamic = TRUE;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
pl->cl = cl;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
pl->s = new_listener(srcaddr, port, &pl->plug,
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
!conf_get_int(conf, CONF_lport_acceptall),
conf, address_family);
if ((err = sk_socket_error(pl->s)) != NULL) {
char *err_ret = dupstr(err);
sk_close(pl->s);
free_portlistener_state(pl);
*pl_ret = NULL;
return err_ret;
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
return NULL;
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static char *pfd_log_close_msg(Channel *chan)
{
return dupstr("Forwarded port closed");
}
static void pfd_close(struct PortForwarding *pf)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
if (!pf)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
return;
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
sk_close(pf->s);
free_portfwd_state(pf);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
SSH port forwarding is now configurable in mid-session. After doing Change Settings, the port forwarding setup function is run again, and tags all existing port forwardings as `do not keep'. Then it iterates through the config in the normal way; when it encounters a port forwarding which is already in the tree, it tags it `keep' rather than setting it up from scratch. Finally, it goes through the tree and removes any that haven't been labelled `keep'. Hence, editing the list of forwardings in Change Settings has the effect of cancelling any forwardings you remove, and adding any new ones. The SSH panel now appears in the reconfig box, and is empty apart from a message explaining that it has to be there for subpanels of it to exist. Better wording for this message would be welcome. [originally from svn r5030]
2004-12-28 17:07:05 +03:00
/*
* Terminate a listener.
*/
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
static void pfl_terminate(struct PortListener *pl)
SSH port forwarding is now configurable in mid-session. After doing Change Settings, the port forwarding setup function is run again, and tags all existing port forwardings as `do not keep'. Then it iterates through the config in the normal way; when it encounters a port forwarding which is already in the tree, it tags it `keep' rather than setting it up from scratch. Finally, it goes through the tree and removes any that haven't been labelled `keep'. Hence, editing the list of forwardings in Change Settings has the effect of cancelling any forwardings you remove, and adding any new ones. The SSH panel now appears in the reconfig box, and is empty apart from a message explaining that it has to be there for subpanels of it to exist. Better wording for this message would be welcome. [originally from svn r5030]
2004-12-28 17:07:05 +03:00
{
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
if (!pl)
return;
sk_close(pl->s);
free_portlistener_state(pl);
SSH port forwarding is now configurable in mid-session. After doing Change Settings, the port forwarding setup function is run again, and tags all existing port forwardings as `do not keep'. Then it iterates through the config in the normal way; when it encounters a port forwarding which is already in the tree, it tags it `keep' rather than setting it up from scratch. Finally, it goes through the tree and removes any that haven't been labelled `keep'. Hence, editing the list of forwardings in Change Settings has the effect of cancelling any forwardings you remove, and adding any new ones. The SSH panel now appears in the reconfig box, and is empty apart from a message explaining that it has to be there for subpanels of it to exist. Better wording for this message would be welcome. [originally from svn r5030]
2004-12-28 17:07:05 +03:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_set_input_wanted(Channel *chan, int wanted)
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
pf->input_wanted = wanted;
sk_set_frozen(pf->s, !pf->input_wanted);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_chan_free(Channel *chan)
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
pfd_close(pf);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
/*
* Called to send data down the raw connection.
*/
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static int pfd_send(Channel *chan, int is_stderr, const void *data, int len)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
return sk_write(pf->s, data, len);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_send_eof(Channel *chan)
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 15:44:03 +04:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
sk_write_eof(pf->s);
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 15:44:03 +04:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_open_confirmation(Channel *chan)
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
{
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
Refactor ssh.c's APIs to x11fwd.c and portfwd.c. The most important change is that, where previously ssh.c held the Socket pointer for each X11 and port forwarding, and the support modules would find their internal state structure by calling sk_get_private_ptr on that Socket, it's now the other way round. ssh.c now directly holds the internal state structure pointer for each forwarding, and when the support module needs the Socket it looks it up in a field of that. This will come in handy when I decouple socket creation from logical forwarding setup, so that X forwardings can delay actually opening a connection to an X server until they look at the authentication data and see which server it has to be. However, while I'm here, I've also taken the opportunity to clean up a few other points, notably error message handling, and also the fact that the same kind of state structure was used for both connection-type and listening-type port forwardings. Now there are separate PortForwarding and PortListener structure types, which seems far more sensible. [originally from svn r10074]
2013-11-17 18:04:41 +04:00
pf->ready = 1;
sk_set_frozen(pf->s, 0);
sk_write(pf->s, NULL, 0);
Rewrite SOCKS client code using BinarySource. I've also replaced the entire SOCKS state machine whose states were barely-documented literal integers with one that uses an actual enum. I think the result is a great deal clearer. In the course of this rewrite I noticed that PuTTY's dynamic port forwarding had never got round to supporting the SOCKS5 IPv6 address format - though there was a FIXME comment saying it ought to. So now it does: if a SOCKS5 client provides a binary IPv6 address (which PuTTY's _own_ SOCKS5 client, in proxy.c, is quite capable of doing!), then that will be translated into the usual IPv6 hex literal representation to put in the "direct-tcpip" channel open request.
2018-05-31 00:36:20 +03:00
if (pf->socksbuf) {
sshfwd_write(pf->c, pf->socksbuf->u + pf->socksbuf_consumed,
pf->socksbuf->len - pf->socksbuf_consumed);
strbuf_free(pf->socksbuf);
pf->socksbuf = NULL;
Dynamic port forwarding by means of a local SOCKS server. Fully supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS 5 isn't supported, but it'll be no difficulty once I actually get round to it). Thanks to Chas Honton for his `stone soup' patch: I didn't end up actually using any of his code, but it galvanised me into doing it properly myself :-) [originally from svn r3055]
2003-04-05 15:45:21 +04:00
}
Oops - actually check in portfwd.c itself! (Makefile also modified because it's been renamed to fit in 8.3, just in case.) [originally from svn r1177]
2001-08-09 00:53:27 +04:00
}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
static void pfd_open_failure(Channel *chan, const char *errtext)
{
assert(chan->vt == &PortForwarding_channelvt);
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
PortForwarding *pf = container_of(chan, PortForwarding, chan);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(pf->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
"Forwarded connection refused by server%s%s",
errtext ? ": " : "", errtext ? errtext : "");
}
/* ----------------------------------------------------------------------
* Code to manage the complete set of currently active port
* forwardings, and update it from Conf.
*/
struct PortFwdRecord {
enum { DESTROY, KEEP, CREATE } status;
int type;
unsigned sport, dport;
char *saddr, *daddr;
char *sserv, *dserv;
struct ssh_rportfwd *remote;
int addressfamily;
struct PortListener *local;
};
static int pfr_cmp(void *av, void *bv)
{
PortFwdRecord *a = (PortFwdRecord *) av;
PortFwdRecord *b = (PortFwdRecord *) bv;
int i;
if (a->type > b->type)
return +1;
if (a->type < b->type)
return -1;
if (a->addressfamily > b->addressfamily)
return +1;
if (a->addressfamily < b->addressfamily)
return -1;
if ( (i = nullstrcmp(a->saddr, b->saddr)) != 0)
return i < 0 ? -1 : +1;
if (a->sport > b->sport)
return +1;
if (a->sport < b->sport)
return -1;
if (a->type != 'D') {
if ( (i = nullstrcmp(a->daddr, b->daddr)) != 0)
return i < 0 ? -1 : +1;
if (a->dport > b->dport)
return +1;
if (a->dport < b->dport)
return -1;
}
return 0;
}
void pfr_free(PortFwdRecord *pfr)
{
/* Dispose of any listening socket. */
if (pfr->local)
pfl_terminate(pfr->local);
sfree(pfr->saddr);
sfree(pfr->daddr);
sfree(pfr->sserv);
sfree(pfr->dserv);
sfree(pfr);
}
struct PortFwdManager {
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
ConnectionLayer *cl;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
Conf *conf;
tree234 *forwardings;
};
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
PortFwdManager *portfwdmgr_new(ConnectionLayer *cl)
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
{
PortFwdManager *mgr = snew(PortFwdManager);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
mgr->cl = cl;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
mgr->conf = NULL;
mgr->forwardings = newtree234(pfr_cmp);
return mgr;
}
void portfwdmgr_close(PortFwdManager *mgr, PortFwdRecord *pfr)
{
PortFwdRecord *realpfr = del234(mgr->forwardings, pfr);
if (realpfr == pfr)
pfr_free(pfr);
}
void portfwdmgr_close_all(PortFwdManager *mgr)
{
PortFwdRecord *pfr;
while ((pfr = delpos234(mgr->forwardings, 0)) != NULL)
pfr_free(pfr);
}
void portfwdmgr_free(PortFwdManager *mgr)
{
portfwdmgr_close_all(mgr);
freetree234(mgr->forwardings);
if (mgr->conf)
conf_free(mgr->conf);
sfree(mgr);
}
void portfwdmgr_config(PortFwdManager *mgr, Conf *conf)
{
PortFwdRecord *pfr;
int i;
char *key, *val;
if (mgr->conf)
conf_free(mgr->conf);
mgr->conf = conf_copy(conf);
/*
* Go through the existing port forwardings and tag them
* with status==DESTROY. Any that we want to keep will be
* re-enabled (status==KEEP) as we go through the
* configuration and find out which bits are the same as
* they were before.
*/
for (i = 0; (pfr = index234(mgr->forwardings, i)) != NULL; i++)
pfr->status = DESTROY;
for (val = conf_get_str_strs(conf, CONF_portfwd, NULL, &key);
val != NULL;
val = conf_get_str_strs(conf, CONF_portfwd, key, &key)) {
char *kp, *kp2, *vp, *vp2;
char address_family, type;
int sport, dport, sserv, dserv;
char *sports, *dports, *saddr, *host;
kp = key;
address_family = 'A';
type = 'L';
if (*kp == 'A' || *kp == '4' || *kp == '6')
address_family = *kp++;
if (*kp == 'L' || *kp == 'R')
type = *kp++;
if ((kp2 = host_strchr(kp, ':')) != NULL) {
/*
* There's a colon in the middle of the source port
* string, which means that the part before it is
* actually a source address.
*/
char *saddr_tmp = dupprintf("%.*s", (int)(kp2 - kp), kp);
saddr = host_strduptrim(saddr_tmp);
sfree(saddr_tmp);
sports = kp2+1;
} else {
saddr = NULL;
sports = kp;
}
sport = atoi(sports);
sserv = 0;
if (sport == 0) {
sserv = 1;
sport = net_service_lookup(sports);
if (!sport) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx, "Service lookup failed for source"
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
" port \"%s\"", sports);
}
}
if (type == 'L' && !strcmp(val, "D")) {
/* dynamic forwarding */
host = NULL;
dports = NULL;
dport = -1;
dserv = 0;
type = 'D';
} else {
/* ordinary forwarding */
vp = val;
vp2 = vp + host_strcspn(vp, ":");
host = dupprintf("%.*s", (int)(vp2 - vp), vp);
if (*vp2)
vp2++;
dports = vp2;
dport = atoi(dports);
dserv = 0;
if (dport == 0) {
dserv = 1;
dport = net_service_lookup(dports);
if (!dport) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
"Service lookup failed for destination"
" port \"%s\"", dports);
}
}
}
if (sport && dport) {
/* Set up a description of the source port. */
pfr = snew(PortFwdRecord);
pfr->type = type;
pfr->saddr = saddr;
pfr->sserv = sserv ? dupstr(sports) : NULL;
pfr->sport = sport;
pfr->daddr = host;
pfr->dserv = dserv ? dupstr(dports) : NULL;
pfr->dport = dport;
pfr->local = NULL;
pfr->remote = NULL;
pfr->addressfamily = (address_family == '4' ? ADDRTYPE_IPV4 :
address_family == '6' ? ADDRTYPE_IPV6 :
ADDRTYPE_UNSPEC);
PortFwdRecord *existing = add234(mgr->forwardings, pfr);
if (existing != pfr) {
if (existing->status == DESTROY) {
/*
* We already have a port forwarding up and running
* with precisely these parameters. Hence, no need
* to do anything; simply re-tag the existing one
* as KEEP.
*/
existing->status = KEEP;
}
/*
* Anything else indicates that there was a duplicate
* in our input, which we'll silently ignore.
*/
pfr_free(pfr);
} else {
pfr->status = CREATE;
}
} else {
sfree(saddr);
sfree(host);
}
}
/*
* Now go through and destroy any port forwardings which were
* not re-enabled.
*/
for (i = 0; (pfr = index234(mgr->forwardings, i)) != NULL; i++) {
if (pfr->status == DESTROY) {
char *message;
message = dupprintf("%s port forwarding from %s%s%d",
pfr->type == 'L' ? "local" :
pfr->type == 'R' ? "remote" : "dynamic",
pfr->saddr ? pfr->saddr : "",
pfr->saddr ? ":" : "",
pfr->sport);
if (pfr->type != 'D') {
char *msg2 = dupprintf("%s to %s:%d", message,
pfr->daddr, pfr->dport);
sfree(message);
message = msg2;
}
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx, "Cancelling %s", message);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
sfree(message);
/* pfr->remote or pfr->local may be NULL if setting up a
* forwarding failed. */
if (pfr->remote) {
/*
* Cancel the port forwarding at the server
* end.
*
* Actually closing the listening port on the server
* side may fail - because in SSH-1 there's no message
* in the protocol to request it!
*
* Instead, we simply remove the record of the
* forwarding from our local end, so that any
* connections the server tries to make on it are
* rejected.
*/
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
ssh_rportfwd_remove(mgr->cl, pfr->remote);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
} else if (pfr->local) {
pfl_terminate(pfr->local);
}
delpos234(mgr->forwardings, i);
pfr_free(pfr);
i--; /* so we don't skip one in the list */
}
}
/*
* And finally, set up any new port forwardings (status==CREATE).
*/
for (i = 0; (pfr = index234(mgr->forwardings, i)) != NULL; i++) {
if (pfr->status == CREATE) {
char *sportdesc, *dportdesc;
sportdesc = dupprintf("%s%s%s%s%d%s",
pfr->saddr ? pfr->saddr : "",
pfr->saddr ? ":" : "",
pfr->sserv ? pfr->sserv : "",
pfr->sserv ? "(" : "",
pfr->sport,
pfr->sserv ? ")" : "");
if (pfr->type == 'D') {
dportdesc = NULL;
} else {
dportdesc = dupprintf("%s:%s%s%d%s",
pfr->daddr,
pfr->dserv ? pfr->dserv : "",
pfr->dserv ? "(" : "",
pfr->dport,
pfr->dserv ? ")" : "");
}
if (pfr->type == 'L') {
char *err = pfl_listen(pfr->daddr, pfr->dport,
pfr->saddr, pfr->sport,
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
mgr->cl, conf, &pfr->local,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
pfr->addressfamily);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
"Local %sport %s forwarding to %s%s%s",
pfr->addressfamily == ADDRTYPE_IPV4 ? "IPv4 " :
pfr->addressfamily == ADDRTYPE_IPV6 ? "IPv6 " : "",
sportdesc, dportdesc,
err ? " failed: " : "", err ? err : "");
if (err)
sfree(err);
} else if (pfr->type == 'D') {
char *err = pfl_listen(NULL, -1, pfr->saddr, pfr->sport,
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
mgr->cl, conf, &pfr->local,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
pfr->addressfamily);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
"Local %sport %s SOCKS dynamic forwarding%s%s",
pfr->addressfamily == ADDRTYPE_IPV4 ? "IPv4 " :
pfr->addressfamily == ADDRTYPE_IPV6 ? "IPv6 " : "",
sportdesc,
err ? " failed: " : "", err ? err : "");
if (err)
sfree(err);
} else {
const char *shost;
if (pfr->saddr) {
shost = pfr->saddr;
} else if (conf_get_int(conf, CONF_rport_acceptall)) {
shost = "";
} else {
shost = "localhost";
}
pfr->remote = ssh_rportfwd_alloc(
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
mgr->cl, shost, pfr->sport, pfr->daddr, pfr->dport,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
pfr->addressfamily, sportdesc, pfr, NULL);
if (!pfr->remote) {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx,
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
"Duplicate remote port forwarding to %s:%d",
pfr->daddr, pfr->dport);
pfr_free(pfr);
} else {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
logeventf(mgr->cl->logctx, "Requesting remote port %s"
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
" forward to %s", sportdesc, dportdesc);
}
}
sfree(sportdesc);
sfree(dportdesc);
}
}
}
/*
* Called when receiving a PORT OPEN from the server to make a
* connection to a destination host.
*
* On success, returns NULL and fills in *pf_ret. On error, returns a
* dynamically allocated error message string.
*/
char *portfwdmgr_connect(PortFwdManager *mgr, Channel **chan_ret,
char *hostname, int port, SshChannel *c,
int addressfamily)
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 21:10:23 +03:00
SockAddr *addr;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
const char *err;
char *dummy_realhost = NULL;
struct PortForwarding *pf;
/*
* Try to find host.
*/
addr = name_lookup(hostname, port, &dummy_realhost, mgr->conf,
addressfamily, NULL, NULL);
if ((err = sk_addr_error(addr)) != NULL) {
char *err_ret = dupstr(err);
sk_addr_free(addr);
sfree(dummy_realhost);
return err_ret;
}
/*
* Open socket.
*/
pf = new_portfwd_state();
*chan_ret = &pf->chan;
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
pf->plug.vt = &PortForwarding_plugvt;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
pf->chan.initial_fixed_window_size = 0;
pf->chan.vt = &PortForwarding_channelvt;
pf->input_wanted = TRUE;
pf->ready = 1;
pf->c = c;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
pf->cl = mgr->cl;
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
pf->socks_state = SOCKS_NONE;
pf->s = new_connection(addr, dummy_realhost, port,
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 09:24:16 +03:00
0, 1, 0, 0, &pf->plug, mgr->conf);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
sfree(dummy_realhost);
if ((err = sk_socket_error(pf->s)) != NULL) {
char *err_ret = dupstr(err);
sk_close(pf->s);
free_portfwd_state(pf);
*chan_ret = NULL;
return err_ret;
}
return NULL;
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
}