> > 2) I have cards with Symbol firmware, previously configured to
> >    `mediaopt adhoc' -- i.e. IBSS mode.  The driver used to do:

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

The symbol firmware with the revision less than 2.50 is too bad to operate
IBSS mode, even for previous revision of wi driver before my changes.

It continues to transmit probe-request across all available channel as
fast it can, without any pause.  As a result, it IBSS is not already
created and can be reached, the card tries to occupy all of the 802.11
channel by its probe-request.

And it is worse that the card respond probe-response with IBSS zero,
regardless the value of IBSS creation.  It is apparently prevent other
lucent card with IBSS creation enabled from creating new IBSS.
So if the IBSS is enabled for old symbol firmware when there are no
IBSS operating for the SSID, it is very likely the IBSS remains
non-operational until the symbol card turned off.

So I won't change the current behavior which disables IBSS mode for
old revision (less than 2.5) of the symbol firmware.  The best we can
would be document it to online manual as well as source.

Regards,

Atsushi Onoe