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.
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.
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.
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
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]
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]
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]
It was only actually used in X11 and port forwarding, to find internal
state structures given only the Socket that ssh.c held. So now that
that lookup has been reworked to be the sensible way round,
private_ptr is no longer used for anything and can be removed.
[originally from svn r10075]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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 == fda9983243]
[r8305 == ca6fc3a4da]
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]
"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]
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]
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]
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 == 57a763b0ec]
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]
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]
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]
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]
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]
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]
long last to move all the Windows-specific source files down into a
`windows' subdirectory. Only platform-specific files remain at the
top level. With any luck this will act as a hint to anyone still
contemplating sending us a Windows-centric patch...
[originally from svn r4792]
