Mac OS X 10.4.x Network Configuration: OIT Notes and Caveats

This document contains OIT notes and caveats about Mac OS X 10.4.x Network Configuration. This document covers version 10.4.10.

• Network startup happens when the Mac boots, and uses whatever location was selected at the time the Mac last shutdown. Mac OS X does not currently provide a way for you to change the selected location until after startup is complete and you have logged in (regardless of whether you log in manually or automatically).

  As a result, if you have moved your Mac to a different connection since last shutting down or logging out, the location in effect at network startup time may not be appropriate. Although you can select a more appropriate location once the Mac has finished starting and you are logged in, having the wrong location selected at network startup time can be inconvenient:

  • It may cause startup delays, if the Mac must attempt to bring up a network port that is disconnected, look for a DHCP or BootP server that will not be found, or look for a wireless network that is not available in your current physical location.

  • Other network-based software that starts at boot time may not function without a working network connection. Some of this software may "heal" when you change the location to an appropriate one. If you find that some of the network-based software on your Mac does not "heal" in this way, you can work around the problem by rebooting your Mac after selecting an appropriate location.

• If your installation of Mac OS 10.4.x involved an upgrade from an OS version older than 10.4, or involved importing network configurations from an older OS version, the imported network configurations may not work correctly. They may not even display the settings that should be displayed in version 10.4.

  In some situations, the Network pane in System Preferences may display elements of the user interface from 10.3, rather than 10.4. Items that were added or changed in 10.4 may not appear. The settings imported from 10.3 may appear acceptable, but fail to work correctly.

  We've seen this in particular with "AirPort" interface settings.

  Correct the problem by completely deleting all network locations that were imported/upgraded from the older OS, then create them anew in 10.4.

• We have been unable to find detailed and accurate Apple documentation describing how the Mac behaves when multiple physical network ports are enabled in a single network location.

  The brief information Apple provides indicates that the Mac tries the network ports in the order they appear in the network location's list of network ports. This information appears to be incomplete at best; it instead appears instead that the OS will make simultaneous use of the enabled ports, at least for some kinds of ports. The effect of the ordering is unclear.

  For Macs with multiple physical network ports (which is typical), we generally recommend that you avoid possible unexpected behaviors by explicitly enabling only a single physical network port (e.g. Ethernet, AirPort, or Modem) in each location, and define a different network location for each physical network port you typically use.

• TCP/IP in the Classic environment uses the same IP address as the Mac OS X environment; they share an IP address. The Classic environment does not perform DHCP, BootP, PPP IPCP, etc. to learn its IP address; it simply shares whatever IP address was obtained by Mac OS X.

  Sharing one IP address between the two environments works extremely well for nearly all situations. One issue to be aware of is that as there's a single IP address; the same TCP or UDP ports cannot be re-used among the Mac OS X and Classic environments. For example, if you run an FTP server (which listens on a particular TCP port number) in Mac OS X, you won't be able to run a second FTP server simultaneously (listening on the same TCP port number) in the Classic environment.

  This does not affect programs that use ephemeral ports (most client programs use ephemeral port numbers, while most server programs use particular port numbers).

  This is not a bug; it's simply something to be aware of if you choose to run servers simultaneously in both environments.

• If the Mac has more than one network port (e.g. Ethernet and Wireless) turned "on" and simultaneously attached to two networks, and these networks are different IP subnets, some traffic sent by the Mac will be discarded by the campus network.

  Mac OS X's IP implementation uses the "Weak End System Model" with respect to transmitting. The Mac transmits some data via one network port, but marks the data as coming from the IP address of the other network port. OIT's IP routers perform "IP ingress spoof filtering" to discard packets containing IP sources inappropriate for the network on which they were received, as such traffic can represent a security problem.

  This is not a bug in Mac OS X's IP implementation; the "Weak End System Model" is allowed by IP specifications. Neither is there anything wrong with the IP ingress spoof filtering performed on OIT's IP routers. However, when used in combination, they result in packet loss. IP ingress spoof filtering is an important measure to combat certain kinds of network-based attacks; it will not be disabled.

  One fix would be for Mac OS X to adopt the "Strong End System Model" with respect to transmitting. This ensures that data transmitted by the Mac from each network port is marked with the IP address of that network port, not the Mac's other network port. Such an approach is especially appropriate for multihomed hosts. However, we are not aware of any plans to enhance Mac OS X to do this.

  This issue is not unique to Mac OS X; most current operating systems employ the Weak End System Model, as their IP implementations were written before IP ingress spoof filtering was a common practice. The issue is highlighted by Mac OS X because by default, it tries to make all ports active, and modern Macs often have both an Ethernet and a Wireless port.

  To work around the problem, we recommend you not allow the Mac to find itself in a situation where more than one network port is turned "on" and simultaneously attached to a live network. You can do so by following OIT's instructions for creating multiple locations, marking just one network port marked as turned "on" in each location. (I.e. do not rely on the Automatic location shipped with Mac OS X if the Mac has multiple network ports.)

• If the Mac has more than one network port (e.g. Ethernet and Wireless) turned "on" and simultaneously attached to the same IP network (i.e. subnet), the Mac's operating system may may operate in a way that's not acceptable on the campus network.

  This is a variation of the issue described above (the "Weak End System Model" with respect to transmitting), but is a larger problem when both interfaces are attached to the same IP subnet. Like most operating systems, Mac OS X may not operate well when it has multiple interfaces attached to the same IP subnet simultaneously. Most operating systems are not designed to handle this configuration.

  You will not encounter this situation if your Mac has just an Ethernet and a Wireless interface, and the Wireless interface is configured to use only OIT Wireless Service, as OIT Wireless Service provides a connection to an IP subnet that is not available via any other mechanism (there are no customer Ethernet ports attached to the same subnet as OIT Wireless Service). But you will encounter this situation if you configure your Wireless interface to use other (private) Wireless Access Points, and any of them are configured to operate as a bridge and are attached to the same IP network that your Mac's Ethernet interface is currently wired to.

  To work around the problem, you must not allow the Mac to find itself in this situation. You can do so by following OIT's instructions for creating multiple locations, marking just one network port marked as turned "on" in each location. (I.e. do not rely on the Automatic location shipped with Mac OS X if the Mac has multiple network ports.)

• The Mac OX X DHCP client sometimes send a DHCPDISCOVER message while in the DHCP BOUND state; it should do so only while in the DHCP INIT state. This behavior is not in compliance with RFC 2231 ("Dynamic Host Configuration Protocol").

  Receipt of a DHCPDISCOVER from a client results in our DHCP server terminating the client's old DHCP lease, as a client may only send a DHCPDISCOVER when it is in the DHCP INIT state. However, the Mac OS X DHCP client sometimes ignores the new DHCPOFFER messages sent to it, and instead continues to use the IP address it has just abandoned by sending the DHCPDISCOVER. That is, it remains in (or returns to) the BOUND state for the old (abandoned) lease.

  If what the client is trying to do is "Detection of Network Attachment in IPv4 (DNAv4)", then this is also not in compliance with RFC 4436. As per that RFC, a device with an "operable address" should start in the DHCP INIT-REBOOT state and send a DHCPREQUEST.

  In this situation, when the Mac OS X DHCP client decides that the lease it imagines still belongs to it is due for DHCP RENEWAL, sometimes the DHCPREQUEST messages it sends are also malformed. Specifically, the DHCP 'Server IP Address Option' is 0, the DHCP 'Requested IP Address Option' is 0, and the 'ciaddr' field is 0. (There is no case where a DHCP client should send a DHCPREQUEST packet with that set of characteristics.) This is not in compliance with RFC 2231.

  We have seen these problems in all versions of Mac OS X versions 10.4.2 through 10.4.10. (It's possible it was introduced earlier, in version 10.4 or 10.4.1, and we only became aware of it starting in 10.4.2.)

  The result of the client's behavior is that sometimes Macs "steal" IP addresses no longer assigned for their use, interfering with service to other customers.

  We reported the problem to Apple; Apple looked into the matter, and responded that they believe that the Mac OX X DHCP client behaves correctly.

  We sought opinions regarding this matter via the IETF DHCP Working Group mailing list. While there was some disagreement, the outcome of the discussion was that the DHCP client is not behaving in compliance with RFC 2231 and (if it is implementing DNAv4) RFC 4436.

  We advised Apple of the outcome of that discussion. Apple indicated that they woudl again looking into the matter, but we've received no indication that there has been any progress.

  While the problem continues, Macs continue to "steal" IP addresses no longer assigned for their use, interfering with service to other customers.

• When configured to connect to a specific wireless network, and that network is protected by a WEP password which the Mac has been configured to use, the Mac sometimes does not try to connect to the wireless network.

  Instead, the Mac acts like it is trying to connect, but in reality is not transmitting any traffic to the Wireless Access Point to request a connection to the wireless network.

  This commonly happens when the Mac is booted, or when it wakes from sleep.

  On occcassion, the Mac will recover after a few minutes, and connect to the network. Sometimes reboot the Mac will resolve the problem, or switching to a different network location (one that doesn't include the AirPort interface) and then switch back. Sometimes it is necessary to delete the interface containing the configuration (e.g. remove the AirPort interface from the location, or remove the entire location definition), reboot, then recreate the configuration (add the AirPort interface back to the location, or add the entire location if it was deleted).

  We have verified the problem exists at least through versions 10.4.10. It may exist in other versions as well.

• Beginning in version 10.4, the wireless network(s) you wish to connect to are not set separately for each AirPort interface in each network location. Although the user interface for the AirPort interface in each the Network pane (in System Preferences) implies that the settings are specific to each AirPort interface in each network location, instead it appears that the list of wireless network(s) is shared among all AirPort interfaces in all locations.

  This prevents you from configuration separate locations to connect to different wireless networks. E.g. if you want to create one location that will connect (only) to OIT Wireless Service (for use on campus), another location that will connect (only) to a private wireless network (e.g. when visiting a residence off-campus), and another location to connect to (only) a commercial wireless network in a bookstore, you will be unable to do so. Any changes made to the list of preferred wireless network(s) in one location will appear in the other locations as well.

  This appears to violate the design of having different network locations to allow you to switch among different sets of network settings.

  If you use multiple locations with different wireless networks, and rely upon these settings to ensure you only connect to specific wireless networks in specific locations, this may represent a security problem, because it may allow your Mac to connect to a wireless network you didn't intend to connect to in a particular location.

  We have verified the problem exists at least through version 10.4.10; it may exist in other versions as well.

• When entering a WEP password, you can explicitly select from WEP 40/128-bit hex and WEP 40/128-bit ASCII to explicitly indicate whether the password is hexadecimal or ASCII, or select WEP Password to obtain the old behavior that may involve guessing. However, 10.4 lacks a way to explicitly do the same for WPA Personal passwords; it still has a single WPA Personal choice that presumably performs guessing (actual behavior doesn't appear to be documented.) Similarly, 10.4 lacks a way to explicitly do the same for WPA2 Personal passwords; it still has a single WPA2 Personal choice that presumably performs guessing (actual behavior doesn't appear to be documented.)

  We have verified this through version 10.4.8.

• Changes made to the AirPort settings in the Network pane of System Preferences often do not take effect after you click the Apply Now button.

  For example, if you make changes to the preferred wireless network(s), or change the network password, the user interface may indicate that the change has been made, but in reality, the Mac has not made the change. If the change should have caused the Mac to disconnect from a previous wireless network, the Mac may in fact not attempt to disconnect from the previous wireless network. If the change should have caused the Mac to connect to a wireless network (perhaps with different settings than before), the Mac may in fact not attempt to connect to the wireless network (with the new settings). Our tests show that when this happens, regardless of what the Mac claims in the user interface, it is failing to transmit the necessary wireless frames to implement the settings you specified in the user interface.

  Convincing the Mac to actually perform the change you request can be a hit or miss affair. Sometimes turning the AirPort interface off and then on will do the trick. Sometimes switching to a different network location in which the AirPort interface is disabled (and then switching back) to work. Sometimes rebooting the Mac will do it. And sometimes nothing short of completely deleting the network location, rebooting, and re-adding the network location (with the new settings) will work.

  We have verified these problems exist at least through version 10.4.10.

• In version 10.4.1, when you try to connect to a wireless network that uses open authentication (e.g. no WEP or WPA passwords, or other authentication schemes), the Mac may erroneously claim it cannot connect to the network, claiming that you entered an incorrect password for the network. (This is despite the fact that you entered no password, and the network uses no password.)

  We have not determined if this bug also affects versions 10.4.2 or later.

• In version 10.4.1, when you are connected to a wireless network, the name of the wireless network displayed in the AirPort pane of the Internet Connect application, in the AirPort menu, and in the AirPort section of the Network pane in the System Preferences application may disagree.

  We have not yet determined if this bug also affects versions 10.4.2 or later.

• Apple's VPN client is a Microsoft-compatible Point to Point Tunneling Protocol (PPTP) implementation. Anyone who relies on a Microsoft-compatible PPTP-based VPN (i.e. essentially all PPTP implementation today) should be aware that there are some security concerns with the use of Microsoft PPTP.

• The PPTP VPN client does not provide a way to tune certain parameters associated with the VPN connection. Some of these parameters a security-conscious customer might have wished to have the ability to tune:
  • The client will attempt to authenticate using the MS-CHAPv1 or MS-CHAPv2 protocol, as selected by the VPN server. If unable to authentiate using one of those protocols, the client will disconnect. (Its willingness to use the MS-CHAPv1 protocol is a security vulnerability. Apple has not yet documented a way to reconfigure it so it will refuse to fall back to MS-CHAPv1.)

  • The client attempts to use the MPPC compression protocol. If unable to negotiate MPPC, it is willing to connect without compression.

  • While the VPN connection is active, the Mac's IP default IP route is via the VPN server. However, the Mac still has an interface route to each locally-attached network. (I.e. the IP subnet to which each interface is currently attached.)

    The Mac will still use those interface routes in preference to the default route.

    As a result, traffic between the Mac and other devices on the same IP subnet as any of its interfaces will not use the VPN connection, but instead will continue to travel directly between the Mac and the other devices.

• The Internet Sharing feature (a combined NAT, DHCP server, and Wireless Access Point) is inappropriate for use on any Macintosh attached to the campus wired or wireless network. Each version we have examined has one or more bugs that cause it to interfere with campus network service.

  By default, this feature is turned off. If your Mac is attached to the campus network, do not turn on this feature.

  For more details, see Do Not Use Mac OS X's Internet Sharing Feature on the Campus Network.