We spent May implementing a reduced-scope prototype, to provide broader exposure for what we are doing, to get feedback on our work so far, and to get ideas about how people will use this, which will help inform our design decisions about more advanced features. By "reduced-scope" we mean that this prototype intentionally makes a simplifying assumption: that only one network interface will ever be active at any given time; this makes the prototype especially useful for laptops, which often have this usage model. This limitation will not be present in the final product, however, which will scale as Solaris does from the laptop to the enterprise server.
See below for
- target system requirements
- how to download the source and the binaries
- a list of shortcomings (known bugs, missing features, planned enhancements)
- usage caveats
- instructions and examples for required manual configuration
Requirements
The ON (OS/Networking) portion of your target machine must be running build 36 or later of Solaris Nevada (SunOS 5.11). For builds 36 - 51, use version 0.3; for builds 52 & 53, version 0.3 can be used but may cause problems because it still refers to the network/pfil SMF service, which went away in build 52; for builds 54 and later, use version 0.4.
Downloads
- Package
- This is only available for i386, at least for now; if anyone has a SPARC laptop on which you wish to try this, let us know and we will see about building it for you.
- Note that when you install it, you will likely get a warning:
The following files are already installed on the system and are beingused by another package: /lib/svc/method/net-svc /var/svc/manifest/milestone/network.xml /var/svc/manifest/network/ipfilter.xml /var/svc/manifest/network/pfil.xml /var/svc/manifest/network/ssh.xml /var/svc/manifest/system/identity.xmlDo you want to install these conflicting files [y,n,?,q]
This is expected; answer 'y'. Note that the network/pfil line will only appear when installing version 0.3; version 0.4 will show the other lines but not that one.
- Source
- Extracting this tar file will generate a netprofd directory, which (as noted in the comments in its Makefile) should be placed under usr/src/cmd/cmd-inet/usr.lib/.
- Download here
Shortcomings
- The driver for your network device must support sending DL_NOTE_LINK_UP and DL_NOTE_LINK_DOWN to IP when a cable is plugged and unplugged for the "auto-magic" part to work. The bge driver on Ferrari 3400s is known to do this properly; the bcme driver on Ferrari 4000s appears not to. Note that there is a difference between the driver logging a message on the console and notifying IP, as some drivers do the former, but the latter is needed. We have verified that starting with Nevada build 43 (specifically, ON nightly builds which include putbacks from 2006-Jun-07 or later), Ferrari 4000s can use bge, and the "auto-magic" works as expected. More details can be found on the DL_NOTE_LINK_{UP,DOWN} page.
- At present, the only way to go 'stand-alone' is svcadm disable [-t] profiled.
- There is no good way at present to get status beyond the usual ifconfig -a.
- Insertion/removal of PCMCIA cards is not yet supported
- The code uses wificonfig
- once libwladm becomes available, its APIs will be used directly.
- The scan of available wireless networks is only done once, when the daemon starts. If this is a problem, svcadm restart profiled will force a rescan, albeit at the cost of tearing down whatever interfaces are currently active. We intend to address this.
- IPv6 is not supported yet.
- Ferrari 3400 laptops with a bge interface, when plugged and unplugged multiple times, and the other end is plugged into a Netgear switch, result in the link light no longer being activated on either end. A manual ifconfig bge0 unplumb ; ifconfig bge0 plumb seems to fix this most of the time. We plan to file a bug once we characterize the problem more completely.
- Punchin users: when punching out, punchctl (from SUNW0punchin versions prior to 1.3.0) restores your old default route, but the interface (in netstat -r output) is unspecified, so you can end up in a situation with two default routes. You can work around this by manually deleting the old one. Alternatively, upgrading SUNW0punchin to version 1.3.0 fixes the problem.
Caveats
- Interface (in the attributes(5) sense) Stability
- This is a prototype.
- It is not yet part of Solaris.
- Until it appears in a release it is subject to change without notice.
- Network Interface (in the ifconfig(1M) sense) Configuration
- Neither /etc/hostname.* files nor /etc/dhcp.* files are used. Instead, the netprofd daemon will detect all available links; it will store information about these links in the file /etc/nwam/llp. This file will be automatically created by the daemon; or it may be created/modified by the user.
- See the Link-Layer Profiles § in the Instructions section below for details on this configuration file.
- So far, almost all of our testing has been on Acer Ferrari 3400 laptops. We look forward to hearing about your experiences on other configurations!
- There is no real user interface: see the Instructions below for how to roll your own versions of the scripts which are needed to make the profiles work, and for samples of such scripts.
Instructions
Link-Layer Profiles
- The format of an entry in /etc/nwam/llp is:
link_name static|dhcp [ipaddr or hostname]
If the second field is dhcp, then DHCP will be used to obtain an IP address. If the second field is static, then the IP address specified by the third field will be assigned to the interface. As an example, the following is common:
bge0 dhcpath0 dhcp
- Only one link will be active at any given time. If more than one link is available, the active one will be selected based on the order in which links appear in the /etc/nwam/llp file: in the above example, bge0 is preferred over ath0. An important implication of this is that if a lower-preference link is running at start-up, and a higher-preference link is available (IFF_RUNNING), the lower-preference link will be taken down, and the higher-preference link will be brought up.
Upper-Layer Profiles
Once an interface is brought up and an IP address is configured for it, /etc/nwam/ulp/check-conditions is run if it exists and is executable. This is expected to print a single line of output, which is the name of the upper-layer profile which the user wishes to be activated based on the current conditions. If such a line is read successfully (foo in this example), then /etc/nwam/ulp/foo/bringup is executed. Likewise, when the interface gets torn down for whatever reason, /etc/nwam/ulp/foo/teardown is executed. Below are samples for the check-conditions, bringup and teardown scripts.
For the curious, /usr/local/bin/punchctl is the script which activates and deactivates the (Sun internal, as yet) IPsec-based VPN which many of us use.