PuTTY bug portfwd-corrupt
Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Pre-release
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
summary: Reports of port forwarding corruption
class: bug: This is clearly an actual problem we want fixed.
priority: historic: This is an old bug report that we think is either fixed without noticing, or confined to old systems, or too vague.
present-in: 0.53b 2003-06-29 0.54 0.58
We've had several reports of data corruption in port-forwarded connections.
Some (possibly all) of these are due to data loss. The PuTTY client (as
opposed to others) appears to be correlated with the data loss, although
it's unclear whether the data is actually being lost before or after PuTTY
is dealing with it.
Problems have been reported with both directions of tunneling, both directions
of data transfer, and both SSH protocols (SSH-1 and SSH-2).
Update, 2005-06-15: I (JTN) have reproduced loss of trailing
data with a remote-to-local SSH-2 port forwarding, where a burst data
is sent from remote to local followed immediately by EOF. I suspect
that PuTTY's lack of support for
half-closed connections is to blame in at least this case.
Update, 2011-09-13: I (SGT) have just (hopefully) fixed the
half-closed issue, so perhaps that will be improved now.
The reports below may correspond to several different bugs, as a range of
symptoms are reported.
2821c598.0306222343.8ea8a79@posting.google.com
(also 3F031766.BC09B85A@uni-mb.si
)
Server: SSH-1.5-OSU_1.4alpha3
on OpenVMS V7.3-1
Protocol: SSH-1
local-to-remote tunnel of POP3/SMTP
Problems with sending messages (dialogue or attachments corrupted)
Apparently the first port-forwarded connection in a session will lose
some quantity of the data sent from PuTTY to the server from the start
of the connection.
SSH packet log makes it look like data is being lost by the server (or
possibly after PuTTY does the logging), but other clients (e.g., OpenSSH,
recent F-Secure) don't show this behaviour.
20040209143157.89534.qmail@web14102.mail.yahoo.com
0.53b + (2004-02-02?) + (2004-02-09?)
Various Red Hat 7.x servers. One is SSH-1.99-OpenSSH_3.1p1.
Protocol: SSH-1 and SSH-2
HTTP tunnel (local-to-remote?)
Result of GET truncated (incomplete)?
Looks to be correlated with slow consumer (web browser)
Same person has same problem with TeraTerm SSH ("Error 10058: Cannot
send after socket shutdown.").
PuTTY sometimes hangs?
Includes SSH packet log; this shows SSH-2 local-to-remote forwarding, with PuTTY apparently receiving all the data. Maybe it fails to pass it on to the HTTP client?
002101c45ee8$ff761990$6801a8c0@carmani600m
"SMTP tunneling corrupts attachments"
It looks like something other than PuTTY was modifying the attachments
(possibly in addition to PuTTY), so we aren't able to extract useful
information from this report.
1090249727.4682.55.camel@oberon.tremagi.org.uk
Win2KSP3 + PuTTY 0.54 (and 0.53b)
Fedora Core 2 (unpatched) + OpenSSH (openssh-server-3.6.1p2-34)
Remote tunnel for "yum" over HTTP: "yum" pulling data
(i.e. outbound from PuTTY)
D9304F864F1759059287F365@[192.168.0.10]
0.53b, 0.58, 2005-06-12:r5952 to OpenSSH 3.9p1
Using SOCKS dynamic forwarding to forward FTP, upload corrupts files
(resulting file is shorter than expected); FTP progress bar goes suspiciously
fast for first 1-200k of a 500k file
Other SOCKS servers behave fine; `get' is fine; static port
forwarding is fine
6.0.0.22.2.20050614193231.01fda408@195.70.37.56
0.58 to Debian OpenSSH
Remote-to-local tunnel for JetDirect (local printer port 9100)
Files under 8k: OK
Files over 8k: all data in PuTTY's log, but not all gets to the
printer
Logs available
SGT, 2024-11-17: classifying this bug as historic. It's too
vague to investigate properly: just "corruption" is unclear about
exactly what happens. The only known problem was truncation
of the end of the data in cases of unidirectional EOF, which as far as
we know was fixed in 2011 by changes to EOF handling.
If you want to comment on this web site, see the
Feedback page.
(last revision of this bug record was at 2024-11-17 14:53:03 +0000)