> Updates to the wi driver have changed functionality in undocumented
> ways.  Namely:

Sorry for inconvenience.  Most of functional changes are not
intentional, and to be fixed, except for the emulation of all the
combination of wiconfig options.

> 1) It's been reported to me that Lucent cards used to work with only
>    one set to IBSS mode.  This is probably because the Lucent cards
>    use the same `port type' for both BSS and IBSS, and was probably a
>    fluke.  I'm not saying it *should* work, but behavioral changes
>    should be documented.

The only issue I know about IBSS mode for Lucent is that IBSS mode is
not working for the recent firmware (8.10.1), PR 18520.  I'm trying to
fix it and it just works on my environment.  I still need other input.
If other problem you have, please send-pr.

> 2) I have cards with Symbol firmware, previously configured to
>    `mediaopt adhoc' -- i.e. IBSS mode.  The driver used to do:
> 
>                 if (sc->sc_sta_firmware_ver >= 20000)
>                         sc->wi_flags |= WI_FLAGS_HAS_IBSS;
>                 if (sc->sc_sta_firmware_ver >= 25000)
>                         sc->wi_flags |= WI_FLAGS_HAS_CREATE_IBSS;
> 
>    but now does:
> 
>                 if (sc->sc_sta_firmware_ver >= 25000)
>                         ic->ic_flags |= IEEE80211_F_HASIBSS;
> 
>    hence, `mediaopt adhoc' is no longer listed with my firmware.

Perhaps it is just a mistake.  I forgot to confirm what happens for
older revision of Symbol firmware.

I test it but the result is bad.  Enabling IBSS mode for the revision
2.0.11 of the symbol firmware announces beacon or probe response
(not sure, should be confirmed with wireless sniffer later),
with illegal BSSID 0:0:0:0:0:0.  Other firmware such as Lucent with IBSS
enabled try to join the BSS but never succeed, perhaps because the value
of the BSSID.  Even worth, the lucent firmware doesn't create IBSS itself,
since the same SSID is already used by Symbol firmware.

So I would say enabling IBSS mode for Symbol firmware is problematic.
I'll confirm if the same problem exist for old wi.c driver.

>    Furthermore, the whole concept of `create IBSS' seems to be poorly
>    understood, documented and implemented.  There is no actual concept
>    of `creating' an IBSS; a host simply starts using it, and other
>    hosts see it in use.  There may be, with some versions of firmware,
>    an arbitrary distinction between using an IBSS that has been seen,
>    and using an IBSS that has not been seen; I suspect this is what
>    the Lucent firmware does.

Actually, IBSS is much complicated feature than Infrastructure.  It is
a real distributed system so that a node in IBSS should listen beacon
even if it creates own IBSS, if the SSID of the beacon matches, compare
the timer value within the beacon.  If the value is greater than its
own timer, it is required to drop the bss and join to the bss with the
greater value.  It is not documented in the standard 802.11 spec if the
IBSS should be join when its channel is different.

Wi-Fi just started IBSS interoperability test late last year or so.
So that all the firmware sold until then don't have large interoperability
test at all even Wi-Fi logo is tagged.

So, because of complexity of definition of IBSS in the spec, and lack of
the interoperability test for years, the IBSS mode for each firmware is
not well documented or not well supported.

The recent Windows driver is required to IBSS mode work, but it doesn't
help us because most (all?) of the driver has updated firmware inside,
and download it when starting.  The firmware in the flashrom in cards
remains old.

Perhaps the best we can would be document all the differences we know
between the revision of firmware into wi.4?

Atsushi Onoe