C Programming Language

1309 readers

1 users here now

Welcome to the C community!

C is quirky, flawed, and an enormous success.
... When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd.
... The only way to learn a new programming language is by writing programs in it.

irc: #c

🌐 https://en.cppreference.com/w/c

founded 3 years ago

MODERATORS

snowe@programming.dev

thomas@lemmy.douwes.co.uk

modev@programming.dev

Suggest improvements to my IPv4 ping census program (github.com)

submitted 1 week ago by sacred_font@infosec.pub to c/c_lang@programming.dev

6 comments fedilink hide all child comments

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

top 6 comments

sorted by: hot top controversial new old

[–] CameronDev@programming.dev 2 points 5 days ago (1 children)

The streamlined way to do this is raw sockets. You only need one, and you can just craft all of the ICMP requests and send them continuously. Then in a separate thread you can read all the replies.

[–] sacred_font@infosec.pub 2 points 5 days ago* (last edited 5 days ago) (1 children)

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.

[–] CameronDev@programming.dev 1 points 5 days ago* (last edited 5 days ago) (1 children)

Dgram would work, I didn't think of that. When you have a hammer... Raw does let you do other scan methods (syn scan, open port scan, etc). Raw may require using bpf filtering.

You should be able to go pretty fast, masscan can scan the entire internet in around 5 minutes: https://github.com/robertdavidgraham/masscan

[–] sacred_font@infosec.pub 2 points 5 days ago* (last edited 5 days ago) (1 children)

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

[–] CameronDev@programming.dev 1 points 4 days ago

Going too hard with your scan may upset your ISP as well, even if you don't lose packets along the way.

[–] dgriffith@aussie.zone 5 points 1 week ago* (last edited 1 week ago)

Been a while since I've done this kind of thing, but you should be able to create a pool of sockets primed with the first batch of IP addresses, then send the packets.

On reply or timeout you then alter the connection information in the socket descriptor for that socket to point to the next address to check, and then go again.