From meem@triplex.East.Sun.COM Mon Nov 6 07:54:20 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA6FsIVg025392 for ; Mon, 6 Nov 2006 07:54:19 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA6Fs3Pn011441; Mon, 6 Nov 2006 23:54:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J8B00D0VG6ET300@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Nov 2006 07:54:14 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J8B001N5G6DZOD0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Nov 2006 07:54:14 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id kA6FsDTi106295; Mon, 06 Nov 2006 10:54:13 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id kA6FsD3v106292; Mon, 06 Nov 2006 10:54:13 -0500 (EST) Date: Mon, 06 Nov 2006 10:54:13 -0500 From: Peter Memishian Subject: PSARC/2006/623 WiFi for GLDv3 Addendum #2 To: psarc-ext@sun.com Cc: wifi-dladm@sun.com Message-id: <17743.23205.621929.78745@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4420 I'm sponsoring this case for myself and the WiFi for GLDv3 team. Because the issues here are quite simple in nature, the timer is set for this Friday, November 10th. As before, all changes are to either unshipped or uncommitted interfaces. We again request Patch binding. ---8<--- Code review and further testing necessitated some additional minor changes to our original interfaces. The changes and their rationale are provided below. In order to provide broader context, we have also updated the WiFi architectural documents and manpages (in the `materials' directory). Thus, those documents provide the overall architecture resulting from PSARC/2006/406, PSARC/2006/517, and this case. Specific pointers to updated sections are provided below. Proposed changes: 1. `speed' property definition change [ dladm-wifi.pdf, section 3.11 ] The `speed' property now sets a single fixed speed for the WiFi link, rather than a set of permitted speeds. This change simplifies our implementation, since the BSD code on which our net80211 module is heavily based only supports setting a single fixed speed. 2. dladm `connect-wifi -T' changes [ dladm-wifi.pdf, section 3.2 ] The -T (timeout) option to connect-wifi no longer accepts "-1", since it was redundant with "forever" and caused getopt(3C) problems. In addition, the implication that "-T0" will work reliably has been removed, and a warning has been added regarding timeouts smaller than the default. 3. dladm WEP key format relaxation [ dladm-wifi.pdf, section 3.8 ] Hexadecimal WEP keys no longer require a leading "0x". This makes cut-and-paste simpler (e.g., from a browser window that has the key value). No ambiguity is introduced since ASCII and hexadecimal key lengths do not overlap. 4. dladm show-linkprop field errata [ dladm-wifi.pdf, section 3.5 ] PSARC/2006/517 changed "MODIFIABLE VALUES" to "POSSIBLE VALUES" but forgot to revise the documented meaning of the field for read-only properties. A syntax for expressing numeric ranges has also been added to "POSSIBLE VALUES", and the wording for the VALUE and DEFAULT fields has also been clarified. 5. single libdladm secobj API namespace [ libdladm.txt, section 2 ] The libdladm APIs previously assumed a per-class secobj namespace (that is, that you could have both WEP and WPA objects named "foo"). This is not yet allowed by dladm, and likely will never be allowed. As such, the libdladm secobj functions have been simplified to no longer require a `class' argument, except for dladm_get_secobj(), which now returns the class of the retrieved secobj. 6. libdladm/libwladm API constification [ libdladm.txt / libwladm.txt ] A number of `name' arguments (e.g, for the object name or property name) have been updated from `char *' to `const char *' to eliminate needless casting by API consumers. This is strictly an interface change; the implementation remains unchanged. 7. libdladm/libwladm error codes [ libdladm.txt / libwladm.txt ] A few new error codes have been added to the libwladm and libdladm APIs to improve error handling and diagnostics. 8. DLADM_OPT_PERSIST enhancement [ libdladm.txt, sections 1.1, 2.1, and 2.3 ] The dladm_set_prop(), dladm_set_secobj(), and dladm_unset_secobj() APIs now support a DLADM_OPT_PERSIST flag. This mirrors the existing DLADM_OPT_TEMP flag by enabling the caller to *only* modify to the persistent store. If DLADM_OPT_PERSIST|DLADM_OPT_TEMP is specified, then both are modified, but error conditions will be ambiguous. 9. libdladm/libwladm link reset API [ libdladm.txt, section 1.1, libwladm.txt, section 2.1 ] The dladm_set_prop() and wladm_set_prop() functions now reset all link properties if the `prop_name' argument is NULL. 10. wladm_wlan_attr_t channel field [ libwladm.txt, section 1.1 ] The wladm_wlan_attr_t structure now has a wa_channel field. This allows the channel to be returned from wladm_scan(), specified to wladm_connect(), and queried via wladm_get_link_attr(). -- meem From meem@triplex.East.Sun.COM Wed Nov 8 10:15:51 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA8IFoiJ010256 for ; Wed, 8 Nov 2006 10:15:50 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA8IFjtB005212; Wed, 8 Nov 2006 18:15:48 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J8F0090PC2BE700@brm-avmta-1.central.sun.com>; Wed, 08 Nov 2006 11:15:47 -0700 (MST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J8F007UYC2A3530@brm-avmta-1.central.sun.com>; Wed, 08 Nov 2006 11:15:47 -0700 (MST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id kA8IFk3Q103417; Wed, 08 Nov 2006 13:15:46 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id kA8IFkBI103414; Wed, 08 Nov 2006 13:15:46 -0500 (EST) Date: Wed, 08 Nov 2006 13:15:46 -0500 From: Peter Memishian Subject: re: PSARC/2006/623 WiFi for GLDv3 Addendum #2 In-reply-to: <17743.23205.621929.78745@triplex.East.Sun.COM> To: Peter Memishian Cc: psarc-ext@sun.com, wifi-dladm@sun.com Message-id: <17746.7890.596626.643117@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17743.23205.621929.78745@triplex.East.Sun.COM> Status: RO Content-Length: 69 This fast-track was approved during today's PSARC meeting. -- meem From meem@triplex.East.Sun.COM Tue Nov 14 19:00:54 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAF30qq6013952 for ; Tue, 14 Nov 2006 19:00:53 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kAF30iIR026230; Wed, 15 Nov 2006 11:00:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J8R00K0B4DFB600@brm-avmta-1.central.sun.com>; Tue, 14 Nov 2006 20:00:51 -0700 (MST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J8R00IN94DE7EC0@brm-avmta-1.central.sun.com>; Tue, 14 Nov 2006 20:00:50 -0700 (MST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id kAF30odQ125483; Tue, 14 Nov 2006 22:00:50 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id kAF30okS125480; Tue, 14 Nov 2006 22:00:50 -0500 (EST) Date: Tue, 14 Nov 2006 22:00:50 -0500 From: Peter Memishian Subject: re: PSARC/2006/623 WiFi for GLDv3 Addendum #2 To: psarc-ext@sun.com Cc: wifi-dladm@sun.com Message-id: <17754.33506.67915.371482@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1197 Folks, Subsequent testing and discussion has resulted in a few additional changes to our specs. Specifically: 1. Six more error codes have been added to libdladm and libwladm (combined) to improve diagnostics. 2. The semantics of unset persistent link property default values (whew! ;-) has been clarified. In short, if it's unset, the property ends up with the current system default at boot. 3. The "POSSIBLE VALUES" field of show-linkprop has been renamed to "POSSIBLE" since the space confounds the parseable output format. ("POSSIBLE" may seem strange, but it follows existing convention -- e.g. "DEFAULT" to mean "default values".) 4. The value "--" in show-linkprop output has been clarified to mean "unset". We discovered an accidental overload where it sometimes meant "unknown"; a new value "?" has been added to mean "unknown". Given that these changes are exceedingly minor and that this case is barely cold, I've updated the case materials with these changes (the original materials are now at "materials.orig"). If anyone finds this inappropriate, speak up and I'll run a new fasttrack to cover the above. Thanks! -- meem