Thank you for this report. What version of Mosh is running on the server?
What architecture is the server (is it also a Debian amd64 machine)? Could you please also test running Mosh 1.2.5 on the client *and* server, and seeing if you can replicate the bug? That will help us determine if this is a regression. Depending on the results, the next request will be for you to use "script" to capture the output (1) entering tmux, (2) leaving tmux and entering mosh, and then (3) leaving mosh. Thanks very much for finding this, Keith On Mon, Nov 7, 2016 at 4:04 AM, Ph. Marek <philipp.ma...@linbit.com> wrote: > Package: mosh > Version: 1.2.6-1+b1 > Severity: normal > > Some interaction of tmux and mosh to access a remote machine makes long > lines being displayed badly. > > For example, scrolling "less /var/log/kern.log" line by line > should be uninterrupted long lines. > > It should be > > |Nov 7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in| > |5: +3.07 V (min = +1.95 V, max = +1.15 V) [ALARM] | > |Nov 7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in| > |7: +3.33 V (min = +3.68 V, max = +2.24 V) [ALARM] | > |Nov 7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in| > |8: +3.30 V (min = +1.39 V, max = +2.43 V) [ALARM] | > > and copy/paste of tha > > But when scrolling individual lines forward the output looks like > > |Nov 7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in| > |5: +3.07 V (min = +1.95 V, max = +1.15 V) [ALARM] | > |Nov 7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in| > |: | > |7: +3.33 V (min = +3.68 V, max = +2.24 V) [ALARM] | > |Nov 7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in| > |: | > |8: +3.30 V (min = +1.39 V, max = +2.43 V) [ALARM] | > > To clarify: these combinations work normally: > > xterm > mosh > less > xterm > mosh > screen > less > konsole > mosh > screen > less > konsole > ssh > screen > less > konsole > tmux > ssh > less > konsole > tmux > ssh > screen > less > > I get the corruption with > > konsole > tmux > mosh > less > xterm > tmux > mosh > less > konsole > tmux > mosh > screen > less > konsole > tmux > mosh > screen > cat > konsole > tmux > mosh > screen > other terminal output > > > When having a "screen" behind "mosh", the results are even more bizarry. > When switching to an (empty, clean) screen window when such a screen > corruption is visible, the freshly displayed screen is garbled, too: > > | b t i ' //www.rsyslog.com/e/2359 ] | > | r 2 -0290: i | > | +3 0 . = R | > | 0 h i w83627hf-isa-0290: i | > | | > | + | > > I guess that mosh tries to optimize for bandwidth by only pushing "changed" > characters, but as the display is out of sync, it doesn't match up again. > > mosh tries to optimize for bandwidth by only pushing "changed" characters, > but as the display is out of sync, it doesn't match up again. > > mosh tries to optimize for bandwidth by only pushing "changed" characters, > but as the display is out of sync, it doesn't match up again. > > tmux and the mosh-clients have TERM=screen-256color; "tput cols" shows the > same value outside tmux, inside tmux but before mosh, and behind mosh. > > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages mosh depends on: > ii dpkg 1.18.10 > ii libc6 2.24-5 > ii libgcc1 1:6.2.0-10 > ii libprotobuf10 3.0.0-7 > ii libssl1.0.2 1.0.2j-1 > ii libstdc++6 6.2.0-10 > ii libtinfo5 6.0+20160917-1 > ii libutempter0 1.1.6-3 > ii openssh-client 1:7.3p1-1 > ii zlib1g 1:1.2.8.dfsg-2+b3 > > Versions of packages mosh recommends: > ii libio-socket-ip-perl 0.38-1 > ii perl-base [libio-socket-ip-perl] 5.24.1~rc3-3 > > mosh suggests no packages. > > -- no debconf information >
