Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
17 check-ins using file config.c version 7323582a73
|
2013-11-17
| ||
| 08:03 | Clean up the semantics of the ssh_rportfwd structure. It's now indexed by source hostname as well as source port (so that separate requests for the server to listen on addr1:1234 and addr2:1234 can be disambiguated), and also its destination host name is dynamically allocated rather than a fixed-size buffer. check-in: 87da2eda2d user: simon tags: trunk | |
| 08:03 | Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. check-in: f163f89666 user: simon tags: trunk | |
|
2013-11-11
| ||
| 17:01 | Replace GetQueueStatus with PeekMessage(PM_NOREMOVE). A couple of users report that my recent reworking of the Windows top-level message loop has led to messages occasionally being lost, and MsgWaitForMultipleObjects blocking when it ought to have been called with a zero timeout. I haven't been able to reproduce this myself, but according to one reporter, PeekMessage(PM_NOREMOVE) is effective at checking for a non-empty message queue in a way that GetQueueStatus is not. Switch to using that instead. Thanks to Eric Flumerfelt for debugging and testing help. check-in: 0eada414dc user: simon tags: trunk | |
|
2013-10-26
| ||
| 09:00 | Fix build failures on Ubuntu 13.10. Automake now insists that we run AM_PROG_AR if we're going to build a library, and AM_PROG_CC_C_O if we're going to build anything with extra compile options. Those extra macros seem harmless in previous versions of automake. check-in: 4dc573c397 user: simon tags: trunk | |
|
2013-10-25
| ||
| 12:44 | Avoid leaving unread Windows messages in the queue. Jochen Erwied points out that once you've used PeekMessage to remove _one_ message from the message queue, MsgWaitForMultipleObjects will consider the whole queue to have been 'read', or at least looked at and deemed uninteresting, and so it will block until a further message comes in. Hence, my change in r10040 which stops us from looping on PeekMessage until the queue is empty has the effect of causing the rest of the message queue not to be acted on until a new message comes in to unblock it. Fix by checking if the queue is nonempty in advance of calling MsgWaitForMultipleObjects, and if so, giving it a zero timeout just as we do if there's a pending toplevel callback. check-in: bb372d7013 user: simon tags: trunk | |
|
2013-10-09
| ||
| 13:38 | random_ref() should always increment the reference count. No current PuTTY utility was calling random_ref more than once per run (ssh.c and the two main PuTTYgen programs call it once each), but if one ever does (or if derived code does), it will want the reference count to actually work sensibly. check-in: 8a375b13f8 user: simon tags: trunk | |
| 13:36 | 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. check-in: b4dcae4371 user: simon tags: trunk | |
|
2013-09-23
| ||
| 09:35 | Fix cut-and-paste errors in nonfatal() implementations. Unix GUI programs should not say 'Fatal Error' in the message box title, and Plink should not destroy its logging context as a side effect of printing a non-fatal error. Both appear to have been due to inattentive cut and paste from the pre-existing fatal error functions. check-in: 3a81deedf0 user: simon tags: trunk | |
|
2013-09-15
| ||
| 09:40 | Oops! Remove a tight-looping diagnostic. I temporarily applied it as a means of testing the revised event loops in r10040, and accidentally folded it into my final commit instead of backing it out. Ahem. check-in: 5bed7cc5ee user: simon tags: trunk | |
| 09:05 | Remove the timed part of the terminal paste mechanism. In r10020 I carefully reimplemented using timing.c and callback.c the same policy for large pastes that the previous code appeared to be implementing ad-hoc, which included a 450ms delay between sending successive lines of pasted text if no visible acknowledgment of the just-sent line (in the form of a \n or \r) came back from the application. However, it turns out that that *wasn't* what the old code was doing. It *would* have done that, but for the bug that it never actually set the 'last_paste' variable, and never has done since it was first introduced way back in r516! So the policy I thought had been in force forever has in fact only been in force since I unwittingly fixed that bug in r10020 - and it turns out to be a bad idea, breaking pastes into vi in particular. So I've removed the timed paste code completely, on the basis that it's never actually worked and nobody seems to have been unhappy about that. Now we still break large pastes into separate lines and send them in successive top-level callbacks, and the user can still press a key to interrupt a paste if they manage to catch it still going on, but there's no attempted *delay* any more. (It's possible that what I *really* ought to be doing is calling back->sendbuffer() to see whether the backend is consuming the data pasted so far, and if not, deferring the rest of the paste until the send buffer becomes smaller. Then we could have pasting be delayed by back-pressure from the recipient, and still manually interruptible during that delay, but not have it delayed by anything else. But what we have here should at least manage to be equivalent to the *actual* rather than the intended old policy.) check-in: 926b4f918a user: simon tags: trunk | |
| 09:05 | Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. check-in: 36d3c24f08 user: simon tags: trunk | |
|
2013-09-08
| ||
| 08:20 | Handle socket errors on half-open channels. Anthony Ho reports that this can occur naturally in some situation involving Windows 8 + IE 11 and dynamic port forwarding: apparently we get through the SOCKS negotiation, send our CHANNEL_OPEN, and then *immediately* suffer a local WSAECONNABORTED error before the server has sent back its OPEN_CONFIRMATION or OPEN_FAILURE. In this situation ssh2_channel_check_close was failing to notice that the channel didn't yet have a valid server id, and sending out a CHANNEL_CLOSE anyway containing 32 bits of uninitialised nonsense. We now handle this by turning our half-open CHAN_SOCKDATA_DORMANT into a half-open CHAN_ZOMBIE, which means in turn that our handler functions for OPEN_CONFIRMATION and OPEN_FAILURE have to recognise and handle that case, the former by immediately initiating channel closure once we _do_ have the channel's server id to do it with. check-in: 1593971ebd user: simon tags: trunk | |
| 02:14 | Pass an error message through to sshfwd_unclean_close. We have access to one at every call site, so there's really no reason not to send it through to ssh.c to be logged. check-in: 36349ac57c user: simon tags: trunk | |
|
2013-09-07
| ||
| 11:15 | Fix SSH2_MSG_CHANNEL_EXTENDED_DATA in logparse. It looks as if it's never worked at all: it had a spurious second printf, it completely forgot to allow for the uint32 type code that SSH2_MSG_CHANNEL_DATA doesn't have, it accessed the channel state's sequence number fields in a way that made no sense and didn't match the rest of the program, *and* it misinvoked the file opening API. I must have never had an occasion to test it. check-in: a938a3ac2e user: simon tags: trunk | |
| 11:15 | Make logparse handle completely bogus channel numbers. Previously it would throw a bunch of Perl undefined-variable-usage warnings; now it cleanly detects the problem, dumps as much of the message as it still reasonably can, and doesn't update any channel states. check-in: 21376cee1b user: simon tags: trunk | |
|
2013-08-26
| ||
| 06:55 | Fix free of an uninitialised pointer. CHAN_AGENT channels need c->u.a.message to be either NULL or valid dynamically allocated memory, because it'll be freed by ssh_channel_destroy. This bug triggers if an agent forwarding channel is opened and closed without having sent any queries. check-in: 7b9042322c user: simon tags: trunk | |
|
2013-08-22
| ||
| 12:45 | Fix handling of IPv6 dynamic forwardings. During the Conf revamp, I changed the internal representation of dynamic forwardings so that they were stored as the conceptually sensible L12345=D rather than the old D12345, and added compensation code to translate to the latter form for backwards-compatible data storage and for OpenSSH-harmonised GUI display. Unfortunately I forgot that keys in the forwarding data can also prefix the L/R with a character indicating IPv4/IPv6, and my translations didn't take account of that possibility. Fix them. check-in: 2ca638ec2c user: simon tags: trunk | |