Roaming with libertas and wpa_supplicant not working

Roaming with libertas and wpa_supplicant not working

[Troels Nilsson]

Hi,

We are having a problem with a custom device which uses the libertas wifi
driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
specifically, whenever wpa_supplicant attempts to roam to a different access
point it gets a EALREADY error.

I have tracked down the problem to this check in sme.c:

        if (wdev->sme_state != CFG80211_SME_IDLE)
                return -EALREADY;

When we get to this check the sme_state is CFG80211_SME_CONNECTED, so
nothing gets done. Changing this check to only fail if sme_state is
CFG80211_SME_CONNECTING fixes the issue, but I guess this check is there for
a reason?

In any case I don't know enough about the wireless system to say if this is
a problem in the libertas driver or cfg80211 or maybe the way wpa_supplicant
is using the API. Any comments/help would be greatly appreciated :)

Re: Roaming with libertas and wpa_supplicant not working

[Johannes Berg]

On Mon, 2013-11-18 at 13:50 +0000, Troels Nilsson wrote:
> Hi,
> 
> We are having a problem with a custom device which uses the libertas wifi
> driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
> specifically, whenever wpa_supplicant attempts to roam to a different access
> point it gets a EALREADY error.
> 
> I have tracked down the problem to this check in sme.c:
> 
>         if (wdev->sme_state != CFG80211_SME_IDLE)
>                 return -EALREADY;

This no longer exists - please try a newer kernel.

johannes

Re: Roaming with libertas and wpa_supplicant not working

[Dan Williams]

On Mon, 2013-11-25 at 17:16 +0100, Johannes Berg wrote:
> On Mon, 2013-11-18 at 13:50 +0000, Troels Nilsson wrote:
> > Hi,
> > 
> > We are having a problem with a custom device which uses the libertas wifi
> > driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
> > specifically, whenever wpa_supplicant attempts to roam to a different access
> > point it gets a EALREADY error.
> > 
> > I have tracked down the problem to this check in sme.c:
> > 
> >         if (wdev->sme_state != CFG80211_SME_IDLE)
> >                 return -EALREADY;
> 
> This no longer exists - please try a newer kernel.

Yeah, though the code there hasn't changed much in cfg80211 in the
"connect" case from what he's using.  It seems that
supplicant-controlled roaming simply won't work with "connect" devices
unless a disconnect is done first?  Libertas is kinda different here
since it does allow userspace roaming control.

Dan

Re: Roaming with libertas and wpa_supplicant not working

[Johannes Berg]

On Mon, 2013-11-25 at 11:16 -0600, Dan Williams wrote:
> On Mon, 2013-11-25 at 17:16 +0100, Johannes Berg wrote:
> > On Mon, 2013-11-18 at 13:50 +0000, Troels Nilsson wrote:
> > > Hi,
> > > 
> > > We are having a problem with a custom device which uses the libertas wifi
> > > driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
> > > specifically, whenever wpa_supplicant attempts to roam to a different access
> > > point it gets a EALREADY error.
> > > 
> > > I have tracked down the problem to this check in sme.c:
> > > 
> > >         if (wdev->sme_state != CFG80211_SME_IDLE)
> > >                 return -EALREADY;
> > 
> > This no longer exists - please try a newer kernel.
> 
> Yeah, though the code there hasn't changed much in cfg80211 in the
> "connect" case from what he's using.  It seems that
> supplicant-controlled roaming simply won't work with "connect" devices
> unless a disconnect is done first?  Libertas is kinda different here
> since it does allow userspace roaming control.

I believe the code *does* in fact allow connect() while connected right
now, though arguably that's a bug and shouldn't be done. It would make
some more sense to allow NL80211_CMD_ROAM to be used for something like
that, but ...

johannes

Re: Roaming with libertas and wpa_supplicant not working

[Dan Williams]

On Mon, 2013-11-25 at 19:36 +0100, Johannes Berg wrote:
> On Mon, 2013-11-25 at 11:16 -0600, Dan Williams wrote:
> > On Mon, 2013-11-25 at 17:16 +0100, Johannes Berg wrote:
> > > On Mon, 2013-11-18 at 13:50 +0000, Troels Nilsson wrote:
> > > > Hi,
> > > > 
> > > > We are having a problem with a custom device which uses the libertas wifi
> > > > driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
> > > > specifically, whenever wpa_supplicant attempts to roam to a different access
> > > > point it gets a EALREADY error.
> > > > 
> > > > I have tracked down the problem to this check in sme.c:
> > > > 
> > > >         if (wdev->sme_state != CFG80211_SME_IDLE)
> > > >                 return -EALREADY;
> > > 
> > > This no longer exists - please try a newer kernel.
> > 
> > Yeah, though the code there hasn't changed much in cfg80211 in the
> > "connect" case from what he's using.  It seems that
> > supplicant-controlled roaming simply won't work with "connect" devices
> > unless a disconnect is done first?  Libertas is kinda different here
> > since it does allow userspace roaming control.
> 
> I believe the code *does* in fact allow connect() while connected right
> now, though arguably that's a bug and shouldn't be done. It would make
> some more sense to allow NL80211_CMD_ROAM to be used for something like
> that, but ...

I think you're right in the libertas case; neither nl80211_connect() or
cfg80211_connect() care about whether the device is associated or not.
I was looking at cfg80211_sme_connect(), which gets run for drivers that
do not implement connect() themselves, and that function *doesn't*
appear to allow roaming.

So if the driver does implement connect() it can allow roaming from
connect() if it wants, but if the driver does not implement connect()
then the stack will not allow roaming from connect().  Seems a bit
inconsistent, so what's the best-practice for drivers here?  Disallow
roaming from connect() and  CMD_ROAM instead?

We'd have to actually implement CMD_ROAM then, I guess...

Dan

Re: Roaming with libertas and wpa_supplicant not working

[Troels Nilsson]

> > > > > Hi,
> > > > >
> > > > > We are having a problem with a custom device which uses the libertas wifi
> > > > > driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
> > > > > specifically, whenever wpa_supplicant attempts to roam to a different access
> > > > > point it gets a EALREADY error.
> > > > >
> > > > > I have tracked down the problem to this check in sme.c:
> > > > >
> > > > >         if (wdev->sme_state != CFG80211_SME_IDLE)
> > > > >                 return -EALREADY;
> > > >
> > > > This no longer exists - please try a newer kernel.
Yes, I saw that it was removed/rewritten in 3.11. However, that is
quite a jump in kernel versions for us at this point, so we will
probably prefer to patch the 3.4 series.

> > >
> > > Yeah, though the code there hasn't changed much in cfg80211 in the
> > > "connect" case from what he's using.  It seems that
> > > supplicant-controlled roaming simply won't work with "connect" devices
> > > unless a disconnect is done first?  Libertas is kinda different here
> > > since it does allow userspace roaming control.
> >
> > I believe the code *does* in fact allow connect() while connected right
> > now, though arguably that's a bug and shouldn't be done. It would make
> > some more sense to allow NL80211_CMD_ROAM to be used for something like
> > that, but ...
>
> I think you're right in the libertas case; neither nl80211_connect() or
> cfg80211_connect() care about whether the device is associated or not.
> I was looking at cfg80211_sme_connect(), which gets run for drivers that
> do not implement connect() themselves, and that function *doesn't*
> appear to allow roaming.
>
> So if the driver does implement connect() it can allow roaming from
> connect() if it wants, but if the driver does not implement connect()
> then the stack will not allow roaming from connect().  Seems a bit
> inconsistent, so what's the best-practice for drivers here?  Disallow
> roaming from connect() and  CMD_ROAM instead?
>
> We'd have to actually implement CMD_ROAM then, I guess...
So I guess the conclusion is that there isn't currently a "correct"
way to do roaming (until CMD_ROAM gets implemented)?

In that case we will go with patching the check to only fail with
-EALREADY in the case where sme_state is CFG80211_SME_CONNECTING,
since that means roaming works with libertas.

Re: Roaming with libertas and wpa_supplicant not working

[Troels Nilsson]

>> > > > > > Hi,
>> > > > > >
>> > > > > > We are having a problem with a custom device which uses the
>> > > > > > libertas wifi
>> > > > > > driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3).
>> > > > > > More
>> > > > > > specifically, whenever wpa_supplicant attempts to roam to a
>> > > > > > different access
>> > > > > > point it gets a EALREADY error.
>
> May I ask why you use *that* old wpa_supplicant?
>
Our user-space is Ubuntu 12.04 (plus some of our own bits), which uses
that version. Do you think this is fixed in a newer version of
wpa_supplicant?

>> > > > > >
>> > > > > > I have tracked down the problem to this check in sme.c:
>> > > > > >
>> > > > > >         if (wdev->sme_state != CFG80211_SME_IDLE)
>> > > > > >                 return -EALREADY;
>> > > > >
>> > > > > This no longer exists - please try a newer kernel.
>> Yes, I saw that it was removed/rewritten in 3.11. However, that is
>> quite a jump in kernel versions for us at this point, so we will
>> probably prefer to patch the 3.4 series.
>>
>
> I would suggest using backports (formerly known as compat-wireless) in that
> case.
That could be a solution as well, thanks for the suggestion.

Re: Roaming with libertas and wpa_supplicant not working

[Dan Williams]

On Tue, 2013-11-26 at 09:24 +0100, Troels Nilsson wrote:
> > > > > > Hi,
> > > > > >
> > > > > > We are having a problem with a custom device which uses the libertas wifi
> > > > > > driver (on kernel 3.4.24) together with wpa_supplicant (0.7.3). More
> > > > > > specifically, whenever wpa_supplicant attempts to roam to a different access
> > > > > > point it gets a EALREADY error.
> > > > > >
> > > > > > I have tracked down the problem to this check in sme.c:
> > > > > >
> > > > > >         if (wdev->sme_state != CFG80211_SME_IDLE)
> > > > > >                 return -EALREADY;
> > > > >
> > > > > This no longer exists - please try a newer kernel.
> Yes, I saw that it was removed/rewritten in 3.11. However, that is
> quite a jump in kernel versions for us at this point, so we will
> probably prefer to patch the 3.4 series.
> 
> > > >
> > > > Yeah, though the code there hasn't changed much in cfg80211 in the
> > > > "connect" case from what he's using.  It seems that
> > > > supplicant-controlled roaming simply won't work with "connect" devices
> > > > unless a disconnect is done first?  Libertas is kinda different here
> > > > since it does allow userspace roaming control.
> > >
> > > I believe the code *does* in fact allow connect() while connected right
> > > now, though arguably that's a bug and shouldn't be done. It would make
> > > some more sense to allow NL80211_CMD_ROAM to be used for something like
> > > that, but ...
> >
> > I think you're right in the libertas case; neither nl80211_connect() or
> > cfg80211_connect() care about whether the device is associated or not.
> > I was looking at cfg80211_sme_connect(), which gets run for drivers that
> > do not implement connect() themselves, and that function *doesn't*
> > appear to allow roaming.
> >
> > So if the driver does implement connect() it can allow roaming from
> > connect() if it wants, but if the driver does not implement connect()
> > then the stack will not allow roaming from connect().  Seems a bit
> > inconsistent, so what's the best-practice for drivers here?  Disallow
> > roaming from connect() and  CMD_ROAM instead?
> >
> > We'd have to actually implement CMD_ROAM then, I guess...
> So I guess the conclusion is that there isn't currently a "correct"
> way to do roaming (until CMD_ROAM gets implemented)?

Not quite; since libertas implements connect() itself, it would appear
(on the face of things) that supplicant-directed roaming should work if
you're using a recent kernel.  Next steps are to (1) use a recent kernel
version, and (2) do something like:

rmmod usb8xxx
rmmod libertas_sdio
rmmod libertas
modprobe libertas lbs_debug=0x20043a7
modprobe libertas_sdio
modprobe usb8xxx

and then let the supplicant try to roam again, and grab the 'dmesg'
output when things fail so we can see what's going on.

Dan