<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body 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">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">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 class="moz-cite-prefix">El 10/10/2014 10:55, Avinash Patil
      escribió:<br>
    </div>
    <blockquote
cite="mid:CAJwzM1kxTZg_HMz7PJKOwjP+NYFgHxb2WzxkbuBOixruAD_YUQ@mail.gmail.com"
      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">&lt;<a moz-do-not-send="true"
              href="mailto:victor@cymonline.com" target="_blank">victor@cymonline.com</a>&gt;</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
                class="">
                On Wed, 2014-10-08 at 12:35 +0200, Víctor Andrés Andrés
                wrote:<br>
                <br>
              </span><span class="">
                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 class="HOEnZb">
              <div class="h5">
                <br>
                _______________________________________________<br>
                HostAP mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:HostAP@lists.shmoo.com" target="_blank">HostAP@lists.shmoo.com</a><br>
                <a moz-do-not-send="true"
                  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>
  </body>
</html>