Juuso,
> Sent: Wednesday, October 06, 2010 12:27 AM
>
> On Wed, 2010-10-06 at 07:21 +0200, ext Gabay, Benzy wrote:
> > Juuso,
> >
> >
> > > Sent: Tuesday, October 05, 2010 11:59 PM
> > >
> > > Hi,
> > >
> > > On Tue, 2010-10-05 at 17:42 +0200, ext Gabay, Benzy wrote:
> > > > Juuso,
> > >
> > > > > > >
> > > > > > > From: Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx>
> > > > > > >
> > > > > > > Currently then dwell times for each channel in scans is set
> to
> > > an
> > > > > > > overly
> > > > > > > long value, and excessive number of probe-requests are
> > > transmitted
> > > > > on
> > > > > > > each
> > > > > > > channel (for active scans.)
> > > > > > >
> > > > > > > Based on testing, comparable results can be received with
> > > smaller
> > > > > > > dwell-time,
> > > > > > > and, with fever probe-requests - in fact, reducing the
> number
> > > of
> > > > > probe-
> > > > > > > requests
> > > > > > > to 2 seems to increase the number of found results.
> > > > > >
> > > > > > I think that this does not making any sense. Less prob
> requests
> > > > > should give you back less results. As less beacons/prob
> responses
> > > are
> > > > > getting back to the station.
> > > > > > I think also that office with 70 AP is not a normal
> environment
> > > to
> > > > > test and optimize numbers.
> > > > > > I would suggest to re-test in a 1-6 AP environment which is
> > > making
> > > > > more sense for both home and enterprise environment.
> > > > >
> > > > > We have actually performed more testing than just mentioned
> here,
> > > in
> > > > > varied environments, and all of the testing seems to indicate
> that
> > > > > reducing the number of probe-reqs per channel is not reducing
> the
> > > > > number
> > > > > of acquired results. Instead, in some scenarios, it is
> increasing
> > > the
> > > > > number of acquired results.
> > > > >
> > > >
> > > > >> I donât know if that is conventional request: can you share
> the
> > > full results and setup details?
> > >
> > > No, I don't have any formal documentation to share.
> > >
> > > The setup details are simple enough though. The tested this on
> command
> > > line using a simple script that flushes existing scan results, then
> > > performs two or three scans counting the number of scan results on
> the
> > > last round using grep and wc.
> > >
> > > We performed the testing in office environment and a shielded
> chamber,
> > > which only has selected AP's within it.
> > >
> > > Between test rounds we modified the driver parameters related to
> > > scanning, i.e. we modified the number of probe-reqs and the dwell
> time
> > > on each channel.
> > >
> > > -Juuso
> >
> >
> > Sounds great. Just one more: which AP brands (excluding Cisco) ?
>
> In the office environment we have a variety of brands, including D-
> link,
> Buffalo, Telewell, TP-link and linksys, cisco etc.
>
> In the shielded chamber we are using linksys wrt610n AP's.
>
> -Juuso
>
Perfect.
If still needed, I ACK this change.
Benzy Gabay
> >
> >
> > >
> > > > > We did not see reduction in the probability of finding a
> specific
> > > AP in
> > > > > a few (one or two) AP environment either.
> > > > >
> > > > > The effect seems to be this way because reducing the number of
> > > > > probe-req's dramatically reduces the noise generated by probe-
> > > responses
> > > > > from AP's on neighbouring channels.
> > > > >
> > > > > -Juuso
> > > > >
> > >
> >
> >
> ï{.nï+ïïïïïïï+%ïïlzwmïïbïëïïrïïzXïï "ïï^ïÈïïïÜ}ïïïÆzï&j:+vïïï
ïïïïzZ
> +ïï+zfïïïhïïï~ïïïïiïïïzï ïwïïï?ïïïï&ï)ßf
>
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ÿ«zW¬³ø¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
