docs: Update posts to follow Vale suggestions

Signed-off-by: Casper Andersson <[email protected]>

content/docs/capmon.md

@@ -11,38 +11,34 @@ hideMeta: true
 published: true
 ---
 
-Monitor when processes check `capabilities(7)` to find out what they require.
+Track when processes check `capabilities(7)` to find out what they require.
 Run `capmon '<cmd>'` to track the capabilities it requires. It's important to not
 run it with sudo since that bypasses certain checks. Let the command fail at the
 first missing capability check and add that capability, then try again and see
-if if fails on more. Rinse and repeat until command runs successfully.
+if it fails on more. Rinse and repeat until the command runs successfully.
 
-If you are not familiar with capabilities can read [A simpler life without
+If you aren't familiar with capabilities you can read [A simpler life without
 sudo]({{< ref "2022-08-26-a-simpler-life-without-sudo.md" >}}).
 
 [Capmon - GitHub](https://github.com/cappe987/capmon)
 
 ## Using Capmon
 
-It is recommended to use Capmon without sudo, since running it with sudo the
-provided command inherits the sudo properties and will bypass several checks.
-Capmon requires `CAP_DAC_OVERRIDE` and `CAP_SYS_ADMIN`.
+Capmon is best used without sudo, since running it with sudo the
+provided command inherits the sudo properties and will bypass several
+checks. Capmon requires `CAP_DAC_OVERRIDE` and `CAP_SYS_ADMIN`.
 
 To use Capmon do
 ```sh
 capmon '<cmd>'
 ```
 
-For example:
+For example
 ```sh
 capmon 'ip link netns add test'
 ```
-It is recommended to enclose the command in quotes to avoid the shell from doing
-any funny business with globbing or other special features, and to avoid Capmon
-from interpreting the command's argument as its own. Capmon will run the command
-with `/bin/sh`.
 
-The output of the above command will be
+will give the output
 ```sh
 [ip]
 - [PASS] CAP_DAC_OVERRIDE
@@ -52,47 +48,53 @@ because the `ip` command required the capabilities `CAP_NET_ADMIN` and
 `CAP_DAC_OVERRIDE` for this particular task. Another example, `ip link set dev
 tap0 up` only requires `CAP_NET_ADMIN`.
 
+Enclose the command in quotes to avoid the shell from doing any funny
+business with globbing or other special features, and to avoid Capmon
+from interpreting the command's argument as its own. Capmon will run
+the command with `/bin/sh`.
+
 If the user didn't have the capabilities it would instead report `[FAIL]` on one
 of the capabilities. If it failed on the first of the two then it may not even
 show the second since commands often bail out as soon as they fail to do
 something.
 
 If a command is still failing even though Capmon doesn't report anything there
 is the flag `-a` or `--all`. This changes the place where it listens to another
-location which covers many more checks, some of which are not always necessary
-and are allowed to fail. This is not the default mode as to not confuse the
-user with a bunch of capabilities that usually will not matter.
+location which covers many more checks, some of which aren't always necessary
+and can fail without issue. This isn't the default mode as to not confuse the
+user with a bunch of capabilities that may not matter.
 
 
 ## How it works
 
-Capmon uses BPF tracepoints and fexit tracing to listen to two different events.
+Capmon uses Berkeley Packet Filter (BPF) `tracepoints` and `fexit`
+tracing to listen to two different events.
 
-1. Capability checks (fexit)
-2. Process starts (tracepoint)
+1. Capability checks (`fexit`)
+2. Process starts (`tracepoint`)
 
 (1) looks a the return value of the capability check. By default it listens to
 the `ns_capable` and `capable_wrt_inode_uidgid` kernel functions. Most required
 capability checks go through either of these two functions. But in case it
 doesn't, the `--all` flag changes it to instead listen to the `cap_capable`. The
-capability and the result is saved and mapped to the PID that did the check.
+capability and result gets saved and mapped to the Process Identifier (PID)
+that did the check.
 
 (2) looks at the PID of the parent process (the one who started the new
-process) and if that matches with the PID of the command it is saved. Next time
-a process starts it will look against all previously saved PID. This ensures
-that any even subprocesses of subprocesses, and so on, are kept track of.
+process) and if that matches with the PID of the command it saves it. Next time
+a process starts it will compare it to all saved PIDs. This ensures
+that even subprocesses of subprocesses gets tracked.
 
-At the end it compares all saved PID (the process and its subprocesses) against
+At the end it compares all saved PIDs (the process and its subprocesses) to
 all capability checks done and takes the intersection. The output is the
 capability checks done by the input command.
 
-Capmon itself ignores `Ctrl-C` (`SIGINT`) so it is passed down to the monitored
-program. This allows it to support interactive programs that are stopped with
-`Ctrl-C`.
+Capmon itself ignores `Ctrl-C` (`SIGINT`) and passes it through to the monitored
+program. This enables support for interactive programs that need `Ctrl-C`.
 
-It currently does not handle orphan processes since it stops once the initial
-command is done. To handle this there is monitor mode using the `--monitor`
-flag. This mode does not run any command, instead it behaves similar to
+It currently doesn't handle orphan processes since it stops once the initial
+command finishes. To handle this there is monitor mode using the `--monitor`
+flag. This mode doesn't run any command, instead it behaves similar to
 `tcpdump` and can filter and output a summary based on PID or name.
 
 

content/docs/hexend.md

@@ -14,9 +14,9 @@ published: true
 
 Send hexdumps copied from Tcpdump/Wireshark. Save the hexdump in a file and
 give it to `hexend` to send it on an interface. Useful for repeating a specific
-captured frame, instead of making a pcap playback or trying to recreate it
+captured frame, instead of making a PCAP playback or trying to recreate it
 using tools like [Nemesis](https://github.com/libnet/nemesis) or
-[EasyFrames](https://github.com/microchip-ung/easyframes). It is also possible
+[EasyFrames](https://github.com/microchip-ung/easyframes). It's also possible
 to write the frame by hand if you so wish.
 
 
@@ -57,5 +57,5 @@ If you just want a simple alternative to this you can use a script like
 #!/bin/sh
 cat $2 | xxd -r -p | socat -u STDIN interface:$1
 ```
-that will behave like Hexend regarding the input, but does not support any
-flags. Looping this is also very inefficient for sending many frames quickly.
+that will behave like Hexend regarding the input, but doesn't support any
+flags. Looping this is also inefficient for sending at low intervals.

content/docs/wiretime.md

@@ -22,41 +22,44 @@ pre > code {
 
 Measure the time a packet is on the wire accurately using hardware timestamping.
 This is useful for measuring the impact of traffic congestion and testing QoS
-features. The timestamped packets are intended to never touch any software on
-their trip through the network since that adds considerable delay and jitter,
-and the benefit of hardware timestamping dwindles. In which case using `ping`
-may be enough precision.
+features. The timestamped packets shouldn't go through any software
+on their trip through the network since that adds considerable delay
+and jitter, and the benefit of hardware timestamping dwindles. In
+which case using `ping` may be enough precision.
 
-If you are unfamiliar with timestamping I recommend checking out my post on [PTP
+For those unfamiliar with timestamping, check out this post on [PTP
 and timestamping methods]({{< ref 2023-04-05-ptp-intro-timestamping.md >}}).
 
 [GitHub repository](https://github.com/cappe987/wiretime)
 
 
 ## Using Wiretime
 
-Wiretime requires two interfaces, one for transmission and one for receival.
+Wiretime requires two interfaces, one for transmission and one for reception.
 This can be the same physical port by creating two VLAN interfaces on top of the
-port interface (note that they must be attached directly to the port and not
-through a bridge as bridges cannot do timestamping). Ideally, Wiretime should be
-used on a network switch that has multiple interface capable of timestamping.
-For best accuracy the ports should use the same Physical Hardware Clock (PHC).
-If they aren't using the same PHC they need to be precisely synced.
-
-The packets will use a path that loops back to the transmitting switch. The
-receiving port should be set to a different VLAN than the transmitting port, or
-removed from the bridge completely, to avoid flooding. Packets are timestamped
-on transmission and receival and the difference is calculated across several
-packets and the average is taken.
+port interface (note that they must attach directly to the port and not
+through a bridge as bridges can't do timestamping). Ideally, use
+Wiretime on a network switch that has more than one interface capable of
+timestamping. For best accuracy the ports should use the same
+Physical Hardware Clock (PHC).  If they aren't using the same PHC they
+need to be precisely synced.
+
+The packets will use a path that loops back to the transmitting
+switch. The receiving port have a different untagged VLAN than the
+transmitting port, or removed from the bridge completely, to avoid
+flooding. Wiretime timestamps packets on transmission and reception,
+and calculates the difference across several packets and outputs an
+average time.
 
 The most basic command looks like this
 ```sh
 wiretime --tx eth1 --rx eth2
 ```
 
 The following is an illustration of an example setup. Wiretime runs on SW1 and
-transmits on one port and receives on another. The packet is switched in
-hardware through SW2, and then back to SW1.
+transmits on one port and receives on another. SW2 forwards it in
+hardware, and then back to SW1.
+
 ```
     ┌───────┐
     │       │
@@ -70,15 +73,15 @@ hardware through SW2, and then back to SW1.
 ### Flags
 
 `-t, --tx <interface>`
-Transmit packets on `<interface>`. Can be a VLAN or other interface,
+Send packets on `<interface>`. Can be a VLAN or other interface,
 as long as the physical port supports hardware timestamping.
 
 `-r, --rx <interface>`
 Receive packets on interface `<interface>`. Can be a VLAN or other interface,
 as long as the physical port supports hardware timestamping.
 
 `-p, --pcp <PCP>`
-PCP priority. If VLAN is not set it will use VLAN 0.
+VLAN Priority Code Point (PCP). If VLAN isn't set it will use VLAN 0.
 
 `-v, --vlan <VID>`
 VID to tag the packet with.
@@ -91,8 +94,8 @@ Use one-step TX instead of two-step.
 
 `-O, --out <filename>`
 Output data into file for plotting. Use when running Wiretime on a device that
-does not have Gnuplot installed. The file can then be copied to another device
-for plotting afterwards.
+doesn't have Gnuplot installed. Then copy it to another device for
+plotting afterward.
 
 `-i, --interval <milliseconds>`
 Interval between packets. Default: 1000.
@@ -110,14 +113,14 @@ not used it will create a temporary file for storing the data. The same plotting
 settings also exists as a bash script in the repository.
 
 `--tstamp-all`
-Enable timestamping of non-PTP packets. On some NICs this will behave
+Enable timestamping of non-PTP packets. On some network cards this will behave
 differently than timestamping PTP packets only. Incompatible with `--one-step`.
 
 
 ## Example plot
 
 Below is an example plot using one-step PHY timestamping taken over 110 seconds.
-The packets are sent from one switch, through another, and back to the senders
+The packets sends from one switch, through another, and back to the senders
 receiving port. The total time spent on the wire is around 3500--4000
 nanoseconds, or 3.5--4 microseconds.