Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #433 (new defect)

Opened 16 years ago

Last modified 14 years ago

freq and channel settings don't "stick"

Reported by: anonymous Assigned to:
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: other Version: trunk
Keywords: channel skipping frequency Cc:
Patch is attached: 0 Pending:

Description

Using a Netgear WG511T (5212 chipset) in a Dell Inspiron 7500 I can't set a channel/frequency with iwconfig. If the adapter is down (ifconfig ath0 down, ifconfig wifi0 down) I can set the value and subsequent iwconfig commands will show the frequency that I set. On bringing up the adapter, though (ifconfig ath0 up), it begins scanning through all channels and cannot/will not connect to my AP, which is broadcasting on a fixed channel. Issuing the iwconfig commands multiple times yields a different freq setting each time. The iwconfig ath0 freq 2.437G and channel 6 command have no noticeable effect when the card is up; the channels just keep scanning. I can connect on _rare_ occasions - I believe it's just luck of the draw with the card hitting the right channel at the exact instant the AP is broadcasting.

Info: Fedora Core 3; kernel 2.6.12-1.1381_FC3; madwifi-ng rev 1454(? svn'ed from trunk 2/22/06)

Change History

03/01/06 22:40:21 changed by auriga@o2.pl

  • keywords set to channel skipping frequency.
  • milestone set to version 0.9.0 - move to new codebase.

I have the exact problem with the version of madwifi-ng (r1408) supplied with Voyage linux v. 0.2pre3 on a 5212 chip and WRAP board, AP client, 802.11a, attempting channel 60, distance 345m. Tentatively reverting to madwifi-old -- might this be a good idea?

arthur

03/10/06 18:45:58 changed by dyqith@gmail.com

maybe related to http://madwifi.org/ticket/122

Bgscan may be scanning over and over.

using iwpriv ath0 bgscan 0 will stop the scan (but doesn't disable it, i may patch it so it disables bgscan and not just stop it)

In the mean time, maybe changing the bgscanidle and bgscanintvl in iwpriv can help ? bgscanintvl are suppose to be in seconds and bgscanidle are in msecs

04/21/06 07:03:53 changed by dyqith

Any updates with this ticket ?

04/23/06 01:22:27 changed by kelmo

  • milestone changed from version 0.9.0 - move to new codebase to version 0.9.x - progressive release candidate phase.

04/28/06 05:39:07 changed by dyqith

  • status changed from new to assigned.
  • owner set to dyqith.

01/26/07 16:36:09 changed by anonymous

Is someone still working on this? I can confirm the problem on a current debian unstable and madwifi 0.9.3 "iwpriv ath0 bgscan 0" does not help

01/26/07 20:49:54 changed by dyqith

Sorry, I've been busy with other projects.

But the gist of the problem is this: In client/managed mode, the driver will keep scanning the channels until it finds a suitable AP to connect to. The problem with this is, the scanning on the channels may be jumping too fast and missing out on the beacons from the AP you want.

The question is, is this what we want or do we want the user to be able to select a channel for the client to stick on?

I haven't looked at the adhoc mode side, so can't tell you what it is.

As for the AP, it should stick to the channel you assigned it.

01/27/07 12:19:36 changed by anonymous

Ok, what I do is, for a known environment like at home: I load the drivers (modprobe), I do a "ifconfig ath0 up". Then I set the channel "iwconfig ath0 channel X" and then I set the ap "iwconfig ath0 ap Y". This ensures that, as long as no one tampers purposly, I connect to the right ap.

It really should stick to the channel that it is assigned. Thanks for your help :-)

05/05/07 00:42:02 changed by anonymous

Seems to be related to #980. Really annoying bug, renders STA+AP/MONITOR combinations almost unusable. Is there an easy fix to prevent scanning completely?

07/24/07 20:56:15 changed by dyqith

  • status changed from assigned to new.
  • owner deleted.