trim(8): minor output correction
"trim /dev/da*" would print the following line multiple times
when given multiple agruments:
dry run: add -f to actually perform the operation
Print it once before looping over arguments.
Also, note possible suffixes P and E after offset/length
as per expand_number(3).
(cherry picked from commit 5d5848648013a189fc766e4ee3a121362905b836)
(cherry picked from commit f1b934c8138cfd98a70e305d54b2b431c842ec21)
trim(8): minor output correction
"trim /dev/da*" would print the following line multiple times
when given multiple agruments:
dry run: add -f to actually perform the operation
Print it once before looping over arguments.
Also, note possible suffixes P and E after offset/length
as per expand_number(3).
(cherry picked from commit 5d5848648013a189fc766e4ee3a121362905b836)
(cherry picked from commit f1b934c8138cfd98a70e305d54b2b431c842ec21)
traceroute: MFC: graceful recover after networking errors with as_server
Currently, the traceroute[6] utility does not check
for possible networking errors while talking to as_server
in case of "traceroute -a". Meantime, there is a common case
when trace is long and it has many non-responding hops
(shown as '* * *'), so as_server aborts our connection,
hence no AS numbers shown for the rest of trace.
Somewhat artifical way to reproduce the problem:
traceroute to 57.144.244.1 (57.144.244.1), 80 hops max, 48 byte packets
5 [AS174] be2950.ccr42.fra05.atlas.cogentco.com (154.54.72.42) 74.277 ms 9.605 ms 9.599 ms
6 [AS174] 149.11.228.19 (149.11.228.19) 9.506 ms 9.466 ms 9.420 ms
7 [AS33182] po172.asw02.fra5.tfbnw.net (129.134.108.146) 9.725 ms 9.874 ms 9.696 ms
8 [AS32934] psw04.fra5.tfbnw.net (157.240.59.85) 8.718 ms 8.691 ms 8.618 ms
9 * * *
10 [AS0] edge-star-mini-shv-01-fra5.facebook.com (57.144.244.1) 9.747 ms 9.815 ms 9.699 ms
[10 lines not shown]
traceroute: MFC: graceful recover after networking errors with as_server
Currently, the traceroute[6] utility does not check
for possible networking errors while talking to as_server
in case of "traceroute -a". Meantime, there is a common case
when trace is long and it has many non-responding hops
(shown as '* * *'), so as_server aborts our connection,
hence no AS numbers shown for the rest of trace.
Somewhat artifical way to reproduce the problem:
traceroute to 57.144.244.1 (57.144.244.1), 80 hops max, 48 byte packets
5 [AS174] be2950.ccr42.fra05.atlas.cogentco.com (154.54.72.42) 74.277 ms 9.605 ms 9.599 ms
6 [AS174] 149.11.228.19 (149.11.228.19) 9.506 ms 9.466 ms 9.420 ms
7 [AS33182] po172.asw02.fra5.tfbnw.net (129.134.108.146) 9.725 ms 9.874 ms 9.696 ms
8 [AS32934] psw04.fra5.tfbnw.net (157.240.59.85) 8.718 ms 8.691 ms 8.618 ms
9 * * *
10 [AS0] edge-star-mini-shv-01-fra5.facebook.com (57.144.244.1) 9.747 ms 9.815 ms 9.699 ms
[10 lines not shown]
traceroute: MFC: graceful recover after networking errors with as_server
Currently, the traceroute[6] utility does not check
for possible networking errors while talking to as_server
in case of "traceroute -a". Meantime, there is a common case
when trace is long and it has many non-responding hops
(shown as '* * *'), so as_server aborts our connection,
hence no AS numbers shown for the rest of trace.
Somewhat artifical way to reproduce the problem:
traceroute to 57.144.244.1 (57.144.244.1), 80 hops max, 48 byte packets
5 [AS174] be2950.ccr42.fra05.atlas.cogentco.com (154.54.72.42) 74.277 ms 9.605 ms 9.599 ms
6 [AS174] 149.11.228.19 (149.11.228.19) 9.506 ms 9.466 ms 9.420 ms
7 [AS33182] po172.asw02.fra5.tfbnw.net (129.134.108.146) 9.725 ms 9.874 ms 9.696 ms
8 [AS32934] psw04.fra5.tfbnw.net (157.240.59.85) 8.718 ms 8.691 ms 8.618 ms
9 * * *
10 [AS0] edge-star-mini-shv-01-fra5.facebook.com (57.144.244.1) 9.747 ms 9.815 ms 9.699 ms
[10 lines not shown]
