From randy at psg.com Mon Oct 1 16:07:14 2012 From: randy at psg.com (Randy Bush) Date: Mon, 01 Oct 2012 15:07:14 +0100 Subject: [atlas] 10/8 Message-ID: an external border, where an atlas probe is on the soft gooey inside, logged packets sourced from 10/8? could this have been the atlas probe? randy Sep 29 08:36:44 r0.sea.rg.net 390: Sep 29 08:36:43.966: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53649) -> 23.63.172.166(443), 1 packet Sep 29 08:36:49 r0.sea.rg.net 391: Sep 29 08:36:48.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46959) -> 23.63.205.115(443), 1 packet Sep 29 08:42:32 r0.sea.rg.net 392: Sep 29 08:42:31.363: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53649) -> 23.63.172.166(443), 1 packet Sep 29 11:24:45 r0.sea.rg.net 393: Sep 29 11:24:44.826: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(32986) -> 64.12.235.15(443), 1 packet Sep 29 11:31:35 r0.sea.rg.net 394: Sep 29 11:31:34.644: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53512) -> 143.225.229.137(554), 1 packet Sep 29 11:37:32 r0.sea.rg.net 395: Sep 29 11:37:31.453: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53512) -> 143.225.229.137(554), 8 packets Sep 29 11:43:21 r0.sea.rg.net 396: Sep 29 11:43:20.339: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(59262) -> 38.102.136.104(80), 1 packet Sep 29 11:43:33 r0.sea.rg.net 397: Sep 29 11:43:32.151: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60780) -> 69.171.228.74(443), 1 packet Sep 29 11:45:23 r0.sea.rg.net 398: Sep 29 11:45:22.013: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60761) -> 69.171.228.74(443), 1 packet Sep 29 11:45:26 r0.sea.rg.net 399: Sep 29 11:45:25.017: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60759) -> 69.171.228.74(443), 1 packet Sep 29 11:48:57 r0.sea.rg.net 400: Sep 29 11:48:56.480: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46352) -> 174.37.29.147(80), 1 packet Sep 29 11:49:32 r0.sea.rg.net 401: Sep 29 11:49:31.465: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60780) -> 69.171.228.74(443), 1 packet Sep 29 11:49:32 r0.sea.rg.net 402: Sep 29 11:49:31.465: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60781) -> 69.171.228.74(443), 2 packets Sep 29 11:50:32 r0.sea.rg.net 403: Sep 29 11:50:31.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60761) -> 69.171.228.74(443), 1 packet Sep 29 11:50:32 r0.sea.rg.net 404: Sep 29 11:50:31.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60759) -> 69.171.228.74(443), 1 packet Sep 29 11:54:32 r0.sea.rg.net 405: Sep 29 11:54:31.469: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46352) -> 174.37.29.147(80), 1 packet Sep 29 12:10:05 r0.sea.rg.net 406: Sep 29 12:10:04.260: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60333) -> 193.0.6.139(443), 1 packet Sep 29 12:10:11 r0.sea.rg.net 407: Sep 29 12:10:10.292: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60348) -> 193.0.6.139(443), 1 packet Sep 29 12:10:24 r0.sea.rg.net 408: Sep 29 12:10:22.640: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60363) -> 193.0.6.139(443), 1 packet Sep 29 12:13:30 r0.sea.rg.net 409: Sep 29 12:13:29.535: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33721) -> 193.0.6.133(443), 1 packet Sep 29 12:14:10 r0.sea.rg.net 410: Sep 29 12:14:09.435: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(37936) -> 178.63.78.16(80), 1 packet Sep 29 12:14:29 r0.sea.rg.net 411: Sep 29 12:14:28.256: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33754) -> 193.0.6.133(443), 1 packet Sep 29 12:15:32 r0.sea.rg.net 412: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60348) -> 193.0.6.139(443), 2 packets Sep 29 12:15:32 r0.sea.rg.net 413: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60363) -> 193.0.6.139(443), 1 packet Sep 29 12:15:32 r0.sea.rg.net 414: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60364) -> 193.0.6.139(443), 2 packets Sep 29 12:15:32 r0.sea.rg.net 415: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60366) -> 193.0.6.139(443), 2 packets Sep 29 12:19:32 r0.sea.rg.net 416: Sep 29 12:19:31.492: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(37936) -> 178.63.78.16(80), 2 packets Sep 29 12:19:32 r0.sea.rg.net 417: Sep 29 12:19:31.492: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33754) -> 193.0.6.133(443), 2 packets Sep 29 12:21:00 r0.sea.rg.net 418: Sep 29 12:20:59.386: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39687) -> 206.219.196.114(443), 1 packet Sep 29 12:21:42 r0.sea.rg.net 419: Sep 29 12:21:41.318: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39683) -> 206.219.196.114(443), 1 packet Sep 29 12:23:57 r0.sea.rg.net 420: Sep 29 12:23:56.533: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56161) -> 88.221.216.66(80), 1 packet Sep 29 12:24:20 r0.sea.rg.net 421: Sep 29 12:24:19.673: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39741) -> 206.219.196.114(443), 1 packet Sep 29 12:26:32 r0.sea.rg.net 422: Sep 29 12:26:31.499: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39687) -> 206.219.196.114(443), 2 packets Sep 29 12:27:32 r0.sea.rg.net 423: Sep 29 12:27:31.500: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39683) -> 206.219.196.114(443), 10 packets Sep 29 12:28:53 r0.sea.rg.net 424: Sep 29 12:28:52.193: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(44361) -> 64.12.104.224(443), 1 packet Sep 29 12:29:32 r0.sea.rg.net 425: Sep 29 12:29:31.502: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56162) -> 88.221.216.66(80), 7 packets Sep 29 12:29:32 r0.sea.rg.net 426: Sep 29 12:29:31.502: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56161) -> 88.221.216.66(80), 6 packets From philip.homburg at ripe.net Mon Oct 1 16:11:48 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 01 Oct 2012 16:11:48 +0200 Subject: [atlas] 10/8 In-Reply-To: References: Message-ID: <5069A4A4.6050200@ripe.net> On 10/1/12 16:07 , Randy Bush wrote: > an external border, where an atlas probe is on the soft gooey inside, > logged packets sourced from 10/8? could this have been the atlas probe? > > It is likely. Maybe you can compare with the list of UDMs on the probe? From randy at psg.com Mon Oct 1 17:04:12 2012 From: randy at psg.com (Randy Bush) Date: Mon, 01 Oct 2012 16:04:12 +0100 Subject: [atlas] 10/8 In-Reply-To: <5069A4A4.6050200@ripe.net> References: <5069A4A4.6050200@ripe.net> Message-ID: >> an external border, where an atlas probe is on the soft gooey inside, >> logged packets sourced from 10/8? could this have been the atlas probe? > It is likely. Maybe you can compare with the list of UDMs on the probe? uh, how can i tell source address of the udms? randy -------------- next part -------------- A non-text attachment was scrubbed... Name: udm.jpg Type: image/jpeg Size: 89487 bytes Desc: not available URL: From philip.homburg at ripe.net Mon Oct 1 17:23:48 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 01 Oct 2012 17:23:48 +0200 Subject: [atlas] 10/8 In-Reply-To: References: <5069A4A4.6050200@ripe.net> Message-ID: <5069B584.5000608@ripe.net> On 10/1/12 17:04 , Randy Bush wrote: >>> an external border, where an atlas probe is on the soft gooey inside, >>> logged packets sourced from 10/8? could this have been the atlas probe? >> It is likely. Maybe you can compare with the list of UDMs on the probe? > uh, how can i tell source address of the udms? > > For UDMs you can't. But if you go to the log download and then download the logs for measurement '1' (Traceroute first hop) it should be there. The weird thing is that the TCP connection to '23.63.172.166(443)' is as far as I know not a static measurement and it does not appear in the list of UDMs either. From astrikos at ripe.net Mon Oct 1 17:54:51 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 1 Oct 2012 17:54:51 +0200 Subject: [atlas] 10/8 In-Reply-To: References: Message-ID: I don't think is an atlas probe. 193.0.6.133 points to access.ripe.net which we use to connect to RIPE NCC SSO accounts. So my guess is that it's someone that's using browser most probably... Regards, Andreas On Oct 1, 2012, at 4:07 PM, Randy Bush wrote: > an external border, where an atlas probe is on the soft gooey inside, > logged packets sourced from 10/8? could this have been the atlas probe? > > randy > > Sep 29 08:36:44 r0.sea.rg.net 390: Sep 29 08:36:43.966: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53649) -> 23.63.172.166(443), 1 packet > Sep 29 08:36:49 r0.sea.rg.net 391: Sep 29 08:36:48.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46959) -> 23.63.205.115(443), 1 packet > Sep 29 08:42:32 r0.sea.rg.net 392: Sep 29 08:42:31.363: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53649) -> 23.63.172.166(443), 1 packet > Sep 29 11:24:45 r0.sea.rg.net 393: Sep 29 11:24:44.826: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(32986) -> 64.12.235.15(443), 1 packet > Sep 29 11:31:35 r0.sea.rg.net 394: Sep 29 11:31:34.644: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53512) -> 143.225.229.137(554), 1 packet > Sep 29 11:37:32 r0.sea.rg.net 395: Sep 29 11:37:31.453: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53512) -> 143.225.229.137(554), 8 packets > Sep 29 11:43:21 r0.sea.rg.net 396: Sep 29 11:43:20.339: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(59262) -> 38.102.136.104(80), 1 packet > Sep 29 11:43:33 r0.sea.rg.net 397: Sep 29 11:43:32.151: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60780) -> 69.171.228.74(443), 1 packet > Sep 29 11:45:23 r0.sea.rg.net 398: Sep 29 11:45:22.013: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60761) -> 69.171.228.74(443), 1 packet > Sep 29 11:45:26 r0.sea.rg.net 399: Sep 29 11:45:25.017: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60759) -> 69.171.228.74(443), 1 packet > Sep 29 11:48:57 r0.sea.rg.net 400: Sep 29 11:48:56.480: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46352) -> 174.37.29.147(80), 1 packet > Sep 29 11:49:32 r0.sea.rg.net 401: Sep 29 11:49:31.465: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60780) -> 69.171.228.74(443), 1 packet > Sep 29 11:49:32 r0.sea.rg.net 402: Sep 29 11:49:31.465: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60781) -> 69.171.228.74(443), 2 packets > Sep 29 11:50:32 r0.sea.rg.net 403: Sep 29 11:50:31.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60761) -> 69.171.228.74(443), 1 packet > Sep 29 11:50:32 r0.sea.rg.net 404: Sep 29 11:50:31.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60759) -> 69.171.228.74(443), 1 packet > Sep 29 11:54:32 r0.sea.rg.net 405: Sep 29 11:54:31.469: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46352) -> 174.37.29.147(80), 1 packet > Sep 29 12:10:05 r0.sea.rg.net 406: Sep 29 12:10:04.260: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60333) -> 193.0.6.139(443), 1 packet > Sep 29 12:10:11 r0.sea.rg.net 407: Sep 29 12:10:10.292: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60348) -> 193.0.6.139(443), 1 packet > Sep 29 12:10:24 r0.sea.rg.net 408: Sep 29 12:10:22.640: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60363) -> 193.0.6.139(443), 1 packet > Sep 29 12:13:30 r0.sea.rg.net 409: Sep 29 12:13:29.535: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33721) -> 193.0.6.133(443), 1 packet > Sep 29 12:14:10 r0.sea.rg.net 410: Sep 29 12:14:09.435: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(37936) -> 178.63.78.16(80), 1 packet > Sep 29 12:14:29 r0.sea.rg.net 411: Sep 29 12:14:28.256: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33754) -> 193.0.6.133(443), 1 packet > Sep 29 12:15:32 r0.sea.rg.net 412: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60348) -> 193.0.6.139(443), 2 packets > Sep 29 12:15:32 r0.sea.rg.net 413: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60363) -> 193.0.6.139(443), 1 packet > Sep 29 12:15:32 r0.sea.rg.net 414: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60364) -> 193.0.6.139(443), 2 packets > Sep 29 12:15:32 r0.sea.rg.net 415: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60366) -> 193.0.6.139(443), 2 packets > Sep 29 12:19:32 r0.sea.rg.net 416: Sep 29 12:19:31.492: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(37936) -> 178.63.78.16(80), 2 packets > Sep 29 12:19:32 r0.sea.rg.net 417: Sep 29 12:19:31.492: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33754) -> 193.0.6.133(443), 2 packets > Sep 29 12:21:00 r0.sea.rg.net 418: Sep 29 12:20:59.386: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39687) -> 206.219.196.114(443), 1 packet > Sep 29 12:21:42 r0.sea.rg.net 419: Sep 29 12:21:41.318: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39683) -> 206.219.196.114(443), 1 packet > Sep 29 12:23:57 r0.sea.rg.net 420: Sep 29 12:23:56.533: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56161) -> 88.221.216.66(80), 1 packet > Sep 29 12:24:20 r0.sea.rg.net 421: Sep 29 12:24:19.673: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39741) -> 206.219.196.114(443), 1 packet > Sep 29 12:26:32 r0.sea.rg.net 422: Sep 29 12:26:31.499: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39687) -> 206.219.196.114(443), 2 packets > Sep 29 12:27:32 r0.sea.rg.net 423: Sep 29 12:27:31.500: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39683) -> 206.219.196.114(443), 10 packets > Sep 29 12:28:53 r0.sea.rg.net 424: Sep 29 12:28:52.193: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(44361) -> 64.12.104.224(443), 1 packet > Sep 29 12:29:32 r0.sea.rg.net 425: Sep 29 12:29:31.502: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56162) -> 88.221.216.66(80), 7 packets > Sep 29 12:29:32 r0.sea.rg.net 426: Sep 29 12:29:31.502: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56161) -> 88.221.216.66(80), 6 packets > From max+ratlml at grobecker.info Mon Oct 1 21:50:12 2012 From: max+ratlml at grobecker.info (Max Grobecker) Date: Mon, 01 Oct 2012 21:50:12 +0200 Subject: [atlas] Strange IPv6 problem with Atlas Message-ID: <5069F3F4.9000909@grobecker.info> Hello, I got my new Atlas a few days ago and connected it to my network (in a separated VLAN). In this VLAN I'm announcing routing advertisements with autonomous IPv6 addressing enabled. Appearently the probe heard this advertisement and have chosen to communicate over IPv6 - but with a link-local IPv6 address only...?! This leads to "Beyond scope"-Messages from my router which I captured with tcpdump: fe80::280:a3ff:fe91:4070.58730 > 2a01:4f8:161:3281::43:148.443: Flags [S], seq 2585125851, win 5360, options [mss 1340,sackOK,TS val 4294950236 ecr 0,nop,wscale 1] fe80::225:90ff:fe92:2478 > fe80::280:a3ff:fe91:4070: ICMP6, destination unreachable, beyond scope 2a01:4f8:161:3281::43:148, source address fe80::280:a3ff:fe91:4070 My routing advertisements are currently looking like that: fe80::225:90ff:fe92:2478 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64 hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s prefix info option (3), length 32 (4): 2a02:a00:e000:b:e6::/96, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s mtu option (5), length 8 (1): 1400 source link-address option (1), length 8 (1): 00:25:90:92:24:78 Is there anything I can do to make the probe communicate over IPv6? Manual IP configuration is not possible since the menu item is greyed out (althrough my probe runs on FW 4470). I disabled RA at the moment so the Atlas cube can talk to the RIPEs Atlas servers. Thank you in advance! -- Greetings from Wuppertal, Germany Max Grobecker From philip.homburg at ripe.net Mon Oct 1 21:56:35 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 01 Oct 2012 21:56:35 +0200 Subject: [atlas] Strange IPv6 problem with Atlas In-Reply-To: <5069F3F4.9000909@grobecker.info> References: <5069F3F4.9000909@grobecker.info> Message-ID: <5069F573.7040608@ripe.net> On 10/1/12 21:50 , Max Grobecker wrote: > My routing advertisements are currently looking like that: > > fe80::225:90ff:fe92:2478 > ff02::1: [icmp6 sum ok] ICMP6, router > advertisement, length 64 > hop limit 64, Flags [none], pref medium, router lifetime 1800s, > reachable time 0s, retrans time 0s > prefix info option (3), length 32 (4): 2a02:a00:e000:b:e6::/96, Flags > [onlink, auto, router], valid time 86400s, pref. time 14400s > mtu option (5), length 8 (1): 1400 > source link-address option (1), length 8 (1): 00:25:90:92:24:78 > > > A /96 is not according the specs. For SLAAC on ethernet you need to have a /64. From lorenzo at google.com Tue Oct 2 03:14:03 2012 From: lorenzo at google.com (Lorenzo Colitti) Date: Tue, 2 Oct 2012 10:14:03 +0900 Subject: [atlas] Strange IPv6 problem with Atlas In-Reply-To: <5069F573.7040608@ripe.net> References: <5069F3F4.9000909@grobecker.info> <5069F573.7040608@ripe.net> Message-ID: On Tue, Oct 2, 2012 at 4:56 AM, Philip Homburg wrote: > > fe80::225:90ff:fe92:2478 > ff02::1: [icmp6 sum ok] ICMP6, router > > advertisement, length 64 > > hop limit 64, Flags [none], pref medium, router lifetime 1800s, > > reachable time 0s, retrans time 0s > > prefix info option (3), length 32 (4): 2a02:a00:e000:b:e6::/96, Flags > > [onlink, auto, router], valid time 86400s, pref. time 14400s > > mtu option (5), length 8 (1): 1400 > > source link-address option (1), length 8 (1): 00:25:90:92:24:78 > > A /96 is not according the specs. For SLAAC on ethernet you need to have > a /64. > Agreed. This will not work. That said - why is SSH trying to communicate over IPv6 with a link-local address in the first place? getaddrinfo should be ranking the global IPv4 address above the link-local IPv6 address and thus causing SSH to prefer IPv4... -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue Oct 2 09:34:15 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 02 Oct 2012 09:34:15 +0200 Subject: [atlas] Strange IPv6 problem with Atlas In-Reply-To: References: <5069F3F4.9000909@grobecker.info> <5069F573.7040608@ripe.net> Message-ID: <506A98F7.8070306@ripe.net> On 10/2/12 3:14 , Lorenzo Colitti wrote: > > > That said - why is SSH trying to communicate over IPv6 with a > link-local address in the first place? getaddrinfo should be ranking > the global IPv4 address above the link-local IPv6 address and thus > causing SSH to prefer IPv4... I have to check, but my guess is that no sorting is being done at all. The probe software is built on top of ucLinux. Large parts of ucLinux are reimplementations with a focus on compactness. I wondered why we never noticed this before. The reason is two fold. One is that dbclient is just about the only part in the Atlas software that can choose between IPv4 and IPv6. All other parts get told to do one or the other. The other reason is that a probe on an IPv4-only LAN will not have an IPv6 default router. So any attempt to use the link local address to connect will remain hidden within the probe. From tibor.djurica at ojdip.net Wed Oct 3 17:02:48 2012 From: tibor.djurica at ojdip.net (Tibor Djurica Potpara) Date: Wed, 03 Oct 2012 17:02:48 +0200 Subject: [atlas] Cannot change network configuration Message-ID: <506C5398.6050604@ojdip.net> Hello, I have recently changed the router that my Atlas probe is connected to. Since it is now in a separate subnet from my home LAN, with dedicated DHCP/RA configuration, there is no longer need for static address configuration, so I would like to revert its settings back to autoconfiguration for both IPv4 and IPv6. However, in the web interface,//"Change Probe's Network Configuration" menu is greyed out, so I cannot do anything even though the probe is up. What am I to do? Thank you, Tibor -------------- next part -------------- An HTML attachment was scrubbed... URL: From dquinn at ripe.net Wed Oct 3 17:15:42 2012 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 03 Oct 2012 17:15:42 +0200 Subject: [atlas] Cannot change network configuration In-Reply-To: <506C5398.6050604@ojdip.net> References: <506C5398.6050604@ojdip.net> Message-ID: <506C569E.3040404@ripe.net> On 10/03/2012 05:02 PM, Tibor Djurica Potpara wrote: > I have recently changed the router that my Atlas probe is connected > to. Since it is now in a separate subnet from my home LAN, with > dedicated DHCP/RA configuration, there is no longer need for static > address configuration, so I would like to revert its settings back to > autoconfiguration for both IPv4 and IPv6. > > However, in the web interface,//"Change Probe's Network Configuration" > menu is greyed out, so I cannot do anything even though the probe is up. There was an issue with some code that we deployed recently that caused some problems with the static configuration of probes. As a temporary stop-gap measure, we disabled this feature on the site and have since worked to repair the issue in development. We will be deploying a new version of the site next week, at which point this feature will be stable and re-enabled. Unfortunately, you will have to wait until then. My apologies for any inconvenience this may have caused. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jprins at betterbe.com Wed Oct 3 22:54:31 2012 From: jprins at betterbe.com (Jan Hugo Prins) Date: Wed, 03 Oct 2012 22:54:31 +0200 Subject: [atlas] Cannot change network configuration In-Reply-To: <506C569E.3040404@ripe.net> References: <506C5398.6050604@ojdip.net> <506C569E.3040404@ripe.net> Message-ID: <506CA607.4070905@betterbe.com> On 10/03/2012 05:15 PM, Daniel Quinn wrote: > There was an issue with some code that we deployed recently that caused > some problems with the static configuration of probes. As a temporary > stop-gap measure, we disabled this feature on the site and have since > worked to repair the issue in development. Is this also the reason that the probe that I received last week died on it's static IP configuration (Ticket 1060049)? -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra consultant E: jprins at betterbe.com T: +31-53-4800694 M: +31-6-26358951 S: jhaprins W: www.betterbe.com From philip.homburg at ripe.net Thu Oct 4 10:53:48 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 04 Oct 2012 10:53:48 +0200 Subject: [atlas] Cannot change network configuration In-Reply-To: <506CA607.4070905@betterbe.com> References: <506C5398.6050604@ojdip.net> <506C569E.3040404@ripe.net> <506CA607.4070905@betterbe.com> Message-ID: <506D4E9C.1080209@ripe.net> On 10/3/12 22:54 , Jan Hugo Prins wrote: > On 10/03/2012 05:15 PM, Daniel Quinn wrote: >> There was an issue with some code that we deployed recently that caused >> some problems with the static configuration of probes. As a temporary >> stop-gap measure, we disabled this feature on the site and have since >> worked to repair the issue in development. > Is this also the reason that the probe that I received last week died on > it's static IP configuration (Ticket 1060049)? > Unfortunately, yes. From robert at ripe.net Thu Oct 4 11:14:49 2012 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 04 Oct 2012 11:14:49 +0200 Subject: [atlas] Forcing https in Atlas Message-ID: <506D5389.4070608@ripe.net> Dear Atlas users, At the moment the Atlas UI servers allow regular, unsecured (http) connections from clients. For particular features, most notably anything that requires authenticated users, we're using secure (https) connections. Unfortunately, the potential mixing of the two schemes causes glitches and inconsistencies for some users. Therefore on 15 October we will start enforcing secure connections towards the Atlas UI servers (atlas.ripe.net and *.atlas.ripe.net). We'll do this by automatically redirecting all http queries to their https equivalents. This should not cause any changes to those of you who already use https by default, and should not cause any notable changes to anyone else. However, some clients (especially CLI based ones) may need some extra flags to deal with https connections. Regards, Robert Kisteleki From BECHA at ripe.net Fri Oct 5 15:39:48 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 05 Oct 2012 15:39:48 +0200 Subject: [atlas] RIPE Atlas roadmap, September 2012 version Message-ID: <506EE324.4080004@ripe.net> [apologies for duplicates] Dear colleagues, we just published a RIPE Labs article with the RIPE Atlas roadmap update for September: https://labs.ripe.net/Members/becha/ripe-atlas-roadmap-september-2012-update (the fact that is already October today is a bit confusing, but we presented this version during the RIPE 65 meeting last week...) This is the invitation to look at our plans, and let us know what you think, so that we can take that into account when making new plans, next month. Thanks, Vesna From sebastian.wiesinger at noris.net Fri Oct 5 16:21:50 2012 From: sebastian.wiesinger at noris.net (Sebastian Wiesinger) Date: Fri, 5 Oct 2012 16:21:50 +0200 Subject: [atlas] Ping does no longer visualize? Message-ID: <20121005142149.GA11652@sol.office.noris.de> Hi, I just noticed that the Ping probe has changed, I can now enter more options but I'm unable to visualize the results. Even if I uncheck "do not visualize" I get no graphs. Regards Sebastian -- noris network AG - Thomas-Mann-Stra?e 16-20 - D-90471 N?rnberg Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG N?rnberg HRB 17689 From vnaumov at ripe.net Fri Oct 5 16:40:12 2012 From: vnaumov at ripe.net (Viktor Naumov) Date: Fri, 05 Oct 2012 16:40:12 +0200 Subject: [atlas] Ping does no longer visualize? In-Reply-To: <20121005142149.GA11652@sol.office.noris.de> References: <20121005142149.GA11652@sol.office.noris.de> Message-ID: <506EF14C.20200@ripe.net> Hi Sebastian, There is a limitation. If you use >= 20 probes, ping visualisation will be disabled. If this its not the case please let us know. Thank you for using Atlas. victor On 10/5/12 4:21 PM, Sebastian Wiesinger wrote: > Hi, > > I just noticed that the Ping probe has changed, I can now enter more > options but I'm unable to visualize the results. Even if I uncheck "do > not visualize" I get no graphs. > > Regards > > Sebastian > From sebastian.wiesinger at noris.net Fri Oct 5 16:46:15 2012 From: sebastian.wiesinger at noris.net (Sebastian Wiesinger) Date: Fri, 5 Oct 2012 16:46:15 +0200 Subject: [atlas] Ping does no longer visualize? In-Reply-To: <506EF14C.20200@ripe.net> References: <20121005142149.GA11652@sol.office.noris.de> <506EF14C.20200@ripe.net> Message-ID: <20121005144615.GB11652@sol.office.noris.de> * Viktor Naumov [2012-10-05 16:40]: > Hi Sebastian, > > There is a limitation. If you use >= 20 probes, ping visualisation > will be disabled. > If this its not the case please let us know. Ups, yes I used 30 probes. :) Thank you for the explanation. Regards Sebastian -- noris network AG - Thomas-Mann-Stra?e 16-20 - D-90471 N?rnberg Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG N?rnberg HRB 17689 From jprins at betterbe.com Tue Oct 9 21:17:54 2012 From: jprins at betterbe.com (Jan Hugo Prins) Date: Tue, 09 Oct 2012 21:17:54 +0200 Subject: [atlas] Convert json traceroute output to normal traceroutes. Message-ID: <50747862.90407@betterbe.com> Hi, Because I'm a little more used to reading regular traceroute output instead of JSON files, I created a little python script to convert the ATLAS traceroute output to readable traceroutes. Comments are always welcome ofcourse. The whois information is gathered from Cymru using: https://github.com/JustinAzoff/python-cymruwhois -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra consultant E: jprins at betterbe.com T: +31-53-4800694 M: +31-6-26358951 S: jhaprins W: www.betterbe.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: json2traceroute.py URL: From bortzmeyer at nic.fr Wed Oct 10 09:46:55 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 10 Oct 2012 09:46:55 +0200 Subject: [atlas] Convert json traceroute output to normal traceroutes. In-Reply-To: <50747862.90407@betterbe.com> References: <50747862.90407@betterbe.com> Message-ID: <20121010074655.GA27701@nic.fr> On Tue, Oct 09, 2012 at 09:17:54PM +0200, Jan Hugo Prins wrote a message of 111 lines which said: > Because I'm a little more used to reading regular traceroute output > instead of JSON files, It would be better if Atlas used the standard structured format for traceroute output, RFC 5388. From jens.weibler at h-da.de Wed Oct 10 11:29:27 2012 From: jens.weibler at h-da.de (Jens Weibler) Date: Wed, 10 Oct 2012 11:29:27 +0200 Subject: [atlas] traceroute via ICMP? Message-ID: <50753FF7.9030206@h-da.de> Hi, how is the development of traceroute via ICMP going? My central firewall team doesn't like opening many udp-ports for traceroute :( -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Sch?fferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler at h-da.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4703 bytes Desc: S/MIME Cryptographic Signature URL: From jprins at betterbe.com Wed Oct 10 11:39:52 2012 From: jprins at betterbe.com (Jan Hugo Prins) Date: Wed, 10 Oct 2012 11:39:52 +0200 Subject: [atlas] traceroute via ICMP? In-Reply-To: <50753FF7.9030206@h-da.de> References: <50753FF7.9030206@h-da.de> Message-ID: <50754268.1040609@betterbe.com> On 10/10/2012 11:29 AM, Jens Weibler wrote: > Hi, > > how is the development of traceroute via ICMP going? > My central firewall team doesn't like opening many udp-ports for > traceroute :( > As far as I know you can make traceroute work by sending ICMP Rejects on the corrent ports. So you don't have to open any firewall to make this work. I have the following rules in my ruleset to make traceroute and tracepath work: iptables -A INPUT -p udp --dport 33434:33523 -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -p udp --dport 44450:44500 -j REJECT --reject-with icmp-port-unreachable -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra consultant E: jprins at betterbe.com T: +31-53-4800694 M: +31-6-26358951 S: jhaprins W: www.betterbe.com From daniel.karrenberg at ripe.net Wed Oct 10 11:41:54 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Oct 2012 11:41:54 +0200 Subject: [atlas] Convert json traceroute output to normal traceroutes. In-Reply-To: <20121010074655.GA27701@nic.fr> References: <50747862.90407@betterbe.com> <20121010074655.GA27701@nic.fr> Message-ID: <591FEF8E-2708-4E8C-8F68-9C0BAC7C35E9@ripe.net> On 10.10.2012, at 9:46 , Stephane Bortzmeyer wrote: > On Tue, Oct 09, 2012 at 09:17:54PM +0200, > Jan Hugo Prins wrote > a message of 111 lines which said: > >> Because I'm a little more used to reading regular traceroute output >> instead of JSON files, > > It would be better if Atlas used the standard structured format for > traceroute output, RFC 5388. Stephane, my experts tell me that the the size of RFC5388 output would be several times that of the json we generate while the json can be easily translated into the XML. So it appears to me that a script that turns the json into the XML would be proper engineering here. If there are many people wanting RFC5388 output we will put it on the to-do list. Daniel From daniel.karrenberg at ripe.net Wed Oct 10 11:43:46 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Oct 2012 11:43:46 +0200 Subject: [atlas] Convert json traceroute output to normal traceroutes. In-Reply-To: <50747862.90407@betterbe.com> References: <50747862.90407@betterbe.com> Message-ID: Thank you, that is very useful. Maybe, with your permission, it can be one of the first things to go into a github page we are going to set up for RIPE Atlas tools? Daniel On 09.10.2012, at 21:17 , Jan Hugo Prins wrote: > Hi, > > Because I'm a little more used to reading regular traceroute output > instead of JSON files, I created a little python script to convert the > ATLAS traceroute output to readable traceroutes. > > Comments are always welcome ofcourse. > > The whois information is gathered from Cymru using: > https://github.com/JustinAzoff/python-cymruwhois > > -- > Met vriendelijke groet / Best regards, > > Jan Hugo Prins > Infra consultant > > E: jprins at betterbe.com > T: +31-53-4800694 > M: +31-6-26358951 > S: jhaprins > W: www.betterbe.com > From jprins at betterbe.com Wed Oct 10 12:48:11 2012 From: jprins at betterbe.com (Jan Hugo Prins) Date: Wed, 10 Oct 2012 12:48:11 +0200 Subject: [atlas] Convert json traceroute output to normal traceroutes. In-Reply-To: References: <50747862.90407@betterbe.com> Message-ID: <5075526B.7000106@betterbe.com> Be my guest. Always good to share code. Jan Hugo On 10/10/2012 11:43 AM, Daniel Karrenberg wrote: > Thank you, that is very useful. Maybe, with your permission, it can be one of the first things to go into a github page we are going to set up for RIPE Atlas tools? > > Daniel > > On 09.10.2012, at 21:17 , Jan Hugo Prins wrote: > >> Hi, >> >> Because I'm a little more used to reading regular traceroute output >> instead of JSON files, I created a little python script to convert the >> ATLAS traceroute output to readable traceroutes. >> >> Comments are always welcome ofcourse. >> >> The whois information is gathered from Cymru using: >> https://github.com/JustinAzoff/python-cymruwhois >> >> -- >> Met vriendelijke groet / Best regards, >> >> Jan Hugo Prins >> Infra consultant >> >> E: jprins at betterbe.com >> T: +31-53-4800694 >> M: +31-6-26358951 >> S: jhaprins >> W: www.betterbe.com >> > -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra consultant E: jprins at betterbe.com T: +31-53-4800694 M: +31-6-26358951 S: jhaprins W: www.betterbe.com From jens.weibler at h-da.de Wed Oct 10 18:20:08 2012 From: jens.weibler at h-da.de (Jens Weibler) Date: Wed, 10 Oct 2012 18:20:08 +0200 Subject: [atlas] traceroute via ICMP? In-Reply-To: <50754268.1040609@betterbe.com> References: <50753FF7.9030206@h-da.de> <50754268.1040609@betterbe.com> Message-ID: <5075A038.7060802@h-da.de> On 10/10/2012 11:39 AM, Jan Hugo Prins wrote: > As far as I know you can make traceroute work by sending ICMP Rejects on > the corrent ports. So you don't have to open any firewall to make this > work. I have the following rules in my ruleset to make traceroute and > tracepath work: this only works if you're the target of the traceroute but not the source if I'm right... -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Sch?fferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler at h-da.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4703 bytes Desc: S/MIME Cryptographic Signature URL: From jprins at betterbe.com Wed Oct 10 22:11:56 2012 From: jprins at betterbe.com (Jan Hugo Prins) Date: Wed, 10 Oct 2012 22:11:56 +0200 Subject: [atlas] traceroute via ICMP? In-Reply-To: <5075A038.7060802@h-da.de> References: <50753FF7.9030206@h-da.de> <50754268.1040609@betterbe.com> <5075A038.7060802@h-da.de> Message-ID: <5075D68C.5050905@betterbe.com> > > this only works if you're the target of the traceroute but not the > source if I'm right... > True, this only works until the edge of your secure zone, and you have to open up the ports to be able to traceroute behind this edge. -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra consultant E: jprins at betterbe.com T: +31-53-4800694 M: +31-6-26358951 S: jhaprins W: www.betterbe.com From BECHA at ripe.net Thu Oct 11 12:08:29 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 11 Oct 2012 12:08:29 +0200 Subject: [atlas] A Case Study of AAAA Filtering Message-ID: <50769A9D.5090300@ripe.net> Hi all, at RIPE 65, Lorenzo Colitti from Google raised the question whether Internet users would see significant filtering of AAAA DNS queries or replies, either by their ISP or by their Customer Premise Equipment (CPE). Emile & Philip used RIPE Atlas to provide an answer to this question. https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-aaaa-filtering Regards, Vesna From lorenzo at google.com Thu Oct 11 13:56:44 2012 From: lorenzo at google.com (Lorenzo Colitti) Date: Thu, 11 Oct 2012 20:56:44 +0900 Subject: [atlas] A Case Study of AAAA Filtering In-Reply-To: <50769A9D.5090300@ripe.net> References: <50769A9D.5090300@ripe.net> Message-ID: On Thu, Oct 11, 2012 at 7:08 PM, Vesna Manojlovic wrote: > at RIPE 65, Lorenzo Colitti from Google raised the question whether > Internet users would see significant filtering of AAAA DNS queries or > replies, either by their ISP or by their Customer Premise Equipment (CPE). > Emile & Philip used RIPE Atlas to provide an answer to this question. > > https://labs.ripe.net/Members/**emileaben/ripe-atlas-a-case-** > study-of-aaaa-filtering Thanks for publishing the results! When you did the AAAA measurements, did you distinguish between the probe not getting a response (e.g., if the dig command timed out) and the probe getting a NODATA response? [I tried to look at the raw data to answer this question, but wasn't able to find out how to download it. I can see the probes that performed the measurement, but not that the results were. Am I doing something wrong?] -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Thu Oct 11 14:07:47 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Thu, 11 Oct 2012 14:07:47 +0200 Subject: [atlas] A Case Study of AAAA Filtering In-Reply-To: References: <50769A9D.5090300@ripe.net> Message-ID: <5076B693.8000301@ripe.net> On 10/11/12 1:56 PM, Lorenzo Colitti wrote: > On Thu, Oct 11, 2012 at 7:08 PM, Vesna Manojlovic > wrote: > > at RIPE 65, Lorenzo Colitti from Google raised the question > whether Internet users would see significant filtering of AAAA DNS > queries or replies, either by their ISP or by their Customer > Premise Equipment (CPE). Emile & Philip used RIPE Atlas to provide > an answer to this question. > > https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-aaaa-filtering > > > Thanks for publishing the results! > > When you did the AAAA measurements, did you distinguish between the > probe not getting a response (e.g., if the dig command timed out) and > the probe getting a NODATA response? > > [I tried to look at the raw data to answer this question, but wasn't > able to find out how to download it. I can see the probes that > performed the measurement, but not that the results were. Am I doing > something wrong?] Click on the bar that says 'Results' at the very bottom of this page? You should be able to download all the results and see the last 100 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo at google.com Thu Oct 11 14:49:44 2012 From: lorenzo at google.com (Lorenzo Colitti) Date: Thu, 11 Oct 2012 21:49:44 +0900 Subject: [atlas] A Case Study of AAAA Filtering In-Reply-To: <5076B693.8000301@ripe.net> References: <50769A9D.5090300@ripe.net> <5076B693.8000301@ripe.net> Message-ID: On Thu, Oct 11, 2012 at 9:07 PM, Andreas Strikos wrote: > [I tried to look at the raw data to answer this question, but wasn't > able to find out how to download it. I can see the probes that performed > the measurement, but not that the results were. Am I doing something wrong?] > > Click on the bar that says 'Results' at the very bottom of this page? > You should be able to download all the results and see the last 100 > Wow, that's really hard to discover. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Thu Oct 11 15:56:41 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 11 Oct 2012 15:56:41 +0200 Subject: [atlas] A Case Study of AAAA Filtering In-Reply-To: References: <50769A9D.5090300@ripe.net> <5076B693.8000301@ripe.net> Message-ID: <0F749863-23FC-4FC2-BE63-23F9E021DAAB@ripe.net> On 11.10.2012, at 14:49 , Lorenzo Colitti wrote: > On Thu, Oct 11, 2012 at 9:07 PM, Andreas Strikos wrote: >> [I tried to look at the raw data to answer this question, but wasn't able to find out how to download it. I can see the probes that performed the measurement, but not that the results were. Am I doing something wrong?] > Click on the bar that says 'Results' at the very bottom of this page? > You should be able to download all the results and see the last 100 > > Wow, that's really hard to discover. Thanks. Isn't making that more obvious already very long on the to-do-list? -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Mon Oct 15 17:14:05 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 15 Oct 2012 17:14:05 +0200 Subject: [atlas] Atlas main database maintenance Message-ID: <507C283D.4080401@ripe.net> Dear Atlas users, Tomorrow around 09:30 CEST we will bring down our main database for maintenance. Hopefully, the whole process will not take more than 2 hours. The majority of the web site functionalities and user interaction with the system will not be available but we don't expect any loss of data flowing in from the probes. We are sorry for any inconvenience this might cause. Regards, Andreas Strikos From lorenzo at google.com Mon Oct 15 17:32:30 2012 From: lorenzo at google.com (Lorenzo Colitti) Date: Tue, 16 Oct 2012 00:32:30 +0900 Subject: [atlas] A Case Study of AAAA Filtering In-Reply-To: References: <50769A9D.5090300@ripe.net> Message-ID: On Thu, Oct 11, 2012 at 8:56 PM, Lorenzo Colitti wrote: > When you did the AAAA measurements, did you distinguish between the probe > not getting a response (e.g., if the dig command timed out) and the probe > getting a NODATA response? > Ok, after having done my own analysis, it looks like the answer to that was no. Strictly speaking, AAAA filtering is when the recursive resolver returns NOERROR with zero records even if there was an AAAA record. However, this but this rare in the raw data here. Many of the cases that the post reports as filtering seem to be problematic home routers returning "not implemented", timing out, or returning SERVFAIL when asked for AAAA records. While this is still a problem for IPv6 (especially in the case of timeouts) it's not really AAAA filtering. The "not implemented" seems to be mostly to blame for the failures in the French AS at the top of the list: Results (produced by the attached Python script): A queries (udmlog_1004102_2012_39.txt): Results: {'successful': 167183, 'norecurse': 382, 'ERR_timeout': 5722, 'refused': 1163, 'ERR_senderror': 416, 'server-failure': 362} AAAA queries (udmlog_1004103_2012_39.txt): Results: {'filtering': 420, 'successful': 165667, 'norecurse': 383, 'ERR_timeout': 6057, 'refused': 1156, 'not-implemented': 774, 'ERR_senderror': 415, 'server-failure': 317} Filtering DNS servers: 124.102.51.104: 96/98 (98.0%) 79.131.194.22: 95/95 (100.0%) 124.212.215.50: 97/97 (100.0%) 88.188.129.85: 2/95 (2.1%) 133.38.4.79: 96/96 (100.0%) 2.85.23.226: 32/55 (58.2%) 81.56.47.149: 2/96 (2.1%) Filtered probes: 2299: 96/98 (98.0%) 2848: 2/96 (2.1%) 3028: 95/95 (100.0%) 2896: 96/96 (100.0%) 2891: 97/97 (100.0%) 2197: 2/95 (2.1%) 268: 32/55 (58.2%) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas.py Type: application/octet-stream Size: 2355 bytes Desc: not available URL: From robert at ripe.net Tue Oct 16 16:01:10 2012 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 16 Oct 2012 16:01:10 +0200 Subject: [atlas] Forcing https in Atlas In-Reply-To: <506D5389.4070608@ripe.net> References: <506D5389.4070608@ripe.net> Message-ID: <507D68A6.9090302@ripe.net> Dear All, This work has been finished today. It was planned for yesterday, but we had to postpone it because of the database maintenance. Please let us know if you have any observations on this. Regards, Robert Kisteleki On 2012.10.04. 11:14, Robert Kisteleki wrote: > Dear Atlas users, > > At the moment the Atlas UI servers allow regular, unsecured (http) > connections from clients. For particular features, most notably anything > that requires authenticated users, we're using secure (https) connections. > Unfortunately, the potential mixing of the two schemes causes glitches and > inconsistencies for some users. > > Therefore on 15 October we will start enforcing secure connections towards > the Atlas UI servers (atlas.ripe.net and *.atlas.ripe.net). We'll do this by > automatically redirecting all http queries to their https equivalents. > > This should not cause any changes to those of you who already use https by > default, and should not cause any notable changes to anyone else. However, > some clients (especially CLI based ones) may need some extra flags to deal > with https connections. > > Regards, > Robert Kisteleki > > From rbarnes at bbn.com Tue Oct 16 18:42:46 2012 From: rbarnes at bbn.com (Richard Barnes) Date: Tue, 16 Oct 2012 12:42:46 -0400 Subject: [atlas] Forcing https in Atlas In-Reply-To: <506D5389.4070608@ripe.net> References: <506D5389.4070608@ripe.net> Message-ID: <995ACD04-7A05-408F-B022-06F84E158C3A@bbn.com> See also: On Oct 4, 2012, at 5:14 AM, Robert Kisteleki wrote: > Dear Atlas users, > > At the moment the Atlas UI servers allow regular, unsecured (http) > connections from clients. For particular features, most notably anything > that requires authenticated users, we're using secure (https) connections. > Unfortunately, the potential mixing of the two schemes causes glitches and > inconsistencies for some users. > > Therefore on 15 October we will start enforcing secure connections towards > the Atlas UI servers (atlas.ripe.net and *.atlas.ripe.net). We'll do this by > automatically redirecting all http queries to their https equivalents. > > This should not cause any changes to those of you who already use https by > default, and should not cause any notable changes to anyone else. However, > some clients (especially CLI based ones) may need some extra flags to deal > with https connections. > > Regards, > Robert Kisteleki > From robert at ripe.net Wed Oct 17 14:14:56 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 17 Oct 2012 14:14:56 +0200 Subject: [atlas] Convert json traceroute output to normal traceroutes. In-Reply-To: <5075526B.7000106@betterbe.com> References: <50747862.90407@betterbe.com> <5075526B.7000106@betterbe.com> Message-ID: <507EA140.2060503@ripe.net> Thank you, we've started a page to collect this kind of contributions: https://atlas.ripe.net/doc/code We'll soon start organising such tools on github (most likely). Regards, Robert On 2012.10.10. 12:48, Jan Hugo Prins wrote: > Be my guest. > Always good to share code. > > Jan Hugo > > > On 10/10/2012 11:43 AM, Daniel Karrenberg wrote: >> Thank you, that is very useful. Maybe, with your permission, it can be one of the first things to go into a github page we are going to set up for RIPE Atlas tools? >> >> Daniel From tore.anderson at redpill-linpro.com Tue Oct 23 22:02:33 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 23 Oct 2012 22:02:33 +0200 Subject: [atlas] Fwd: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> Message-ID: <5086F7D9.2040507@redpill-linpro.com> Here's a suggestion for an Atlas experiment and subsequent RIPE Labs article. Do a ping measurement from all the probes to the .0 and .255 address of the same /24, plus to another control address in the same /24, and compare success rates. It's particularly interesting for me as my own personal home page is accessible at 87.238.60.0 at the moment.., Might also be worth checking it out for IPv6 at the same time (at least the case where the last 64 bits are all zeroes). Tore -------- Opprinnelig melding -------- Emne: Issues encountered with assigning .0 and .255 as usable addresses? Dato: Mon, 22 Oct 2012 22:07:50 +0000 Fra: Paul Zugnoni Til: nanog at nanog.org Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy?. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. From BECHA at ripe.net Wed Oct 24 16:48:28 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 24 Oct 2012 16:48:28 +0200 Subject: [atlas] New probe firmware released: version 4.480 Message-ID: <5087FFBC.2070809@ripe.net> Hi everyone, few days ago we have released a new version of the probe firmware: 4.480. It introduces few bug fixes, and improvements that enable us to work on new features, but that still require work on the User Interface to make it visible to users. Until now, about 1.500 probes have been upgraded to new firmware. Below are the technical details. Regards, Vesna * Fixed bug in traceroute when it has to deal with rfc4884 objects (mpls) that have a wrong size. * Delayed DNS name resolution in ping and traceroute. This feature will soon be enabled through the UI. * Fixed bug in HTTP GET where some characters where not properly escaped in generating the result JSON. * Fixed bugs in the libevent stub resolver to better handle DNS errors and timeouts (affects mostly httpget) * Limit the amount of measurement data that is sent as one unit. This prevents probes that have not connected to a controller for some time from overloading the controller. * The probe uptime is now in the DNS SOS messages that are sent by probes before they try to connect. This will allow making a distinction between various reasons for disconnects: e.g. probe reboot vs. network problems. (also published on https://atlas.ripe.net/announce ) From BECHA at ripe.net Wed Oct 24 16:59:59 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 24 Oct 2012 16:59:59 +0200 Subject: [atlas] Fwd: Issues encountered with assigning .0 and .255 as usable addresses? In-Reply-To: <5086F7D9.2040507@redpill-linpro.com> References: <73A9A2579638014A8254BF9FE31DDB244FAF4FA6@mbx2.jiveland.com> <5086F7D9.2040507@redpill-linpro.com> Message-ID: <5088026F.1040100@ripe.net> Hi Tore, thanks, that's an interesting idea, we'll look into it and investigate how best to set up an experiment. Regards, Vesna On 10/23/12 10:02 PM, Tore Anderson wrote: > Here's a suggestion for an Atlas experiment and subsequent RIPE Labs > article. Do a ping measurement from all the probes to the .0 and .255 > address of the same /24, plus to another control address in the same > /24, and compare success rates. > > It's particularly interesting for me as my own personal home page is > accessible at 87.238.60.0 at the moment.., > > Might also be worth checking it out for IPv6 at the same time (at least > the case where the last 64 bits are all zeroes). > > Tore > > -------- Opprinnelig melding -------- > Emne: Issues encountered with assigning .0 and .255 as usable addresses? > Dato: Mon, 22 Oct 2012 22:07:50 +0000 > Fra: Paul Zugnoni > Til: nanog at nanog.org > > Curious whether it's commonplace to find systems that automatically > regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic > that should be considered invalid. When you have a pool of assignable > addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing > traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run > into a commercial IP mgmt product and getting reports of M$ ISA proxy > that is specifically blocking traffic for an IP ending in .0 or .255. > > Any experience or recommendations? Besides replace the ISA proxy?. Since > it's not mine to replace. Also curious whether there's an RFC > recommending against the use of .0 or .255 addresses for this reason. > > > >