mirror of
https://github.com/freebsd/freebsd-src
synced 2024-09-06 09:10:28 +00:00
ipfilter: Fix manpage typos
Reported by: jrtc27
Fixes: 2582ae5740
MFC after: 1 month
This commit is contained in:
parent
ed166a0173
commit
ad07e93fe1
|
@ -108,7 +108,7 @@ auth
|
|||
rules cause the matching packet to be queued up for processing by a
|
||||
user space program. The user space program is responsible for making
|
||||
an ioctl system call to collect the information about the queued
|
||||
packet( and another ioctl system call to return the verdict (block,);
|
||||
packet and another ioctl system call to return the verdict (block,
|
||||
pass, etc) on what to do with the packet. In the event that the queue
|
||||
becomes full, the packets will end up being dropped.
|
||||
.HP
|
||||
|
|
|
@ -68,7 +68,7 @@ The ioctls which are for use with logging and don't affect the filter are:
|
|||
The SIOCIPFFB ioctl flushes the log buffer and returns the number of bytes
|
||||
flushed. FIONREAD returns the number of bytes currently used for storing
|
||||
log data. If IPFILTER_LOG is not defined when compiling, SIOCIPFFB is not
|
||||
available( and FIONREAD will return but not do anything.);
|
||||
available and FIONREAD will return but not do anything.
|
||||
.PP
|
||||
There is currently no support for non-blocking IO with this device, meaning
|
||||
all read operations should be considered blocking in nature (if there is no
|
||||
|
|
|
@ -44,7 +44,7 @@ in providing a secure IP environment.
|
|||
\fBipftest\fP will parse any standard ruleset for use with \fBipf\fP,
|
||||
\fBipnat\fP and/or \fBippool\fP
|
||||
and apply input, returning output as to the result. However, \fBipftest\fP
|
||||
will( return one of three values for packets passed through the filter:);
|
||||
will return one of three values for packets passed through the filter:
|
||||
pass, block or nomatch. This is intended to give the operator a better
|
||||
idea of what is happening with packets passing through their filter
|
||||
ruleset.
|
||||
|
|
|
@ -252,8 +252,8 @@ are always in the
|
|||
.I inbound
|
||||
,
|
||||
.I outbound
|
||||
order.( In this case, hme0 would be the return interface and le0 would be);
|
||||
the( outgoing interface. If you wish to allow return packets on any);
|
||||
order. In this case, hme0 would be the return interface and le0 would be
|
||||
the outgoing interface. If you wish to allow return packets on any
|
||||
interface, the correct syntax to use would be:
|
||||
.nf
|
||||
|
||||
|
|
|
@ -107,7 +107,7 @@ further protocol headers.
|
|||
.TP
|
||||
.B hl <number>
|
||||
manually specifies the IP header length (automatically adjusts with the
|
||||
presence of IP options and defaults to 5);
|
||||
presence of IP options and defaults to 5
|
||||
.TP
|
||||
.B v <number>
|
||||
set the IP version. Default is 4.
|
||||
|
|
Loading…
Reference in a new issue