FreeBSD 6.0-RELEASE Errata

---

1 Introduction

This errata document contains “late-breaking news” about FreeBSD 6.0-RELEASE. Before installing this version, it is important to consult this document to learn about any post-release discoveries or problems that may already have been found and fixed.

Any version of this errata document actually distributed with the release (for example, on a CDROM distribution) will be out of date by definition, but other copies are kept updated on the Internet and should be consulted as the “current errata” for this release. These other copies of the errata are located at http://www.FreeBSD.org/releases/, plus any sites which keep up-to-date mirrors of this location.

Source and binary snapshots of FreeBSD 6-STABLE also contain up-to-date copies of this document (as of the time of the snapshot).

For a list of all FreeBSD CERT security advisories, see http://www.FreeBSD.org/security/ or ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/.

---

2 Update Information

No news.

---

3 Security Advisories

The following security advisories pertain to FreeBSD 6.0-RELEASE. For more information, consult the individual advisories available from ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/.

---

4 Known Problems and Solutions

(2005/11/26) On 6.0-RELEASE, the following ipfw(4) rule is interpreted in a different way from the previous releases:

allow ipv6 from 192.168.0.2 to me

When ipfw(4) does not support IPv6 (see the next entry for the details), ipfw(8) accepts this rule and this blocks an IPv6 packet encapsulated in an IPv4 packet (IPv6-over-IPv4 tunneling, protocol number 41) whose source address is 192.168.0.2. When it supports IPv6, on the other hand, this means a rule to allow an IPv6 packet from 192.168.0.2, and actually ipfw(8) rejects this rule because the syntax is incorrect (“an IPv6 packet from an IPv4 address” never happens). Unfortunately there is no simple workaround for this problem.

The ipfw(4) IPv6 support still has rough edges and there are other problems due to incompatibility between the two. As a workaround for them, you can use a combination of IPv4-only ipfw(4) and ip6fw(8), which is almost compatible with the prior releases, instead of ipfw(4) with IPv6 support. To disable IPv6 support of ipfw(4), use the ipfw.ko kernel module and do not use the kernel option IPFIREWALL.

(2005/11/19) Although the FreeBSD 6.0-RELEASE Release Notes states that ipfw(4) subsystem now supports IPv6, the combination of the GENERIC kernel and a kernel module ipfw.ko does not support the ip6 protocol keyword for packet filtering rule. This is because the kernel option INET6 in the kernel configuration file is not recognized when the ipfw.ko is built. To enable IPv6 support of ipfw(4), rebuild the kernel with kernel options INET6 and IPFIREWALL instead of using the ipfw.ko module.

(2005/11/16) Using if_bridge(4) in combination with a packet filter such as ipfw(4) and pf(4) can prevent the network stack from working and/or lead to a system panic after a certain period of time. This is because it allocates mbuf(9) buffers for network packets and never releases a part of them, so eventually all of the buffer memory will be exhausted. This problem has been fixed in the HEAD and the RELENG_6 branch after 10:17:15 2005/11/16 UTC.

(2005/11/16, updated on 2005/11/19) When an ipfw(4) divert rule is specified with the protocol keyword ip or all, IPv6 packets are silently discarded at that rule since the divert(4) socket does not support IPv6. This can be a problem especially for an IPv4 and IPv6 dual-stack host with natd(8) enabled. Note that the kernel module ipfw.ko does not have this problem because it does not support IPv6. To avoid this problem, use an IPv4 specific divert rule such as divert natd ipv4 instead of divert natd all.

(2005/11/6) The FreeBSD 6.0-RELEASE Release Notes wrongly states a kernel option related to ipfw(8) as IPFIRWALL_FORWARD. The correct option keyword is IPFIREWALL_FORWARD.

(2005/11/5) The FreeBSD 6.0-RELEASE Release Notes wrongly states the version number of OpenSSH and IPFilter integrated into FreeBSD as 4.1p1 and 4.1.18. The correct versions are 4.2p1 and 4.1.8 respectively.

(2005/11/5) Distribution of 6.0-RELEASE contains CHECKSUM.MD5 and CHECKSUM.SHA256 files for protecting the integrity of data. However, these files in 6.0-RELEASE erroneously include checksums for the checksum files themselves. Although the checksums look like wrong, they can be safely ignored because a checksum for the checksum file never corresponds to one in the file. This problem will be fixed in the next releases.

(2005/11/5, FreeBSD/amd64 specific) The pmcstat(8) utility cannot yet handle 32-bit executables when converting hwpmc(4) log files to gprof(1) format.

(2005/11/5, FreeBSD/powerpc specific) The following panic may occur at boot-time on some older PowerMac G4 systems:

...
KDB: current backend: ddb
panic: Assertion curthread != NULL failed at
/usr/src/sys/kern/kern_mutex.c:268
KDB: enter panic

This is a known problem with no workaround, and will be fixed in the next release.

(2005/11/5) Changes of on-disk format of /usr/share/locale/*/LC_* files in 6.0-RELEASE prevent third-party software which uses setlocale(3) for its localization from working after a 5.x system upgraded. The software includes ones installed into the 5.x system by using FreeBSD Ports Collection and so on. To solve this problem, perform one of the following:

• Install misc/compat5x package into the upgraded 6.0 system. This package installs a library lib/compat/libc.so.5 which makes the software complied in a 5.x system use the old locale files to keep compatibility. Note that you need to remove /lib/libc.so.5 after upgrading.

  This package is available only for Tier-1 platforms.

• Recompile the software on the 6.0 system.

(2005/10/3) At boot time the FreeBSD/sparc64 GENERIC kernel may output the following messages when the machine has no framebuffer:

Aug 26 19:31:27 hostname getty[429]: open /dev/ttyv1: No such file or directory

This is because the machine with no supported graphics hardware does not recognize syscons(4) and /dev/ttyv* device nodes are not created. This is not a harmful error and can be suppressed by disabling /dev/ttyv* entries in /etc/ttys.

(2005/10/3) Kernel modules do not work on FreeBSD/sparc64 when the machine has more than 4GB memory. There is no workaround for this issue except for compiling the modules statically into your custom kernel in advance.

(2005/10/3) The kgdb(1) utility does not work properly on FreeBSD/sparc64 for debugging panics which include traps. As a workaround you can use devel/gdb53.