<div dir="ltr"><div><div><div><div>Hi Victor,<br><br></div>SD8787 14.66.35.p52 is latest FW revision- 35x is branch from where FW is created. <br>For other FW revision 14.66.9.p192 , this is from 9x branch. They cannot be compared.<br><br></div>For your second query, yes while command is in process, data path is blocked and so data cannot be transmitted.<br></div>I would suggest you running single channel scan so as to have minimum disruption.<br><br></div>Thanks,<br>Avinash.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 3:26 PM, Víctor Andrés <span dir="ltr"><<a href="mailto:victor@cymonline.com" target="_blank">victor@cymonline.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi Avinash,<br>
<br>
I'm using the firmware version 14.66.9.p192 (<a href="http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=633d06edab7a2b82efaa134ec5591cd20f9ac0a3" target="_blank">http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=633d06edab7a2b82efaa134ec5591cd20f9ac0a3</a>)
and testing the recent commit p52 version (<a href="http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=3f45b8c4cc1eb1d102bc3486b19677332dd215ab" target="_blank">http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=3f45b8c4cc1eb1d102bc3486b19677332dd215ab</a>),
but
I'm not sure of this last commit, because<span style="color:windowtext">
even if it was posted more recent,</span> it's a previo<span style="color:windowtext">u</span>s
versi<span style="color:windowtext">o</span>n<span style="color:windowtext"> of
the FW</span>.<br>
<br>
Yes, the roaming is working now. I'm trying to reduce the scanning
time<span style="color:windowtext"> in order</span> to<span style="color:windowtext">
scan</span> only <span style="color:windowtext">the channel in
use or only for the known
</span>bssid<span style="color:windowtext">.</span> When the
interface is scanning it isn't
transmitting data<span style="color:windowtext">, and what I need is
a </span>continuous
flow of data.<br>
<br>
Víctor<br>
<br>
<div>El 10/10/2014 10:55, Avinash Patil
escribió:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>Hi Victor,<br>
<br>
</div>
What is SD8787 FW version you are using? As I understand from
your last email, roaming is now working fine, right?<br>
<br>
Thanks,<br>
Avinash<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 10, 2014 at 12:38 PM,
Víctor Andrés <span dir="ltr"><<a href="mailto:victor@cymonline.com" target="_blank">victor@cymonline.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dan.<br>
Thanks by your help.<br>
<br>
I tested it in a different board and the signal level of the
APs were correct. At least, not all the same and with a
value of -101. May be a problem of the chip wifi of that
board, I don't know. I use the same antenna for the 2 tests,
and the boards were in the same position (more or less) for
the 2 tests (with the same AP locations). I'll continue with
the tests. I don't understand how can I connect with these
APs that the wifi have detected with that poor signal.<br>
<br>
I've compiled Wpa-supplicant with bgscan option enabled and
tested in a different board, and now I have roaming between
that 2 APs (with bgscan:learn). Now I'm trying to reduce the
searching time, because when the wireless is searching
network it can't transmit data, isn't it?<br>
<br>
Víctor<br>
<br>
<br>
El 08/10/2014 19:33, Dan Williams escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On Wed, 2014-10-08 at 12:35 +0200, Víctor Andrés Andrés
wrote:<br>
<br>
</span><span>
First, roaming works better with "bgscan" options
enabled. This option<br>
tells the supplicant to periodically scan looking for a
better AP. If<br>
scans don't happen (either through "bgscan" or manually
via the control<br>
interface) the supplicant will stick with the current AP
until the<br>
connection is broken. The only way the supplicant knows
which AP is<br>
better is if a scan has taken place and it knows the
RSSI of each AP.<br>
<br>
Second, it looks like the driver is broken for signal
strength<br>
reporting. -100dBm signal level is quite awful, and the
fact that it<br>
shows *all* APs at that level is pretty much a smoking
gun. This is the<br>
reason the supplicant won't switch APs even if you do
trigger a manual<br>
scan, because no AP really has a better signal level
than the current<br>
one.<br>
<br>
(one other slight possibility: your antenna isn't
connected very well,<br>
or isn't connected at all, and you're close to the
APs...)<br>
<br>
Dan<br>
<br>
</span></blockquote>
<div>
<div>
<br>
_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP@lists.shmoo.com" target="_blank">HostAP@lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>