Re: netscan.org - broadcast ICMP list

[troy () LTNX NET (Troy Davis)]

On Wed, Dec 30, 1998 at 02:40:14PM -0500, epperson () VAK12ED EDU wrote:

> > 32508 networks have been probed with the SAR
> > 15969 of them are currently broken
> > 7208 have been fixed after being listed here
>
> Hmmm.  netscan.org reports 144,047 "broken" networks.  Either their
> effort is on a higher order of magnitude than SAR's, or it all
> depends on what the definition of "network" is....

Both, but mostly the former.  We scanned *.*.*.255 and .0; SAR scans the
networks people submit.  We checked somewhere around (assuming 3/4 of the
class A's are allocated according to ARIN):

255*255*255*0.75        # number of potential class Cs * 0.75 allocated
12436031.25                     # est. allocated class Cs
12436031*2                      # 2 pings (.0 and .255) per class C
24872062                        # that many pings sent/IPs checked

Very roughly, 24.8 million IPs checked or 12.4 million class Cs, versus 32k
networks at SAR.  Their broken:total ratio is much higher than ours for the
same reason - we scanned all class Cs, they scanned networks that people
submitted (which are most likely broken).

Their scanner is more flexible than ours in the definition of a network;
ours takes only class Cs right now, whereas theirs handles other netmasks.

We're working on making netscan.org handle netmasks (both for length of
block and size it's subnetted into).  We'll probably recheck SAR's database
when ours supports netmasks and may also do all /25s - shouldn't be far away.

Other additions in the works are searching by BGP ASN and/or NIC contact.  If
you're the admin for a class B or large netblock, email me and I'll give you
the raw database output.

A week or two after the database is properly searchable (see above), we'll
release the raw database.  This wasn't done originally because admins should
have time to fix their nets.

To scan down to /30 (smallest allocation) will be somewhere around 790 million
IPs, so we're taking donations of bandwidth/CPU resources to scan from.

Comments/suggestions welcome.

Cheers,

Troy Davis