“Diskless booting” means that the FreeBSD box is booted over a network, and reads the necessary files from a server instead of its hard disk. For full details, please read the Handbook entry on diskless booting.
Typically, people who ask this question have two PCs at home, one with FreeBSD and one with some version of Windows the idea is to use the FreeBSD box to connect to the Internet and then be able to access the Internet from the Windows box through the FreeBSD box. This is really just a special case of the previous question and works perfectly well.
If the alias is on the same subnet as an address already configured on the interface, then add netmask 0xffffffff to your ifconfig(8) command-line, as in the following:
# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff
Otherwise, just specify the network address and netmask as usual:
# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00
You can read more about this in the FreeBSD Handbook.
Some versions of the Linux NFS code only accept mount requests from a privileged port; try to issue the following command:
# mount -o -P linuxbox:/blah /mnt
FreeBSD supports multicast host operations by default. If you want your box to run as a multicast router, you need to recompile your kernel with the MROUTING option and run mrouted(8). FreeBSD will start mrouted(8) at boot time if the flag mrouted_enable is set to YES in /etc/rc.conf.
See the answer in the FreeBSD Handbook.
If you have compiled your kernel with the IPFIREWALL option, you need to be aware that the default policy is to deny all packets that are not explicitly allowed.
If you had unintentionally misconfigured your system for firewalling, you can restore network operability by typing the following while logged in as root:
# ipfw add 65534 allow all from any to any
You can also set firewall_type="open" in /etc/rc.conf.
For further information on configuring a FreeBSD firewall, see the Handbook chapter.
Possibly because you want to do network address translation (NAT) and not just forward packets. A “fwd” rule does exactly what it says; it forwards packets. It does not actually change the data inside the packet. Say we have a rule like:
01000 fwd 10.0.0.1 from any to foo 21
When a packet with a destination address of foo arrives at the machine with this rule, the packet is forwarded to 10.0.0.1, but it still has the destination address of foo! The destination address of the packet is not changed to 10.0.0.1. Most machines would probably drop a packet that they receive with a destination address that is not their own. Therefore, using a “fwd” rule does not often work the way the user expects. This behavior is a feature and not a bug.
You can redirect FTP (and other service) request with the sysutils/socket port. Simply replace the service's command line to call socket instead, like so:
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp
where ftp.example.com and ftp are the host and port to redirect to, respectively.
You are running a program that requires the Berkeley Packet Filter (bpf(4)), but it is not in your kernel. Add this to your kernel config file and build a new kernel:
device bpf # Berkeley Packet Filter
Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as mount_smbfs(8) in the base system.
This is the kernel telling you that some activity is provoking it to send more ICMP or TCP reset (RST) responses than it thinks it should. ICMP responses are often generated as a result of attempted connections to unused UDP ports. TCP resets are generated as a result of attempted connections to unopened TCP ports. Among others, these are the kinds of activities which may cause these messages:
Brute-force denial of service (DoS) attacks (as opposed to single-packet attacks which exploit a specific vulnerability).
Port scans which attempt to connect to a large number of ports (as opposed to only trying a few well-known ports).
The first number in the message tells you how many packets the kernel would have
sent if the limit was not in place, and the second number tells you the limit. You
can control the limit using the
net.inet.icmp.icmplim sysctl variable like this, where 300 is the limit in packets per second:
# sysctl net.inet.icmp.icmplim=300
If you do not want to see messages about this in your log files, but you still
want the kernel to do response limiting, you can use the
net.inet.icmp.icmplim_output sysctl variable to disable the
output like this:
# sysctl net.inet.icmp.icmplim_output=0
Finally, if you want to disable response limiting, you can set the
net.inet.icmp.icmplim sysctl variable (see above for an
example) to 0. Disabling response limiting is discouraged
for the reasons listed above.
This means that some device on your local Ethernet is using a MAC address in a format that FreeBSD does not recognize. This is probably caused by someone experimenting with an Ethernet card somewhere else on the network. You will see this most commonly on cable modem networks. It is harmless, and should not affect the performance of your FreeBSD machine.