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

685 строки
20 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 {
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 ssh_channel *c; /* channel structure held by ssh.c */
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
Ssh ssh; /* instance of SSH backend itself */
/* Note that ssh need not be filled in if c is non-NULL */
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
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
const Plug_vtable *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
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 {
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
Ssh ssh; /* instance of SSH backend itself */
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
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
const Plug_vtable *plugvt;
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
}
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
static void pfd_log(Plug plug, int type, SockAddr addr, int port,
const char *error_msg, int error_code)
{
/* we have to dump these since we have no interface to logging.c */
}
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 pfl_log(Plug plug, int type, SockAddr addr, int port,
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);
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
static void pfd_closing(Plug plug, const char *error_msg, int error_code,
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
{
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
struct PortForwarding *pf = FROMFIELD(plug, struct PortForwarding, plugvt);
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
}
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
static void pfl_closing(Plug plug, const char *error_msg, int error_code,
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);
}
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 struct ssh_channel *wrap_send_port_open(
Ssh ssh, const char *hostname, int port, 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;
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
struct ssh_channel *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
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
toret = ssh_send_port_open(ssh, hostname, port, description, 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
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));
}
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
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
{
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
struct PortForwarding *pf = FROMFIELD(plug, struct PortForwarding, plugvt);
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
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->c = wrap_send_port_open(pf->ssh, 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
}
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
static void pfd_sent(Plug plug, int bufsize)
{
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
struct PortForwarding *pf = FROMFIELD(plug, struct PortForwarding, plugvt);
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
}
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
static const Plug_vtable PortForwarding_plugvt = {
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,
};
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
* 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.
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
char *pfd_connect(Channel **chan_ret, char *hostname,int port,
struct ssh_channel *c, Conf *conf, int addressfamily)
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
{
SockAddr addr;
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;
Fix a bad free on portfwd name resolution failure. If name resolution fails, pfd_connect tries to sfree(dummy_realhost) when it's completely uninitialised - the failed resolution didn't write to it, and we also didn't precautionarily initialise it to NULL first. Now we do the latter.
2018-05-25 16:03:13 +03:00
char *dummy_realhost = 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
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
/*
* Try to find host.
*/
Tell the truth about DNS lookups in the Event Log. We've always had the back-end code unconditionally print 'Looking up host' before calling name_lookup. But name_lookup doesn't always do an actual lookup - in cases where the connection will be proxied and we're configured to let the proxy do the DNS for us, it just calls sk_nonamelookup to return a dummy SockAddr with the unresolved name still in it. It's better to print a message that varies depending on whether we're _really_ doing DNS or not, e.g. so that people can tell the difference between DNS failure and proxy misconfiguration. Hence, those log messages are now generated inside name_lookup(), which takes a couple of extra parameters for the purpose - a frontend pointer to pass to logevent(), and a reason string so that it can say what the hostname it's (optionally) looking up is going to be used for. (The latter is intended for possible use in logging subsidiary lookups for port forwarding, though the moment I haven't changed the current setup where those connection setups aren't logged in detail - we just pass NULL in that situation.)
2015-11-22 12:58:14 +03:00
addr = name_lookup(hostname, port, &dummy_realhost, conf, addressfamily,
NULL, NULL);
Control of 'addr' is now handed over to {platform_,}new_connection() and sk_new() on invocation; these functions become responsible for (eventually) freeing it. The caller must not do anything with 'addr' after it's been passed in. (Ick.) Why: A SOCKS5 crash appears to have been caused by overzealous freeing of a SockAddr (ssh.c:1.257 [r2492]), which for proxied connections is squirreled away long-term (and this can't easily be avoided). It would have been nice to make a copy of the SockAddr, in case the caller has a use for it, but one of the implementations (uxnet.c) hides a "struct addrinfo" in there, and we have no defined way to duplicate those. (None of the current callers _do_ have a further use for the SockAddr.) As far as I can tell, everything _except_ proxying only needs addr for the duration of the call, so sk_addr_free()s immediately. If I'm mistaken, it should at least be easier to find the offending free()... [originally from svn r3383] [r2492 == bdd6633970d9c53ce0ad97b460c8c684285bb15e]
2003-08-07 20:04:33 +04:00
if ((err = sk_addr_error(addr)) != 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
char *err_ret = dupstr(err);
Control of 'addr' is now handed over to {platform_,}new_connection() and sk_new() on invocation; these functions become responsible for (eventually) freeing it. The caller must not do anything with 'addr' after it's been passed in. (Ick.) Why: A SOCKS5 crash appears to have been caused by overzealous freeing of a SockAddr (ssh.c:1.257 [r2492]), which for proxied connections is squirreled away long-term (and this can't easily be avoided). It would have been nice to make a copy of the SockAddr, in case the caller has a use for it, but one of the implementations (uxnet.c) hides a "struct addrinfo" in there, and we have no defined way to duplicate those. (None of the current callers _do_ have a further use for the SockAddr.) As far as I can tell, everything _except_ proxying only needs addr for the duration of the call, so sk_addr_free()s immediately. If I'm mistaken, it should at least be easier to find the offending free()... [originally from svn r3383] [r2492 == bdd6633970d9c53ce0ad97b460c8c684285bb15e]
2003-08-07 20:04:33 +04:00
sk_addr_free(addr);
Two more memory leak fixes, on error paths I didn't spot in r9919. [originally from svn r9948] [r9919 == ea301bdd9b892a5e70692f82f5c0b98bd585e775]
2013-07-21 11:40:26 +04:00
sfree(dummy_realhost);
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 err_ret;
Control of 'addr' is now handed over to {platform_,}new_connection() and sk_new() on invocation; these functions become responsible for (eventually) freeing it. The caller must not do anything with 'addr' after it's been passed in. (Ick.) Why: A SOCKS5 crash appears to have been caused by overzealous freeing of a SockAddr (ssh.c:1.257 [r2492]), which for proxied connections is squirreled away long-term (and this can't easily be avoided). It would have been nice to make a copy of the SockAddr, in case the caller has a use for it, but one of the implementations (uxnet.c) hides a "struct addrinfo" in there, and we have no defined way to duplicate those. (None of the current callers _do_ have a further use for the SockAddr.) As far as I can tell, everything _except_ proxying only needs addr for the duration of the call, so sk_addr_free()s immediately. If I'm mistaken, it should at least be easier to find the offending free()... [originally from svn r3383] [r2492 == bdd6633970d9c53ce0ad97b460c8c684285bb15e]
2003-08-07 20:04:33 +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
/*
* Open socket.
*/
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 = new_portfwd_state();
*chan_ret = &pf->chan;
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
pf->plugvt = &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;
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;
pf->c = c;
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
pf->ssh = NULL; /* we shouldn't need this */
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->s = new_connection(addr, dummy_realhost, 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
0, 1, 0, 0, &pf->plugvt, conf);
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
sfree(dummy_realhost);
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 ((err = sk_socket_error(pf->s)) != NULL) {
char *err_ret = dupstr(err);
sk_close(pf->s);
free_portfwd_state(pf);
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
*chan_ret = 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
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;
}
/*
called when someone connects to the local 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
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;
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
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
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
pl = FROMFIELD(p, struct PortListener, plugvt);
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();
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
pf->plugvt = &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;
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
pf->ssh = pl->ssh;
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
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
pf->s = s = constructor(ctx, &pf->plugvt);
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;
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->c = wrap_send_port_open(pl->ssh, 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;
}
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
static const Plug_vtable PortListener_plugvt = {
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.
*
* 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
*/
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
char *pfl_listen(char *desthost, int destport, char *srcaddr,
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
int port, Ssh ssh, Conf *conf,
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_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();
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
pl->plugvt = &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;
Pass the Ssh structure to portfwd.c with a tag. Again, safer than using a 'void *'.
2018-09-11 17:33:10 +03:00
pl->ssh = ssh;
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
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
pl->s = new_listener(srcaddr, port, &pl->plugvt,
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.
*/
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
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);
PortForwarding *pf = FROMFIELD(chan, PortForwarding, chan);
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);
PortForwarding *pf = FROMFIELD(chan, PortForwarding, chan);
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);
PortForwarding *pf = FROMFIELD(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);
PortForwarding *pf = FROMFIELD(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);
PortForwarding *pf = FROMFIELD(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);
PortForwarding *pf = FROMFIELD(chan, PortForwarding, chan);
char *msg = dupprintf(
"Forwarded connection refused by server%s%s",
errtext ? ": " : "", errtext ? errtext : "");
logevent(ssh_get_frontend(pf->ssh), msg);
sfree(msg);
}