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

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

• 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 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.

• We have been unable to find detailed and accurate Apple documentation describing how the Mac behaves when multiple physical network ports are active 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 designating inactive all but one of the network ports in each location. Define a different network location for each physical network port you typically use.

• When working with the Locations sheet in the Network pane of Systems Preferences, on rare occassions the Systems Preferences application will crash. This may cause recent changes you have made to be lost.

  We have confirmed this problem through version 10.5.0.

• When working with the Locations sheet in the Network pane of Systems Preferences, sometimes locations you deleted in the past will unexpectedly re-appear.

  We have confirmed this problem through version 10.5.0.

• When you use the Locations sheet in the Network pane of Systems Preferences, the Duplicate Location command (accessed by selecting Edit Locations... and then using the Action (gear) menu) doesn't make a perfect duplicate of the currently-selected location.

  For example, if any network interfaces in the original location were marked inactive, they will be marked active in the duplicate location. And some of the individual settings scattered throughout the new location's network ports will not have the same values as the original location, but instead will revert to their default values. As a result, you must proofread the duplicate carefully, correcting each individual item.

  We have confirmed this problem through version 10.5.0.

• When you click on the name of network port (a.k.a. "service") in the left side of the Network pane of Systems Preferences, sometimes the selected location in the Location pop-up menu suddenly changes.

  This may happen more often if you have selected a different location used the Location pop-up menu shortly before clicking on the name of a network port in the newly-selected location.

  We have confirmed this problem through version 10.5.0.

• If the Mac has more than one network port (e.g. Ethernet and Wireless) designated Active 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 designated Active and simultaneously attached to a live network. You can do so by following OIT's instructions for creating multiple locations, designated all but one network port as Inactive 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) designated Active 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, designating all but one network port as Inactive 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.) We have not yet determined if the problem continues to affect version 10.5.0 and later; we assume it does until we determine otherwise.

  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.

• If you create multiple network locations, it appears that some of the configuration settings for AirPort interfaces in each location are not stored separately.

  This may affect settings that appear on an AirPort interface's basic configuration display and under the AirPort tab in the Advanced configuration display.

  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, the Mac may not always behave that way.

  For example, if you change the selected wireless network name in one location, enabling or disabling the AirPort interface, or altering the list of preferred wireless network names, these changes may affect the AirPort interface in other locations as well.

  If this happens, it prevents you from reliably configuring separate locations to explicitly connect to different wireless networks. For example, 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 cafe, you may be unable to do so. Any changes made to one location may appear in the other locations as well.

  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 are not yet sure whether the problem is still present in version 10.5.0.

• 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.5.x 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.5.x 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.5.0.

• If there are no wireless network names in the Preferred Networks list, and you have specified the Mac should not Remember any network this computer has joined, and you have specified the Mac should Ask to join new networks, the Mac should prompt you every time before joining any wireless network.

  Instead, it typically doesn't display any prompt. It just doesn't try to join any wireless network.

  We have confirmed this problem through version 10.5.0.

• The AirPort menu in the menu bar often malfunctions in a variety of ways.

  This menu sometimes fails to list available wireless networks. Sometimes it will indicate the Mac is connected to one wireless network, when in fact the Mac is connected to a different wireless network, or not connected to any wireless network. Sometimes it will indicate the Mac is not connected to any wireless network, when the Mac is indeed connected to a wireless network.

  This menu may claim that the AirPort network interface is turned off when the interface is in fact turned on. It displays a Turn AirPort On command that has no effect.

  While connected to a wireless network, the icon of the menu should change from a hollow "pie segment" outline, to instead show signal strength. Instead, it sometimes doesn't change.

  The Open Network Preferences command in this menu sometimes has no effect.

  Until these problems are fixed, the AirPort menu is of limited value.

  We have confirmed these problems through version 10.5.0.

• If you have created two (or more) locations with an AirPort interface active, and each location specifies a different wireless network name, the Network pane of System Preferences can sometimes display misleading information.

  This can happen in the following common situation: You use one location that has an active AirPort interface configured to use one wireless network name. You open System Preferences, and select the Network Preferences panel. You use the Location pop-up menu to change to a different location that also contains an active AirPort interface configured to use a different wireless network name. You click on the AirPort interface in the list of ports on the left side of the pane. In the basic configuration on the right side of the pane, the Network Name pop-up menu should show the wireless network name configured for the selected AirPort interface in the current location. However, unless you click the Apply button in the lower-right corner, this pop-up menu may instead show the wireless network name from the previous location. It's not accurately display the settings for the location you've asked to work with.

  We have confirmed this problem through version 10.5.0.

• 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.

• Within a single network location, a single VPN (PPTP) network port can effectively support only one VPN service configuration.

  (It can effectively be used with more than account name/password combination, when all the other VPN settings for the VPN service configuration remain the same. As long as you don't save a password as part of the configuration, you will be prompted for the account name and password each time you connect to a VPN server.)

  Although the basic configuration pane for a VPN (PPTP) network port has an Add Configuration... command (in the Configuration pop-up menu) to allow you to define multiple configurations, all these configurations share a single set of advanced configuration settings. It is unlikely that a single group of advanced settings would be appropriate for different VPN services.

  To be able to have truly independant settings for each VPN service within a single network location, do not use the Add Configuration... command. Instead, for each VPN service, create a separate VPN (PPTP) network port in the location. The settings for separate VPN (PPTP) network ports in a single location are independent. You may select which VPN (PPTP) network port to use from the VPN Of course, a different approach is to use separate locations to store the settings for different VPN services.

  We have confirmed this problem through version 10.5.0.

• The Configuration pop-up menu in the basic configuration display displayed for VPN (PPTP) interfaces often malfunctions.

  This is a pop-up meu that appears when you are displaying the Network preferences pane of System Preferences, have selected a location that has a VPN (PPTP) interface, and you have selected the VPN (PPTP) interface on the left side of the pane. The Configuration pop-up menu apears in the right side of the pane, a display we refer to as the basic settings for this network port.

  If you create multiple configurations using this pop-up menu, the Delete command in this menu will sometimes delete a configuration other than the one you instructed it to delete. It can sometimes delete more than one configuration. Sometimes a configuration it deleted mysteriously returns.

  It's best to create just a single configuration in this menu, and not create any others; that will minimize the opportunities to trigger this bug.

  We have confirmed this problem through version 10.5.0.

• The Server Address value entered in the basic configuration display displayed for VPN (PPTP) interfaces sometimes loses its setting.

  This is a text field that appears when you are displaying the Network preferences pane of System Preferences, have selected a location that has a VPN (PPTP) interface, and you have selected the VPN (PPTP) interface on the left side of the pane. The Server Address text field appears in the right side of the pane, a display we refer to as the basic settings for this network port.

  After you enter a value in this field and apply the change, it appears to be saved. But the value you enter appears to be lost from time to time, perhaps after you switch among multiple locations and then return to this location.

  We have confirmed this problem through version 10.5.0.

• The Encryption value selected in the basic configuration display displayed for VPN (PPTP) interfaces often reverts to the default value.

  This is a pop-up menu that appears when you are displaying the Network preferences pane of System Preferences, have selected a location that has a VPN (PPTP) interface, and you have selected the VPN (PPTP) interface on the left side of the pane. The Encryption pop-up menu appears in the right side of the pane, a display we refer to as the basic settings for this network port.

  The default value for this field is Automatic (128 bit or 40 bit). In most circumstances, you change this to Maximum (128 bit only). However, when you do so, the menu often reverts to the default value. This represents a security issue.

  We have confirmed this problem through version 10.5.0.

• 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.