Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

[0.63-t017] Tunnel settings don't stick between sessions #81

Open
Viper007Bond opened this Issue · 8 comments

3 participants

@Viper007Bond

I had been using 0.62-t013 with tunnel (proxy) functionality working fine. Updated to 0.63-t017 and it doesn't work now ("The proxy server is refusing connections").

I can resolve the issue by going to Settings -> Connection -> SSH -> Tunnel, removing the forwarded port, and then re-adding it (8080, dynamic, IPv4).

One thing to note that is when I remove the port, it fills in the fields with the data of the port I removed. This is normal. However instead of filling in the source port field with "8080", it puts "L8080" in there and the bottom setting to auto instead of IPv4. This seems to me like it's having trouble parsing the value from the saved configuration.

@FauxFaux
Owner

This is an upstream bug. This patch should fix it, but I'll submit it upstream and see if they have a neater fix.

Thanks.

@FauxFaux FauxFaux closed this
@Viper007Bond

I'm not sure that this is actually fixed. I'm using 0.63-t018 and am still having this issue.

Are you sure this is about old-style entries? Even if I delete the port, re-add it, and then hit save, I run into the issue the next time I load the session. If it was a matter of importing from old saves only, then creating the forward from scratch would solve it which it doesn't.

This is the entry in the configuration file:

PortForwardings\DL8080=\

It seems to be an issue loading the value from any saved configuration.

@Viper007Bond

Installing an older version of PuTTYTray and then writing out the saved configuration seems to have done the trick. Upgraded again and it's working fine now (4D8080).

@FauxFaux
Owner

Oh, file settings. I guess I should have a look at that, then.

@FauxFaux FauxFaux reopened this
@Viper007Bond

I don't think this is specifically file session related. I normally use sessions stored in my registry but I was playing around with ones stored on the filesystem in an attempt to debug it, as well as to view the raw session data.

It just seems to still have trouble parsing DL8080 even in 0.63-t018 where it is supposed to be fixed.

@FauxFaux FauxFaux referenced this issue from a commit
@FauxFaux Revert "GH-81: attempt to accept old-style dymanic port entries"
This reverts commit 6a87693.

A more complete fix has appeared in upstream as
f57ca03: "Fix handling of IPv6 dynamic
forwardings."
f0529a6
@FauxFaux FauxFaux referenced this issue from a commit
simon GH-81: 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.

git-svn-id: svn://svn.tartarus.org/sgt/putty@10031 cda61777-01e9-0310-a592-d414129be87e
b1a2e77
@bastoooun

Hello, I'm having the same issue as described above ...
This bug is not present in the 0.62 version, only on 0.63 beta

@Viper007Bond

I worked around the issue by deleting the profile and creating a new one, but it should be fixed in next release presumably based on the above commits.

@Viper007Bond

Actually, you can save your session to a file-based one and then close PuTTYTray. Then you can open it up in a text editor and change DL8080 to 4D8080. Then open PuTTYTray again, load it from a file, and then save it back to the registry. Or just keep it as a file-based session.

Either way changing the configuration from "DL" to "4D" will fix the issue until a new release comes out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.