Allan,
I solved the problem. In my Mac-side SSH configuration (OS X 10.8.4), I had
AddressFamily inet
listed in my .ssh/config. This limits ssh connections to using IPv4. If I disable that, then it works fine. For some reason the change to allowing IPv6 in TextMate in conjunction with the above openssh option fails. Disabling the AddressFamily line makes it work.
Related, I had "disabled" IPv6 on my Mac networking by setting it to "local link-only". It still works with that, but I get an error message on the server side from rmate:
setsockopt TCP_NODELAY: Invalid argument
This error goes away by changing IPv6 to "Automatic" in the Mac network settings.
So, it appears that the change to allowing for IPv6 actually requires it to be present.
Cheers, Brian
TextMate did switch to using IPv6 API instead of IPv4, but for me the above works w/o issues, I tried with TextMate listening for both local and remote clients, tried setting up tunnel via command line and ~/.ssh/config, all cases for me was a success.
This is on OS X 10.8.4 using OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012 (the one in /usr/bin) and network has an IPv4 IP (obtained via DHCP) but no IPv6 IP (config set to ?automitcally? which gives me no values for the IPv6 things in network settings).
Any mismatch in environment?
I just discovered the same problem in alpha.9503. For me, IPv6 is configured in its default (automatic) state on both sides of the connection. The problem seems to be, as Brian noted, that IPv4 alone isn't working. In my case, the RemoteForward directive used the numeric IPv4 address, as in the example in the help document referenced by the help button on the "Terminal" preferences pane:
RemoteForward 52698 127.0.0.1:52698
This had the effect of restricting operation to IPv4, just as the AddressFamily directive did for Brian. Replacing 127.0.0.1 with localhost seems to circumvent the problem when IPv6 is properly configured on the local and remote sides and the remote side resolves localhost to the IPv6 address.
Seems like it's unintended behavior for IPv4 not to work, but I'd suggest at least changing the help document to refer to localhost instead of 127.0.0.1 as that would avoid the problem for MOST people, but also note the reliance on its resolving to the IPv6 address if you're unable to make it work for both address families.
My environment specs: Mac OS 10.8.5 /usr/bin/ssh -V = OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013. TextMate is 2.0-alpha.9503
Brian Powell-4 wrote
I solved the problem. In my Mac-side SSH configuration (OS X 10.8.4), I had
AddressFamily inet
listed in my .ssh/config. This limits ssh connections to using IPv4. If I disable that, then it works fine. For some reason the change to allowing IPv6 in TextMate in conjunction with the above openssh option fails. Disabling the AddressFamily line makes it work.
TextMate did switch to using IPv6 API instead of IPv4, but for me the above works w/o issues, I tried with TextMate listening for both local and remote clients, tried setting up tunnel via command line and ~/.ssh/config, all cases for me was a success.
This is on OS X 10.8.4 using OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012 (the one in /usr/bin) and network has an IPv4 IP (obtained via DHCP) but no IPv6 IP (config set to ?automitcally? which gives me no values for the IPv6 things in network settings).
Any mismatch in environment?
-- View this message in context: http://textmate.1073791.n5.nabble.com/rmate-stopped-working-with-alpha-9459-... Sent from the textmate users mailing list archive at Nabble.com.
On 4 Feb 2014, at 2:50, tmanhollan wrote:
I just discovered the same problem in alpha.9503. For me, IPv6 is configured in its default (automatic) state on both sides of the connection […]
And you were using 127.0.0.1 and had no IPv4 connection setup between the two machines?
[…] I'd suggest at least changing the help document to refer to localhost instead of 127.0.0.1 as that would avoid the problem for MOST people
Using ‘localhost’ was not working for a lot of people.
I don’t know why it was failing and it’s not failing for me, but using the IPv4 IP made it work, and that is why we changed the documentation. Since then, only you and Brian have reported issues (with ‘127.0.0.1’) and in both cases it sounds like the reason is lack of IPv4 (in Brian’s case it was disabled via an SSH setting).
I just discovered the same problem in alpha.9503. For me, IPv6 is configured in its default (automatic) state on both sides of the connection […]
And you were using 127.0.0.1 and had no IPv4 connection setup between the two machines?
No, I'm sorry, the connection between the two machines is IPv4; I only mentioned my IPv6 config to indicate that it does not deviate from the default configuration. I should have given a more complete description of my setup:
TextMate and ssh config set exactly as the examples in the documentation. Local (TextMate machine) IPv4 address is DHCP-assigned (e.g. 10.0.1.100). Server's IPv4 address manually assigned (e.g. 10.0.1.8). No IPv6 addresses configured on anything other than each device having the default IPv6 settings (i.e. stock OS settings) on the loopback interface.
I don’t know why it was failing and it’s not failing for me, but using the IPv4 IP made it work, and that is why we changed the documentation. Since then, only you and Brian have reported issues (with ‘127.0.0.1’) and in both cases it sounds like the reason is lack of IPv4 (in Brian’s case it was disabled via an SSH setting).
I think in both cases it's lack of IPv6, not IPv4, unless I'm misinterpreting something. In Brian's case it was IPv6 that was disabled via the AddressFamily setting (from the man page: "valid arguments are ``any'', ``inet'' (use IPv4 only), or ``inet6'' (use IPv6 only).") Brian's setting "inet" would have forced connecting using only IPv4. Removing the directive presumably is equivalent to "any", so my assumption reading his description of the problem was that it ONLY worked for him when IPv6 was available. That's what lead me to try changing the address in the config--initially the setup described above worked, but after an update (I'm not sure which one), rmate started producing the same error Brian described. My guess is that the original IPv4 numeric address similarly forced the connection to IPv4, but switching to the hostname, which resolved to both v4 and v6 addresses allowed it to work (ultimately because it was communicating via IPv6).
That said, I did a little more troubleshooting. I did a packet capture of several communication tests (using telnet to try to reach TextMate on port 52698). I tested over the ssh connection forwarded back as well as directly from the local client (taking remote forwarding out of the picture), and each test involving the IPv4 address failed, while those involving the IPv6 address succeeded. Those using the hostname "localhost" succeeded only when it resolved to the IPv6 address; removing the IPv6 address from /etc/hosts caused it to stop working. For IPv4, the packet trace shows the initial connection packet, an acknowledgment, and a connection reset with no further communication. I also have a clean install of Mountain Lion in a virtual machine that I use for testing. I put TextMate on it and ran the same tests there--fresh OS and TextMate install, default configurations, same behavior, so it is repeatable.
It seems to me that TextMate is only listening on IPv6 now. But I'm not familiar with the inner workings of all that nor with the TextMate source code, so I'm only basing that on the observations I've shared here. If I can provide any additional troubleshooting information to you, let me know what you need--I can send you the packet trace logs or if you have any suggestions on what else to look for, I can try out some other things. It is working for me now, just not as described in the documentation, so I'm not suggesting it's completely broken. But I do think there's something wrong with IPv4 and if you want to get to the bottom of it, I'll be happy to help out.
On 6 Feb 2014, at 23:51, Tony Manhollan wrote:
[…] It seems to me that TextMate is only listening on IPv6 now […]
Yes, sorry, I think I confused things here.
You are right that the help document is wrong in that the help document says “127.0.0.1” when it should say “localhost”. We updated the blog post and documentation on GitHub, and I thought it was the update you referred to (as I had forgotten about the copy of the blog post embedded in TextMate.app). I have now updated the embedded document as well.
So just to emphasize, localhost *is* the correct value to use (despite my previous reply) and the reason is that TextMate (now) only listens on IPv6 (we can’t listen on IPv4 without creating an extra socket observer, which I deemed not worth it).
And thanks for clarifying Brian’s issue, I never realized what the exact problem was, but yes, you’re right, he had disabled IPv6 so SSH was unable to locally connect to TextMate (and forward the connection).
No worries, Allan. Thank you for the update and clarification.
On Feb 8, 2014, at 4:19 AM, "Allan Odgaard" mailinglist@textmate.org wrote:
...
Yes, sorry, I think I confused things here.
...
So just to emphasize, localhost *is* the correct value to use (despite my previous reply) and the reason is that TextMate (now) only listens on IPv6 (we can’t listen on IPv4 without creating an extra socket observer, which I deemed not worth it).
...
-
Allan Odgaard -
Brian Powell -
tmanhollan -
Tony Manhollan