On Windows NT, 2000, or XP, the registry key to create or change is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\TcpMaxDataRetransmissions
and it must be of type DWORD. (See MS Knowledge Base articles 120642
and 314053
for more information.) Set the key's value to something like 10. This will cause Windows to try harder to keep connections alive instead of abandoning them.
A.7.12 When I cat a binary file, I get ‘PuTTYPuTTYPuTTY’ on my command line. Don't do that, then.
This is designed behaviour; when PuTTY receives the character Control-E from the remote server, it interprets it as a request to identify itself, and so it sends back the string ‘PuTTY’ as if that string had been entered at the keyboard. Control-E should only be sent by programs that are prepared to deal with the response. Writing a binary file to your terminal is likely to output many Control-E characters, and cause this behaviour. Don't do it. It's a bad plan.
To mitigate the effects, you could configure the answerback string to be empty (see section 4.3.7
); but writing binary files to your terminal is likely to cause various other unpleasant behaviour, so this is only a small remedy. A.7.13 When I cat a binary file, my window title changes to a nonsense string. Don't do that, then.
It is designed behaviour that PuTTY should have the ability to adjust the window title on instructions from the server. Normally the control sequence that does this should only be sent deliberately, by programs that know what they are doing and intend to put meaningful text in the window title. Writing a binary file to your terminal runs the risk of sending the same control sequence by accident, and cause unexpected changes in the window title. Don't do it.
A.7.14 My keyboard stops working once PuTTY displays the password prompt. No, it doesn't. PuTTY just doesn't display the password you type, so that someone looking at your screen can't see what it is.
Unlike the Windows login prompts, PuTTY doesn't display the password as a row of asterisks either. This is so that someone looking at your screen can't even tell how long your password is, which might be valuable information.
A.7.15 One or more function keys don't do what I expected in a server-side application. If you've already tried all the relevant options in the PuTTY Keyboard panel, you may need to mail the PuTTY maintainers and ask.
It is not usually helpful just to tell us which application, which server operating system, and which key isn't working; in order to replicate the problem we would need to have a copy of every operating system, and every application, that anyone has ever complained about.
PuTTY responds to function key presses by sending a sequence of control characters to the server. If a function key isn't doing what you expect, it's likely that the character sequence your application is expecting to receive is not the same as the one PuTTY is sending. Therefore what we really need to know is what sequence the application is expecting.
The simplest way to investigate this is to find some other terminal environment, in which that function key does work; and then investigate what sequence the function key is sending in that situation. One reasonably easy way to do this on a Unix system is to type the command cat, and then press the function key. This is likely to produce output of the form ^[[11~. You can also do this in PuTTY, to find out what sequence the function key is producing in that. Then you can mail the PuTTY maintainers and tell us ‘I wanted the F1 key to send ^[[11~, but instead it's sending ^[OP, can this be done?’, or something similar.