headers
Joerg Albert | 11 Oct 2004 03:44
Picon
Picon

Re: Scan fails to find wireless networks

Hi,

sorry for the late reply - I was off for a week.

On Fri, 1 Oct 2004, Mike Pinna wrote:

> I am having a bit of trouble getting my recent cvs version of the
> at76c503 driver working with my `AIN Communication AWU2000P WLAN USB
> Adapter' which I believe it should support.  The problem I am having is
> with scanning for wireless networks, which does not appear to work at
> all unless (rather stangely) I am already connected to an access point,
> in which case it does what I would expect.
>
> This occurs both with an x86 machine running linux 2.6.6 and
> cross-compiling to an ARM machine running a patched 2.4.26 .
>
> As a separate issue I am often experiencing complete lockups of my
> machines on unplugging the wireless adapter, but for the moment I'm not
> so concerned about that.
>
> Here is a transcript of my attempts to get things working on the x86
> box:

Loading the driver (e.g. triggered by plugging the device in or starting
the USB subsys) does only initialize it. It starts after the netdevice is
opened, e.g. by
	ifconfig wlan0 up
Guess that makes the difference in your case, I doubt that you need it to
be connected to an access point.
(Continue reading)

Permalink | Reply |
headers
Mike Pinna | 12 Oct 2004 11:31
Favicon

Re: Scan fails to find wireless networks

On Mon, Oct 11, 2004 at 03:44:12AM +0200, Joerg Albert wrote:
> On Fri, 1 Oct 2004, Mike Pinna wrote:
> Loading the driver (e.g. triggered by plugging the device in or starting
> the USB subsys) does only initialize it. It starts after the netdevice is
> opened, e.g. by
> 	ifconfig wlan0 up
> Guess that makes the difference in your case, I doubt that you need it to
> be connected to an access point.

You are quite right, thank you.  That aspect works fine now.

After I have brought up the interface would you expect it to work
immediately, or is it expected that for some time data sent on the
interface might be lost?  I'm consistently getting behaviour like the
following, with apparently complete packet loss for around six seconds
after the interface comes up:

# ifconfig wlan0 down; ifconfig wlan0 192.168.5.78; ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1): 56 data bytes
64 bytes from 192.168.5.1: icmp_seq=6 ttl=64 time=28.3 ms
64 bytes from 192.168.5.1: icmp_seq=7 ttl=64 time=13.8 ms
64 bytes from 192.168.5.1: icmp_seq=8 ttl=64 time=13.7 ms
64 bytes from 192.168.5.1: icmp_seq=9 ttl=64 time=13.5 ms
--- 192.168.5.1 ping statistics ---
10 packets transmitted, 4 packets received, 60% packet loss

This affects all data transfer consistently for that amount of time, not
just ping. 

[ assertion failures on arm ]
(Continue reading)

Permalink | Reply |
headers
Joerg Albert | 14 Oct 2004 05:32
Picon
Picon

Re: Scan fails to find wireless networks

Hi,

On Tue, 12 Oct 2004, Mike Pinna wrote:

> After I have brought up the interface would you expect it to work
> immediately, or is it expected that for some time data sent on the
> interface might be lost?  I'm consistently getting behaviour like the
> following, with apparently complete packet loss for around six seconds
> after the interface comes up:
>
> # ifconfig wlan0 down; ifconfig wlan0 192.168.5.78; ping 192.168.5.1
> PING 192.168.5.1 (192.168.5.1): 56 data bytes
> 64 bytes from 192.168.5.1: icmp_seq=6 ttl=64 time=28.3 ms
> 64 bytes from 192.168.5.1: icmp_seq=7 ttl=64 time=13.8 ms
> 64 bytes from 192.168.5.1: icmp_seq=8 ttl=64 time=13.7 ms
> 64 bytes from 192.168.5.1: icmp_seq=9 ttl=64 time=13.5 ms
> --- 192.168.5.1 ping statistics ---
> 10 packets transmitted, 4 packets received, 60% packet loss
>
> This affects all data transfer consistently for that amount of time, not
> just ping.

Yes, that's the same here:
---
roke:~# ifconfig wlan0 192.168.1.54; ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=9.5 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2.8 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=3.0 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=3.3 ms
(Continue reading)

Permalink | Reply |
headers
Mike Pinna | 14 Oct 2004 14:07
Favicon

Re: Scan fails to find wireless networks

On Thu, Oct 14, 2004 at 05:32:14AM +0200, Joerg Albert wrote:
> On Tue, 12 Oct 2004, Mike Pinna wrote:
> > [...] complete packet loss for around six seconds after the interface
> > comes up:
> Yes, that's the same here:
>
> [...]
> 
> Most of the time is spent waiting for the result of two scan runs (~ 2.5 s
> each) - you see it if you exec.
> 	iwpriv wlan0 set_debug 0x180003
> before the above line.

OK, well if that's unavoidable I guess it's not that big a deal.

> > at76c503.c: at76c503.c:2905 assertion dev->istate == INIT failed
> 
> I'll look into this during the weekend.

Thanks.

> There was a bug in the i/f to "iwlist wlanX scanning" (I guess you use
> this for scanning) which let it report only a random subset of the whole
> table. It's fixed in the cvs 0.12beta21.

Yes, that's how I do the scan.  I've tried updating to this version but
the behaviour doesn't seem to have improved at all.

> If you still miss some APs, increase the minimum channel time, i.e.
> the device scans on a channel, before it hops to the next one:
(Continue reading)

Permalink | Reply |
headers
Joerg Albert | 20 Oct 2004 02:28
Picon
Picon

Re: Scan fails to find wireless networks

Hi,

> > > at76c503.c: at76c503.c:2905 assertion dev->istate == INIT failed
> >
> > I'll look into this during the weekend.
>
> Thanks.

sorry, I'm still lacking time to spend on this issue.

> > There was a bug in the i/f to "iwlist wlanX scanning" (I guess you use
> > this for scanning) which let it report only a random subset of the whole
> > table. It's fixed in the cvs 0.12beta21.
>
> Yes, that's how I do the scan.  I've tried updating to this version but
> the behaviour doesn't seem to have improved at all.

Strange, it helped here with the same chipset/radio.

> > If you still miss some APs, increase the minimum channel time, i.e.
> > the device scans on a channel, before it hops to the next one:
> >
> > 	iwpriv wlan0 scan_times N 120
> >
> > with N = 30,40, ... (N=10 is the default). The 120 is the max. channel
> > time, increasing it let iwlist fail here.
>
> This also doesn't seem to make any difference, which is what initially
> led me to believe there might be a firmware issue.  Should I notice the
> scan taking any longer when I increase the minimum time?  What are the
(Continue reading)

Permalink | Reply |
headers
Mike Pinna | 21 Oct 2004 19:25
Favicon

Re: Scan fails to find wireless networks

On Wed, Oct 20, 2004 at 02:28:31AM +0200, Joerg Albert wrote:
> > > There was a bug in the i/f to "iwlist wlanX scanning" (I guess you use
> > > this for scanning) which let it report only a random subset of the whole
> > > table. It's fixed in the cvs 0.12beta21.
> > Yes, that's how I do the scan.  I've tried updating to this version but
> > the behaviour doesn't seem to have improved at all.
> Strange, it helped here with the same chipset/radio.

Ah, now I've updated to 0.12beta22 and the behaviour seems to have
improved - sort of.  I must have messed up the upgrade last time.

Now the scan works perfectly every time, but only if I have already
associated to an access point (I know I claimed this was the case last
time, and what I needed to do instead was merely bring the interface up
- I've remembered to do that this time round :) ).

For example:

(immediately after installing the driver modules)
# ifconfig wlan0 up
# time iwlist wlan0 scan
wlan0     Failed to read scan data : Resource temporarily unavailable

real    0m 5.00s
user    0m 0.00s
sys     0m 0.04s
# iwconfig wlan0 essid FD57
# iwlist wlan0 scan

[ all the APs ]
(Continue reading)

Permalink | Reply |

Gmane