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.