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

1838 lines
49 KiB
C
Raw Normal View History

Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* Windows networking abstraction.
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
*
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
* For the IPv6 code in here I am indebted to Jeroen Massar and
* unfix.org.
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
*/
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#include <winsock2.h> /* need to put this first, for winelib builds */
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
#include <stdio.h>
Fix miscellaneous compiler warnings. Thanks to Jacob Nevins [originally from svn r755]
2000-10-24 10:47:49 +00:00
#include <stdlib.h>
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 17:09:23 +00:00
#include <assert.h>
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#define NEED_DECLARATION_OF_SELECT /* in order to initialise it */
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
#include "putty.h"
#include "network.h"
#include "tree234.h"
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
#include <ws2tcpip.h>
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
clang-specific pragmas to suppress -Wmissing-braces. When I added some extra braces in commit 095072fa4 to suppress this warning, I think in fact I did the wrong thing, because the declaration syntax I was originally using is the Microsoft-recommended one in spite of clang not liking it - I think MS would be within their rights (should they feel like it) to add those missing braces in a later version of the WinSock headers, which would make the current warning-clean code stop compiling. So it's better to put the code back as it was, and avoid the clang warning by using clang's warning-suppression pragmas for just those declarations. I've also done the same thing in winnet.c, for two initialisers of IPv6 well-known addresses which had the same problem (but which I didn't notice yesterday because a misjudged set of Windows version macros had prevented me from compiling that file successfully at all).
2017-02-05 11:19:22 +00:00
#ifdef __clang__
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmissing-braces"
#endif
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
const struct in6_addr in6addr_any = IN6ADDR_ANY_INIT;
const struct in6_addr in6addr_loopback = IN6ADDR_LOOPBACK_INIT;
clang-specific pragmas to suppress -Wmissing-braces. When I added some extra braces in commit 095072fa4 to suppress this warning, I think in fact I did the wrong thing, because the declaration syntax I was originally using is the Microsoft-recommended one in spite of clang not liking it - I think MS would be within their rights (should they feel like it) to add those missing braces in a later version of the WinSock headers, which would make the current warning-clean code stop compiling. So it's better to put the code back as it was, and avoid the clang warning by using clang's warning-suppression pragmas for just those declarations. I've also done the same thing in winnet.c, for two initialisers of IPv6 well-known addresses which had the same problem (but which I didn't notice yesterday because a misjudged set of Windows version macros had prevented me from compiling that file successfully at all).
2017-02-05 11:19:22 +00:00
#ifdef __clang__
#pragma clang diagnostic pop
#endif
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
#endif
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
#define ipv4_is_loopback(addr) \
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
((p_ntohl(addr.s_addr) & 0xFF000000L) == 0x7F000000L)
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
/*
* Mutable state that goes with a SockAddr: stores information
* about where in the list of candidate IP(v*) addresses we've
* currently got to.
*/
typedef struct SockAddrStep_tag SockAddrStep;
struct SockAddrStep_tag {
#ifndef NO_IPV6
struct addrinfo *ai; /* steps along addr->ais */
#endif
int curraddr;
};
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 08:29:33 +00:00
typedef struct NetSocket NetSocket;
struct NetSocket {
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const char *error;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
SOCKET s;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *plug;
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
bufchain output_data;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool connected;
bool writable;
bool frozen; /* this causes readability notifications to be ignored */
bool frozen_readable; /* this means we missed at least one readability
* notification while we were frozen */
bool localhost_only; /* for listening sockets */
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 17:09:23 +00:00
char oobdata[1];
Robert de Bath's TCP Urgent / Telnet SYNCH patch. [originally from svn r912]
2001-01-29 14:49:21 +00:00
int sending_oob;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool oobinline, nodelay, keepalive, privport;
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 11:44:03 +00:00
enum { EOF_NO, EOF_PENDING, EOF_SENT } outgoingeof;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *addr;
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
SockAddrStep step;
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 14:29:34 +00:00
int port;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int pending_error; /* in case send() returns error */
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
/*
* We sometimes need pairs of Socket structures to be linked:
* if we are listening on the same IPv6 and v4 port, for
* example. So here we define `parent' and `child' pointers to
* track this link.
*/
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 08:29:33 +00:00
NetSocket *parent, *child;
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
Socket sock;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
};
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
struct SockAddr {
Implement sk_addr_dup(). [originally from svn r8294]
2008-11-08 16:58:55 +00:00
int refcount;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
char *error;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool resolved;
bool namedpipe; /* indicates that this SockAddr is phony, holding a Windows
* named pipe pathname instead of a network address */
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
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 14:29:34 +00:00
struct addrinfo *ais; /* Addresses IPv6 style. */
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
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 14:29:34 +00:00
unsigned long *addresses; /* Addresses IPv4 style. */
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
int naddresses;
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
char hostname[512]; /* Store an unresolved host name. */
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
};
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
/*
* Which address family this address belongs to. AF_INET for IPv4;
* AF_INET6 for IPv6; AF_UNSPEC indicates that name resolution has
* not been done and a simple host name is held in this SockAddr
* structure.
*/
#ifndef NO_IPV6
#define SOCKADDR_FAMILY(addr, step) \
(!(addr)->resolved ? AF_UNSPEC : \
(step).ai ? (step).ai->ai_family : AF_INET)
#else
#define SOCKADDR_FAMILY(addr, step) \
(!(addr)->resolved ? AF_UNSPEC : AF_INET)
#endif
/*
* Start a SockAddrStep structure to step through multiple
* addresses.
*/
#ifndef NO_IPV6
#define START_STEP(addr, step) \
((step).ai = (addr)->ais, (step).curraddr = 0)
#else
#define START_STEP(addr, step) \
((step).curraddr = 0)
#endif
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
static tree234 *sktree;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
static int cmpfortree(void *av, void *bv)
{
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 08:29:33 +00:00
NetSocket *a = (NetSocket *)av, *b = (NetSocket *)bv;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
unsigned long as = (unsigned long) a->s, bs = (unsigned long) b->s;
if (as < bs)
return -1;
if (as > bs)
return +1;
sktree is indexed on the numeric value of the socket structure's underlying WinSock SOCKET. Therefore, if we plan to modify the SOCKET in a socket, we must remove it from the tree before doing so, and put it back again afterwards. Otherwise it'll violate the tree's sorting order, and sooner or later someone will try to find it and get back NULL. [originally from svn r7795]
2007-11-26 21:09:54 +00:00
if (a < b)
return -1;
if (a > b)
return +1;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return 0;
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
static int cmpforsearch(void *av, void *bv)
{
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 08:29:33 +00:00
NetSocket *b = (NetSocket *)bv;
Cast pointers to uintptr_t instead of unsigned {long,int}. On 64bit Windows, pointers are 64bit whereas both unsigned long and unsigned int are 32bit. Using uintptr_t avoids truncation.
2015-08-11 12:01:02 +00:00
uintptr_t as = (uintptr_t) av, bs = (uintptr_t) b->s;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (as < bs)
return -1;
if (as > bs)
return +1;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return 0;
}
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, WSAStartup, (WORD, LPWSADATA));
DECL_WINDOWS_FUNCTION(static, int, WSACleanup, (void));
DECL_WINDOWS_FUNCTION(static, int, closesocket, (SOCKET));
DECL_WINDOWS_FUNCTION(static, u_long, ntohl, (u_long));
DECL_WINDOWS_FUNCTION(static, u_long, htonl, (u_long));
DECL_WINDOWS_FUNCTION(static, u_short, htons, (u_short));
DECL_WINDOWS_FUNCTION(static, u_short, ntohs, (u_short));
DECL_WINDOWS_FUNCTION(static, int, gethostname, (char *, int));
DECL_WINDOWS_FUNCTION(static, struct hostent FAR *, gethostbyname,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(const char FAR *));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, struct servent FAR *, getservbyname,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(const char FAR *, const char FAR *));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, unsigned long, inet_addr, (const char FAR *));
DECL_WINDOWS_FUNCTION(static, char FAR *, inet_ntoa, (struct in_addr));
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
DECL_WINDOWS_FUNCTION(static, const char FAR *, inet_ntop,
(int, void FAR *, char *, size_t));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, connect,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(SOCKET, const struct sockaddr FAR *, int));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, bind,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(SOCKET, const struct sockaddr FAR *, int));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, setsockopt,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(SOCKET, int, int, const char FAR *, int));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SOCKET, socket, (int, int, int));
DECL_WINDOWS_FUNCTION(static, int, listen, (SOCKET, int));
DECL_WINDOWS_FUNCTION(static, int, send, (SOCKET, const char FAR *, int, int));
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 11:44:03 +00:00
DECL_WINDOWS_FUNCTION(static, int, shutdown, (SOCKET, int));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, ioctlsocket,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(SOCKET, long, u_long FAR *));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SOCKET, accept,
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
(SOCKET, struct sockaddr FAR *, int FAR *));
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
DECL_WINDOWS_FUNCTION(static, int, getpeername,
(SOCKET, struct sockaddr FAR *, int FAR *));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, recv, (SOCKET, char FAR *, int, int));
DECL_WINDOWS_FUNCTION(static, int, WSAIoctl,
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
(SOCKET, DWORD, LPVOID, DWORD, LPVOID, DWORD,
LPDWORD, LPWSAOVERLAPPED,
LPWSAOVERLAPPED_COMPLETION_ROUTINE));
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 14:29:34 +00:00
#ifndef NO_IPV6
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, int, getaddrinfo,
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 14:29:34 +00:00
(const char *nodename, const char *servname,
const struct addrinfo *hints, struct addrinfo **res));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, void, freeaddrinfo, (struct addrinfo *res));
DECL_WINDOWS_FUNCTION(static, int, getnameinfo,
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 14:29:34 +00:00
(const struct sockaddr FAR * sa, socklen_t salen,
A small pile of Windows compiler-warning fixes. These include an unused variable left over from the command-line refactoring; an explicit referencing of the module handle for sspicli.dll which we really do deliberately load and then don't (directly) use; a missing pointer-type cast in the Windows handle socket code; and two 32/64 bit integer size mismatches in the types of functions I was importing from system API DLLs. The last of those are a bit worrying, and suggest to me that after going to all that trouble to add type-checking of those runtime imports in commit 49fb598b0, I might have only checked the resulting compiler output in a 32-bit build and not a 64-bit one. Oops!
2017-12-10 09:19:15 +00:00
char FAR * host, DWORD hostlen, char FAR * serv,
DWORD servlen, int flags));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, char *, gai_strerror, (int ecode));
DECL_WINDOWS_FUNCTION(static, int, WSAAddressToStringA,
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
(LPSOCKADDR, DWORD, LPWSAPROTOCOL_INFO,
From Corey Stup: when we're declaring stuff for WSAAddressToStringA, we should use the explicitly-narrow type LPSTR, not the switchable type LPTSTR. (Since we currently build without UNICODE this makes no practical difference to us now.) [originally from svn r8627]
2009-08-21 22:29:58 +00:00
LPSTR, LPDWORD));
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 14:29:34 +00:00
#endif
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
static HMODULE winsock_module = NULL;
static WSADATA wsadata;
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 14:29:34 +00:00
#ifndef NO_IPV6
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
static HMODULE winsock2_module = NULL;
static HMODULE wship6_module = NULL;
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 14:29:34 +00:00
#endif
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sk_startup(int hi, int lo)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
WORD winsock_ver;
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
winsock_ver = MAKEWORD(hi, lo);
if (p_WSAStartup(winsock_ver, &wsadata)) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
}
if (LOBYTE(wsadata.wVersion) != LOBYTE(winsock_ver)) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
}
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
/* Actually define this function pointer, which won't have been
* defined alongside all the others by PUTTY_DO_GLOBALS because of the
* annoying winelib header-ordering issue. (See comment in winstuff.h.) */
DECL_WINDOWS_FUNCTION(/* empty */, int, select,
(int, fd_set FAR *, fd_set FAR *,
fd_set FAR *, const struct timeval FAR *));
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
void sk_init(void)
{
Francois L'Archeveque spotted that the variable `winsock2_module' only exists when compiling for IPv6, so we shouldn't try assigning to it the rest of the time. [originally from svn r7059]
2007-01-05 18:43:58 +00:00
#ifndef NO_IPV6
winsock2_module =
#endif
Create, and use for all loads of system DLLs, a wrapper function called load_system32_dll() which constructs a full pathname for the DLL using GetSystemDirectory. The only DLL load not covered by this change is the one for gssapi32.dll, because that one's not in the system32 directory. [originally from svn r8993]
2010-09-13 08:29:45 +00:00
winsock_module = load_system32_dll("ws2_32.dll");
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
if (!winsock_module) {
Create, and use for all loads of system DLLs, a wrapper function called load_system32_dll() which constructs a full pathname for the DLL using GetSystemDirectory. The only DLL load not covered by this change is the one for gssapi32.dll, because that one's not in the system32 directory. [originally from svn r8993]
2010-09-13 08:29:45 +00:00
winsock_module = load_system32_dll("wsock32.dll");
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
}
if (!winsock_module)
Get rid of fatalbox() completely. It's an incoherent concept! There should not be any such thing as an error box that terminates the entire program but is not modal. If it's bad enough to terminate the whole program, i.e. _all_ currently live connections, then there's no point in permitting progress to continue in windows other than the affected one, because all windows are affected anyway. So all previous uses of fatalbox() have become modalfatalbox(), except those which looked to me as if they shouldn't have been fatal in the first place, e.g. lingering pieces of error handling in winnet.c which ought to have had the severity of 'give up on this particular Socket and close it' rather than 'give up on the ENTIRE UNIVERSE'.
2017-11-26 17:43:02 +00:00
modalfatalbox("Unable to load any WinSock library");
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00: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 14:29:34 +00:00
#ifndef NO_IPV6
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
/* Check if we have getaddrinfo in Winsock */
if (GetProcAddress(winsock_module, "getaddrinfo") != NULL) {
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, getaddrinfo);
GET_WINDOWS_FUNCTION(winsock_module, freeaddrinfo);
GET_WINDOWS_FUNCTION(winsock_module, getnameinfo);
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
/* This function would fail its type-check if we did one,
* because the VS header file provides an inline definition
* which is __cdecl instead of WINAPI. */
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, gai_strerror);
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
} else {
/* Fall back to wship6.dll for Windows 2000 */
Create, and use for all loads of system DLLs, a wrapper function called load_system32_dll() which constructs a full pathname for the DLL using GetSystemDirectory. The only DLL load not covered by this change is the one for gssapi32.dll, because that one's not in the system32 directory. [originally from svn r8993]
2010-09-13 08:29:45 +00:00
wship6_module = load_system32_dll("wship6.dll");
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
if (wship6_module) {
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(wship6_module, getaddrinfo);
GET_WINDOWS_FUNCTION(wship6_module, freeaddrinfo);
GET_WINDOWS_FUNCTION(wship6_module, getnameinfo);
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
/* See comment above about type check */
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, gai_strerror);
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
} else {
}
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 14:29:34 +00:00
}
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock2_module, WSAAddressToStringA);
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 14:29:34 +00:00
#endif
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, WSAAsyncSelect);
GET_WINDOWS_FUNCTION(winsock_module, WSAEventSelect);
Fix a few compiler warnings from MinGW. A few variables that gcc couldn't tell I'd initialised on all the important paths, a variable that didn't really need to be there anyway, and yet another use of GET_WINDOWS_FUNCTION_NO_TYPECHECK.
2018-06-03 20:48:08 +00:00
/* We don't type-check select because at least some MinGW versions
* of the Windows API headers seem to disagree with the
* documentation on whether the 'struct timeval *' pointer is
* const or not. */
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, select);
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, WSAGetLastError);
GET_WINDOWS_FUNCTION(winsock_module, WSAEnumNetworkEvents);
GET_WINDOWS_FUNCTION(winsock_module, WSAStartup);
GET_WINDOWS_FUNCTION(winsock_module, WSACleanup);
GET_WINDOWS_FUNCTION(winsock_module, closesocket);
Coverity build fixes. Like every other toolchain I've tried, my Coverity scanning build has its share of random objections to parts of my Windows API type- checking system. I do wonder if that bright idea was worth the hassle - but it would probably cost all the annoyance all over again to back out now...
2017-06-20 18:02:48 +00:00
#ifndef COVERITY
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, ntohl);
GET_WINDOWS_FUNCTION(winsock_module, htonl);
GET_WINDOWS_FUNCTION(winsock_module, htons);
GET_WINDOWS_FUNCTION(winsock_module, ntohs);
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 08:29:33 +00:00
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, gethostname);
Coverity build fixes. Like every other toolchain I've tried, my Coverity scanning build has its share of random objections to parts of my Windows API type- checking system. I do wonder if that bright idea was worth the hassle - but it would probably cost all the annoyance all over again to back out now...
2017-06-20 18:02:48 +00:00
#else
/* The toolchain I use for Windows Coverity builds doesn't know
* the type signatures of these */
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, ntohl);
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, htonl);
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, htons);
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, ntohs);
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, gethostname);
#endif
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, gethostbyname);
GET_WINDOWS_FUNCTION(winsock_module, getservbyname);
GET_WINDOWS_FUNCTION(winsock_module, inet_addr);
GET_WINDOWS_FUNCTION(winsock_module, inet_ntoa);
Condition out some API type-checks in the MinGW build. A couple of the functions for which I was already turning off the type check for old Visual Studio turn out to also need it turning off for MinGW.
2017-04-15 17:13:47 +00:00
#if (defined _MSC_VER && _MSC_VER < 1900) || defined __MINGW32__
/* Older Visual Studio, and MinGW as of Ubuntu 16.04, don't know
* about this function at all, so can't type-check it */
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
GET_WINDOWS_FUNCTION_NO_TYPECHECK(winsock_module, inet_ntop);
#else
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
GET_WINDOWS_FUNCTION(winsock_module, inet_ntop);
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
#endif
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, connect);
GET_WINDOWS_FUNCTION(winsock_module, bind);
GET_WINDOWS_FUNCTION(winsock_module, setsockopt);
GET_WINDOWS_FUNCTION(winsock_module, socket);
GET_WINDOWS_FUNCTION(winsock_module, listen);
GET_WINDOWS_FUNCTION(winsock_module, send);
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 11:44:03 +00:00
GET_WINDOWS_FUNCTION(winsock_module, shutdown);
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, ioctlsocket);
GET_WINDOWS_FUNCTION(winsock_module, accept);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
GET_WINDOWS_FUNCTION(winsock_module, getpeername);
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
GET_WINDOWS_FUNCTION(winsock_module, recv);
GET_WINDOWS_FUNCTION(winsock_module, WSAIoctl);
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
/* Try to get the best WinSock version we can get */
if (!sk_startup(2,2) &&
!sk_startup(2,0) &&
!sk_startup(1,1)) {
Get rid of fatalbox() completely. It's an incoherent concept! There should not be any such thing as an error box that terminates the entire program but is not modal. If it's bad enough to terminate the whole program, i.e. _all_ currently live connections, then there's no point in permitting progress to continue in windows other than the affected one, because all windows are affected anyway. So all previous uses of fatalbox() have become modalfatalbox(), except those which looked to me as if they shouldn't have been fatal in the first place, e.g. lingering pieces of error handling in winnet.c which ought to have had the severity of 'give up on this particular Socket and close it' rather than 'give up on the ENTIRE UNIVERSE'.
2017-11-26 17:43:02 +00:00
modalfatalbox("Unable to initialise WinSock");
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
sktree = newtree234(cmpfortree);
}
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
void sk_cleanup(void)
{
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 08:29:33 +00:00
NetSocket *s;
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
int i;
if (sktree) {
for (i = 0; (s = index234(sktree, i)) != NULL; i++) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_closesocket(s->s);
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
}
Joe Yates's memory leak patches. [originally from svn r3650]
2003-12-19 12:44:46 +00:00
freetree234(sktree);
sktree = NULL;
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
}
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
Corey Stup points out that any attempt to display the message "Unable to load any WinSock library" will lead to a segfault. [originally from svn r8625]
2009-08-21 20:05:24 +00:00
if (p_WSACleanup)
p_WSACleanup();
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
if (winsock_module)
FreeLibrary(winsock_module);
Petri Kero pointed out a FreeLibrary() call that should be guarded by NO_IPV6. [originally from svn r5268]
2005-02-07 12:23:10 +00:00
#ifndef NO_IPV6
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 14:29:34 +00:00
if (wship6_module)
FreeLibrary(wship6_module);
Petri Kero pointed out a FreeLibrary() call that should be guarded by NO_IPV6. [originally from svn r5268]
2005-02-07 12:23:10 +00:00
#endif
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
}
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const char *winsock_error_string(int error)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Add a fallback case to winsock_error_string() which makes it call FormatMessage to get the OS's text for any error not in our own translation table. Should eliminate the frustrating 'unknown error'. (I haven't chosen to use FormatMessage unconditionally, because it comes out with enormous messages along the lines of "No connection could be made because the target machine actively refused it" in place of "Connection refused" and I'm Unixy enough to prefer the latter. Also, on older Windowses, Winsock error codes are in a separate API segment and don't work with FormatMessage anyway.) [originally from svn r9704]
2012-11-13 18:36:27 +00:00
/*
* Error codes we know about and have historically had reasonably
* sensible error messages for.
*/
Apply improved WinSock error handling to the few situations it still hadn't been applied to. [originally from svn r827]
2000-12-18 09:20:26 +00:00
switch (error) {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
case WSAEACCES:
return "Network error: Permission denied";
case WSAEADDRINUSE:
return "Network error: Address already in use";
case WSAEADDRNOTAVAIL:
return "Network error: Cannot assign requested address";
case WSAEAFNOSUPPORT:
return
"Network error: Address family not supported by protocol family";
case WSAEALREADY:
return "Network error: Operation already in progress";
case WSAECONNABORTED:
return "Network error: Software caused connection abort";
case WSAECONNREFUSED:
return "Network error: Connection refused";
case WSAECONNRESET:
return "Network error: Connection reset by peer";
case WSAEDESTADDRREQ:
return "Network error: Destination address required";
case WSAEFAULT:
return "Network error: Bad address";
case WSAEHOSTDOWN:
return "Network error: Host is down";
case WSAEHOSTUNREACH:
return "Network error: No route to host";
case WSAEINPROGRESS:
return "Network error: Operation now in progress";
case WSAEINTR:
return "Network error: Interrupted function call";
case WSAEINVAL:
return "Network error: Invalid argument";
case WSAEISCONN:
return "Network error: Socket is already connected";
case WSAEMFILE:
return "Network error: Too many open files";
case WSAEMSGSIZE:
return "Network error: Message too long";
case WSAENETDOWN:
return "Network error: Network is down";
case WSAENETRESET:
return "Network error: Network dropped connection on reset";
case WSAENETUNREACH:
return "Network error: Network is unreachable";
case WSAENOBUFS:
return "Network error: No buffer space available";
case WSAENOPROTOOPT:
return "Network error: Bad protocol option";
case WSAENOTCONN:
return "Network error: Socket is not connected";
case WSAENOTSOCK:
return "Network error: Socket operation on non-socket";
case WSAEOPNOTSUPP:
return "Network error: Operation not supported";
case WSAEPFNOSUPPORT:
return "Network error: Protocol family not supported";
case WSAEPROCLIM:
return "Network error: Too many processes";
case WSAEPROTONOSUPPORT:
return "Network error: Protocol not supported";
case WSAEPROTOTYPE:
return "Network error: Protocol wrong type for socket";
case WSAESHUTDOWN:
return "Network error: Cannot send after socket shutdown";
case WSAESOCKTNOSUPPORT:
return "Network error: Socket type not supported";
case WSAETIMEDOUT:
return "Network error: Connection timed out";
case WSAEWOULDBLOCK:
return "Network error: Resource temporarily unavailable";
case WSAEDISCON:
return "Network error: Graceful shutdown in progress";
Apply improved WinSock error handling to the few situations it still hadn't been applied to. [originally from svn r827]
2000-12-18 09:20:26 +00:00
}
Add a fallback case to winsock_error_string() which makes it call FormatMessage to get the OS's text for any error not in our own translation table. Should eliminate the frustrating 'unknown error'. (I haven't chosen to use FormatMessage unconditionally, because it comes out with enormous messages along the lines of "No connection could be made because the target machine actively refused it" in place of "Connection refused" and I'm Unixy enough to prefer the latter. Also, on older Windowses, Winsock error codes are in a separate API segment and don't work with FormatMessage anyway.) [originally from svn r9704]
2012-11-13 18:36:27 +00:00
/*
winnet.c: remove duplicated errstring system. There's one of these centralised in win_strerror() in winmisc.c, and it doesn't seem worth keeping an earlier iteration of the same idea entirely separate in winsock_error_string. This removal means that non-network-specific error codes received in a network context will no longer have "Network error:" prefixed to them. But I think that's OK, because it seems unlikely to be critically important that such an error was received from a network function - if anything like that comes up then it's probably some kind of systemwide chaos.
2018-11-03 08:32:25 +00:00
* Handle any other error code by delegating to win_strerror.
Add a fallback case to winsock_error_string() which makes it call FormatMessage to get the OS's text for any error not in our own translation table. Should eliminate the frustrating 'unknown error'. (I haven't chosen to use FormatMessage unconditionally, because it comes out with enormous messages along the lines of "No connection could be made because the target machine actively refused it" in place of "Connection refused" and I'm Unixy enough to prefer the latter. Also, on older Windowses, Winsock error codes are in a separate API segment and don't work with FormatMessage anyway.) [originally from svn r9704]
2012-11-13 18:36:27 +00:00
*/
winnet.c: remove duplicated errstring system. There's one of these centralised in win_strerror() in winmisc.c, and it doesn't seem worth keeping an earlier iteration of the same idea entirely separate in winsock_error_string. This removal means that non-network-specific error codes received in a network context will no longer have "Network error:" prefixed to them. But I think that's OK, because it seems unlikely to be critically important that such an error was received from a network function - if anything like that comes up then it's probably some kind of systemwide chaos.
2018-11-03 08:32:25 +00:00
return win_strerror(error);
Apply improved WinSock error handling to the few situations it still hadn't been applied to. [originally from svn r827]
2000-12-18 09:20:26 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *sk_namelookup(const char *host, char **canonicalname,
int address_family)
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *ret = snew(SockAddr);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
unsigned long a;
`realhost', passed back from all the backend init functions, was scoped within those functions. It's now dynamically allocated. [originally from svn r1108]
2001-05-09 14:01:15 +00:00
char realhost[8192];
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
int hint_family;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
/* Default to IPv4. */
hint_family = (address_family == ADDRTYPE_IPV4 ? AF_INET :
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
address_family == ADDRTYPE_IPV6 ? AF_INET6 :
#endif
AF_UNSPEC);
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
/* Clear the structure and default to IPv4. */
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
memset(ret, 0, sizeof(SockAddr));
Martin Prikryl points out that we weren't always initialising new "addrinfo" members of Windows SockAddr_tag; particular in sk_nonamelookup() (proxy resolution at far end) this was causing trouble. Make sure they _always_ start out NULL (since the Windows getaddrinfo() documentation doesn't make any claims about initialisation), and also initialise 'naddresses' in sk_nonamelookup() for good measure. [originally from svn r5297]
2005-02-14 11:43:27 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
ret->ais = NULL;
Martin Prikryl points out that we weren't always initialising new "addrinfo" members of Windows SockAddr_tag; particular in sk_nonamelookup() (proxy resolution at far end) this was causing trouble. Make sure they _always_ start out NULL (since the Windows getaddrinfo() documentation doesn't make any claims about initialisation), and also initialise 'naddresses' in sk_nonamelookup() for good measure. [originally from svn r5297]
2005-02-14 11:43:27 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->namedpipe = false;
Always initialise the `addresses' field of a SockAddr to NULL, because it gets unconditionally sfree()d in sk_addr_free(). This just bit me when running under the MSVC debugger; not sure how it hasn't bitten anyone until now! [originally from svn r6800]
2006-08-26 08:37:42 +00:00
ret->addresses = NULL;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->resolved = false;
Implement sk_addr_dup(). [originally from svn r8294]
2008-11-08 16:58:55 +00:00
ret->refcount = 1;
`realhost', passed back from all the backend init functions, was scoped within those functions. It's now dynamically allocated. [originally from svn r1108]
2001-05-09 14:01:15 +00:00
*realhost = '\0';
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
if ((a = p_inet_addr(host)) == (unsigned long) INADDR_NONE) {
Another warning fix and cosmetic tweakage. [originally from svn r8665]
2009-09-27 16:07:10 +00:00
struct hostent *h = NULL;
resolve (no real impact) issue found by cppcheck: [windows/winnet.c:589]: (error) Uninitialized variable: err
2017-06-20 04:36:07 +00:00
int err = 0;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00: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 14:29:34 +00:00
* Use getaddrinfo when it's available
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00: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 14:29:34 +00:00
if (p_getaddrinfo) {
Cleanups to sk_namelookup(). In particular, it now doesn't segfault if you explicitly specify IPv6 and then try to look up a hostname which doesn't have an IPv6 address. [originally from svn r5082]
2005-01-08 14:02:06 +00:00
struct addrinfo hints;
memset(&hints, 0, sizeof(hints));
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
hints.ai_family = hint_family;
Tone down canonical-name resolution when using getaddrinfo(). Previously we were doing a forward+reverse lookup, which seems above and beyond the call of duty, especially given that getaddrinfo() can be persuaded to return a canonical name (this is what unix/uxnet.c does). Unfortunately, I'm unable to test this at all as Win98 doesn't have getaddrinfo(); hopefully I'll be able to find a mug with a modern version of Windows to check it's not completely broken. I think the effects of this are mostly cosmetic -- the canonical name is used for window titles (and some people have been annoyed at the new behaviour), other displays, and probably also for proxy exclusions. [originally from svn r5614]
2005-04-07 22:33:42 +00:00
hints.ai_flags = AI_CANONNAME;
Use the new host_str* functions to improve IPv6 literal support. I've gone through everywhere we handle host names / addresses (on command lines, in PuTTY config, in port forwarding, in X display names, in host key storage...) and tried to make them handle IPv6 literals sensibly, by using the host_str* functions I introduced in my previous commit. Generally it's now OK to use a bracketed IPv6 literal anywhere a hostname might have been valid; in a few cases where no ambiguity exists (e.g. no :port suffix is permitted anyway) unbracketed IPv6 literals are also acceptable. [originally from svn r10120]
2014-01-25 15:58:54 +00:00
{
/* strip [] on IPv6 address literals */
char *trimmed_host = host_strduptrim(host);
err = p_getaddrinfo(trimmed_host, NULL, &hints, &ret->ais);
sfree(trimmed_host);
}
if (err == 0)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->resolved = true;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
/*
* Otherwise use the IPv4-only gethostbyname...
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
* (NOTE: we don't use gethostbyname as a fallback!)
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
*/
Cleanups to sk_namelookup(). In particular, it now doesn't segfault if you explicitly specify IPv6 and then try to look up a hostname which doesn't have an IPv6 address. [originally from svn r5082]
2005-01-08 14:02:06 +00:00
if ( (h = p_gethostbyname(host)) )
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->resolved = true;
Cleanups to sk_namelookup(). In particular, it now doesn't segfault if you explicitly specify IPv6 and then try to look up a hostname which doesn't have an IPv6 address. [originally from svn r5082]
2005-01-08 14:02:06 +00:00
else
err = p_WSAGetLastError();
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
}
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (!ret->resolved) {
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
ret->error = (err == WSAENETDOWN ? "Network is down" :
Cleanups to sk_namelookup(). In particular, it now doesn't segfault if you explicitly specify IPv6 and then try to look up a hostname which doesn't have an IPv6 address. [originally from svn r5082]
2005-01-08 14:02:06 +00:00
err == WSAHOST_NOT_FOUND ? "Host does not exist" :
err == WSATRY_AGAIN ? "Host not found" :
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
p_getaddrinfo&&p_gai_strerror ? p_gai_strerror(err) :
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
"gethostbyname: unknown error");
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else {
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
ret->error = NULL;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
/* If we got an address info use that... */
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (ret->ais) {
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
/* Are we in IPv4 fallback mode? */
/* We put the IPv4 address into the a variable so we can further-on use the IPv4 code... */
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (ret->ais->ai_family == AF_INET)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
memcpy(&a,
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
(char *) &((SOCKADDR_IN *) ret->ais->
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
ai_addr)->sin_addr, sizeof(a));
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (ret->ais->ai_canonname)
strncpy(realhost, ret->ais->ai_canonname, lenof(realhost));
Tone down canonical-name resolution when using getaddrinfo(). Previously we were doing a forward+reverse lookup, which seems above and beyond the call of duty, especially given that getaddrinfo() can be persuaded to return a canonical name (this is what unix/uxnet.c does). Unfortunately, I'm unable to test this at all as Win98 doesn't have getaddrinfo(); hopefully I'll be able to find a mug with a modern version of Windows to check it's not completely broken. I think the effects of this are mostly cosmetic -- the canonical name is used for window titles (and some people have been annoyed at the new behaviour), other displays, and probably also for proxy exclusions. [originally from svn r5614]
2005-04-07 22:33:42 +00:00
else
strncpy(realhost, host, lenof(realhost));
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
}
/* We used the IPv4-only gethostbyname()... */
else
#endif
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00: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 14:29:34 +00:00
int n;
for (n = 0; h->h_addr_list[n]; n++);
ret->addresses = snewn(n, unsigned long);
ret->naddresses = n;
for (n = 0; n < ret->naddresses; n++) {
memcpy(&a, h->h_addr_list[n], sizeof(a));
ret->addresses[n] = p_ntohl(a);
}
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
memcpy(&a, h->h_addr, sizeof(a));
/* This way we are always sure the h->h_name is valid :) */
`realhost', passed back from all the backend init functions, was scoped within those functions. It's now dynamically allocated. [originally from svn r1108]
2001-05-09 14:01:15 +00:00
strncpy(realhost, h->h_name, sizeof(realhost));
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
}
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else {
Remove my dire-warning `FIXME' in IPv4 dotted-decimal handling because Jeroen points out that it's perfectly OK the way it is :-) [originally from svn r1080]
2001-04-28 11:24:45 +00:00
/*
* This must be a numeric IPv4 address because it caused a
* success return from inet_addr.
*/
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 14:29:34 +00:00
ret->addresses = snewn(1, unsigned long);
ret->naddresses = 1;
ret->addresses[0] = p_ntohl(a);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->resolved = true;
`realhost', passed back from all the backend init functions, was scoped within those functions. It's now dynamically allocated. [originally from svn r1108]
2001-05-09 14:01:15 +00:00
strncpy(realhost, host, sizeof(realhost));
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
`realhost', passed back from all the backend init functions, was scoped within those functions. It's now dynamically allocated. [originally from svn r1108]
2001-05-09 14:01:15 +00:00
realhost[lenof(realhost)-1] = '\0';
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 16:14:26 +00:00
*canonicalname = snewn(1+strlen(realhost), char);
`realhost', passed back from all the backend init functions, was scoped within those functions. It's now dynamically allocated. [originally from svn r1108]
2001-05-09 14:01:15 +00:00
strcpy(*canonicalname, realhost);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return ret;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *sk_nonamelookup(const char *host)
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *ret = snew(SockAddr);
sk_nonamelookup() should ensure the sockaddr it returns has `error' set to NULL. Otherwise it'll be random uninitialised goop. Not good. [originally from svn r2416]
2003-01-02 10:07:50 +00:00
ret->error = NULL;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->resolved = false;
Martin Prikryl points out that we weren't always initialising new "addrinfo" members of Windows SockAddr_tag; particular in sk_nonamelookup() (proxy resolution at far end) this was causing trouble. Make sure they _always_ start out NULL (since the Windows getaddrinfo() documentation doesn't make any claims about initialisation), and also initialise 'naddresses' in sk_nonamelookup() for good measure. [originally from svn r5297]
2005-02-14 11:43:27 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
ret->ais = NULL;
Martin Prikryl points out that we weren't always initialising new "addrinfo" members of Windows SockAddr_tag; particular in sk_nonamelookup() (proxy resolution at far end) this was causing trouble. Make sure they _always_ start out NULL (since the Windows getaddrinfo() documentation doesn't make any claims about initialisation), and also initialise 'naddresses' in sk_nonamelookup() for good measure. [originally from svn r5297]
2005-02-14 11:43:27 +00:00
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->namedpipe = false;
Always initialise the `addresses' field of a SockAddr to NULL, because it gets unconditionally sfree()d in sk_addr_free(). This just bit me when running under the MSVC debugger; not sure how it hasn't bitten anyone until now! [originally from svn r6800]
2006-08-26 08:37:42 +00:00
ret->addresses = NULL;
Martin Prikryl points out that we weren't always initialising new "addrinfo" members of Windows SockAddr_tag; particular in sk_nonamelookup() (proxy resolution at far end) this was causing trouble. Make sure they _always_ start out NULL (since the Windows getaddrinfo() documentation doesn't make any claims about initialisation), and also initialise 'naddresses' in sk_nonamelookup() for good measure. [originally from svn r5297]
2005-02-14 11:43:27 +00:00
ret->naddresses = 0;
Implement sk_addr_dup(). [originally from svn r8294]
2008-11-08 16:58:55 +00:00
ret->refcount = 1;
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
strncpy(ret->hostname, host, lenof(ret->hostname));
ret->hostname[lenof(ret->hostname)-1] = '\0';
return ret;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *sk_namedpipe_addr(const char *pipename)
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *ret = snew(SockAddr);
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
ret->error = NULL;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->resolved = false;
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
#ifndef NO_IPV6
ret->ais = NULL;
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->namedpipe = true;
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
ret->addresses = NULL;
ret->naddresses = 0;
ret->refcount = 1;
strncpy(ret->hostname, pipename, lenof(ret->hostname));
ret->hostname[lenof(ret->hostname)-1] = '\0';
return ret;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sk_nextaddr(SockAddr *addr, SockAddrStep *step)
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 14:29:34 +00:00
{
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (step->ai) {
if (step->ai->ai_next) {
step->ai = step->ai->ai_next;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
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 14:29:34 +00:00
} else
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
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 14:29:34 +00:00
}
#endif
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (step->curraddr+1 < addr->naddresses) {
step->curraddr++;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
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 14:29:34 +00:00
} else {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
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 14:29:34 +00:00
}
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
void sk_getaddr(SockAddr *addr, char *buf, int buflen)
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
{
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
SockAddrStep step;
START_STEP(addr, step);
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (step.ai) {
Improve buffer handling in Windows sk_getaddr() -- we were passing uninitialised storage into WSAAddressToString()'s length function (and presumably getting away with it by luck). Also improve error handling (exposed by my Wine installation, which returns an error from WSAAddressToString() for connections to localhost for some reason). [originally from svn r8737]
2009-11-08 18:25:29 +00:00
int err = 0;
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
if (p_WSAAddressToStringA) {
Improve buffer handling in Windows sk_getaddr() -- we were passing uninitialised storage into WSAAddressToString()'s length function (and presumably getting away with it by luck). Also improve error handling (exposed by my Wine installation, which returns an error from WSAAddressToString() for connections to localhost for some reason). [originally from svn r8737]
2009-11-08 18:25:29 +00:00
DWORD dwbuflen = buflen;
err = p_WSAAddressToStringA(step.ai->ai_addr, step.ai->ai_addrlen,
NULL, buf, &dwbuflen);
After discussion with Jeroen Massar, here's a patch (mostly his) which we think fixes the vista-ipv6 problem. [originally from svn r7007]
2006-12-23 09:04:27 +00:00
} else
Improve buffer handling in Windows sk_getaddr() -- we were passing uninitialised storage into WSAAddressToString()'s length function (and presumably getting away with it by luck). Also improve error handling (exposed by my Wine installation, which returns an error from WSAAddressToString() for connections to localhost for some reason). [originally from svn r8737]
2009-11-08 18:25:29 +00:00
err = -1;
if (err) {
strncpy(buf, addr->hostname, buflen);
if (!buf[0])
strncpy(buf, "<unknown>", buflen);
buf[buflen-1] = '\0';
}
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
} else
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
#endif
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (SOCKADDR_FAMILY(addr, step) == AF_INET) {
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
struct in_addr a;
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
assert(addr->addresses && step.curraddr < addr->naddresses);
a.s_addr = p_htonl(addr->addresses[step.curraddr]);
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
strncpy(buf, p_inet_ntoa(a), buflen);
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
buf[buflen-1] = '\0';
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
} else {
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
strncpy(buf, addr->hostname, buflen);
buf[buflen-1] = '\0';
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
}
}
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
/*
* This constructs a SockAddr that points at one specific sub-address
* of a parent SockAddr. The returned SockAddr does not own all its
* own memory: it points into the old one's data structures, so it
* MUST NOT be used after the old one is freed, and it MUST NOT be
* passed to sk_addr_free. (The latter is why it's returned by value
* rather than dynamically allocated - that should clue in anyone
* writing a call to it that something is weird about it.)
*/
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static SockAddr sk_extractaddr_tmp(
SockAddr *addr, const SockAddrStep *step)
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr toret;
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
toret = *addr; /* structure copy */
toret.refcount = 1;
#ifndef NO_IPV6
toret.ais = step->ai;
#endif
if (SOCKADDR_FAMILY(addr, *step) == AF_INET
#ifndef NO_IPV6
&& !toret.ais
#endif
)
toret.addresses += step->curraddr;
return toret;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sk_addr_needs_port(SockAddr *addr)
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return !addr->namedpipe;
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sk_hostname_is_local(const char *name)
Stop proxying connections to localhost by default; should fix `x11-proxy-crash'. [originally from svn r2348]
2002-12-18 12:18:54 +00:00
{
Add some hard-coded textual literal-IP representations of localhost to sk_hostname_is_local(), to catch the case where we're doing something like X11 forwarding over SSH through a proxy, and we've thus disabled local lookup of hostnames. (I think this is what's behind the report in <e9a86996-5dc2-4428-9b0c-c65693ca6351@m32g2000hsf.googlegroups.com> in comp.security.ssh, although I'd like to know more of the circumstances.) [originally from svn r8385]
2009-01-05 02:45:38 +00:00
return !strcmp(name, "localhost") ||
!strcmp(name, "::1") ||
!strncmp(name, "127.", 4);
Stop proxying connections to localhost by default; should fix `x11-proxy-crash'. [originally from svn r2348]
2002-12-18 12:18:54 +00:00
}
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
static INTERFACE_INFO local_interfaces[16];
static int n_local_interfaces; /* 0=not yet, -1=failed, >0=number */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool ipv4_is_local_addr(struct in_addr addr)
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
{
if (ipv4_is_loopback(addr))
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true; /* loopback addresses are local */
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
if (!n_local_interfaces) {
SOCKET s = p_socket(AF_INET, SOCK_DGRAM, 0);
DWORD retbytes;
Make Windows sockets non-inheritable When we create a socket with socket() (in try_connect, sk_newlistener, and ipv4_is_local_addr) also call SetHandleInformation to disable handle inheritance for this socket. This fixes dup-sessions-dont-close.
2017-02-19 13:49:12 +00:00
SetHandleInformation((HANDLE)s, HANDLE_FLAG_INHERIT, 0);
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
if (p_WSAIoctl &&
p_WSAIoctl(s, SIO_GET_INTERFACE_LIST, NULL, 0,
local_interfaces, sizeof(local_interfaces),
&retbytes, NULL, NULL) == 0)
n_local_interfaces = retbytes / sizeof(INTERFACE_INFO);
else
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
n_local_interfaces = -1;
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
}
if (n_local_interfaces > 0) {
int i;
for (i = 0; i < n_local_interfaces; i++) {
SOCKADDR_IN *address =
(SOCKADDR_IN *)&local_interfaces[i].iiAddress;
if (address->sin_addr.s_addr == addr.s_addr)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return true; /* this address is local */
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
}
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false; /* this address is not local */
Actually fix winnet-if2lo, I think. Tested in an ad-hoc manner by deliberately making a connection from nemesis's real IP address to its loopback address; not tested in the original failing case of SMB. [originally from svn r3503]
2003-10-12 14:12:54 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sk_address_is_local(SockAddr *addr)
Stop proxying connections to localhost by default; should fix `x11-proxy-crash'. [originally from svn r2348]
2002-12-18 12:18:54 +00:00
{
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
SockAddrStep step;
int family;
START_STEP(addr, step);
family = SOCKADDR_FAMILY(addr, step);
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (family == AF_INET6) {
Windows's sk_address_is_local() was returning the wrong answers for IPv6 addresses, because I'd mistakenly cast an ai_addr to the low- level 'struct in6_addr' instead of the correct 'struct sockaddr_in6'. [originally from svn r9690]
2012-10-17 20:48:07 +00:00
return IN6_IS_ADDR_LOOPBACK(&((const struct sockaddr_in6 *)step.ai->ai_addr)->sin6_addr);
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
} else
Stop proxying connections to localhost by default; should fix `x11-proxy-crash'. [originally from svn r2348]
2002-12-18 12:18:54 +00:00
#endif
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (family == AF_INET) {
sk_address_is_local() was ignoring the possibility that a SockAddr might have an IPv4 address in `ai' rather than in `addresses'. Thanks to Martin Prikryl for pointing this out. [originally from svn r5587]
2005-04-01 08:46:26 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (step.ai) {
return ipv4_is_local_addr(((struct sockaddr_in *)step.ai->ai_addr)
sk_address_is_local() was ignoring the possibility that a SockAddr might have an IPv4 address in `ai' rather than in `addresses'. Thanks to Martin Prikryl for pointing this out. [originally from svn r5587]
2005-04-01 08:46:26 +00:00
->sin_addr);
} else
#endif
{
struct in_addr a;
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
assert(addr->addresses && step.curraddr < addr->naddresses);
a.s_addr = p_htonl(addr->addresses[step.curraddr]);
sk_address_is_local() was ignoring the possibility that a SockAddr might have an IPv4 address in `ai' rather than in `addresses'. Thanks to Martin Prikryl for pointing this out. [originally from svn r5587]
2005-04-01 08:46:26 +00:00
return ipv4_is_local_addr(a);
}
Stop proxying connections to localhost by default; should fix `x11-proxy-crash'. [originally from svn r2348]
2002-12-18 12:18:54 +00:00
} else {
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
assert(family == AF_UNSPEC);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false; /* we don't know; assume not */
Stop proxying connections to localhost by default; should fix `x11-proxy-crash'. [originally from svn r2348]
2002-12-18 12:18:54 +00:00
}
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool sk_address_is_special_local(SockAddr *addr)
If you configure Unix PuTTY to use a proxy, tell it to even proxy localhost connections, and also enable X forwarding in such a way that it will attempt to connect to a Unix-domain X server socket, an assertion will fail when proxy_for_destination() tries to call sk_getaddr(). Fix by ensuring that Unix-domain sockets are _never_ proxied, since they fundamentally can't be. [originally from svn r9688]
2012-10-16 20:15:51 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false; /* no Unix-domain socket analogue here */
If you configure Unix PuTTY to use a proxy, tell it to even proxy localhost connections, and also enable X forwarding in such a way that it will attempt to connect to a Unix-domain X server socket, an assertion will fail when proxy_for_destination() tries to call sk_getaddr(). Fix by ensuring that Unix-domain sockets are _never_ proxied, since they fundamentally can't be. [originally from svn r9688]
2012-10-16 20:15:51 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
int sk_addrtype(SockAddr *addr)
SOCKS proxy support added (next instalment of Justin Bradford's proxy work). SOCKS 5 username/password authentication still unsupported. [originally from svn r1622]
2002-04-27 15:01:18 +00:00
{
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
SockAddrStep step;
int family;
START_STEP(addr, step);
family = SOCKADDR_FAMILY(addr, step);
return (family == AF_INET ? ADDRTYPE_IPV4 :
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
family == AF_INET6 ? ADDRTYPE_IPV6 :
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
#endif
ADDRTYPE_NAME);
SOCKS proxy support added (next instalment of Justin Bradford's proxy work). SOCKS 5 username/password authentication still unsupported. [originally from svn r1622]
2002-04-27 15:01:18 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
void sk_addrcopy(SockAddr *addr, char *buf)
SOCKS proxy support added (next instalment of Justin Bradford's proxy work). SOCKS 5 username/password authentication still unsupported. [originally from svn r1622]
2002-04-27 15:01:18 +00:00
{
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
SockAddrStep step;
int family;
START_STEP(addr, step);
family = SOCKADDR_FAMILY(addr, step);
assert(family != AF_UNSPEC);
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (step.ai) {
if (family == AF_INET)
memcpy(buf, &((struct sockaddr_in *)step.ai->ai_addr)->sin_addr,
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 14:29:34 +00:00
sizeof(struct in_addr));
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
else if (family == AF_INET6)
memcpy(buf, &((struct sockaddr_in6 *)step.ai->ai_addr)->sin6_addr,
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 14:29:34 +00:00
sizeof(struct in6_addr));
else
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
assert(false);
Support for doing DNS at the proxy end. I've invented a new type of SockAddr, which just contains an unresolved hostname and is created by a stub function in *net.c. It's an error to pass this to most of the real-meat functions in *net.c; these fake addresses should have been dealt with by the time they get down that far. proxy.c now contains name_lookup(), a wrapper on sk_namelookup() which decides whether or not to do real DNS, and the individual proxy implementations each deal sensibly with being handed an unresolved address and avoid ever passing one down to *net.c. [originally from svn r2353]
2002-12-18 16:23:11 +00:00
} else
SOCKS proxy support added (next instalment of Justin Bradford's proxy work). SOCKS 5 username/password authentication still unsupported. [originally from svn r1622]
2002-04-27 15:01:18 +00:00
#endif
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (family == AF_INET) {
SOCKS proxy support added (next instalment of Justin Bradford's proxy work). SOCKS 5 username/password authentication still unsupported. [originally from svn r1622]
2002-04-27 15:01:18 +00:00
struct in_addr a;
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
assert(addr->addresses && step.curraddr < addr->naddresses);
a.s_addr = p_htonl(addr->addresses[step.curraddr]);
Use memcpy rather than strncpy in sk_addrcopy! How did that happen? [originally from svn r1968]
2002-09-20 17:54:17 +00:00
memcpy(buf, (char*) &a.s_addr, 4);
SOCKS proxy support added (next instalment of Justin Bradford's proxy work). SOCKS 5 username/password authentication still unsupported. [originally from svn r1622]
2002-04-27 15:01:18 +00:00
}
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
void sk_addr_free(SockAddr *addr)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Implement sk_addr_dup(). [originally from svn r8294]
2008-11-08 16:58:55 +00:00
if (--addr->refcount > 0)
return;
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 14:29:34 +00:00
#ifndef NO_IPV6
if (addr->ais && p_freeaddrinfo)
p_freeaddrinfo(addr->ais);
#endif
if (addr->addresses)
sfree(addr->addresses);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
sfree(addr);
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *sk_addr_dup(SockAddr *addr)
Implement sk_addr_dup(). [originally from svn r8294]
2008-11-08 16:58:55 +00:00
{
addr->refcount++;
return addr;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Plug *sk_net_plug(Socket *sock, Plug *p)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *ret = s->plug;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (p)
s->plug = p;
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
return ret;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_net_flush(Socket *s)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
/*
* We send data to the socket as soon as we can anyway,
* so we don't need to do anything here. :-)
*/
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_net_close(Socket *s);
static int sk_net_write(Socket *s, const void *data, int len);
static int sk_net_write_oob(Socket *s, const void *data, int len);
static void sk_net_write_eof(Socket *s);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void sk_net_set_frozen(Socket *s, bool is_frozen);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static const char *sk_net_socket_error(Socket *s);
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
static SocketPeerInfo *sk_net_peer_info(Socket *s);
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
extern char *do_select(SOCKET skt, bool startup);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
static const SocketVtable NetSocket_sockvt = {
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 08:29:33 +00:00
sk_net_plug,
sk_net_close,
sk_net_write,
sk_net_write_oob,
sk_net_write_eof,
sk_net_flush,
sk_net_set_frozen,
sk_net_socket_error,
sk_net_peer_info,
};
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Socket *sk_net_accept(accept_ctx_t ctx, Plug *plug)
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 08:29:33 +00:00
{
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
DWORD err;
char *errstr;
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 08:29:33 +00:00
NetSocket *ret;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00: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 08:29:33 +00:00
* Create NetSocket structure.
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00: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 08:29:33 +00:00
ret = snew(NetSocket);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
ret->sock.vt = &NetSocket_sockvt;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->error = NULL;
ret->plug = plug;
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
bufchain_init(&ret->output_data);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->writable = true; /* to start with */
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->sending_oob = 0;
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 11:44:03 +00:00
ret->outgoingeof = EOF_NO;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->frozen = true;
ret->frozen_readable = false;
ret->localhost_only = false; /* unused, but best init anyway */
Fix the `SERIOUS NETWORK INTERNAL ERROR' oversight in winnet.c. See the comment in try_send() for details of the problem. [originally from svn r1335]
2001-10-28 09:57:47 +00:00
ret->pending_error = 0;
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
ret->parent = ret->child = NULL;
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 14:29:34 +00:00
ret->addr = NULL;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
Replace the hacky 'OSSocket' type with a closure. The mechanism for constructing a new connection-type Socket when a listening one receives an incoming connection previously worked by passing a platform-specific 'OSSocket' type to the plug_accepting function, which would then call sk_register to wrap it with a proper Socket instance. This is less flexible than ideal, because it presumes that only one kind of OS object might ever need to be turned into a Socket. So I've replaced OSSocket throughout the code base with a pair of parameters consisting of a function pointer and a context such that passing the latter to the former returns the appropriate Socket; this will permit different classes of listening Socket to pass different function pointers. In deference to the reality that OSSockets tend to be small integers or pointer-sized OS handles, I've made the context parameter an int/pointer union that can hold either of those directly, rather than the usual approach of making it a plain 'void *' and requiring a context structure to be dynamically allocated every time. [originally from svn r10068]
2013-11-17 14:03:55 +00:00
ret->s = (SOCKET)ctx.p;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
if (ret->s == INVALID_SOCKET) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->error = winsock_error_string(err);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->oobinline = false;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
/* Set up a select mechanism. This could be an AsyncSelect on a
* window, or an EventSelect on an event object. */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
errstr = do_select(ret->s, true);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
if (errstr) {
ret->error = errstr;
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
add234(sktree, ret);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00: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 08:29:33 +00:00
static DWORD try_connect(NetSocket *sock)
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
{
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
SOCKET s;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
SOCKADDR_IN6 a6;
#endif
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
SOCKADDR_IN a;
DWORD err;
char *errstr;
Experimental Rlogin support, thanks to Delian Delchev. Local flow control is unsupported, and server-to-client comms may fail for want of working TCP Urgent. [originally from svn r875]
2001-01-19 10:10:37 +00:00
short localport;
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 14:29:34 +00:00
int family;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00: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 14:29:34 +00:00
if (sock->s != INVALID_SOCKET) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
do_select(sock->s, false);
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 14:29:34 +00:00
p_closesocket(sock->s);
}
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr thisaddr = sk_extractaddr_tmp(
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
sock->addr, &sock->step);
plug_log(sock->plug, 0, &thisaddr, sock->port, NULL, 0);
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* Open socket.
*/
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
family = SOCKADDR_FAMILY(sock->addr, sock->step);
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 14:29:34 +00:00
sktree is indexed on the numeric value of the socket structure's underlying WinSock SOCKET. Therefore, if we plan to modify the SOCKET in a socket, we must remove it from the tree before doing so, and put it back again afterwards. Otherwise it'll violate the tree's sorting order, and sooner or later someone will try to find it and get back NULL. [originally from svn r7795]
2007-11-26 21:09:54 +00:00
/*
* Remove the socket from the tree before we overwrite its
* internal socket id, because that forms part of the tree's
* sorting criterion. We'll add it back before exiting this
* function, whether we changed anything or not.
*/
del234(sktree, sock);
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 14:29:34 +00:00
s = p_socket(family, SOCK_STREAM, 0);
sock->s = s;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
if (s == INVALID_SOCKET) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
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 14:29:34 +00:00
sock->error = winsock_error_string(err);
goto ret;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Yet another attempt at OOB handling in the network abstraction. This version allows you to specify, per socket, which sockets receive OOB data in-line (so that you know what was before the mark and what was after) and which receive it out of line (so it's really a one-byte out-of-band facility rather than discard-to-mark). This reflects the fact that rlogin appears to make more sense in the latter mode, and telnet in the former. This patch makes rlogin work right for me. [originally from svn r921]
2001-02-01 14:11:04 +00:00
Make Windows sockets non-inheritable When we create a socket with socket() (in try_connect, sk_newlistener, and ipv4_is_local_addr) also call SetHandleInformation to disable handle inheritance for this socket. This fixes dup-sessions-dont-close.
2017-02-19 13:49:12 +00:00
SetHandleInformation((HANDLE)s, HANDLE_FLAG_INHERIT, 0);
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 14:29:34 +00:00
if (sock->oobinline) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
BOOL b = true;
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_setsockopt(s, SOL_SOCKET, SO_OOBINLINE, (void *) &b, sizeof(b));
Robert de Bath's TCP Urgent / Telnet SYNCH patch. [originally from svn r912]
2001-01-29 14:49:21 +00:00
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00: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 14:29:34 +00:00
if (sock->nodelay) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
BOOL b = true;
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (void *) &b, sizeof(b));
Configurable TCP_NODELAY option on network connections [originally from svn r1428]
2001-11-29 21:47:11 +00: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 14:29:34 +00:00
if (sock->keepalive) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
BOOL b = true;
Add a configuration option for TCP keepalives (SO_KEEPALIVE), default off. No very good reason, but I've occasionally wanted to frob it to see if it makes any difference to problems I'm having, and it was easy. Tested that it does actually cause keepalives on Windows (with tcpdump); should also work on Unix. Not implemented on Mac (does nothing), but then neither is TCP_NODELAY. Quite a big checkin, much of which is adding `keepalive' alongside `nodelay' in network function calls. [originally from svn r4309]
2004-06-20 17:07:38 +00:00
p_setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, (void *) &b, sizeof(b));
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* Bind to local address.
*/
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 14:29:34 +00:00
if (sock->privport)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
localport = 1023; /* count from 1023 downwards */
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
else
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
localport = 0; /* just use port 0 (ie winsock picks) */
Experimental Rlogin support, thanks to Delian Delchev. Local flow control is unsupported, and server-to-client comms may fail for want of working TCP Urgent. [originally from svn r875]
2001-01-19 10:10:37 +00:00
/* Loop round trying to bind */
while (1) {
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 14:29:34 +00:00
int sockcode;
Experimental Rlogin support, thanks to Delian Delchev. Local flow control is unsupported, and server-to-client comms may fail for want of working TCP Urgent. [originally from svn r875]
2001-01-19 10:10:37 +00:00
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
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 14:29:34 +00:00
if (family == AF_INET6) {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
memset(&a6, 0, sizeof(a6));
a6.sin6_family = AF_INET6;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
/*a6.sin6_addr = in6addr_any; */ /* == 0 done by memset() */
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a6.sin6_port = p_htons(localport);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
a.sin_family = AF_INET;
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a.sin_addr.s_addr = p_htonl(INADDR_ANY);
a.sin_port = p_htons(localport);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
}
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
sockcode = p_bind(s, (family == AF_INET6 ?
(struct sockaddr *) &a6 :
(struct sockaddr *) &a),
(family == AF_INET6 ? sizeof(a6) : sizeof(a)));
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#else
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 14:29:34 +00:00
sockcode = p_bind(s, (struct sockaddr *) &a, sizeof(a));
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
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 14:29:34 +00:00
if (sockcode != SOCKET_ERROR) {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
err = 0;
break; /* done */
} else {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (err != WSAEADDRINUSE) /* failed, for a bad reason */
break;
}
if (localport == 0)
break; /* we're only looping once */
localport--;
if (localport == 0)
break; /* we might have got to the end */
Experimental Rlogin support, thanks to Delian Delchev. Local flow control is unsupported, and server-to-client comms may fail for want of working TCP Urgent. [originally from svn r875]
2001-01-19 10:10:37 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (err) {
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 14:29:34 +00:00
sock->error = winsock_error_string(err);
goto ret;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
/*
* Connect to remote address.
*/
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
if (sock->step.ai) {
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 14:29:34 +00:00
if (family == AF_INET6) {
a6.sin6_family = AF_INET6;
a6.sin6_port = p_htons((short) sock->port);
a6.sin6_addr =
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
((struct sockaddr_in6 *) sock->step.ai->ai_addr)->sin6_addr;
a6.sin6_flowinfo = ((struct sockaddr_in6 *) sock->step.ai->ai_addr)->sin6_flowinfo;
a6.sin6_scope_id = ((struct sockaddr_in6 *) sock->step.ai->ai_addr)->sin6_scope_id;
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 14:29:34 +00:00
} else {
a.sin_family = AF_INET;
a.sin_addr =
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
((struct sockaddr_in *) sock->step.ai->ai_addr)->sin_addr;
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 14:29:34 +00:00
a.sin_port = p_htons((short) sock->port);
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
assert(sock->addr->addresses && sock->step.curraddr < sock->addr->naddresses);
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
a.sin_family = AF_INET;
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
a.sin_addr.s_addr = p_htonl(sock->addr->addresses[sock->step.curraddr]);
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 14:29:34 +00:00
a.sin_port = p_htons((short) sock->port);
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
}
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
/* Set up a select mechanism. This could be an AsyncSelect on a
* window, or an EventSelect on an event object. */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
errstr = do_select(s, true);
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
if (errstr) {
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 14:29:34 +00:00
sock->error = errstr;
err = 1;
goto ret;
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if ((
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
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 14:29:34 +00:00
p_connect(s,
((family == AF_INET6) ? (struct sockaddr *) &a6 :
(struct sockaddr *) &a),
(family == AF_INET6) ? sizeof(a6) : sizeof(a))
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#else
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_connect(s, (struct sockaddr *) &a, sizeof(a))
Jeroen Massar's IPv6 patch. Disabled by default, for now. [originally from svn r849]
2001-01-07 19:16:16 +00:00
#endif
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
) == SOCKET_ERROR) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
/*
* We expect a potential EWOULDBLOCK here, because the
* chances are the front end has done a select for
* FD_CONNECT, so that connect() will complete
* asynchronously.
*/
if ( err != WSAEWOULDBLOCK ) {
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 14:29:34 +00:00
sock->error = winsock_error_string(err);
goto ret;
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
}
} else {
/*
* If we _don't_ get EWOULDBLOCK, the connect has completed
* and we should set the socket as writable.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
sock->writable = true;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00: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 14:29:34 +00:00
err = 0;
ret:
sktree is indexed on the numeric value of the socket structure's underlying WinSock SOCKET. Therefore, if we plan to modify the SOCKET in a socket, we must remove it from the tree before doing so, and put it back again afterwards. Otherwise it'll violate the tree's sorting order, and sooner or later someone will try to find it and get back NULL. [originally from svn r7795]
2007-11-26 21:09:54 +00:00
/*
* No matter what happened, put the socket back in the tree.
*/
add234(sktree, sock);
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
if (err) {
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr thisaddr = sk_extractaddr_tmp(
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
sock->addr, &sock->step);
plug_log(sock->plug, 1, &thisaddr, sock->port, sock->error, err);
}
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 14:29:34 +00:00
return err;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
Socket *sk_new(SockAddr *addr, int port, bool privport, bool oobinline,
bool nodelay, bool keepalive, Plug *plug)
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 14:29:34 +00: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 08:29:33 +00:00
NetSocket *ret;
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 14:29:34 +00:00
DWORD err;
/*
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 08:29:33 +00:00
* Create NetSocket structure.
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 14:29:34 +00: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 08:29:33 +00:00
ret = snew(NetSocket);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
ret->sock.vt = &NetSocket_sockvt;
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 14:29:34 +00:00
ret->error = NULL;
ret->plug = plug;
bufchain_init(&ret->output_data);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->connected = false; /* to start with */
ret->writable = false; /* to start with */
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 14:29:34 +00:00
ret->sending_oob = 0;
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 11:44:03 +00:00
ret->outgoingeof = EOF_NO;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->frozen = false;
ret->frozen_readable = false;
ret->localhost_only = false; /* unused, but best init anyway */
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 14:29:34 +00:00
ret->pending_error = 0;
ret->parent = ret->child = NULL;
ret->oobinline = oobinline;
ret->nodelay = nodelay;
ret->keepalive = keepalive;
ret->privport = privport;
ret->port = port;
ret->addr = addr;
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
START_STEP(ret->addr, ret->step);
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 14:29:34 +00:00
ret->s = INVALID_SOCKET;
err = 0;
do {
err = try_connect(ret);
Move out of the SockAddr structure the mutable fields "ai" and "curraddr", and turn "family" into a macro-derived property of the other fields. The idea is that this renders SockAddrs immutable once created, which should open up the possibility of duplicating and reusing one without having to redo the actual DNS lookup. I _hope_ I haven't broken anything. The new code architecture contains several rather dubious-looking operations (namely the arbitrary choice of the first returned address in functions like sk_getaddr and sk_address_is_local - what if, for instance, a DNS lookup returned a local and a non-local address?), but I think they were functionally just as dubious beforehand and all this change has done is to make them more obviously so to a reader. [originally from svn r8293]
2008-11-08 16:45:45 +00:00
} while (err && sk_nextaddr(ret->addr, &ret->step));
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 16:04:33 +00:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *sk_newlistener(const char *srcaddr, int port, Plug *plug,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool local_host_only, int orig_address_family)
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
{
SOCKET s;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
SOCKADDR_IN6 a6;
#endif
SOCKADDR_IN a;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
DWORD err;
char *errstr;
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 08:29:33 +00:00
NetSocket *ret;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
int retcode;
int on = 1;
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
int address_family;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00: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 08:29:33 +00:00
* Create NetSocket structure.
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00: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 08:29:33 +00:00
ret = snew(NetSocket);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
ret->sock.vt = &NetSocket_sockvt;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->error = NULL;
ret->plug = plug;
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 17:09:23 +00:00
bufchain_init(&ret->output_data);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->writable = false; /* to start with */
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->sending_oob = 0;
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 11:44:03 +00:00
ret->outgoingeof = EOF_NO;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->frozen = false;
ret->frozen_readable = false;
Due to fears that an incompetent WinSock might allow localhost- listening sockets to be talked to by non-local hosts, reinstate the explicit peer address check on connection acceptance. [originally from svn r1306]
2001-10-12 19:32:13 +00:00
ret->localhost_only = local_host_only;
Fix the `SERIOUS NETWORK INTERNAL ERROR' oversight in winnet.c. See the comment in try_send() for details of the problem. [originally from svn r1335]
2001-10-28 09:57:47 +00:00
ret->pending_error = 0;
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
ret->parent = ret->child = NULL;
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 14:29:34 +00:00
ret->addr = NULL;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
/*
* Translate address_family from platform-independent constants
* into local reality.
*/
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
address_family = (orig_address_family == ADDRTYPE_IPV4 ? AF_INET :
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
orig_address_family == ADDRTYPE_IPV6 ? AF_INET6 :
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#endif
AF_UNSPEC);
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
/*
* Our default, if passed the `don't care' value
* ADDRTYPE_UNSPEC, is to listen on IPv4. If IPv6 is supported,
* we will also set up a second socket listening on IPv6, but
* the v4 one is primary since that ought to work even on
* non-v6-supporting systems.
*/
if (address_family == AF_UNSPEC) address_family = AF_INET;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
/*
* Open socket.
*/
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
s = p_socket(address_family, SOCK_STREAM, 0);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->s = s;
if (s == INVALID_SOCKET) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->error = winsock_error_string(err);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00: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 08:29:33 +00:00
SetHandleInformation((HANDLE)s, HANDLE_FLAG_INHERIT, 0);
Make Windows sockets non-inheritable When we create a socket with socket() (in try_connect, sk_newlistener, and ipv4_is_local_addr) also call SetHandleInformation to disable handle inheritance for this socket. This fixes dup-sessions-dont-close.
2017-02-19 13:49:12 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
ret->oobinline = false;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char *)&on, sizeof(on));
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
if (address_family == AF_INET6) {
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
memset(&a6, 0, sizeof(a6));
a6.sin6_family = AF_INET6;
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
if (local_host_only)
a6.sin6_addr = in6addr_loopback;
else
a6.sin6_addr = in6addr_any;
Support explicit IPv6 source addresses in Windows port forwarding. There's been a long-standing FIXME in Windows's sk_newlistener which says that in IPv6 mode, an explicit source address (e.g. from a command-line option of the form -L srcaddr:12345:dest:22) is ignored. Now it's honoured if possible. [originally from svn r10122]
2014-01-25 15:58:59 +00:00
if (srcaddr != NULL && p_getaddrinfo) {
struct addrinfo hints;
struct addrinfo *ai;
int err;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_INET6;
hints.ai_flags = 0;
{
/* strip [] on IPv6 address literals */
char *trimmed_addr = host_strduptrim(srcaddr);
err = p_getaddrinfo(trimmed_addr, NULL, &hints, &ai);
sfree(trimmed_addr);
}
if (err == 0 && ai->ai_family == AF_INET6) {
a6.sin6_addr =
((struct sockaddr_in6 *)ai->ai_addr)->sin6_addr;
}
}
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a6.sin6_port = p_htons(port);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
} else
#endif
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool got_addr = false;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
a.sin_family = AF_INET;
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
/*
* Bind to source address. First try an explicitly
* specified one...
*/
if (srcaddr) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a.sin_addr.s_addr = p_inet_addr(srcaddr);
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
if (a.sin_addr.s_addr != INADDR_NONE) {
/* Override localhost_only with specified listen addr. */
ret->localhost_only = ipv4_is_loopback(a.sin_addr);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
got_addr = true;
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
}
}
/*
* ... and failing that, go with one of the standard ones.
*/
if (!got_addr) {
if (local_host_only)
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a.sin_addr.s_addr = p_htonl(INADDR_LOOPBACK);
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
else
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a.sin_addr.s_addr = p_htonl(INADDR_ANY);
Implement `portfwd-loopback-choice'. Works on local side in Unix as well, though it's a lot less useful since you still can't bind to low-numbered ports of odd loopback IPs. Should work in principle for SSH2 remote forwardings as well as local ones, but OpenSSH seems unwilling to cooperate. [originally from svn r2344]
2002-12-18 11:39:25 +00:00
}
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
a.sin_port = p_htons((short)port);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
retcode = p_bind(s, (address_family == AF_INET6 ?
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
(struct sockaddr *) &a6 :
(struct sockaddr *) &a),
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
(address_family ==
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
AF_INET6 ? sizeof(a6) : sizeof(a)));
#else
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
retcode = p_bind(s, (struct sockaddr *) &a, sizeof(a));
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
#endif
if (retcode != SOCKET_ERROR) {
err = 0;
} else {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
if (err) {
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
p_closesocket(s);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->error = winsock_error_string(err);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
if (p_listen(s, SOMAXCONN) == SOCKET_ERROR) {
p_closesocket(s);
Fix another error-reporting bug, in which sk_newlistener would fail to capture the error code if listen() returned an error, and instead pass 0 (saved from the previous successful bind) to winsock_error_string. [originally from svn r9708]
2012-11-14 18:32:09 +00:00
ret->error = winsock_error_string(p_WSAGetLastError());
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
/* Set up a select mechanism. This could be an AsyncSelect on a
* window, or an EventSelect on an event object. */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
errstr = do_select(s, true);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
if (errstr) {
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
p_closesocket(s);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
ret->error = errstr;
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
add234(sktree, ret);
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
#ifndef NO_IPV6
/*
* If we were given ADDRTYPE_UNSPEC, we must also create an
* IPv6 listening socket and link it to this one.
*/
if (address_family == AF_INET && orig_address_family == ADDRTYPE_UNSPEC) {
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *other = sk_newlistener(srcaddr, port, plug,
local_host_only, ADDRTYPE_IPV6);
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
if (other) {
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *ns = container_of(other, NetSocket, sock);
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 08:29:33 +00:00
if (!ns->error) {
ns->parent = ret;
ret->child = ns;
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
} else {
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 08:29:33 +00:00
sfree(ns);
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
}
}
}
#endif
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_net_close(Socket *sock)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
Add X11 forwarding, mainly thanks to Andreas Schultz [originally from svn r878]
2001-01-22 11:34:52 +00:00
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
if (s->child)
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
sk_net_close(&s->child->sock);
For local and dynamic port forwardings (i.e. the ones which listen on a local port), the `Auto' protocol option on the Tunnels panel should always produce a port you can connect to in _either_ of IPv4 and v6, because the aim is for the user not to have to know or care which one they're using. This was not the case on Windows, and now is. Also, updated the docs to give more detail on issues like this. [originally from svn r5083]
2005-01-08 14:45:26 +00:00
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
del234(sktree, s);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
do_select(s->s, false);
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_closesocket(s->s);
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 14:29:34 +00:00
if (s->addr)
sk_addr_free(s->addr);
Make memory management uniform: _everything_ now goes through the smalloc() macros and thence to the safemalloc() functions in misc.c. This should allow me to plug in a debugging allocator and track memory leaks and segfaults and things. [originally from svn r818]
2000-12-12 10:33:13 +00:00
sfree(s);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Revamp net_pending_errors using toplevel callbacks. Again, I've removed the special-purpose ad-hockery from the assorted front end message loops that dealt with deferred handling of socket errors, and instead uxnet.c and winnet.c arrange that for themselves by calling the new general top-level callback mechanism. [originally from svn r10023]
2013-08-17 16:06:27 +00:00
/*
* Deal with socket errors detected in try_send().
*/
static void socket_error_callback(void *vs)
{
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 08:29:33 +00:00
NetSocket *s = (NetSocket *)vs;
Revamp net_pending_errors using toplevel callbacks. Again, I've removed the special-purpose ad-hockery from the assorted front end message loops that dealt with deferred handling of socket errors, and instead uxnet.c and winnet.c arrange that for themselves by calling the new general top-level callback mechanism. [originally from svn r10023]
2013-08-17 16:06:27 +00:00
/*
* Just in case other socket work has caused this socket to vanish
* or become somehow non-erroneous before this callback arrived...
*/
if (!find234(sktree, s, NULL) || !s->pending_error)
return;
/*
* An error has occurred on this socket. Pass it to the plug.
*/
Don't pass WinSock error codes to strerror. Martin Prikryl helpfully points out that when I revamped the socket error mechanism using toplevel callbacks, I also accidentally passed the error code to the wrong function. Use winsock_error_string instead. [originally from svn r10048]
2013-10-09 18:36:56 +00:00
plug_closing(s->plug, winsock_error_string(s->pending_error),
s->pending_error, 0);
Revamp net_pending_errors using toplevel callbacks. Again, I've removed the special-purpose ad-hockery from the assorted front end message loops that dealt with deferred handling of socket errors, and instead uxnet.c and winnet.c arrange that for themselves by calling the new general top-level callback mechanism. [originally from svn r10023]
2013-08-17 16:06:27 +00:00
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* The function which tries to send on a socket once it's deemed
* writable.
*/
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 08:29:33 +00:00
void try_send(NetSocket *s)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00: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 17:09:23 +00:00
while (s->sending_oob || bufchain_size(&s->output_data) > 0) {
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
int nsent;
DWORD err;
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 17:09:23 +00:00
void *data;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
int len, urgentflag;
if (s->sending_oob) {
urgentflag = MSG_OOB;
len = s->sending_oob;
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 17:09:23 +00:00
data = &s->oobdata;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else {
urgentflag = 0;
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 17:09:23 +00:00
bufchain_prefix(&s->output_data, &data, &len);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
}
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
nsent = p_send(s->s, data, len, urgentflag);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
noise_ultralight(nsent);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
if (nsent <= 0) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = (nsent < 0 ? p_WSAGetLastError() : 0);
Fix the intermittent fault in the socket layer that was occasionally bombing out X forwarding. It turns out to be a workaround for YET ANOTHER useless WinSock implementation. Arrgh! [originally from svn r1232]
2001-09-05 22:04:19 +00:00
if ((err < WSABASEERR && nsent < 0) || err == WSAEWOULDBLOCK) {
David Brinegar's workaround for an error reporting problem in some WinSocks. [originally from svn r1004]
2001-03-15 13:25:48 +00:00
/*
* Perfectly normal: we've sent all we can for the moment.
*
Fix the intermittent fault in the socket layer that was occasionally bombing out X forwarding. It turns out to be a workaround for YET ANOTHER useless WinSock implementation. Arrgh! [originally from svn r1232]
2001-09-05 22:04:19 +00:00
* (Some WinSock send() implementations can return
* <0 but leave no sensible error indication -
* WSAGetLastError() is called but returns zero or
* a small number - so we check that case and treat
* it just like WSAEWOULDBLOCK.)
David Brinegar's workaround for an error reporting problem in some WinSocks. [originally from svn r1004]
2001-03-15 13:25:48 +00:00
*/
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
s->writable = false;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
return;
Get rid of fatalbox() completely. It's an incoherent concept! There should not be any such thing as an error box that terminates the entire program but is not modal. If it's bad enough to terminate the whole program, i.e. _all_ currently live connections, then there's no point in permitting progress to continue in windows other than the affected one, because all windows are affected anyway. So all previous uses of fatalbox() have become modalfatalbox(), except those which looked to me as if they shouldn't have been fatal in the first place, e.g. lingering pieces of error handling in winnet.c which ought to have had the severity of 'give up on this particular Socket and close it' rather than 'give up on the ENTIRE UNIVERSE'.
2017-11-26 17:43:02 +00:00
} else {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
/*
Get rid of fatalbox() completely. It's an incoherent concept! There should not be any such thing as an error box that terminates the entire program but is not modal. If it's bad enough to terminate the whole program, i.e. _all_ currently live connections, then there's no point in permitting progress to continue in windows other than the affected one, because all windows are affected anyway. So all previous uses of fatalbox() have become modalfatalbox(), except those which looked to me as if they shouldn't have been fatal in the first place, e.g. lingering pieces of error handling in winnet.c which ought to have had the severity of 'give up on this particular Socket and close it' rather than 'give up on the ENTIRE UNIVERSE'.
2017-11-26 17:43:02 +00:00
* If send() returns a socket error, we unfortunately
* can't just call plug_closing(), because it's quite
* likely that we're currently _in_ a call from the
* code we'd be calling back to, so we'd have to make
* half the SSH code reentrant. Instead we flag a
* pending error on the socket, to be dealt with (by
* calling plug_closing()) at some suitable future
* moment.
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
*/
Fix the `SERIOUS NETWORK INTERNAL ERROR' oversight in winnet.c. See the comment in try_send() for details of the problem. [originally from svn r1335]
2001-10-28 09:57:47 +00:00
s->pending_error = err;
Revamp net_pending_errors using toplevel callbacks. Again, I've removed the special-purpose ad-hockery from the assorted front end message loops that dealt with deferred handling of socket errors, and instead uxnet.c and winnet.c arrange that for themselves by calling the new general top-level callback mechanism. [originally from svn r10023]
2013-08-17 16:06:27 +00:00
queue_toplevel_callback(socket_error_callback, s);
Fix the `SERIOUS NETWORK INTERNAL ERROR' oversight in winnet.c. See the comment in try_send() for details of the problem. [originally from svn r1335]
2001-10-28 09:57:47 +00:00
return;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
} else {
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 17:09:23 +00:00
if (s->sending_oob) {
if (nsent < len) {
memmove(s->oobdata, s->oobdata+nsent, len-nsent);
s->sending_oob = len - nsent;
} else {
s->sending_oob = 0;
}
} else {
bufchain_consume(&s->output_data, nsent);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
}
}
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 11:44:03 +00:00
/*
* If we reach here, we've finished sending everything we might
* have needed to send. Send EOF, if we need to.
*/
if (s->outgoingeof == EOF_PENDING) {
p_shutdown(s->s, SD_SEND);
s->outgoingeof = EOF_SENT;
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static int sk_net_write(Socket *sock, const void *buf, int len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
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 11:44:03 +00:00
assert(s->outgoingeof == EOF_NO);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* Add the data to the buffer list on the socket.
*/
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 17:09:23 +00:00
bufchain_add(&s->output_data, buf, len);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* Now try sending from the start of the buffer list.
*/
if (s->writable)
try_send(s);
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 17:09:23 +00:00
return bufchain_size(&s->output_data);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static int sk_net_write_oob(Socket *sock, const void *buf, int len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
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 11:44:03 +00:00
assert(s->outgoingeof == EOF_NO);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* Replace the buffer list on the socket with the data.
*/
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 17:09:23 +00:00
bufchain_clear(&s->output_data);
assert(len <= sizeof(s->oobdata));
memcpy(s->oobdata, buf, len);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
s->sending_oob = len;
/*
* Now try sending from the start of the buffer list.
*/
if (s->writable)
try_send(s);
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 17:09:23 +00:00
return s->sending_oob;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_net_write_eof(Socket *sock)
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 11:44:03 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
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 11:44:03 +00:00
assert(s->outgoingeof == EOF_NO);
/*
* Mark the socket as pending outgoing EOF.
*/
s->outgoingeof = EOF_PENDING;
/*
* Now try sending from the start of the buffer list.
*/
if (s->writable)
try_send(s);
}
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
void select_result(WPARAM wParam, LPARAM lParam)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
int ret;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
DWORD err;
Increase the read buffer size in network processing for extra speed. [originally from svn r1047]
2001-04-16 12:25:03 +00:00
char buf[20480]; /* nice big buffer for plenty of speed */
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 08:29:33 +00:00
NetSocket *s;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool atmark;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/* wParam is the socket itself */
Add a new diagnostic in winnet.c, to attempt to pinpoint the reason for the tree234 assertion failure we've had reported recently. [originally from svn r2288]
2002-12-08 11:00:47 +00:00
Remove the diagnostic added in rev 1.42 [r2288]; apparently it's all true and WinSock _does_ occasionally send us netevent messages with no socket for no reason. Ignore them when they appear. [originally from svn r2518] [r2288 == 3bb2e4568c15f5cd76544772ec20f337b8ffb8d5]
2003-01-09 19:26:12 +00:00
if (wParam == 0)
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
return; /* boggle */
Add a new diagnostic in winnet.c, to attempt to pinpoint the reason for the tree234 assertion failure we've had reported recently. [originally from svn r2288]
2002-12-08 11:00:47 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
s = find234(sktree, (void *) wParam, cmpforsearch);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
if (!s)
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
return; /* boggle */
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
if ((err = WSAGETSELECTERROR(lParam)) != 0) {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
/*
* An error has occurred on this socket. Pass it to the
* plug.
*/
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 14:29:34 +00:00
if (s->addr) {
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr thisaddr = sk_extractaddr_tmp(
Report the right address in connection setup errors. backend_socket_log was generating the IP address in its error messages by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr, which may contain a whole list of candidate addresses; it doesn't also get the information stored in the 'step' field of the Socket that was actually trying to make the connection, which says _which_ of those addresses we were in the middle of trying to connect to. So now we construct a temporary SockAddr that points at the appropriate one of the addresses, and use that for calls to plug_log during connection setup.
2017-01-28 10:56:19 +00:00
s->addr, &s->step);
plug_log(s->plug, 1, &thisaddr, s->port,
Support for falling back through the list of addresses returned from a DNS lookup, whether they're IPv4, v6 or a mixture of both. [originally from svn r5119] [this svn revision also touched putty-wishlist]
2005-01-16 14:29:34 +00:00
winsock_error_string(err), err);
Add error variable to loop condition In case of connection errors before and during the handshake, net_select_result is retrying with the next address of the server. It however was immediately going to the last address as it was not checking the return value of try_connect for all intermediate addresses.
2017-01-23 17:51:03 +00:00
while (err && s->addr && sk_nextaddr(s->addr, &s->step)) {
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 14:29:34 +00:00
err = try_connect(s);
}
}
if (err != 0)
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_closing(s->plug, winsock_error_string(err), err, 0);
return;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
Improved entropy gathering. [originally from svn r750]
2000-10-23 15:20:05 +00:00
noise_ultralight(lParam);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
switch (WSAGETSELECTEVENT(lParam)) {
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
case FD_CONNECT:
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
s->connected = true;
s->writable = true;
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 14:29:34 +00:00
/*
* Once a socket is connected, we can stop falling
* back through the candidate addresses to connect
* to.
*/
if (s->addr) {
sk_addr_free(s->addr);
s->addr = NULL;
}
Robert de Bath's asynchronous-connect patch. Helps a lot in port forwarding; improves Event Log; and causes the PuTTY window to appear earlier in the setup process. [originally from svn r1239]
2001-09-07 22:39:01 +00:00
break;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
case FD_READ:
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
/* In the case the socket is still frozen, we don't even bother */
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 17:09:23 +00:00
if (s->frozen) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
s->frozen_readable = true;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
break;
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 17:09:23 +00:00
}
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
/*
* We have received data on the socket. For an oobinline
* socket, this might be data _before_ an urgent pointer,
* in which case we send it to the back end with type==1
* (data prior to urgent).
*/
if (s->oobinline) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
u_long atmark_from_ioctl = 1;
p_ioctlsocket(s->s, SIOCATMARK, &atmark_from_ioctl);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
/*
* Avoid checking the return value from ioctlsocket(),
* on the grounds that some WinSock wrappers don't
* support it. If it does nothing, we get atmark==1,
* which is equivalent to `no OOB pending', so the
* effect will be to non-OOB-ify any OOB data.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
atmark = atmark_from_ioctl;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
atmark = true;
Yet another attempt at OOB handling in the network abstraction. This version allows you to specify, per socket, which sockets receive OOB data in-line (so that you know what was before the mark and what was after) and which receive it out of line (so it's really a one-byte out-of-band facility rather than discard-to-mark). This reflects the fact that rlogin appears to make more sense in the latter mode, and telnet in the former. This patch makes rlogin work right for me. [originally from svn r921]
2001-02-01 14:11:04 +00:00
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
ret = p_recv(s->s, buf, sizeof(buf), 0);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
noise_ultralight(ret);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
if (ret < 0) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
if (err == WSAEWOULDBLOCK) {
break;
}
}
if (ret < 0) {
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_closing(s->plug, winsock_error_string(err), err, 0);
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
} else if (0 == ret) {
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_closing(s->plug, NULL, 0, 0);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
} else {
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_receive(s->plug, atmark ? 0 : 1, buf, ret);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
break;
case FD_OOB:
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
/*
* This will only happen on a non-oobinline socket. It
* indicates that we can immediately perform an OOB read
* and get back OOB data, which we will send to the back
* end with type==2 (urgent data).
*/
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
ret = p_recv(s->s, buf, sizeof(buf), MSG_OOB);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
noise_ultralight(ret);
if (ret <= 0) {
Get rid of fatalbox() completely. It's an incoherent concept! There should not be any such thing as an error box that terminates the entire program but is not modal. If it's bad enough to terminate the whole program, i.e. _all_ currently live connections, then there's no point in permitting progress to continue in windows other than the affected one, because all windows are affected anyway. So all previous uses of fatalbox() have become modalfatalbox(), except those which looked to me as if they shouldn't have been fatal in the first place, e.g. lingering pieces of error handling in winnet.c which ought to have had the severity of 'give up on this particular Socket and close it' rather than 'give up on the ENTIRE UNIVERSE'.
2017-11-26 17:43:02 +00:00
int err = p_WSAGetLastError();
plug_closing(s->plug, winsock_error_string(err), err, 0);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else {
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_receive(s->plug, 2, buf, ret);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
}
break;
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
case FD_WRITE:
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 17:09:23 +00:00
{
int bufsize_before, bufsize_after;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
s->writable = true;
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 17:09:23 +00:00
bufsize_before = s->sending_oob + bufchain_size(&s->output_data);
try_send(s);
bufsize_after = s->sending_oob + bufchain_size(&s->output_data);
if (bufsize_after < bufsize_before)
plug_sent(s->plug, bufsize_after);
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
break;
case FD_CLOSE:
Don't forget to read any outstanding data on receipt of FD_CLOSE. Particularly useful for people speaking HTTP, Finger etc over raw connections. [originally from svn r913]
2001-01-29 15:10:56 +00:00
/* Signal a close on the socket. First read any outstanding data. */
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
do {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
ret = p_recv(s->s, buf, sizeof(buf), 0);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (ret < 0) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (err == WSAEWOULDBLOCK)
break;
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_closing(s->plug, winsock_error_string(err), err, 0);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else {
if (ret)
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_receive(s->plug, 0, buf, ret);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
else
windows: Make select_result() return void. Nothing now uses its return value anyway.
2016-06-02 21:38:36 +00:00
plug_closing(s->plug, NULL, 0, 0);
Dave Hinton's modifications to the network layer interface, which should make it possible to add SSL support later. [originally from svn r996]
2001-03-13 10:22:45 +00:00
}
Don't forget to read any outstanding data on receipt of FD_CLOSE. Particularly useful for people speaking HTTP, Finger etc over raw connections. [originally from svn r913]
2001-01-29 15:10:56 +00:00
} while (ret > 0);
windows: Fix control-flow error in select_result(). When making select_result() return void (a2fb1d9), I removed a "return" at the end of the FD_CLOSE case, causing a fallthrough into FD_ACCEPT with hilarious (segfaulting) consequences. Re-instate the "return".
2017-05-17 22:02:14 +00:00
return;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
case FD_ACCEPT:
{
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifdef NO_IPV6
Due to fears that an incompetent WinSock might allow localhost- listening sockets to be talked to by non-local hosts, reinstate the explicit peer address check on connection acceptance. [originally from svn r1306]
2001-10-12 19:32:13 +00:00
struct sockaddr_in isa;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#else
struct sockaddr_storage isa;
#endif
int addrlen = sizeof(isa);
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
SOCKET t; /* socket of connection */
Replace the hacky 'OSSocket' type with a closure. The mechanism for constructing a new connection-type Socket when a listening one receives an incoming connection previously worked by passing a platform-specific 'OSSocket' type to the plug_accepting function, which would then call sk_register to wrap it with a proper Socket instance. This is less flexible than ideal, because it presumes that only one kind of OS object might ever need to be turned into a Socket. So I've replaced OSSocket throughout the code base with a pair of parameters consisting of a function pointer and a context such that passing the latter to the former returns the appropriate Socket; this will permit different classes of listening Socket to pass different function pointers. In deference to the reality that OSSockets tend to be small integers or pointer-sized OS handles, I've made the context parameter an int/pointer union that can hold either of those directly, rather than the usual approach of making it a plain 'void *' and requiring a context structure to be dynamically allocated every time. [originally from svn r10068]
2013-11-17 14:03:55 +00:00
accept_ctx_t actx;
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
memset(&isa, 0, sizeof(isa));
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
err = 0;
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
t = p_accept(s->s,(struct sockaddr *)&isa,&addrlen);
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
if (t == INVALID_SOCKET)
{
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
err = p_WSAGetLastError();
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
if (err == WSATRY_AGAIN)
break;
}
Replace the hacky 'OSSocket' type with a closure. The mechanism for constructing a new connection-type Socket when a listening one receives an incoming connection previously worked by passing a platform-specific 'OSSocket' type to the plug_accepting function, which would then call sk_register to wrap it with a proper Socket instance. This is less flexible than ideal, because it presumes that only one kind of OS object might ever need to be turned into a Socket. So I've replaced OSSocket throughout the code base with a pair of parameters consisting of a function pointer and a context such that passing the latter to the former returns the appropriate Socket; this will permit different classes of listening Socket to pass different function pointers. In deference to the reality that OSSockets tend to be small integers or pointer-sized OS handles, I've made the context parameter an int/pointer union that can hold either of those directly, rather than the usual approach of making it a plain 'void *' and requiring a context structure to be dynamically allocated every time. [originally from svn r10068]
2013-11-17 14:03:55 +00:00
actx.p = (void *)t;
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#ifndef NO_IPV6
if (isa.ss_family == AF_INET &&
s->localhost_only &&
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
!ipv4_is_local_addr(((struct sockaddr_in *)&isa)->sin_addr))
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#else
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
if (s->localhost_only && !ipv4_is_local_addr(isa.sin_addr))
Integrate unfix.org's IPv6 patches up to level 10, with rather a lot of polishing to bring them to what I think should in principle be release quality. Unlike the unfix.org patches themselves, this checkin enables IPv6 by default; if you want to leave it out, you have to build with COMPAT=-DNO_IPV6. I have tested that this compiles on Visual C 7 (so the nightlies _should_ acquire IPv6 support without missing a beat), but since I don't have IPv6 set up myself I haven't actually tested that it _works_. It still seems to make correct IPv4 connections, but that's all I've been able to verify for myself. Further testing is needed. [originally from svn r5047] [this svn revision also touched putty-wishlist]
2004-12-30 16:45:11 +00:00
#endif
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
{
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_closesocket(t); /* dodgy WinSock let nonlocal through */
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 08:29:33 +00:00
} else if (plug_accepting(s->plug, sk_net_accept, actx)) {
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
p_closesocket(t); /* denied or error */
Port forwarding update: local-host-only listening sockets are now done properly (by binding to INADDR_LOOPBACK) instead of hackishly (by binding to INADDR_ANY, looking at the peer address when a connection is accepted, and slamming the connection shut at that point). [originally from svn r1215]
2001-08-27 15:59:37 +00:00
}
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
}
}
/*
* Special error values are returned from sk_namelookup and sk_new
* if there's a problem. These functions extract an error message,
* or return NULL if there's no problem.
*/
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
const char *sk_addr_error(SockAddr *addr)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return addr->error;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static const char *sk_net_socket_error(Socket *sock)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return s->error;
}
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
static SocketPeerInfo *sk_net_peer_info(Socket *sock)
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
#ifdef NO_IPV6
struct sockaddr_in addr;
#else
struct sockaddr_storage addr;
Fix a compile failure with NO_IPV6. A user points out that buf[] in sk_tcp_peer_info is only used in the IPv6 branch of an ifdef, and is declared with a size of INET6_ADDRSTRLEN, which won't be defined in NO_IPV6 mode. So moving the definition inside another IPv6-only ifdef fixes the resulting build failure.
2016-12-11 22:27:40 +00:00
char buf[INET6_ADDRSTRLEN];
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
#endif
int addrlen = sizeof(addr);
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
SocketPeerInfo *pi;
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
if (p_getpeername(s->s, (struct sockaddr *)&addr, &addrlen) < 0)
return NULL;
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
pi = snew(SocketPeerInfo);
pi->addressfamily = ADDRTYPE_UNSPEC;
pi->addr_text = NULL;
pi->port = -1;
pi->log_text = NULL;
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
if (((struct sockaddr *)&addr)->sa_family == AF_INET) {
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
pi->addressfamily = ADDRTYPE_IPV4;
memcpy(pi->addr_bin.ipv4, &((struct sockaddr_in *)&addr)->sin_addr, 4);
pi->port = p_ntohs(((struct sockaddr_in *)&addr)->sin_port);
pi->addr_text = dupstr(
p_inet_ntoa(((struct sockaddr_in *)&addr)->sin_addr));
pi->log_text = dupprintf("%s:%d", pi->addr_text, pi->port);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
#ifndef NO_IPV6
} else if (((struct sockaddr *)&addr)->sa_family == AF_INET6) {
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
pi->addressfamily = ADDRTYPE_IPV6;
memcpy(pi->addr_bin.ipv6,
&((struct sockaddr_in6 *)&addr)->sin6_addr, 16);
pi->port = p_ntohs(((struct sockaddr_in6 *)&addr)->sin6_port);
pi->addr_text = dupstr(
p_inet_ntop(AF_INET6, &((struct sockaddr_in6 *)&addr)->sin6_addr,
buf, sizeof(buf)));
pi->log_text = dupprintf("[%s]:%d", pi->addr_text, pi->port);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
#endif
} else {
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
sfree(pi);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
return NULL;
}
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
return pi;
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void sk_net_set_frozen(Socket *sock, bool is_frozen)
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NetSocket *s = container_of(sock, NetSocket, sock);
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 17:09:23 +00:00
if (s->frozen == is_frozen)
return;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
s->frozen = is_frozen;
After we thaw a frozen socket, we apparently need to restart the WSAAsyncSelect or else Windows loses read events. [originally from svn r5521]
2005-03-18 19:47:21 +00:00
if (!is_frozen) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
do_select(s->s, true);
After we thaw a frozen socket, we apparently need to restart the WSAAsyncSelect or else Windows loses read events. [originally from svn r5521]
2005-03-18 19:47:21 +00:00
if (s->frozen_readable) {
char c;
p_recv(s->s, &c, 1, MSG_PEEK);
}
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
s->frozen_readable = false;
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
}
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
void socket_reselect_all(void)
{
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 08:29:33 +00:00
NetSocket *s;
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
int i;
for (i = 0; (s = index234(sktree, i)) != NULL; i++) {
if (!s->frozen)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
do_select(s->s, true);
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
}
}
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
/*
* For Plink: enumerate all sockets currently active.
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
SOCKET first_socket(int *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 08:29:33 +00:00
NetSocket *s;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
*state = 0;
s = index234(sktree, (*state)++);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return s ? s->s : INVALID_SOCKET;
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
SOCKET next_socket(int *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 08:29:33 +00:00
NetSocket *s = index234(sktree, (*state)++);
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r745]
2000-10-23 11:55:11 +00:00
return s ? s->s : INVALID_SOCKET;
}
More preparatory work: remove the <windows.h> include from lots of source files in which it's no longer required (it was previously required in anything that included <putty.h>, but not any more). Also moved a couple of stray bits of exposed WinSock back into winnet.c (getservbyname from ssh.c and AF_INET from proxy.c). [originally from svn r2160]
2002-10-30 17:57:31 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
extern bool socket_writable(SOCKET skt)
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00: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 08:29:33 +00:00
NetSocket *s = find234(sktree, (void *)skt, cmpforsearch);
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
if (s)
return bufchain_size(&s->output_data) > 0;
else
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false;
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
}
More preparatory work: remove the <windows.h> include from lots of source files in which it's no longer required (it was previously required in anything that included <putty.h>, but not any more). Also moved a couple of stray bits of exposed WinSock back into winnet.c (getservbyname from ssh.c and AF_INET from proxy.c). [originally from svn r2160]
2002-10-30 17:57:31 +00:00
int net_service_lookup(char *service)
{
struct servent *se;
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
se = p_getservbyname(service, NULL);
More preparatory work: remove the <windows.h> include from lots of source files in which it's no longer required (it was previously required in anything that included <putty.h>, but not any more). Also moved a couple of stray bits of exposed WinSock back into winnet.c (getservbyname from ssh.c and AF_INET from proxy.c). [originally from svn r2160]
2002-10-30 17:57:31 +00:00
if (se != NULL)
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
return p_ntohs(se->s_port);
More preparatory work: remove the <windows.h> include from lots of source files in which it's no longer required (it was previously required in anything that included <putty.h>, but not any more). Also moved a couple of stray bits of exposed WinSock back into winnet.c (getservbyname from ssh.c and AF_INET from proxy.c). [originally from svn r2160]
2002-10-30 17:57:31 +00:00
else
return 0;
}
RJK's patch to enable PuTTY's X forwarding to connect to local X servers using Unix sockets (on Unix only, obviously!). [originally from svn r4263]
2004-05-31 14:01:52 +00:00
Since r8305, Unix PuTTY has always "upgraded" an X11 display like "localhost:0" to a Unix-domain socket. This typically works fine when PuTTY is run on the same machine as the X server, but it's broken multi-hop X forwarding through OpenSSH; when OpenSSH creates a proxy X server "localhost:10", it only listens on TCP, not on a Unix-domain socket. Instead, when deciding on the details of the display, we actively probe to see if there's a Unix-domain socket we can use instead, and only use it if it's there, falling back to the specified IP "localhost" if not. Independently, when looking for local auth details in Xauthority for a "localhost" TCP display, we prefer a matching Unix-domain entry, but will fall back to an IP "localhost" entry (which would be unusual, but we don't trust a Windows X server not to do it) -- this is a generalisation of the special case added in r2538 (but removed in r8305, as the automatic upgrade masked the need for it). (This is now done in platform-independent code, so a side-effect is that get_hostname() is now part of the networking abstraction on all platforms.) [originally from svn r8462] [r2538 == fda998324345ba50a913655754303ce8f0a4cfde] [r8305 == ca6fc3a4daf51166a15693feffc967bee9e3f59a]
2009-02-24 01:01:23 +00:00
char *get_hostname(void)
{
int len = 128;
char *hostname = NULL;
do {
len *= 2;
hostname = sresize(hostname, len, char);
if (p_gethostname(hostname, len) < 0) {
sfree(hostname);
hostname = NULL;
break;
}
Fix the _rest_ of the Windows compile warnings. (ahem) [originally from svn r9201]
2011-07-12 18:13:33 +00:00
} while (strlen(hostname) >= (size_t)(len-1));
Since r8305, Unix PuTTY has always "upgraded" an X11 display like "localhost:0" to a Unix-domain socket. This typically works fine when PuTTY is run on the same machine as the X server, but it's broken multi-hop X forwarding through OpenSSH; when OpenSSH creates a proxy X server "localhost:10", it only listens on TCP, not on a Unix-domain socket. Instead, when deciding on the details of the display, we actively probe to see if there's a Unix-domain socket we can use instead, and only use it if it's there, falling back to the specified IP "localhost" if not. Independently, when looking for local auth details in Xauthority for a "localhost" TCP display, we prefer a matching Unix-domain entry, but will fall back to an IP "localhost" entry (which would be unusual, but we don't trust a Windows X server not to do it) -- this is a generalisation of the special case added in r2538 (but removed in r8305, as the automatic upgrade masked the need for it). (This is now done in platform-independent code, so a side-effect is that get_hostname() is now part of the networking abstraction on all platforms.) [originally from svn r8462] [r2538 == fda998324345ba50a913655754303ce8f0a4cfde] [r8305 == ca6fc3a4daf51166a15693feffc967bee9e3f59a]
2009-02-24 01:01:23 +00:00
return hostname;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *platform_get_x11_unix_address(const char *display, int displaynum,
OS X Leopard, it turns out, has a new and exciting strategy for addressing X displays. Update PuTTY's display-name-to-Unix-socket- path translation code to cope with it, thus causing X forwarding to start working again on Leopard. [originally from svn r8020]
2008-05-28 19:23:57 +00:00
char **canonicalname)
RJK's patch to enable PuTTY's X forwarding to connect to local X servers using Unix sockets (on Unix only, obviously!). [originally from svn r4263]
2004-05-31 14:01:52 +00:00
{
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
SockAddr *ret = snew(SockAddr);
memset(ret, 0, sizeof(SockAddr));
RJK's patch to enable PuTTY's X forwarding to connect to local X servers using Unix sockets (on Unix only, obviously!). [originally from svn r4263]
2004-05-31 14:01:52 +00:00
ret->error = "unix sockets not supported on this platform";
Implement sk_addr_dup(). [originally from svn r8294]
2008-11-08 16:58:55 +00:00
ret->refcount = 1;
RJK's patch to enable PuTTY's X forwarding to connect to local X servers using Unix sockets (on Unix only, obviously!). [originally from svn r4263]
2004-05-31 14:01:52 +00:00
return ret;
}
Reference in New Issue Copy Permalink