The quick fix is to run "LANG=C luit iftop" instead.
More detail: The problem is that we've made a design decision not to honor ISO 2022 locking escape sequences (which can be used as line-drawing characters), because they can end up sticking the terminal in permanent hieroglyphs and UTF-8 is supposed to be a stateless, self-synchronizing encoding. (See http://www.cl.cam.ac.uk/~mgk25/unicode.html#term for more detail than you probably want, or the examples I just added to mosh.mit.edu.)
We use the NCURSES_NO_UTF8_ACS=1 environment variable to request UTF-8 from ncurses instead of ISO 2022, and 99% of programs honor that -- but iftop is not one of them. It's within its rights, but I think these programs are rare enough that if you want to use the old-style line-drawing characters in mosh, it would be better to run just that program in luit (which is a translator), so that at least when luit exits, you'll be out of hieroglyphs for sure.
The quick fix is to run "LANG=C luit iftop" instead.
More detail: The problem is that we've made a design decision not to honor ISO 2022 locking escape sequences (which can be used as line-drawing characters), because they can end up sticking the terminal in permanent hieroglyphs and UTF-8 is supposed to be a stateless, self-synchronizing encoding. (See http://www.cl.cam.ac.uk/~mgk25/unicode.html#term for more detail than you probably want, or the examples I just added to mosh.mit.edu.)
We use the NCURSES_NO_UTF8_ACS=1 environment variable to request UTF-8 from ncurses instead of ISO 2022, and 99% of programs honor that -- but iftop is not one of them. It's within its rights, but I think these programs are rare enough that if you want to use the old-style line-drawing characters in mosh, it would be better to run just that program in luit (which is a translator), so that at least when luit exits, you'll be out of hieroglyphs for sure.