search

traviscross / mtr

Official repository for mtr, a network diagnostic tool
http://www.bitwizard.nl/mtr/
GNU General Public License v2.0
2.7k stars 341 forks source link

Scrambled line in route when it does not fit all the screen #285

Open naoliv opened 5 years ago

naoliv commented 5 years ago

While using Debian's 0.92-2 version I am seeing a small problem when the whole route does not fit on the screen.

For example, using a standard size terminal I am seeing this:

See that line 19 is all messed if we compare to a slightly resized terminal window:

Is there anything that I can do to help with this, please? (testing something, giving more info, etc)

rewolff commented 5 years ago

On my system, when I resize my xterm to be ridiculously small, I get the "expected" output: A truncated list of hosts. Did you resize the window while mtr was running? Or does it depend on that the hosts before the final one are not responding at all? (I couldn't find an example like yours where the destination responds but a few routers before don't).

yvs2014 commented 5 years ago

That could be 8.8.8.8 for example 4ex

workaround

diff --git a/ui/curses.c b/ui/curses.c
index 5a2285a..6d99bd4 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -508,6 +508,8 @@ static void mtr_curses_hosts(
             attron(A_BOLD);
             printw("(%s)", host_error_to_string(err));
             attroff(A_BOLD);
+            getyx(stdscr, y, __unused_int);
+            move(y, startstat);
         }

         printw("\n");

by the way, let's get rid of some build warnings

  CC       ui/mtr-mtr.o
ui/mtr.c: In function ‘init_fld_options’:
ui/mtr.c:302:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
     memset(ctl->fld_index, -1, FLD_INDEX_SZ);
     ^~~~~~
diff --git a/ui/mtr.c b/ui/mtr.c
index 35953cf..dff40f9 100644
--- a/ui/mtr.c
+++ b/ui/mtr.c
@@ -299,7 +299,7 @@ static void init_fld_options(
 {
     int i;

-    memset(ctl->fld_index, -1, FLD_INDEX_SZ);
+    memset(ctl->fld_index, -1, sizeof(ctl->fld_index));

     for (i = 0; data_fields[i].key != 0; i++) {
         ctl->available_options[i] = data_fields[i].key;
rewolff commented 5 years ago

On Sat, Dec 22, 2018 at 10:02:29AM -0800, yvs2014 wrote:

That could be 8.8.8.8 for example

Of 4 billion possible IP addresses... That's the first one I tried.

  1. 108.170.241.161 0.0% 6 8.8 9.0 8.8 9.3 0.2
  2. 108.170.236.219 0.0% 6 7.9 8.0 7.8 8.4 0.2
  3. google-public-dns-a.google.com 0.0% 6 6.8 6.5 6.2 6.8 0.2
yvs2014 commented 5 years ago

Of 4 billion possible IP addresses... That's the first one I tried.

:)

  1. 108.170.241.161 0.0% 6 8.8 9.0 8.8 9.3 0.2
  2. 108.170.236.219 0.0% 6 7.9 8.0 7.8 8.4 0.2
  3. google-public-dns-a.google.com 0.0% 6 6.8 6.5 6.2 6.8 0.2

idk, local blocking some transit addresses might work in order to simulate the same effect, something like ip r a 108.170.241.161/32 dev lo ip r a 108.170.236.219/32 dev lo for path above

naoliv commented 5 years ago

I am tracing to 8.8.8.8 and the terminal wasn't resized (the first screenshot is really my default urxvt size). It seems that somehow it's merging the ??? from the previous lines (19, 20, 21, 22) into the last one (23) (as we can see on the ???20. ???21. ???22. ???23. string)

rewolff commented 5 years ago

@yvs2014 i don't normally use the "ip" tool. It took me a while to understand what you're doing there. That won't work. You are sabotaging our "we want to send something to those specific hosts". We're not ping-ing those hosts, we're sending packets to 8.8.8.8 and those hosts are reporting back to us that some packets didn't have enough bus-tokens on them to go any further. (They are the fare-checking officers in the field that send back a message: "your friend didn't have enough money!"... Who cares that I don't have their phone number. They are calling ME).

Using iptables to block packets from them should work.

@naoliv can you try yves' fix?

naoliv commented 5 years ago

I will be able to test it only on the next year.

yvs2014 commented 5 years ago

@yvs2014 i don't normally use the "ip" tool. It took me a while to understand what you're doing there. That won't work. We're not ping-ing those hosts, we're sending packets to 8.8.8.8 and those hosts are reporting back to us that some packets didn't have enough bus-tokens on them to go any further. (They are the fare-checking officers in the field that send back a message: "your friend didn't have enough money!"... Who cares that I don't have their phone number. They are calling ME).

Yes, you're right, but that was about some simulation, and it's a bit tricky with the network stack's receive path. At least it's enough for output testing on my computer:


# ./mtr -rn -c5 yahoo.com
...
11.|-- 66.196.67.99               0.0%     5  182.5 182.5 182.2 182.7   0.2
12.|-- 67.195.37.73               0.0%     5  181.5 188.2 181.5 213.9  14.4
13.|-- 98.137.120.25              0.0%     5  182.0 182.4 182.0 183.0   0.5
14.|-- 98.137.246.7               0.0%     5  182.3 182.3 182.1 182.5   0.1

ip r a 98.137.120.25 dev lo

./mtr -rn -c5 yahoo.com

... 11.|-- 66.196.67.103 0.0% 5 183.0 183.0 182.9 183.1 0.1 12.|-- 67.195.37.73 0.0% 5 182.3 182.2 182.1 182.3 0.1 13.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 14.|-- 98.137.246.8 0.0% 5 182.1 182.1 181.8 182.4 0.2

rewolff commented 5 years ago

I don't know how that can be, but on my system it doesn't work as I expected....

yvs2014 commented 5 years ago

There is also another problem with a truncated terminal, not just in those cases where the destination responds but some routers before do not. Example of the truncated output below, where the output in part1 fits the terminal size, and in part2 the terminal is truncated to two hops, where the statistic for hop#2 corresponds to the data for the last hop (it's hop#14 over there).

part1:

 Host                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. gateway                                        0.0%    36    0.2   0.2   0.1   1.1   0.2
 2. static.80.66.201.195.clients.your-server.de    0.0%    36    0.2   0.2   0.1   0.3   0.0
 3. static.1.66.201.195.clients.your-server.de     0.0%    36   17.8  22.8  11.6 183.8  31.2
 4. spine2.cloud1.nbg1.hetzner.com                 0.0%    36   16.6   2.1   0.7  16.6   3.4
 5. core12.nbg1.hetzner.com                        0.0%    36    0.4   0.4   0.3   2.2   0.4
 6. juniper5.dc2.nbg1.hetzner.com                  0.0%    36    0.3   0.7   0.3  10.5   1.7
 7. ae5-710.nbg40.core-backbone.com                0.0%    36    0.7   1.8   0.5  34.3   6.3
 8. ae1-2003.fra20.core-backbone.com               0.0%    36    3.8   5.0   3.7  22.7   4.5
 9. de-cix.ULCO02.telstraglobal.net                0.0%    36  161.6 165.8 161.0 203.1  11.2
10. i-92.1wlt-core02.telstraglobal.net             0.0%    35  154.4 153.6 152.3 163.5   1.4
11. i-16.sydp-core03.telstraglobal.net             0.0%    35  345.5 346.3 345.3 347.3   0.6
12. bundle-ether3.pad-gw10.sydney.telstra.net      0.0%    35  341.0 341.1 340.1 342.1   0.6
13. bundle-ether3.chw-core10.sydney.telstra.net    0.0%    35  339.4 339.5 338.2 344.5   1.0
14. bundle-ether1.chw-edge901.sydney.telstra.net   0.0%    35  329.3 329.4 329.1 330.5   0.4

part2:

 Host                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. gateway                                        0.0%    38    0.1   0.2 0.3.1   1.2   0.1
 2. static.80.66.201.195.clients.your-server.de    0.0%    37  329.3 329.3 329.1 330.5   0.3

In order to avoid the wrapping that is due to reaching the maximum height of the window, maybe it's necessary to test every new-line in curses output.