6 Aug
2013
6 Aug
'13
2:41 p.m.
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?
3 Feb
3 Feb
2:50 p.m.
New subject: rmate stopped working with alpha.9459
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.
4 Feb
4 Feb
2:49 a.m.
New subject: rmate stopped working with alpha.9459
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).
6 Feb
6 Feb
11:51 a.m.
New subject: rmate stopped working with alpha.9459
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 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.
8 Feb
8 Feb
4:19 a.m.
New subject: rmate stopped working with alpha.9459
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).
10 Feb
10 Feb
10:49 a.m.
New subject: rmate stopped working with alpha.9459
No worries, Allan. Thank you for the update and clarification.
On Feb 8, 2014, at 4:19 AM, "Allan Odgaard" <mailinglist(a)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).
...
2414
days inactive
2602
days old
5 comments
4 participants
participants (4)
-
Allan Odgaard -
Brian Powell -
tmanhollan -
Tony Manhollan