On 27-10-17 22:10, Johannes Berg wrote:
Hi,
IIUC, mwifiex hasn't told the firmware to do anything at this point --
the -EALREADY check is practically the first thing it does within
connect(). So it just quits the connect() request and tries to carry on
as usual. It will only do something differ
Hi,
> IIUC, mwifiex hasn't told the firmware to do anything at this point --
> the -EALREADY check is practically the first thing it does within
> connect(). So it just quits the connect() request and tries to carry on
> as usual. It will only do something different if the upper layers tell
> it t
Hi,
I'm not sure I've followed all the problems here, but I wanted to point
some things out:
On Tue, Oct 17, 2017 at 12:48:18PM +0200, Johannes Berg wrote:
> On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
>
> > > Does mwifiex treat this -EALREADY as *keeping* an old connection,
> > > or te
On Tue, Oct 17, 2017 at 11:10 PM, Johannes Berg
wrote:
> Hi,
>
>> > > https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
>> > >
>> > > Can you also give that a spin?
>
> Thanks for testing!
>
>> > Issued four reassociate, the network interface is still alive. Also
>> > with this patch it stays with B
Hi,
> > > https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
> > >
> > > Can you also give that a spin?
Thanks for testing!
> > Issued four reassociate, the network interface is still alive. Also
> > with this patch it stays with BSSID1 and I don't see any
> > "Association request to the driver fa
On Tue, Oct 17, 2017 at 10:08 PM, Jesse Sung wrote:
> On Tue, Oct 17, 2017 at 9:13 PM, Johannes Berg
> wrote:
>>
>> On Tue, 2017-10-17 at 21:07 +0800, Jesse Sung wrote:
>> >
>> > > Not really quite sure about it yet, but that should address the
>> > > issue?
>> >
>> > A very rough test by issuing
On Tue, Oct 17, 2017 at 9:13 PM, Johannes Berg
wrote:
>
> On Tue, 2017-10-17 at 21:07 +0800, Jesse Sung wrote:
> >
> > > Not really quite sure about it yet, but that should address the
> > > issue?
> >
> > A very rough test by issuing reassociate in wpa_cli:
> > mwifiex works after reassociate - l
On Tue, 2017-10-17 at 21:07 +0800, Jesse Sung wrote:
>
> > Not really quite sure about it yet, but that should address the
> > issue?
>
> A very rough test by issuing reassociate in wpa_cli:
> mwifiex works after reassociate - looks good
Ok. Discussing this with Ilan, we realized that this was b
On Tue, Oct 17, 2017 at 6:48 PM, Johannes Berg
wrote:
> On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
>
>> > Does mwifiex treat this -EALREADY as *keeping* an old connection,
>> > or tearing it down entirely?
>>
>> From the call trace:
>
> Well, the call trace can't really answer that :-)
>
On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
> > Does mwifiex treat this -EALREADY as *keeping* an old connection,
> > or tearing it down entirely?
>
> From the call trace:
Well, the call trace can't really answer that :-)
Does mwifiex firmware stay connected?
> 139.451318: nl80211_get
Hi Johannes,
On Tue, Oct 17, 2017 at 5:51 PM, Johannes Berg
wrote:
> Hi,
>
>> While working on an issue that marvell module stops connecting to AP,
>> bisect reveals that the issue starts to happen from commit 0711d638,
>> which uses wdev->ssid_len instead of wdev->current_bss to determine
>> if
Hi,
> While working on an issue that marvell module stops connecting to AP,
> bisect reveals that the issue starts to happen from commit 0711d638,
> which uses wdev->ssid_len instead of wdev->current_bss to determine
> if driver's .disconnect() should be called.
>
> It happens because mwifiex_cfg
Hi,
While working on an issue that marvell module stops connecting to AP,
bisect reveals that the issue starts to happen from commit 0711d638,
which uses wdev->ssid_len instead of wdev->current_bss to determine
if driver's .disconnect() should be called.
It happens because mwifiex_cfg80211_connec
13 matches
Mail list logo