New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing IPv6-support #81

Open
skibbi opened this Issue Mar 25, 2012 · 87 comments

Comments

Projects
None yet
@skibbi

skibbi commented Mar 25, 2012

Mosh does not seem to support IPv6. When specifying a hostname with both IPv4 and IPv6, an IPv4-connection is used. Specifying an IPv6-address results in:

/usr/bin/mosh: Could not resolve hostname 2a01:238:42a0:a200:e709:8d1c:581d:6e5a
ssh_exchange_identification: Connection closed by remote host
/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).

@keithw

This comment has been minimized.

Member

keithw commented Mar 26, 2012

Yes, the mosh protocol is IPv4 for now. I'm happy to add IPv6 support if I can test it; we need to make sure that (1) IPv4-to-IPv6-to-IPv4 roaming works correctly, and (2) mosh behaves sensibly in common situations.

For example, if you're at your office talking to the mosh-server over IPv6, and then you roam to a cellular connection that only passes IPv4, that needs to work correctly. Which means we probably need to pass both addresses to mosh-client on startup, which is a little tricky -- since right now we only get one address (the one we connect the SSH connection to).

Looking up and passing both addresses is (in theory) fine, but what happens if the server is multihomed and the same A record advertises 4 IPv4 addresses, and an AAAA record advertises 4 IPv6 addresses? We can't just pick one of each at random because we don't know they're the same server!

@stapelberg

This comment has been minimized.

stapelberg commented Mar 27, 2012

I have machines which are accessible via IPv4 only, IPv6 only, and which are dual-homed. I frequently roam between IPv6 and non-IPv6-networks. I started implementing a bit of IPv6 support already, but it’s not working completely. I will look into it in more detail soon.

@stapelberg

This comment has been minimized.

stapelberg commented Apr 3, 2012

I pushed a branch with preliminary IPv6 support here:
https://github.com/mstap/mosh/commit/e06321f0056e9d943d2ebcc3f9c33effe897d9c4
As the commit message mentions, this doesn’t address all the points yet.

@schinckel

This comment has been minimized.

schinckel commented Apr 10, 2012

When I try to use the indicated fork, I get the error:

Can't locate Net/INET6Glue.pm in @INC (@INC contains: /Library/Perl/5.12/darwin-thread-multi-2level /Library/Perl/5.12 /Network/Library/Perl/5.12/darwin-thread-multi-2level /Network/Library/Perl/5.12 /Library/Perl/Updates/5.12.3 /System/Library/Perl/5.12/darwin-thread-multi-2level /System/Library/Perl/5.12 /System/Library/Perl/Extras/5.12/darwin-thread-multi-2level /System/Library/Perl/Extras/5.12 .) at /usr/local/bin/mosh line 25.
BEGIN failed--compilation aborted at /usr/local/bin/mosh line 25.
@stapelberg

This comment has been minimized.

@blblack

This comment has been minimized.

Contributor

blblack commented Apr 12, 2012

Looking up and passing both addresses is (in theory) fine, but what happens if the server is multihomed and the same A record advertises 4 IPv4 addresses, and an AAAA record advertises 4 IPv6 addresses? We can't just pick one of each at random because we don't know they're the same server!

IMHO, that's just an even further corner case problem. I'd argue it's mostly irrelevant in the real world. Far more important just to get IPv6 support working sanely at all. Let someone else file an issue about their 4xIPv4 + 4xIPv6 destination hostname later :).

For the most part, if you're opening a shell to a remote host, it's a specific host. For example, I might have a hostname in my DNS called "lb" which maps to 12x IPv4 and 6x IPv6 addresses for a pool of front-end loadbalancers for HTTP. But when I'm logging in over ssh or mosh for diagnostic troubleshooting I don't use that hostname. I use one of the several hostnames that map directly to the underlying, specific machines.

Just be pragmatic: support basic v6+v4 like all software should these days, and ignore the v4:v6 mapping problem on reconnect for now, and I bet nobody ever complains. If they do, it might be better to solve this problem by probing anyways (the client can probe the list of possible/reachable IPs and check to see if the correct port responds with the correct response to a challenge, with the challenge and answer pre-shared back when the link was last active).

@keithw

This comment has been minimized.

Member

keithw commented Apr 13, 2012

Unfortunately we do have users who use round-robin DNS entries and I don't really want to break mosh for them.

@jgater

This comment has been minimized.

jgater commented Apr 16, 2012

Looking up and passing both addresses is (in theory) fine, but what happens if the server is multihomed and the same A record advertises 4 IPv4 addresses, and an AAAA record advertises 4 IPv6 addresses? We can't just pick one of each at random because we don't know they're the same server!

While being able to roam from ipv4 to ipv6 and back again would be useful, I'm wondering if that might be gilding the lily initially.

In my own case, I have a bunch of linux servers behind a firewall; our public IPv4 address space is very limited, so rather than assign each server a specific port for SSH (and having to note which server has which) I give them AAAA records on the public DNS, and access them directly via IPv6. Then to get in, I can just ssh directly to their dns name (obviously the IPv6 firewall only allows ssh traffic, and I use key-auth for ssh). Most don't even have A records. In the event IPv6 isn't available when roaming, I can either fire up my own IPv6 tunnel to a broker, or as last resort go via IPv4 vpn and get in via internal DNS records over IPv4. In either case, transparent reconnect when roaming probably isn't going to work anyway, as the tunnel has to be up first. I wouldn't be surprised if IPv4 address limitations isn't a standard reason for using IPv6 for SSH in the first place.

I'm thinking a relatively simple implementation for a first step would be to add a flag for IPv6 connections; if given, then mosh only attempts to connect via AAAA record, and ignores A/CNAME records. In the event IPv6 isn't available after roaming to a new connection, or resuming from sleep etc, then the connection is abandoned, though if it is then resume as per normal. You wouldn't need to break or alter IPv4 connectivity for round-robin users, but will still allow people wanting to use IPv6 to take advantage of the local-buffer, auto-resume, unicode support etc in mosh if they're prepared to use IPv6 exclusively for that connection.

Once IPv6 becomes more common - as IPv4 exhaustion begins to bite - then it may be worth returning and looking at live roaming from IPv6 to IPv4 (and back) but I think basic IPv6 support would be very useful currently even absent that capability.

@blblack

This comment has been minimized.

Contributor

blblack commented Apr 16, 2012

Yeah I'm not sure what the perfect solution is on the RR thing, but as the situation stands today: I wanted to try mosh, and the host I wanted to try it with is in a basic, normal mixed-family setup, and mosh failed to work. It didn't even fail gracefully - the client process had to be killed from another terminal window because it wouldn't accept input from me (e.g. Ctrl-C, Ctrl-^...).

My local laptop and the remote host both have working, separate, singular IPv4 and IPv6 addresses, and both addresses are in DNS (as A + AAAA recs for a single name). This works fine with every piece of software I use (most everything preferentially connects over v6, and some older software sometimes uses v4 for various reasons, but one way or another they connect fine), except for mosh.

@keithw

This comment has been minimized.

Member

keithw commented Apr 16, 2012

It sounds like you hit a different bug unrelated to IPv6. (Are you by any chance on a Mac?) mosh 1.2 (probably out this week) will have a fix for this bug, and you're welcome to try the current git master which also has it.

@blblack

This comment has been minimized.

Contributor

blblack commented Apr 16, 2012

Yes, client side is mac, server side is Linux, in the case cited above. I'll try the current master.

@blblack

This comment has been minimized.

Contributor

blblack commented Apr 16, 2012

Yes, switched to master on both sides and everything's fine. I guess my problem wasn't IPv6 after all :)

@barak

This comment has been minimized.

barak commented Apr 17, 2012

I would agree with the above "don't let the perfect be the enemy of the good" suggestions. I currently use ssh+screen to connect to an IPv6-only host. (It has a NAT IPv4 address which is irrelevant here.) So I don't care about switching between IPv4 and IPv6. I suspect most users who want IPv6 are in the same boat. So I would urge: get mosh working with IPv6, and worry about roaming IPv6-to-IPv4 later.

I would further note that this "host might change address" issue is, in principle, not an IPv6 issue. A host can change its IPv4 address too...

@kmcallister

This comment has been minimized.

Contributor

kmcallister commented Apr 17, 2012

A host can change its IPv4 address too...

Yeah. An important instance of this is #210. Solutions to that problem may also apply to IPv6 and vice versa.

@mithro

This comment has been minimized.

mithro commented May 7, 2012

Any update on this? I'd love to use mosh but most of the machines I want to use it on are IPv6 only.

@stapelberg

This comment has been minimized.

stapelberg commented May 7, 2012

Well, I pushed the branch and it works for me. I expect keithw or some other core developer (if there are any besides him) to review it and decide on the error handling, and maybe clean it up and merge it.

@keithw

This comment has been minimized.

Member

keithw commented May 7, 2012

Thanks, mstap. We expect we will have this (with support for roaming to IPv4-only commercial networks) in mosh 1.3. Unfortunately I don't have a real IPv6 Internet connection myself, which makes this hard to test. We may post some candidates and I will be counting on you folks to test them.

@blblack

This comment has been minimized.

Contributor

blblack commented May 7, 2012

My personal fave is the free tunnels at http://www.tunnelbroker.com/ , it's what I use at home for IPv6. Also, if you want to play with some cheap headless virtual servers that have "real" IPv6 connectivity: http://www.linode.com/IPv6/

@mithro

This comment has been minimized.

mithro commented May 7, 2012

I'd be happy to give you access to IPv6 dual-homed and single-homed boxes
if you need.

Otherwise, there are quite a few free IPv6 tunnel brokers out there.

Tim

On 8 May 2012 02:41, Brandon Black <
reply@reply.github.com

wrote:

My personal fave is the free tunnels at http://www.tunnelbroker.com/ ,
it's what I use at home for IPv6. Also, if you want to play with some
cheap headless virtual servers that have "real" IPv6 connectivity:
http://www.linode.com/IPv6/


Reply to this email directly or view it on GitHub:
#81 (comment)

@ddrown

This comment has been minimized.

ddrown commented Jun 24, 2012

I have a slightly different IPv6 implementation:
ddrown@225792a

My solution to the load balancer problem is as follows:

  1. If the hostname has a mix of A and AAAA records, use the first A record (choose IPv4 when possible)
  2. If the hostname only has AAAA records, use the first AAAA record (use IPv6 when there's no choice)

This solves the roaming problem in two ways:

  1. All (non-test) internet connections have some form of IPv4 and will continue to do so in the future, so IPv4 access should work everywhere
  2. If a hostname has only IPv6 records, failing when on a connection without IPv6 access is the only possible result (without tunnels/vpn)
@bobveznat

This comment has been minimized.

bobveznat commented Jul 10, 2012

Please don't invent your own algorithms for deciding whether or not to use one address family or another. The proper way to do this is specified in RFC 3484 and that has already been implemented for you by your operating system. All modern operating systems already do The Right Thing. Simply call getaddrinfo(3).

The results of a call from a dual stack client:

socket.getaddrinfo('veznat.com', '22')
[(30, 2, 17, '', ('2607:f8c8:4:1025::234', 22, 0, 0)), (30, 1, 6, '', ('2607:f8c8:4:1025::234', 22, 0, 0)), (2, 2, 17, '', ('208.75.243.234', 22)), (2, 1, 6, '', ('208.75.243.234', 22))]

The results from a v4-only client (the client still has link-local IPv6 addresses):

socket.getaddrinfo('veznat.com', '22')[(2, 2, 17, '', ('208.75.243.234', 22)), (2, 1, 6, '', ('208.75.243.234', 22)), (30, 2, 17, '', ('2607:f8c8:4:1025::234', 22, 0, 0)), (30, 1, 6, '', ('2607:f8c8:4:1025::234', 22, 0, 0))]

Do like ssh(1) and telnet(1) do and have a -4 and a -6 switch to specify v4 or v6 only on the command line.

Once you have this basic functionality in place you can try implementing Happy Eyeballs. All modern web browsers do this now.

http://en.wikipedia.org/wiki/Happy_Eyeballs

But please. No matter what you do. Don't redo the 100s of man years of research and testing already carried out by the IETF.

@bobveznat

This comment has been minimized.

bobveznat commented Jul 10, 2012

Glancing at the code I have a few other unsolicited tips for the IPv6 port: Use sockaddr_storage, not sockaddr_in (nor sockaddr_in6). Use inet_ntop and inet_pton for converting between presentation (ascii) and network byte order.

You can use inet_pton to verify an IP address rather than doing naive "sanity checks".

This is obviously a whole lot easier to do the first time you write an app, rather than backporting it in.

@stapelberg

This comment has been minimized.

stapelberg commented Jul 10, 2012

@bobveznat Huh? I already use sockaddr_storage and getaddrinfo in the code I linked to.

@bobveznat

This comment has been minimized.

bobveznat commented Jul 10, 2012

@mstap I didn't look at your patch. I looked only at the code in the mosh repo and the recent patch by ddrown.

@ddrown

This comment has been minimized.

ddrown commented Jul 10, 2012

@bobveznat I thank you for the code review. I'll go over your concerns:

  1. Selection of address - there are two restrictions on using the OS supplied address order (RFC3484). The first restriction is we have no guarantee that multiple addresses for the same hostname go to the same host (see kiethw's comment at the top). So to solve that, I'm using the same address on all networks. The second restriction is that not all networks have IPv6. This means if a IPv6 address is chosen, it is likely to break on network roaming. Because of this, I choose IPv4 over IPv6. Having a command-line switch to over-ride the default is fine, but it needs to work by default. Web browsers have different requirements for address selection, http is not restricted to using the same host for the same "session". So algorithms designed for the web do not work here, as they have different restrictions.
  2. sockaddr_storage vs sockaddr_in/in6 - I'm using a union to make it easier to deal with the struct's fields. Otherwise, it would require more code to cast to various types. It is equivalent to using sockaddr_storage in that it has one object to deal with both types of addresses.
  3. inet_ntop/inet_pton - I'm already using these functions
@bobveznat

This comment has been minimized.

bobveznat commented Jul 10, 2012

Having numerous hosts behind a single hostname and then expecting deterministic reconnection behavior seems somewhat silly, doesn't it? ssh connections, in my experience, have always been made to specific hosts, not to generic names. In a large web deployment you might ssh to prod-www1.example.com; never to www.example.com (possibly a host with numerous A and AAAA records). I question whether this is a real scenario that someone has actually deployed or some made up use case.

If this is a real use case perhaps mosh could support, and these operators provide, SRV records in DNS that more specifically direct mosh to the correct IP address.

It's a bit of an aside but HTTP (web) applications also have this notion of a session. In load balancer terminology we call them "sticky sessions" because we "stick" a user session to a specific web server behind a load balancer. It's often used for web applications that maintain state on individual web servers (imagine sessions stored in local memory).

I'll reiterate that inventing your own address selection routines is not good for the internet community. Network applications should be predictable and homogeneous in their connection behavior and not filled with arbitrary choices for v4 and v6. RFC 3484 has rules that try really hard to figure out which address family is going to be better for any given connection. Happy Eyeballs tests it at runtime.

Assuming that everyone today runs native IPv4 and that IPv6 is equivalent or worse in performance than IPv4 is dangerous and often incorrect. T-Mobile, today, is deploying IPv6-only networks where IPv4 is proxied through a v6-v4 gateway. Choosing IPv4 first in this T-Mobile scenario would be less than ideal. AT&T is deploying layers of NAT between the internet and individual customers (in addition to the NAT already done by your router). mosh packets could have a direct v6 connection or go through many layers of IPv4 NAT. Choosing IPv6 would be better than v4 but the algorithms discussed in this issue would never choose v6.

@ddrown

This comment has been minimized.

ddrown commented Jul 10, 2012

Using SRV records to load balance between hosts would be acceptable to me, but the question still remains: what to do when SRV records are absent? You can reject the scenario that has already been described as "made up", but it was given as a restriction of a solution. It already works today in the v4-only client, and it should continue to work in the future.

I am well aware of T-Mobile's NAT64 setup, and I recommend using 464xlat to give applications (such as this one) better IPv4 access.

@blblack

This comment has been minimized.

Contributor

blblack commented Jul 10, 2012

I tend to concur with Bob's view. For this one desirable feature (reconnecting sessions to a "virtual" hostname that has addresses for many real hosts), you're complicating things a lot. I echo his argument about ssh and prod-www1 above. People who have multiple hosts can surely just connect to the "real" hostnames, and/or you can invent some SRV (or other) scheme specifically to support that case, rather than mucking with default behavior that works well for the common v4 and v6 cases.

@keithw

This comment has been minimized.

Member

keithw commented Jul 10, 2012

Thanks, Bob, for your review. I was fortunate to have the benefit of discussing Mosh with a lot of people at IETF in March and got some good feedback. The common initial reaction from IETF-type folks (including me) has definitely been, "Oh, just use Happy Eyeballs!" or "Oh, I think we have an Internet-Draft on that." Unfortunately when people think more about the problem, they do conclude (as I did) that no current standard addresses the question of cross-version IP roaming (or in other words, connections to multihomed servers where connectivity to different interfaces shifts in the middle of a connection). That makes sense because none of those other applications (including Web browsers running HTTP over TCP or TCP-for-IPv6) can roam. Neither RFC 3484 nor Happy Eyeballs deals with the particular problem of wanting to reconsider the choice of IPv4 vs. IPv6 in the middle of a connection to a particular host.

So while we are not going to reinvent the wheel, we do have to do some extra work to confront complexities that non-roaming protocols didn't have to worry about.

@bobveznat: "Having numerous hosts behind a single hostname and then expecting deterministic reconnection behavior seems somewhat silly, doesn't it?"

Not at all -- the case of round-robin DNS records is not uncommon. MIT uses it with their "athena.dialup.mit.edu" record for shell servers.

Mosh currently roams properly in this scenario, our users do make use of this behavior, and we don't plan to break this.

Thinking about Mosh as exhibiting "reconnection behavior" is not quite how I think about it. SSP provides a state-synchronization service that is robust to IP address changes by the client. Right now, the client doesn't "reconnect" when it roams -- actually the client doesn't even know it has roamed. It just keeps working, connected to the same host.

I like your analogy to "sticky sessions." Unfortunately we don't have the benefit of protocol-specific load balancers in the way. It's just a round-robin DNS record where the client does all the selection.

@brendanjerwin

This comment has been minimized.

brendanjerwin commented Sep 28, 2014

@TimCook1

This comment has been minimized.

TimCook1 commented Sep 28, 2014

@brendanjerwin Just a follow-up. Now that I've had a bit of sleep and time to do a little more research, you actually can just outright replace IO::Socket; with IO::Socket::INET6;

IO::Socket::INET6 actually includes all of IO::Socket plus the IPv6 hooks, so having them both is redundant. That should be a permafix.

@andersk

This comment has been minimized.

Member

andersk commented Sep 28, 2014

@tcsac, when you say you have “the libio package installed”, are you sure you’re referring to libio-socket-ip-perl (IO::Socket::IP), not libio-socket-perl (IO::Socket)? The Mosh client always requires IO::Socket, but you also need the separate IO::Socket::IP package for -6 to work. (The server doesn’t use Perl at all.)

IO::Socket::IP was added to the Perl core in Perl 5.20, but needs to be separately installed from your package manager or CPAN for older versions of Perl.

To be sure, check that running
perl -e 'use IO::Socket::IP'
gives no errors.

@TimCook1

This comment has been minimized.

TimCook1 commented Sep 28, 2014

@andersk I mean that OSX has the correct libraries out of the gate for IPv6. As I already posted, the problem is in the code. The mosh client code doesn't define the correct library, if you add

use IO::Socket::INET6;

to the mosh client, it works fine.

@andersk

This comment has been minimized.

Member

andersk commented Sep 29, 2014

@tcsac, I understand that you can make it work with IO::Socket::INET6. What I want to find out now why it’s not working with IO::Socket::IP, which is why I started by asking you to confirm that IO::Socket::IP is indeed installed. What happens when you run
perl -e 'use IO::Socket::IP'
on the client?

(To give you an idea of where I’m going with this: my understanding is that the Perl developers have expressed a preference for IO::Socket::IP over IO::Socket::INET6 as the way forward for IPv6 support in Perl, as evidenced by the Perl IPv6 whitepaper and by their decision to include IO::Socket::IP in the Perl 5.20 core. If this is not the case, or if there are a significant number of systems preinstalled with IO::Socket::INET6 and not IO::Socket::IP, or if there’s some bug that makes IO::Socket::IP not work for you even if it is installed, then I would definitely like to hear details—maybe it would be appropriate to adjust the code to support either module somehow. But it also seems possible that you’ve installed IO::Socket::INET6 as a dependency of some other package that you’ve forgotten about, and never installed IO::Socket::IP.)

@TimCook1

This comment has been minimized.

TimCook1 commented Sep 29, 2014

@andersk Literally nothing includes Socket::IP today. Every server I've looked at ships with 5.18 or older. OSX is 5.16 as for 10.9, and 5.18 as of 10.10.

Can't locate IO/Socket/IP.pm in @inc (@inc contains: /Library/Perl/5.16/darwin-thread-multi-2level /Library/Perl/5.16

I didn't install INET6, it comes out of the box as part of perl on OSX, and is included out of the box on 5.18 for debian/ubuntu. You are indeed correct that I have not installed Socket::IP because there is no packaging system that has it readily available for OSX that I can find. While IP may be the way of the future, I think it's more than a bit premature to use that as the default when it simply breaks everything. INET6 works, it seems to me the logical option until 5.20 is out and readily available.

@andersk

This comment has been minimized.

Member

andersk commented Sep 29, 2014

(Wow dude, you almost sound like an IPv4 apologist yelling about how IPv6 breaks everything. :-P)

Note that IO::Socket::IP is not tied to a particular Perl version. It was packaged in Ubuntu 11.10 (Perl 5.12) and later, and I believe it works on even earlier versions. Perl 5.20 is just the first version that includes it in Perl core. IO::Socket::INET6, on the other hand, has never been in core; it just seems to be a commonly installed extra module because it predates IO::Socket::IP.

That’s fine—there’s no reason we can’t support both IO::Socket::IP and IO::Socket::INET6, whichever is installed. I’ve opened #553 for that.

@TimCook1

This comment has been minimized.

TimCook1 commented Oct 21, 2014

Ran into another issue for you @andersk. If you do a mosh -6 HOSTNAME to a hostname that has both ipv4 and ipv6 IPs associated with it, mosh loses it's brain:

/usr/local/bin/mosh: Could not connect to HOSTNAME: IO::Socket::INET6: connect: Connection refused
ssh_exchange_identification: Connection closed by remote host
/usr/local/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).

Works fine with a standard ssh -6 HOSTNAME

@andersk

This comment has been minimized.

Member

andersk commented Oct 21, 2014

Well, you brought IO::Socket::INET6 into this, not me—does it work with IO::Socket::IP?

That said, I just set up a host with both IPv4 and IPv6 addresses, and it works for me with either IO::Socket::IP or IO::Socket::INET6. You’ll need to do some more debugging. Maybe add some lines right before IO::Socket->new to print the address+port it’s connecting to on stderr (not stdout, that will confuse ssh).

@TimCook1

This comment has been minimized.

TimCook1 commented Oct 21, 2014

Based on my rudimentary test, it's trying to connect to the ipv4 address (which is not listening for ssh). I would love to use IO::Socket::IP, but as we discussed above, that's not an option on OS X so I'm stuck trying to find workarounds for INET6 :(

@andersk

This comment has been minimized.

Member

andersk commented Oct 21, 2014

Did you type mosh -6? Mosh will not (yet) try to use an IPv6 address unless you use the -6 flag, even if SSH would, for reasons discussed above.

@TimCook1

This comment has been minimized.

TimCook1 commented Oct 21, 2014

Yes sir, using the -6 flag. If you have any code you can pass me to help debug I'm happy to test.

@eminence

This comment has been minimized.

Member

eminence commented Oct 22, 2014

Hi all. On my OSX machine I was able to get this working by installing IO-Socket-IP-0.32. This required an updated version of Socket, so I installed that too (version 2.014). This was done by downloading these packages from CPAN and manually installing on top of perl 5.12 from macports. No changes to scripts/mosh were required.

Also, I am unable to reproduce what tcsac has reported. My macbook normally has a working ipv6 route, but that's broken at the moment. It has working ipv4, so this is convenient for testing. Here is what happens when i try to mosh to something with both ipv4 and ipv6 addresses:

mbp:mosh achin$ perl scripts/mosh -6 achin@google.com
/Users/achin/devel/mosh/scripts/mosh: Could not connect to google.com: No route to host
ssh_exchange_identification: Connection closed by remote host
scripts/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).

This suggests that mosh is correctly trying to use ipv6. If it was using ipv4 as tcsac is reported, we would see a very different message (connection timed out most likely)

@TimCook1

This comment has been minimized.

TimCook1 commented Oct 22, 2014

Well... that is a partial workaround. If you have xcode command line tools installed, you can actually do it with a:
sudo cpan install IO::Socket::IP

no need to go to macports. I actually didn't even think of that duh.

@jech

This comment has been minimized.

jech commented Dec 22, 2014

Keith already knows that, but Boutier's multipath-capable branch of Mosh pretty much solves all of the issues outlined in this discussion.

https://github.com/boutier/mosh

Boutier is busy cleaning up the code, and hopefully he will be able to push it to Keith in the near future.

boutier pushed a commit to boutier/mosh that referenced this issue Mar 11, 2015

Matthieu Boutier
script: Fix -6 command.
Perl before version 5.20 is not able to deals with this
command.  Thank's to Tyler Gillies for the fix.  Remark
that it's only meaningful for bootstrap: when multipath
is active, both v4 and v6 will be used, independently of
the "-4" or "-6" options.

For more information:

  mobile-shell#81

@zombiezen zombiezen referenced this issue Apr 8, 2015

Closed

Support IPv6 #87

@dtaht

This comment has been minimized.

dtaht commented Jun 16, 2015

will mosh multipath be merged?

@cgull

This comment has been minimized.

Member

cgull commented Jun 16, 2015

Not for mosh-1.2.5, which is just a rollup of bugfixes and cleanup PRs that were in the queue-- no more new features. I haven't even looked at https://github.com/boutier/mosh yet, though I'm definitely interested.

@nomadium

This comment has been minimized.

nomadium commented Jun 20, 2015

@cgull is there an ETA for mosh-1.2.5?

@cgull

This comment has been minimized.

Member

cgull commented Jun 20, 2015

I should have the two remaining issues wrapped up this weekend-- OS X build and Debian bash completion. Release will come soon after that, depending on how much bake time it gets and if we find anything else.

@nomadium

This comment has been minimized.

nomadium commented Jun 21, 2015

Good to know, thanks for taking care of the release.

@kurtkraut

This comment has been minimized.

kurtkraut commented Apr 21, 2016

With the mosh -6 parameter I'm able to connect to my server using IPv6 but without mentioning this parameter, mosh (version 1.2.5 tested) will always prefer to connect using IPv4 instead of IPv6 if a AAAA DNS entry is available for the FQDN.

I strongly suggest as browsers, OpenSSH and other client/daemon softwares behave, AAAA is prefered over A addresses.

@Mikaela

This comment has been minimized.

Mikaela commented Apr 21, 2016

I strongly suggest as browsers, OpenSSH and other client/daemon softwares behave, AAAA is prefered over A addresses.

They follow RFC 6555 aka Happy Eyeballs which everything should support nowadays.

@graingert

This comment has been minimized.

graingert commented Apr 21, 2016

@Mikaela but mosh doesn't need to support Happy Eyeballs, it can make multiple connections simultaneously

@dtaht

This comment has been minimized.

dtaht commented Apr 21, 2016

I really would like to see mosh multipath merged. It's even happier than happy eyeballs.

@pavlix

This comment has been minimized.

pavlix commented Feb 6, 2017

I hope you don't mind that I created an issue just for the roaming, see #855 . This is an old issue for lack of IPv6 support. I have tried using mosh 1.2.6 on IPv6 with success and therefore I believe this issue should just be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment