Re: A christmassy related issue with traceroute
On 2014-12-26, Michael lesniewskis...@gmail.com wrote: Apologies, I must've missed something that was mentioned in the man pages, in OpenBSD it seems that addresses are printed for each attempt rather than (the other OS' tested, Win, Debian, Android) that seem to take the first returned name for example It just seemed odd as both the man pages on the other os' and OpenBSD state that three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time. It is just the first time I have seen this as other os that I have had experience of show things differently (as below). At least one of the ISPs showing in your traceroute is using multipath routing, some of the packets you are sending take a different path to others. traceroute is simply showing you which routers returned those packets. If other traceroute programs don't show this, then either they are doing something different that causes the same path to be taken for all packets (perhaps they are using icmp instead of udp) or perhaps they are just hiding some of the information.
Re: A christmassy related issue with traceroute
On 2014-12-26, Michael lesniewskis...@gmail.com wrote: Apologies, I must've missed something that was mentioned in the man pages, in OpenBSD it seems that addresses are printed for each attempt rather than (the other OS' tested, Win, Debian, Android) that seem to take the first returned name for example It just seemed odd as both the man pages on the other os' and OpenBSD state that three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time. It is just the first time I have seen this as other os that I have had experience of show things differently (as below). At least one of the ISPs showing in your traceroute is using multipath routing, some of the packets you are sending take a different path to others. traceroute is simply showing you which routers returned those packets. If other traceroute programs don't show this, then either they are doing something different that causes the same path to be taken for all packets (perhaps they are using icmp instead of udp) or perhaps they are just hiding some of the information. Or I'll say it my way; They are dumbing down how the internet works, for well, you decide who they are doing that for. In general every packet takes own way, and presuming otherwise is a trap.
Re: A christmassy related issue with traceroute
Apologies, I must've missed something that was mentioned in the man pages, in OpenBSD it seems that addresses are printed for each attempt rather than (the other OS' tested, Win, Debian, Android) that seem to take the first returned name for example It just seemed odd as both the man pages on the other os' and OpenBSD state that three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time. It is just the first time I have seen this as other os that I have had experience of show things differently (as below). I don't understand why this default wrong behaviour is shown for others but figured this may be useful in the archives for others that don't understand the internet. 1072 ms 162 ms 983 ms ae53.edge2.newyork1.level3.net [4.71.230.101] 11 1245 ms 546 ms 2950 ms ae-240-3616.edge6.london1.level3.net [4.69.166.93] 12 127 ms 151 ms 165 ms ae-240-3616.edge6.london1.level3.net [4.69.166.93] 13 678 ms 2879 ms 245 ms high-speed.edge6.london1.level3.net [195.50.90.134] 14 1598 ms 999 ms 140 ms xe-3-4.core00.sov.uk.hso-group.net [46.17.60.173] 15 633 ms 2848 ms 140 ms xe-4-1.core00.tch.uk.hso-group.net [77.75.108.149] 16 3480 ms 572 ms 441 ms xe-4-1.core00.hex.uk.hso-group.net [77.75.108.153] 17 2853 ms 538 ms * xe-4-4.core00.lhc.uk.hso-group.net [77.75.108.158] 18 472 ms 1152 ms 569 ms xe-4-4.core00.tut.uk.hso-group.net [77.75.108.156] 19 2232 ms 574 ms * xe-4-1.core00.gs1.uk.hso-group.net [77.75.108.154] 20 543 ms 1654 ms 562 ms ae0-1203.edge00.sov.uk.hso-group.net [46.17.60.117] 21 1393 ms 198 ms 746 ms xoxoxoxoxoxo.ho.ho.ho.xoxoxoxoxoxo [93.89.84.75] 22 1195 ms 441 ms 173 ms xooxooo.v.ooxx [82.133.91.37] 23 475 ms 522 ms 226 ms ooxoxo.mmm.xxoooxo [82.133.91.18] 24 364 ms 3218 ms 638 ms oooxoxooo.e.oooxox [82.133.91.63] 25 143 ms 1862 ms 238 ms xooxooox.rrr.ooxox [82.133.91.56] 26 886 ms 745 ms 567 ms oxooxoo.r.oooxooxo [82.133.91.55] 27 * 431 ms * xoooxo.yyy.oooxxoo [82.133.91.58] 28 335 ms 118 ms 154 ms ooxoxo.ccc.xoooxoo [82.133.91.96] 29 2462 ms 1113 ms 554 ms oxooo.h.oxooox [82.133.91.23] 30 736 ms 1126 ms 153 ms ooxooxoo.rrr.ooxoooxoo [82.133.91.49] 31 309 ms 2658 ms 850 ms oxoooxo.i.oooxooxo [82.133.91.60] 32 271 ms 957 ms 3498 ms oooxoo.sss.oox [82.133.91.42] 33 934 ms 561 ms 2909 ms oooxoooxoo.ttt.xoo [82.133.91.61] 34 * 491 ms 2098 ms ooxoo.mm.oooxo [82.133.91.34] 35 112 ms 162 ms 558 ms xxoo..oxoo [82.133.91.80] 36 200 ms 343 ms 1077 ms oxo.ss.ooo [82.133.91.40] 37 1835 ms 471 ms 1073 ms ooxooo.xxx.oxo [82.133.91.35] 38 1418 ms 562 ms 1270 ms ox.xxx.xxo [82.133.91.10] 39 * 491 ms 554 ms oh.the.weather.outside.is.frightful [82.133.91.41] 40 142 ms 441 ms 551 ms but.the.fire.is.so.delightful [82.133.91.19] 41 561 ms * 492 ms and.since.weve.no.place.to.go [82.133.91.77] 42 3204 ms 558 ms 130 ms let.it.snow.let.it.snow.let.it.snow [82.133.91.43] 43 3431 ms 390 ms 698 ms xxx [82.133.91.24] 44 171 ms 1214 ms 118 ms it.doesnt.show.signs.of.stopping [82.133.91.36] 45 566 ms 3458 ms 550 ms and.ive.bought.some.corn.for.popping [82.133.91.73] 46 2168 ms 741 ms 555 ms the.lights.are.turned.way.down.low [82.133.91.76] 47 3315 ms 570 ms * let.it.snow.let.it.snow.let.it.snow [82.133.91.67] 48 124 ms 421 ms 598 ms xxx [82.133.91.38] 49 203 ms 1718 ms 194 ms when.we.finally.kiss.good.night [82.133.91.62] 50 332 ms * 918 ms how.ill.hate.going.out.in.the.storm [82.133.91.45] 51 498 ms 118 ms 116 ms but.if.youll.really.hold.me.tight [82.133.91.78] 52 2269 ms 549 ms * all.the.way.home.ill.be.warm [82.133.91.17] 53 759 ms * 496 ms xxx [82.133.91.70] 54 2375 ms 553 ms 1803 ms the.fire.is.slowly.dying [82.133.91.95] 55 555 ms 717 ms 550 ms and.my.dear.were.still.goodbying [82.133.91.57] 56 1950 ms 550 ms 1898 ms but.as.long.as.you.love.me.so [82.133.91.31] 57 2289 ms 108 ms 122 ms let.it.snow.let.it.snow.let.it.snow [82.133.91.53] 58 2782 ms 269 ms 141 ms ooo [82.133.91.94] 59 180 ms 150 ms 135 ms ho.ho.ho.are.we.having.fun.yet [82.133.91.64] 60 2707 ms 550 ms 570 ms m.e.r.r.y.c.h.r.i.s.t.m.a.s [82.133.91.86] 61 1421 ms 565 ms 455 ms ooo [82.133.91.15] 62 2127 ms 565 ms 519 ms dashing.through.the.snow [82.133.91.14] 63 2969 ms 570 ms 387 ms in.a.one-horse.open.sleigh [82.133.91.83] 64 1181 ms 141 ms
Re: A christmassy related issue with traceroute
On Wed, Dec 24, 2014 at 7:26 PM, Mike lesniewskis...@gmail.com wrote: Hi All, While performing an install and catching up with some Christmas spirited news, I heard that someone had put a Christmas song in DNS records for our enjoyment. Alas, I was disappointed to see that the OpenBSD traceroute seems to munge the output. :( To test, run traceroute -m 255 xmas.futile.net Oh, that just won't do. See if you get better results with this instead: traceroute -q1 -m 255 xmas.futile.net
Re: A christmassy related issue with traceroute
Alas, I was disappointed to see that the OpenBSD traceroute seems to munge the output. :( Guess you don't understand internet.