<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-openbsd/sbin/ping, branch master</title>
<subtitle>WireGuard implementation for the OpenBSD kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-openbsd/atom/sbin/ping?h=master</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-openbsd/atom/sbin/ping?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/'/>
<updated>2021-02-21T17:18:01Z</updated>
<entry>
<title>exclamation mark needs escaped too;</title>
<updated>2021-02-21T17:18:01Z</updated>
<author>
<name>jmc</name>
<email>jmc@openbsd.org</email>
</author>
<published>2021-02-21T17:18:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=504edf8d9462bbdc18ed20da4454d8fb74c60c66'/>
<id>urn:sha1:504edf8d9462bbdc18ed20da4454d8fb74c60c66</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Add ping -g, a concise display format similar to that used by other</title>
<updated>2021-02-21T10:38:42Z</updated>
<author>
<name>sthen</name>
<email>sthen@openbsd.org</email>
</author>
<published>2021-02-21T10:38:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=24d24f2db71c5e95f121269c49dbcb76974d7876'/>
<id>urn:sha1:24d24f2db71c5e95f121269c49dbcb76974d7876</id>
<content type='text'>
network devices that shows one character per echo request (! for normal
response, . for timed out, D for duplicate, T for truncated) making
it easier to identify patterns of loss over periods of time.

ok remi@ kn@, feedback from deraadt@ chris@

!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!.........!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!.........!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!.........!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!..........!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!..........!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!..........!!!!!!!!!!!!!!!!!!!!....!!!!!!!!!!!!!!!!!!!!!!!!!!.....!!!!!!!!!!!!!!
</content>
</entry>
<entry>
<title>If we manage to send all "count" flood pings before receiving all</title>
<updated>2020-12-29T16:40:47Z</updated>
<author>
<name>florian</name>
<email>florian@openbsd.org</email>
</author>
<published>2020-12-29T16:40:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=134f02be11686282be9123a4ee0fdca1a015d123'/>
<id>urn:sha1:134f02be11686282be9123a4ee0fdca1a015d123</id>
<content type='text'>
answers we would exit after receiving the first answer and claiming a
(huge) packet loss.
OK benno
</content>
</entry>
<entry>
<title>ICMP raw sockets start to receive packets as soon as they are created</title>
<updated>2020-10-21T11:11:58Z</updated>
<author>
<name>florian</name>
<email>florian@openbsd.org</email>
</author>
<published>2020-10-21T11:11:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=b1f4f7a2b84630c3198b012da2097c9d6c717233'/>
<id>urn:sha1:b1f4f7a2b84630c3198b012da2097c9d6c717233</id>
<content type='text'>
by socket(2). They also receive all ICMP packets on the system, for
example from parallel running ping(8)s.

After creating the raw socket ping(8) sets various socket options with
setsockopt(2) and assumes that they apply to all packets it later
processes.

For example ping6(8) uses setsockopt(IPV6_RECVHOPLIMIT) to print the
IPv6 hop count. Packets received between the socket(2) and
setsockopt(2) call however do not have the hoplimit information and
ping6(8) prints a wrong and missleading warning.

To avoid this we have to drain our socket of packets we received
before we were fully setup.

Problem reported and testing by martijn
Input deraadt
OK benno
</content>
</entry>
<entry>
<title>Missing space for '-i interval' option error message.</title>
<updated>2020-09-21T12:19:08Z</updated>
<author>
<name>mglocker</name>
<email>mglocker@openbsd.org</email>
</author>
<published>2020-09-21T12:19:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=9a27d676676bb3b6b10f61ede6bb3a816c51d1a0'/>
<id>urn:sha1:9a27d676676bb3b6b10f61ede6bb3a816c51d1a0</id>
<content type='text'>
From &lt;piotr (at) durlej (dot) net&gt;.  Thanks!
</content>
</entry>
<entry>
<title>Simplify and unify wording for the -I sourceaddr option in various places.</title>
<updated>2020-02-11T18:41:39Z</updated>
<author>
<name>deraadt</name>
<email>deraadt@openbsd.org</email>
</author>
<published>2020-02-11T18:41:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=7081304181fbabfd45e7ed5f2df223bbe61bb1aa'/>
<id>urn:sha1:7081304181fbabfd45e7ed5f2df223bbe61bb1aa</id>
<content type='text'>
This is somewhat related to the "-b bind_addr" option some programs have,
which should get some cleanup also...
input florian claudio jmc
</content>
</entry>
<entry>
<title>ping(8): improve "-i wait" parsing and error-checking code</title>
<updated>2020-01-04T01:00:18Z</updated>
<author>
<name>cheloha</name>
<email>cheloha@openbsd.org</email>
</author>
<published>2020-01-04T01:00:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=ee30f25344610b48a00f41b4295304aea963b5dc'/>
<id>urn:sha1:ee30f25344610b48a00f41b4295304aea963b5dc</id>
<content type='text'>
 - Never accept negative values.

 - Cap the interval at UINT_MAX seconds to avoid strange rounding
   behavior at the end of the input range.

 - Use error messages that resemble other parts of the tree where we
   are able to use strtonum(3).

 - Leverage modf(3) for cleaner code.

 - Call it "-i interval" to avoid accidental visual similarity to
   "-w maxwait".

With input from cjeker@, kettenis@, kn@.

ok kn@
</content>
</entry>
<entry>
<title>At startup, unveil entire filesystem to read-only. If after privdrop, some</title>
<updated>2019-08-28T20:03:51Z</updated>
<author>
<name>deraadt</name>
<email>deraadt@openbsd.org</email>
</author>
<published>2019-08-28T20:03:51Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=115bfdf815fc2d6ff8ac45f24842ac7a4ee03de4'/>
<id>urn:sha1:115bfdf815fc2d6ff8ac45f24842ac7a4ee03de4</id>
<content type='text'>
implausible bug existed in the socket setup (mostly dns-related and
setsockopt) it would be largely neutered.  of course, a very restrictive
pledge is installed soon after that...
ok mestre brynet florian
</content>
</entry>
<entry>
<title>ping(8): don't round inter-packet delay up to HZ</title>
<updated>2019-07-20T00:49:54Z</updated>
<author>
<name>cheloha</name>
<email>cheloha@openbsd.org</email>
</author>
<published>2019-07-20T00:49:54Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=557c6584f16d9dcac62ebf63aeb273c5fd29d737'/>
<id>urn:sha1:557c6584f16d9dcac62ebf63aeb273c5fd29d737</id>
<content type='text'>
ping(8) doesn't know the value of HZ and shouldn't round the user's
packet wait up to whatever it thinks HZ is.  If the period is too small
the interrupt will simply fire less often than instructed.  The kernel
will do the right thing regardless.

Given the rarity of this usage we don't really need to print a warning,
either.

ok millert@
</content>
</entry>
<entry>
<title>When system calls indicate an error they return -1, not some arbitrary</title>
<updated>2019-06-28T13:32:41Z</updated>
<author>
<name>deraadt</name>
<email>deraadt@openbsd.org</email>
</author>
<published>2019-06-28T13:32:41Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=df69c215c7c66baf660f3f65414fd34796c96152'/>
<id>urn:sha1:df69c215c7c66baf660f3f65414fd34796c96152</id>
<content type='text'>
value &lt; 0.  errno is only updated in this case.  Change all (most?)
callers of syscalls to follow this better, and let's see if this strictness
helps us in the future.
</content>
</entry>
</feed>
