Problems connecting to Meru VCell / Per Station BSSID + WPA-PSK

Bug #360692 reported by Tony Espy
6
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: network-manager

Wi-Fi association fails to connect to a Meru Virtual Access point configured for per-station BSSID and WPA-PSK.

Association works fine if the AP cell is configured with no Security, or WEP, however it always fails when configured for WPA-PSK.

Note, the version of NM used was the Intrepid version backported to Hardy:

0.7~~svn20081018t105859+mbm.f2-0ubuntu1~hardy5

The same problem is also seen with NM 0.6.6 in 8.04.

The problem occurs with multiple drivers ( Broadcom 'wl', RaLink Rt2x00, rt73usb ).

Occasionally association succeeds, but the connection continually disconnects and is un-usable.

Revision history for this message
Tony Espy (awe) wrote :
Download full text (7.2 KiB)

Here's a description of Meru's Virtual Cell technology:

What is Virtual Cell?
By default, access points on the same channel share a BSSID when you create an
ESSID. This allows the formation of a Virtual Cell, which is a group
of access points
on the same channel sharing the same BSSID. You can disable access points on the
same channel from sharing the same BSSID, which prevents the formation
of a Virtual
Cell. If you prevent access points on the same channel from sharing
the same BSSID,
each access point has its own unique BSSID.

The per-station-bssid feature assigns each station its own unique, link-local
BSSID, called a Meru SSID of MSSID, which a station keeps throughout the Virtual
Cell. It is permissible to have a mix of ESS profiles that use both shared and
per-station BSSID implementations of Virtual Cell.
Types of Virtual Cell
                             Shared BSSID Vcell
                             Per-station BSSID Vcell

Per-station BSSID Vcell OVERVIEW for AP200:

Starting in release 3.4, there is a new method to support the Meru
Virtual Cell (VC) functionality called "per-station-bssid". The
primary difference between "per-station-bssid" and the traditional VC
method (called "shared-bssid" in the web interface and ioscli) is that
"per-station-bssid" modifies the beacon behavior so that only one AP
will send beacons for a given BSSID - i.e. rather than all APs
supporting the same essid/channel pair beaconing for that BSSID . The
original method of VC will continue to be supported and a single
controller will be able to simultaneously support essids configured to
use the new "per-station-bssid" along with essids configured to use
the original VC method.

The "per-station-bssid" is supported in the AP 201 and 208 in 3.4. A
future release will support the AP 300 series. There is no planned
per-station BSSID support for the AP 150.

SUITABLE DEPLOYMENTS

"Per-station-bssid" is well-suited for any deployments that make heavy
use of wireless stations with the Intel 3945 chipset. The
interoperability issues between the Intel 3945 chipset and the
original implementation of Meru's Virtual Cell functionality was one
of the primary reasons for the new virtual cell implementation.

Along with the specific Intel 3945 issue, there have been a handful of
other, more minor, interoperability issues with other
chipsets/supplicants because of how the original VC method was
implemented.

SOME NUTS AND BOLTS

                                  "per-station-bssid" works by
generating a unique BSSID for each station that comes onto the
network.
                                  Beacons are sent from that generated
BSSID at the configured beacon interval of the associated ESSID
profile. So, in contrast to the original VC method, where an air
capture would show n beacons per beacon interval from a given BSSID, n
equal to the number of APs supporting that BSSID, a per-station BSSID
air capture will show 1 beacon per beacon interval from an individual
station's BSSID.
                                  Beacons will be generally
transmitted at the individual station's unicast transmission rate (but
no higher than 24M by default), which will almost always ...

Read more...

Revision history for this message
Alexander Sack (asac) wrote :

have you checked if this scenario works better using the complete jaunty stack? or is that issue still there?

What do you see in syslog when doing this? Is there a driver for which it works? or is it broken everywhere? Does using wpasupplicant manually work properly?

Changed in network-manager (Ubuntu):
status: New → Incomplete
Revision history for this message
Alexandre_L (alacroix-connectdata) wrote :

Hi everybody,
I'am experiencing a similar problem since i've upgrade from Ubuntu 8.10 to Ubuntu 9.04.
Since this upgrade I'am not able to see Meru ESSID from Network manager or from Wicd.
I ve a intel 3945 chipset too, and my Meru controler is in version 3.6.x

When I was using Ubuntu 8.10 I ve no probleme to see and to connect to my MERU networks.

I'am using virtual cell too with AP208.

If someone as an idee how to make this works it will be great.

Revision history for this message
Victor Vargas (kamus) wrote :

Since this report have a long time without activity, please could you check (if is possible) in latest version included in Karmic if this issue is still happening? Thanks in advance.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]

Changed in network-manager (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.