Bug 248367 - /sbin/ping fails when run many times simultaneously
Summary: /sbin/ping fails when run many times simultaneously
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-30 12:49 UTC by D
Modified: 2020-08-05 11:43 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description D 2020-07-30 12:49:58 UTC 
How to repeat
# uname -a
FreeBSD r 12.1-RELEASE-p5 FreeBSD 12.1-RELEASE-p5 GENERIC  amd64

Run this line some times:

# sh -c 'for i in $(seq 100); do ping -c1 127.0.0.1 >/dev/null & done; wait'

It runs 100 ping processes in parallel. Sometimes some of them fail and produce such output:

ping: unable to limit access to system.dns service: Socket is not connected

That command is synthetic. In my real system I have this message even for 20 processes run to ping different hosts.

The bug also presents in 11.4-RELEASE-p1.
Comment 1 Vladimir Druzenko freebsd_committer freebsd_triage 2020-07-30 13:59:44 UTC 
Nice self-DoS. :-D

I think you need to tune some sysctl.
Something like:
net.local.stream.recvspace=65536
net.local.stream.sendspace=65536
Comment 2 D 2020-07-30 19:11:38 UTC 
(In reply to VVD from comment #1)
Didn't help even with 265536 :(
Comment 3 Vladimir Druzenko freebsd_committer freebsd_triage 2020-07-30 19:35:05 UTC 
I said "something like", but not "these"…
So maybe exist other sysctl variables that can help.
Comment 4 D 2020-07-30 20:54:35 UTC 
I only found that error is concerned with libcasper but its sources didn't help me to find solution. Also I found

kern.features.security_capabilities: 1
kern.features.security_capability_mode: 1

but they also didn't help.
Comment 5 Vladimir Druzenko freebsd_committer freebsd_triage 2020-08-05 11:43:18 UTC 
(In reply to D from comment #4)
I don't know - it was an assumption.