[-] sacred_font@infosec.pub 4 points 22 hours ago

Unlabeled grey square at the bottom

[-] sacred_font@infosec.pub 2 points 22 hours ago* (last edited 22 hours ago)

This was a ping scan, so it wasn't probing any TCP/UDP ports (see shodan.io). I suppose you could use ICMP control messages (Destination Unreachable) to determine if something was unused, but that assumes the other side is being friendly.

[-] sacred_font@infosec.pub 24 points 1 day ago* (last edited 1 day ago)

Comparison is the thief of joy 🙃

Though if I push my scanner hard it could probably do 16k/sec on the single core and 1gig connection it is on. The problem is how reliably I could do 16k/sec over the network, since a good portion would be dropped even if the host's hardware could keep up.

I'd probably need access to enterprise-level equipment that could handle the routing load if I were to do it in 5 seconds lol, it's insane they managed to do that

[-] sacred_font@infosec.pub 28 points 1 day ago* (last edited 1 day ago)

about a month, since I ran it at about 6000 addresses / sec checking distinct addresses 4 times (round robin) or 1500 finished / sec. This was the fastest I went to avoid silent UDP drops and to hopefully not annoy my VPS hoster too much.

[-] sacred_font@infosec.pub 29 points 1 day ago

I left details out to be less verbose.

185
submitted 1 day ago* (last edited 19 hours ago) by sacred_font@infosec.pub to c/programming@programming.dev

I pinged every IP address that wasn't reserved. The image is 8k by 8k and is re-encoded as an AVIF to be friendlier to mobile devices. Like every other survey done, it is using a Hilbert Curve to convert the linear address space to a contiguous 2d space. The hotter the colors (blue is coolest), the denser the ping responses were.

(If you are interested the full-resolution pyramidal-tiled TIFF can be downloaded and viewed in QuPath on desktop. I've also compressed the ping response data into its own format down to about 150 MB. PM me for a link)

Non-proxied image

Here is a 2006 survey to compare.

Some observations: Big Tech (USA) is in the top left. US government allocations, for the most part, did not respond to any pings. And maybe you didn't realize this before, but Multicast (Class D) & Class E consume a whopping 12% of the IPv4 range.

[-] sacred_font@infosec.pub 3 points 1 day ago

commenting because it may interest you, but have you looked at the pintos project? It is an educational OS framework with the instructions on how to implement basic things like threading, user programs, file systems

https://en.wikipedia.org/wiki/Pintos

[-] sacred_font@infosec.pub 1 points 1 month ago

Here you go!!! Purple is reserved range. It's a Hilbert curve as seen here https://www.caida.org/archive/id-consumption/census-map/images/20061108.png

[-] sacred_font@infosec.pub 2 points 1 month ago* (last edited 1 month ago)

I gave it some further thought and I might be completely misguided to try and max throughput. Datagrams are completely connectionless and therefore can’t know if your router’s send buffer is full or not, unless I’m missing something internal between the kernel and the router that makes sendto block (which AFAIK only happens when the socket’s send buffer is full). Therefore most “extra” datagrams I send would just be dropped anyways. I know ICMP was a dated method of congestion control but have no idea if it would still be in use for simple pings.

Edit: apparently source quench is a thing but still, no clue if the kernel intercepts this or if it is even sent in 2026 due to deprecation

[-] sacred_font@infosec.pub 2 points 1 month ago* (last edited 1 month ago)

Is there any reason why it has to be a raw socket, rather than a dgram icmp socket? (which allows you to run as non-root) Silly me for not realizing I only needed one socket. Ofc my speed would only be at most 1-2Mbps. I currently track outgoing pings in memory so I would probably need to keep a single large circular array instead for timeout purposes -- not too different from what I'm doing currently.

[-] sacred_font@infosec.pub 1 points 1 month ago

Thank you can’t believe I forgot this

18

cross-posted from: https://infosec.pub/post/47574072

Hello lemmings, I made a program to ping every IPv4 address and collect data on respondents. I am almost done, but I want feedback on things I should change or how I can improve my current record of 5,000 pings / second.

I am currently aware that I need to properly parse the data I receive on the receive socket, since it's possible the TTL router messages might be confused as replies. ICMP is used on networks to inform other machines of network problems.

One issue I'm aware of is the tuning that has to go into maximizing throughput while also avoiding a total system freeze. My code seems to spend too much time opening sockets that it leaves no room for the actual OS. My only fix currently is limiting the CPU time to the ping timeout I used.

The overall program works like this: It keeps a linked list / pool of task objects. All objects are initially in the "free list" and then when they become associated with a socket, they move to the "active list". The program first checks for updated sockets with epoll which results in like 5% of sockets giving a response. It then closes any tasks that have timed out via linked list in O(1) each. The slow part is when it creates new sockets, since it doesn't really know when to stop, besides when the non-blocking socket informs it that it would block. I implemented a time limit on sending that is currently the maximum of the ping timeout. To increase throughput it seems like I need to streamline how I send ICMP packets.

https://github.com/bneils/PingStorm

9

cross-posted from: https://infosec.pub/post/47574072

Hello lemmings, I made a program to ping every IPv4 address and collect data on respondents. I am almost done, but I want feedback on things I should change or how I can improve my current record of 5,000 pings / second.

I am currently aware that I need to properly parse the data I receive on the receive socket, since it's possible the TTL router messages might be confused as replies. ICMP is used on networks to inform other machines of network problems.

One issue I'm aware of is the tuning that has to go into maximizing throughput while also avoiding a total system freeze. My code seems to spend too much time opening sockets that it leaves no room for the actual OS. My only fix currently is limiting the CPU time to the ping timeout I used.

The overall program works like this: It keeps a linked list / pool of task objects. All objects are initially in the "free list" and then when they become associated with a socket, they move to the "active list". The program first checks for updated sockets with epoll which results in like 5% of sockets giving a response. It then closes any tasks that have timed out via linked list in O(1) each. The slow part is when it creates new sockets, since it doesn't really know when to stop, besides when the non-blocking socket informs it that it would block. I implemented a time limit on sending that is currently the maximum of the ping timeout. To increase throughput it seems like I need to streamline how I send ICMP packets.

https://github.com/bneils/PingStorm

7

Hello lemmings, I made a program to ping every IPv4 address and collect data on respondents. I am almost done, but I want feedback on things I should change or how I can improve my current record of 5,000 pings / second.

I am currently aware that I need to properly parse the data I receive on the receive socket, since it's possible the TTL router messages might be confused as replies. ICMP is used on networks to inform other machines of network problems.

One issue I'm aware of is the tuning that has to go into maximizing throughput while also avoiding a total system freeze. My code seems to spend too much time opening sockets that it leaves no room for the actual OS. My only fix currently is limiting the CPU time to the ping timeout I used.

The overall program works like this: It keeps a linked list / pool of task objects. All objects are initially in the "free list" and then when they become associated with a socket, they move to the "active list". The program first checks for updated sockets with epoll which results in like 5% of sockets giving a response. It then closes any tasks that have timed out via linked list in O(1) each. The slow part is when it creates new sockets, since it doesn't really know when to stop, besides when the non-blocking socket informs it that it would block. I implemented a time limit on sending that is currently the maximum of the ping timeout. To increase throughput it seems like I need to streamline how I send ICMP packets.

https://github.com/bneils/PingStorm

view more: next ›

sacred_font

0 post score
0 comment score
joined 4 months ago