of by mount point, umount had to take care not to unmount the wrong
file system if another file system was covering the requested one.
Now that the file system to unmount is specified to the kernel using
the filesystem ID, this confusion cannot occur, so remove the code
that checked for it.
Allow set 31 to be used for rules other than 65535.
Set 31 is still special because rules belonging to it are not deleted
by the "ipfw flush" command, but must be deleted explicitly with
"ipfw delete set 31" or by individual rule numbers.
This implement a flexible form of "persistent rules" which you might
want to have available even after an "ipfw flush".
Note that this change does not violate POLA, because you could not
use set 31 in a ruleset before this change.
Suggested by: Paul Richards
o Warn when recieved packet length is not equal to length of the
packet we sent out. Idea from NetBSD.
o Fit the dump of packet with wrong data to 80 columns (from NetBSD).
Comments from: bde
introduced in the latest commits).
Also:
* update the 'ipfw -h' output;
* allow rules of the form "100 add allow ..." i.e. with the index first.
(requested by Paul Richards). This was an undocumented ipfw1 behaviour,
and it is left undocumented.
and minor code cleanups.
* make the code compile with WARNS=5 (at least on i386), mostly
by adding 'const' specifier and replacing "void *" with "char *"
in places where pointer arithmetic was used.
This also spotted a few places where invalid tests (e.g. uint < 0)
were used.
* support ranges in "list" and "show" commands. Now you can say
ipfw show 100-1000 4000-8000
which is very convenient when you have large rulesets.
* implement comments in ipfw commands. These are implemented in the
kernel as O_NOP commands (which always match) whose body contains
the comment string. In userland, a comment is a C++-style comment:
ipfw add allow ip from me to any // i can talk to everybody
The choice of '//' versus '#' is somewhat arbitrary, but because
the preprocessor/readfile part of ipfw used to strip away '#',
I did not want to change this behaviour.
If a rule only contains a comment
ipfw add 1000 // this rule is just a comment
then it is stored as a 'count' rule (this is also to remind
the user that scanning through a rule is expensive).
* improve handling of flags (still to be completed).
ipfw_main() was written thinking of 'one rule per ipfw invocation',
and so flags are set and never cleared. With readfile/preprocessor
support, this changes and certain flags should be reset on each
line. For the time being, only fix handling of '-a' which
differentiates the "list" and "show" commands.
* rework the preprocessor support -- ipfw_main() already had most
of the parsing code, so i have moved in there the only missing
bit (stripping away '#' and comments) and removed the parsing
from ipfw_readfile().
Also, add some more options (such as -c, -N, -S) to the readfile
section.
MFC after: 3 days
spaces and comma-separated lists of arguments;
* reword the description of address specifications, to include
previous and current changes for address sets and lists;
* document the new '-n' flag.
* update the section on differences between ipfw1 and ipfw2
(this is becoming boring!)
MFC after: 3 days
* Make the addr-set size optional (defaults to /24)
You can now write 1.2.3.0/24{56-80} or 1.2.3.0{56-80}
Also make the parser more strict.
* Support a new format for the list of addresses:
1.2.3.4,5.6.7.8/30,9.10.11.12/22,12.12.12.13, ...
which exploits the new capabilities of O_IP_SRC_MASK/O_IP_DST_MASK
* Allow spaces after commas to make lists of addresses more readable.
1.2.3.4, 5.6.7.8/30, 9.10.11.12/22, 12.12.12.13, ...
* ipfw will now accept full commands as a single argument and strip
extra leading/trailing whitespace as below:
ipfw "-q add allow ip from 1.2.3.4 to 5.6.7.8, 9.10.11.23 "
This should help in moving the body of ipfw into a library
that user programs can invoke.
* Cleanup some comments and data structures.
* Do not print rule counters for dynamic rules with ipfw -d list
(PR 51182)
* Improve 'ipfw -h' output (PR 46785)
* Add a '-n' flag to test the syntax of commands without actually
calling [gs]etsockopt() (PR 44238)
* Support the '-n' flag also with the preprocessors;
Manpage commit to follow.
MFC after: 3 days
Should work with both regular and fast ipsec (mutually exclusive).
See manpage for more details.
Submitted by: Ari Suutari (ari.suutari@syncrontech.com)
Revised by: sam
MFC after: 1 week
They don't have alot of reason to be in sbin and contribute to library
bloat in the dynamic case. If you are using any of these filesystem
type to hold your /usr, please seek professional help.
The actual code was repo-copied by joe.
system by specifying the file system ID instead of a path. Use this
by default in umount(8). This avoids the need to perform any vnode
operations to look up the mount point, so it makes it possible to
unmount a file system whose root vnode cannot be looked up (e.g.
due to a dead NFS server, or a file system that has become detached
from the hierarchy because an underlying file system was unmounted).
It also provides an unambiguous way to specify which file system is
to be unmunted.
Since the ability to unmount using a path name is retained only for
compatibility, that case now just uses a simple string comparison
of the supplied path against f_mntonname of each mounted file system.
Discussed on: freebsd-arch
mdoc help from: ru
1.2.3.4/24{5,6,7,10-20,60-90}
for set of ip addresses.
Previously you needed to specify every address in the range, which
was unconvenient and lead to very long lines.
Internally the set is still stored in the same way, just the
input and output routines are modified.
Manpage update still missing.
Perhaps a similar preprocessing step would be useful for port ranges.
MFC after: 3 days
"ipid" options. This feature has been requested by several users.
On passing, fix some minor bugs in the parser. This change is fully
backward compatible so if you have an old /sbin/ipfw and a new
kernel you are not in trouble (but you need to update /sbin/ipfw
if you want to use the new features).
Document the changes in the manpage.
Now you can write things like
ipfw add skipto 1000 iplen 0-500
which some people were asking to give preferential treatment to
short packets.
The 'MFC after' is just set as a reminder, because I still need
to merge the Alpha/Sparc64 fixes for ipfw2 (which unfortunately
change the size of certain kernel structures; not that it matters
a lot since ipfw2 is entirely optional and not the default...)
PR: bin/48015
MFC after: 1 week
with a new implementation that has a mostly reentrant "addchar"
routine, supports multiple message buffers in the kernel, and hides
the implementation details from callers.
The new code uses a kind of sequence number to represend the current
read and write positions in the buffer. This approach (suggested
mainly by bde) permits the read and write pointers to be maintained
separately, which reduces the number of atomic operations that are
required. The "mostly reentrant" above refers to the way that while
it is now always safe to have any number of concurrent writers,
readers could see the message buffer after a writer has advanced
the pointers but before it has witten the new character.
Discussed on: freebsd-arch
(1) Reject zero-length strings for CTLTYPE_INT, _UINT, _LONG,
_ULONG. Do not silently convert to 0.
(2) When converting CTLTYPE_INT, _UINT, _LONG, and _ULONG, check the
end pointer generated by strtol() and strtoul() rather than
discarding it. Reject the string if either none of the string
was useful for conversion to an integer, or if there was
trailing garbage.
I.e., we will not allow you to set a numeric sysctl to a value unless
we can completely convert the string argument to a numeric value.
I tripped over this when I put the following in /etc/sysctl.conf:
kern.maxfiles="4000"
Ouch.
and libdevstat, since the new way of doing things is to just list
maintainership in src/MAINTAINERS.
Also, remove duplicate entries in src/MAINTAINERS for those utilities. I
already had entries for them.
number X, rather than mdX, making it easier to script tests that
use md devices but don't want to make assumptions about any existing
md use (such as in diskless environments).
