Do you think you could reproduce this? It would be wonderful to
capture what the server thinks is happening (i.e. the debugging output
of mosh-server new -v).
On Mon, Dec 31, 2012 at 12:47 AM, Axel Beckert wrote:
> Hi,
>
> On Mon, Dec 31, 2012 at 01:44:34AM +0100, Christoph von Stuckrad wrote:
>>
Hi,
On Mon, Dec 31, 2012 at 01:44:34AM +0100, Christoph von Stuckrad wrote:
> On 30.12.2012 23:55, Axel Beckert wrote:
> ...
> > And now that you mention it: That clock still works, i.e. it's updated
> > on the client. It updates once a second, but the blue bar on top is
> > still there and says "
On 30.12.2012 23:55, Axel Beckert wrote:
...
> And now that you mention it: That clock still works, i.e. it's updated
> on the client. It updates once a second, but the blue bar on top is
> still there and says "mosh: Last reply 45804 seconds ago. [To quit:
> Ctrl-^ .]". But nothing I type is shown
Hi Keith,
On Sun, Dec 30, 2012 at 01:59:53PM -0500, Keith Winstein wrote:
> Something is awry here but I am a little confused, especially about
> why packets are being sent so often. I wonder if somehow two
> sessions got slotted in to the same spot, somehow, on the
> intermediate NATted link. But
Something is awry here but I am a little confused, especially about why
packets are being sent so often. I wonder if somehow two sessions got
slotted in to the same spot, somehow, on the intermediate NATted link. But
really I don't quite understand what is going on.
Is the display (visible on t
Hi Keith,
On Sun, Dec 30, 2012 at 12:31:46PM -0500, Keith Winstein wrote:
> Thanks for the detailed report. "Last reply" means that the _server_
> is not getting (or at least not acknowledging) packets from the
> _client_. (If the client were not getting packets at all, it would
> say "Last contac
Hello Axel,
Thanks for the detailed report. "Last reply" means that the _server_ is
not getting (or at least not acknowledging) packets from the _client_. (If
the client were not getting packets at all, it would say "Last contact.")
So the client-side tcpdump is somewhat as expected. Are you ab
Hi Quentin,
On Sun, Dec 30, 2012 at 11:22:42AM -0500, Quentin Smith wrote:
> On Sun, 30 Dec 2012, Axel Beckert wrote:
> > Any idea what could have cause such a bad lockup in a mosh connection?
> > IIRC as of now, mosh does DNS lookups only once at start, so it
> > couldn't be a cached bad DNS repl
Hi Axel,
Just to check the obvious first - to your knowledge, the server resolved
to the same IP address before and after you restarted the AP? (That is,
the server didn't appear to move for any reason?)
What version of mosh are you using? Mosh 1.2.3 adds a new behavior where
it will try openi
Hi,
today (after close to one year of occassional mosh usage) I had the
first case where mosh connections didn't come back and I had to kill
and restart them. After which they worked fine again.
I was online for over 7 days over an so called mobile AP (which does
NAT). My mobile carrier (E-Plus i
10 matches
Mail list logo
