Phase 0

Phase 0 is the name we are giving to productizing our prototype as an interim fix while we do the implementation of the larger project. This is being done under the aegis of PSARC case 2007/136. Details about how to use this functionality are below.

Availability

 We putback into build 62 of Nevada (a.k.a. SunOS 5.11, sometimes called Solaris 11).

Caveats

• Enabling/Disabling NWAM: NWAM is implemented as an alternate instance of svc:/network/physical. To enable NWAM, first disable the default instance, svc:/network/physical:default, and then enable the NWAM instance, svc:/network/physical:nwam, using the svcadm(1M) command. Refer to the nwamd man page for more details
   Be cautious when enabling/disabling instance of network/physical, however. Your network configuration may change as a result; in particular, you may get a different IP address, which can wreak havoc with existing TCP connections, including NFS mounts. It is safest to make this configuration change in single-user mode, before the network has been configured.
• Automatic discovery of IP interfaces which may have become available as a result of a card insertion is not yet supported, but restarting the NWAM service (by invoking 'svcadm restart nwam') after such an insertion (or removal) will work around this limitation.
• Incorrect security keys: If a security key for a wireless LAN is incorrectly specified, or if the key changes, there is no way for nwamd to detect if something is wrong - the wireless link will report itself to be connected even if a wrong key is used, but no traffic will flow, and DHCP will time out. To fix this, it is currently necessary to delete the incorrect key manually. To do this, as root, run

    # dladm show-secobj

 and look for the object named nwam-<essid>-<bssid> or nwam-<essid>, where essid/bssid are the ESSID/BSSID of the problematic WLAN. These can be determined via

    # dladm show-wifi -p

 Then run:

    # dladm delete-secobj nwam-<essid>-<bssid>

 ...followed by

    # svcadm restart nwam

 The security key should be prompted for again, giving an opportunity to enter the correct/changed key.

Changing Configuration Policy

 By default, NWAM will implement a set of policy rules when configuring interfaces. It will configure one active interface at a time; it will select the one interface to configure based on availability (for wired interfaces, is the wire plugged in?) and preferring wired interfaces over wireless. Once an interface has been selected, NWAM will use DHCP to obtain an IP address and DNS server parameters for the interface. Only IPv4 will be enabled on the interface configured by NWAM.

 If you wish to change any of these policy rules, you may do so by modifying the /etc/nwam/llp configuration file; details on the format of this file may be found here. Note that this file will be deprecated when more extensive user interfaces are available (with the delivery of NWAM Phase 1).

Driver Oddities

Wired

See our DL_NOTE_LINK_{UP,DOWN} page for details.

Wireless
:

• The ath driver works well, though it had intermittent problems connecting via WEP until 6551525 was fixed in build 66.
• The iwi driver works well, though it had a confusing auto-connect behavior until 6542321 was fixed in build 66.
• The pcan driver works, though it did not report ESSIDs on SPARC until 6562579 was fixed in build 66.
• Other drivers are less well tested.

Tunables

 All of these are properties under the property group nwamd of the service instance svc:/network/physical:nwam.

Help!

 If you are having problems with NWAM, it may help to visit our troubleshooting guide.