Add device ID for cheapo BlueNext rt2571-based stick BN-WD54G
Signed-off-by: Andy Green <[email protected]>
---
drivers/net/wireless/rt73usb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt73usb.c b/drivers/net/wireless/rt73usb.c
index 3d838d1..82bb23c 100644
--- a/drivers/net/wireless/rt73usb.c
+++ b/drivers/net/wireless/rt73usb.c
@@ -1814,6 +1814,8 @@ static struct usb_device_id rt73usb_device_table[] = {
{ USB_DEVICE(0x050d, 0x905b), USB_DEVICE_DATA(&rt73usb_ops) },
/* Billionton */
{ USB_DEVICE(0x1631, 0xc019), USB_DEVICE_DATA(&rt73usb_ops) },
+ /* BlueNEXT */
+ { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
/* CNet */
{ USB_DEVICE(0x1371, 0x9022), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x1371, 0x9032), USB_DEVICE_DATA(&rt73usb_ops) },
Somebody in the thread at some point said:
>> Are there known problems with the monitor mode? It seems incomplete
>> even with one virtual interface, eg
>
> Sounds awfully familiar. :(
Don't feel bad, monitor mode is not in a coherent state all over the
drivers at the moment. I would really like to see it become trustable
in all cases.
> At which rate should the other box be sending the frames?
54Mbps, I am a couple of metres from the AP.
>> # while [ 1 ] ; do ls -l / ; done
>>
>> over an ssh link which is being carried on another wireless device on
>> the same box associated on to channel 6...
>
> Could you enable debugfs and do inside the "rt73usb" folder within the
> mac80211 debugfs entry do:
>
> echo 16 > csr_offset
> cat csr_value
>
> This will read the TXRX_CSR0 register of rt73usb which controls the filtering
> of the frames. That will help determining if the missing frames have been
> droppen in the hardware or not.
I have to add debugfs in my .config for that, it is rebuilding.
However, I added the following debug line inside the loop at
rt2x00_dev.c function
void rt2x00lib_rxdone(struct data_entry *entry, char *data,
const int size, const int signal, const int rssi, const int ofdm)
printk("signal=%d, ofdm=%d, rate->val=%d, val=%d\n", signal, ofdm,
rate->val, val);
and ran tcpdump at the same time. What I see is that even though
tcpdump on ch 6 is only willing to show 1Mbps packets, packets with
other rates passed through here, eg,
signal=20, ofdm=0, rate->val=4106, val=10
signal=20, ofdm=0, rate->val=16789524, val=20
signal=110, ofdm=0, rate->val=4106, val=10
signal=110, ofdm=0, rate->val=16789524, val=20
signal=110, ofdm=0, rate->val=33583159, val=55
signal=110, ofdm=0, rate->val=50393198, val=110
but ALWAYS ofdm is 0, ie, it only sees CCK packets.
If I look over on channel 11, my neighbour has an 80211b device
apparently, I see data packets at 11Mbps, again CCK.
-Andy
> Are there known problems with the monitor mode? It seems incomplete
> even with one virtual interface, eg
Sounds awfully familiar. :(
> 13:37:00.549494 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request ()
> [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
> 13:37:00.550243 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request ()
> [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
> 13:37:00.590127 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
> [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
> 13:37:00.692568 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
> [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
> 13:37:00.897401 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
> [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
> 13:37:00.999773 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
> [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
>
> and reports the rate as 1Mbps in all cases. During this capture I have
> another box doing
At which rate should the other box be sending the frames?
> # while [ 1 ] ; do ls -l / ; done
>
> over an ssh link which is being carried on another wireless device on
> the same box associated on to channel 6...
Could you enable debugfs and do inside the "rt73usb" folder within the
mac80211 debugfs entry do:
echo 16 > csr_offset
cat csr_value
This will read the TXRX_CSR0 register of rt73usb which controls the filtering
of the frames. That will help determining if the missing frames have been
droppen in the hardware or not.
Ivo
Somebody in the thread at some point said:
>> Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this.
>> I just noticed that when the first and only interface is a monitor interface
>> the device was not being configured at all. This has now been fixed in rt2x00.git,
>> so it will be part of the 2.0.5 release later today. :)
>
> Great, I will check for it on the serialmonkey site later and give it a go.
Ah I saw it went to git.kernel.org
Yes current rt2x00 git in there works fine for simple monitor mode
now... thanks a lot for your hard work!
-Andy
Somebody in the thread at some point said:
> echo 16 > csr_offset
> cat csr_value
>
> This will read the TXRX_CSR0 register of rt73usb which controls the filtering
> of the frames. That will help determining if the missing frames have been
> droppen in the hardware or not.
after the echo, catting that spews
0x007eb162
repeatedly to the console.
-Andy
Hi,
> > > Which version are you using?
> > > wireless-dev <---
> > > rt2x00.git
> > > rt2x00 cvs
>
> Ok, rt2x00.git contains many changes to the initialization of the device,
> so it is a bit hard to compare at the moment. At least it is confirmed that rt2x00 can
> receive all frames in monitor mode and the problem area is the DROP filter.
>
> I'll release rt2x00 2.0.5 later today with all those changes, including the rxdone rate
> selection fix. So if you could retest later to see if the problem disappeared in 2.0.5 it
> would be great. :)
Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this.
I just noticed that when the first and only interface is a monitor interface
the device was not being configured at all. This has now been fixed in rt2x00.git,
so it will be part of the 2.0.5 release later today. :)
Ivo
On Tuesday 31 July 2007, Andy Green wrote:
> Somebody in the thread at some point said:
>
> > I think I have an idea why mac80211 always reports 1 MBs,
> > rt2x00 checks if PREAMBLE was enabled or not. If that is the case it sets
> > the rate value to rate->val2
> > Mac80211 in turn only compares the value against rate->val which
> > means that it won't find the rate and assume the lowest possible rate.
> > I'll fix this by always setting the rate->val value instead (It isn't
> really
> > important for mac80211 to know if the preamble bit was set anyway).
>
> Somehow the rates seem to be correct now after your change to the DROP
> bits...
Excellent! :)
> > #define TXRX_CSR0_DROP_CRC FIELD32(0x00020000)
> > #define TXRX_CSR0_DROP_PHYSICAL FIELD32(0x00040000)
> > #define TXRX_CSR0_DROP_CONTROL FIELD32(0x00080000)
> > #define TXRX_CSR0_DROP_NOT_TO_ME FIELD32(0x00100000)
> > #define TXRX_CSR0_DROP_TO_DS FIELD32(0x00200000)
> > #define TXRX_CSR0_DROP_VERSION_ERROR FIELD32(0x00400000)
> > #define TXRX_CSR0_DROP_MULTICAST FIELD32(0x00800000)
> > #define TXRX_CSR0_DROP_BORADCAST FIELD32(0x01000000)
> > #define TXRX_CSR0_DROP_ACK_CTS FIELD32(0x02000000)
> >
> > Which means it will only pass multicast, broadcast and ACK_CTS frames. :S
> > Always dropping CRC errors is correct, since enabling that will
> greatly upset
> > any monitoring tool listening to the interface.
>
> Well one day it will be nice if there is a stack-level way to turn it on
> and off. We can also pass in the radiotap part a flag to show if the
> packet's CRC was valid or not. The tools can then either turn on the
> filtering before the packets come or filter on good packets only.
Well the problem with the CRC errors is that, when enabled, mac80211
will be flooded with frames. Regular frames which are usually the interesting
ones could get lost in there.
But you are right, having the stack to control the DROP filter would be a very
nice feature. :)
> > To see if it helps try:
> >
> > echo 16 > csr_offset
> > echo 0x0002b162 > csr_value
> >
> > This will disable all DROP bits (except for the CRC error) and thus should
> > trigger more frames to be received by your interface. In the mean time
> I'll search
> > why those bits weren't cleared when enabling the interface in monitor
> mode.
>
> Yes, that seems to have done it, thanks
Excellent :)
> > Which version are you using?
> > wireless-dev <---
> > rt2x00.git
> > rt2x00 cvs
Ok, rt2x00.git contains many changes to the initialization of the device,
so it is a bit hard to compare at the moment. At least it is confirmed that rt2x00 can
receive all frames in monitor mode and the problem area is the DROP filter.
I'll release rt2x00 2.0.5 later today with all those changes, including the rxdone rate
selection fix. So if you could retest later to see if the problem disappeared in 2.0.5 it
would be great. :)
Ivo
> > At which rate should the other box be sending the frames?
>
> 54Mbps, I am a couple of metres from the AP.
Ok. That means we can at least assume several frames should
be send with higher rates then 1 Mbs. ;)
> >> # while [ 1 ] ; do ls -l / ; done
> >>
> >> over an ssh link which is being carried on another wireless device on
> >> the same box associated on to channel 6...
> >
> > Could you enable debugfs and do inside the "rt73usb" folder within the
> > mac80211 debugfs entry do:
> >
> > echo 16 > csr_offset
> > cat csr_value
> >
> > This will read the TXRX_CSR0 register of rt73usb which controls the filtering
> > of the frames. That will help determining if the missing frames have been
> > droppen in the hardware or not.
>
> I have to add debugfs in my .config for that, it is rebuilding.
Thanks.
> However, I added the following debug line inside the loop at
> rt2x00_dev.c function
> void rt2x00lib_rxdone(struct data_entry *entry, char *data,
> const int size, const int signal, const int rssi, const int ofdm)
>
> printk("signal=%d, ofdm=%d, rate->val=%d, val=%d\n", signal, ofdm,
> rate->val, val);
>
> and ran tcpdump at the same time. What I see is that even though
> tcpdump on ch 6 is only willing to show 1Mbps packets, packets with
> other rates passed through here, eg,
>
> signal=20, ofdm=0, rate->val=4106, val=10
> signal=20, ofdm=0, rate->val=16789524, val=20
> signal=110, ofdm=0, rate->val=4106, val=10
> signal=110, ofdm=0, rate->val=16789524, val=20
> signal=110, ofdm=0, rate->val=33583159, val=55
> signal=110, ofdm=0, rate->val=50393198, val=110
>
> but ALWAYS ofdm is 0, ie, it only sees CCK packets.
>
> If I look over on channel 11, my neighbour has an 80211b device
> apparently, I see data packets at 11Mbps, again CCK.
I think I have an idea why mac80211 always reports 1 MBs,
rt2x00 checks if PREAMBLE was enabled or not. If that is the case it sets
the rate value to rate->val2
Mac80211 in turn only compares the value against rate->val which
means that it won't find the rate and assume the lowest possible rate.
I'll fix this by always setting the rate->val value instead (It isn't really
important for mac80211 to know if the preamble bit was set anyway).
> after the echo, catting that spews
>
> 0x007eb162
>
> repeatedly to the console.
And here is a big problem..
This register is defined as:
#define TXRX_CSR0_DROP_CRC FIELD32(0x00020000)
#define TXRX_CSR0_DROP_PHYSICAL FIELD32(0x00040000)
#define TXRX_CSR0_DROP_CONTROL FIELD32(0x00080000)
#define TXRX_CSR0_DROP_NOT_TO_ME FIELD32(0x00100000)
#define TXRX_CSR0_DROP_TO_DS FIELD32(0x00200000)
#define TXRX_CSR0_DROP_VERSION_ERROR FIELD32(0x00400000)
#define TXRX_CSR0_DROP_MULTICAST FIELD32(0x00800000)
#define TXRX_CSR0_DROP_BORADCAST FIELD32(0x01000000)
#define TXRX_CSR0_DROP_ACK_CTS FIELD32(0x02000000)
Which means it will only pass multicast, broadcast and ACK_CTS frames. :S
Always dropping CRC errors is correct, since enabling that will greatly upset
any monitoring tool listening to the interface.
To see if it helps try:
echo 16 > csr_offset
echo 0x0002b162 > csr_value
This will disable all DROP bits (except for the CRC error) and thus should
trigger more frames to be received by your interface. In the mean time I'll search
why those bits weren't cleared when enabling the interface in monitor mode.
Which version are you using?
wireless-dev
rt2x00.git
rt2x00 cvs
Ivo
Somebody in the thread at some point said:
> Hi,
>
>>>> Which version are you using?
>>>> wireless-dev <---
>>>> rt2x00.git
>>>> rt2x00 cvs
>> Ok, rt2x00.git contains many changes to the initialization of the device,
>> so it is a bit hard to compare at the moment. At least it is confirmed that rt2x00 can
>> receive all frames in monitor mode and the problem area is the DROP filter.
>>
>> I'll release rt2x00 2.0.5 later today with all those changes, including the rxdone rate
>> selection fix. So if you could retest later to see if the problem disappeared in 2.0.5 it
>> would be great. :)
>
> Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this.
> I just noticed that when the first and only interface is a monitor interface
> the device was not being configured at all. This has now been fixed in rt2x00.git,
> so it will be part of the 2.0.5 release later today. :)
Great, I will check for it on the serialmonkey site later and give it a go.
I just received four different kinds of cheap cards from ebuyer, I hoped
to get a bcm43xx card again but you can't choose when the cards are only
GBP8 each. So later I will see what can happen with the other cards
that are new to me: Libertas on 88W8335 PC Card, Libertas USB stick
1286:1fab, and a Realtek PC Card RTL-8185.
Thanks to your help it looks like the first RT2571-based one is a winner ;-)
-Andy
Somebody in the thread at some point said:
> I think I have an idea why mac80211 always reports 1 MBs,
> rt2x00 checks if PREAMBLE was enabled or not. If that is the case it sets
> the rate value to rate->val2
> Mac80211 in turn only compares the value against rate->val which
> means that it won't find the rate and assume the lowest possible rate.
> I'll fix this by always setting the rate->val value instead (It isn't
really
> important for mac80211 to know if the preamble bit was set anyway).
Somehow the rates seem to be correct now after your change to the DROP
bits...
> #define TXRX_CSR0_DROP_CRC FIELD32(0x00020000)
> #define TXRX_CSR0_DROP_PHYSICAL FIELD32(0x00040000)
> #define TXRX_CSR0_DROP_CONTROL FIELD32(0x00080000)
> #define TXRX_CSR0_DROP_NOT_TO_ME FIELD32(0x00100000)
> #define TXRX_CSR0_DROP_TO_DS FIELD32(0x00200000)
> #define TXRX_CSR0_DROP_VERSION_ERROR FIELD32(0x00400000)
> #define TXRX_CSR0_DROP_MULTICAST FIELD32(0x00800000)
> #define TXRX_CSR0_DROP_BORADCAST FIELD32(0x01000000)
> #define TXRX_CSR0_DROP_ACK_CTS FIELD32(0x02000000)
>
> Which means it will only pass multicast, broadcast and ACK_CTS frames. :S
> Always dropping CRC errors is correct, since enabling that will
greatly upset
> any monitoring tool listening to the interface.
Well one day it will be nice if there is a stack-level way to turn it on
and off. We can also pass in the radiotap part a flag to show if the
packet's CRC was valid or not. The tools can then either turn on the
filtering before the packets come or filter on good packets only.
> To see if it helps try:
>
> echo 16 > csr_offset
> echo 0x0002b162 > csr_value
>
> This will disable all DROP bits (except for the CRC error) and thus should
> trigger more frames to be received by your interface. In the mean time
I'll search
> why those bits weren't cleared when enabling the interface in monitor
mode.
Yes, that seems to have done it, thanks
15:20:34.157203 54.0 Mb/s 2437 MHz (0x0480) 214dB signal Data IV:1b30
Pad 20 KeyID 0
15:20:34.157206 24.0 Mb/s 2437 MHz (0x0480) 232dB signal Acknowledgment
RA:00:11:50:ad:ce:38 (oui Unknown)
15:20:34.157942 54.0 Mb/s 2437 MHz (0x0480) 232dB signal Data IV:16aa
Pad 20 KeyID 0
15:20:34.157945 36.0 Mb/s 2437 MHz (0x0480) 214dB signal Acknowledgment
RA:00:19:d2:59:8f:d5 (oui Unknown)
15:20:34.161265 54.0 Mb/s 2437 MHz (0x0480) 214dB signal Data IV:1b31
Pad 20 KeyID 0
15:20:34.161268 24.0 Mb/s 2437 MHz (0x0480) 230dB signal Acknowledgment
RA:00:11:50:ad:ce:38 (oui Unknown)
15:20:34.165809 1.0 Mb/s 2437 MHz (0x0480) 218dB signal Beacon (froh)
[1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
15:20:34.165812 54.0 Mb/s 2437 MHz (0x0480) 214dB signal Data IV:1b32
Pad 20 KeyID 0
15:20:34.165815 24.0 Mb/s 2437 MHz (0x0480) 232dB signal Acknowledgment
RA:00:11:50:ad:ce:38 (oui Unknown)
15:20:34.166498 54.0 Mb/s 2437 MHz (0x0480) 232dB signal Data IV:16ab
Pad 20 KeyID 0
15:20:34.166502 36.0 Mb/s 2437 MHz (0x0480) 214dB signal Acknowledgment
RA:00:19:d2:59:8f:d5 (oui Unknown)
> Which version are you using?
> wireless-dev <---
> rt2x00.git
> rt2x00 cvs
-Andy
Somebody in the thread at some point said:
>> + /* BlueNEXT */
>> + { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
>
> This USB ID is already in the List under the Label "Ralink"
>
> /* Ralink */
> { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
Gah! I guess I jumped to the wrong conclusion when it didn't work,
because rt2500usb.ko also claims this ID. Blacklisting rt2500usb and
"adding" the ID in rt73usb got me able to do monitor mode, but I guess
blacklisting rt2500usb was what did the trick.
Sorry for the noise, but maybe the same ID in rt2500usb should be
removed, unless there is some story here about ID reuse...
-Andy
On Tuesday 31 July 2007, warmcat wrote:
> Add device ID for cheapo BlueNext rt2571-based stick BN-WD54G
>
> Signed-off-by: Andy Green <[email protected]>
> ---
>
> drivers/net/wireless/rt73usb.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rt73usb.c b/drivers/net/wireless/rt73usb.c
> index 3d838d1..82bb23c 100644
> --- a/drivers/net/wireless/rt73usb.c
> +++ b/drivers/net/wireless/rt73usb.c
> @@ -1814,6 +1814,8 @@ static struct usb_device_id rt73usb_device_table[] = {
> { USB_DEVICE(0x050d, 0x905b), USB_DEVICE_DATA(&rt73usb_ops) },
> /* Billionton */
> { USB_DEVICE(0x1631, 0xc019), USB_DEVICE_DATA(&rt73usb_ops) },
> + /* BlueNEXT */
> + { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
This USB ID is already in the List under the Label "Ralink"
/* Ralink */
{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
Ivo
On Tuesday 31 July 2007, Andy Green wrote:
> Somebody in the thread at some point said:
>
> >> + /* BlueNEXT */
> >> + { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
> >
> > This USB ID is already in the List under the Label "Ralink"
> >
> > /* Ralink */
> > { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
>
> Gah! I guess I jumped to the wrong conclusion when it didn't work,
> because rt2500usb.ko also claims this ID. Blacklisting rt2500usb and
> "adding" the ID in rt73usb got me able to do monitor mode, but I guess
> blacklisting rt2500usb was what did the trick.
:)
> Sorry for the noise, but maybe the same ID in rt2500usb should be
> removed, unless there is some story here about ID reuse...
Unfortunately there have been reports about devices with that USB ID
that contains a rt2500usb chipset. There are a number of duplicate USB ID's
between rt2500usb and rt73usb.
Some manufacturers like to release new revisions of their wireless USB stick
with different chipsets but with the same USB ID.
Ivo
Somebody in the thread at some point said:
> Unfortunately there have been reports about devices with that USB ID
> that contains a rt2500usb chipset. There are a number of duplicate USB ID's
> between rt2500usb and rt73usb.
> Some manufacturers like to release new revisions of their wireless USB stick
> with different chipsets but with the same USB ID.
Oh well.
Are there known problems with the monitor mode? It seems incomplete
even with one virtual interface, eg
13:37:00.549494 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request ()
[1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
13:37:00.550243 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request ()
[1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
13:37:00.590127 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
[1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
13:37:00.692568 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
[1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
13:37:00.897401 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
[1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
13:37:00.999773 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh)
[1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
and reports the rate as 1Mbps in all cases. During this capture I have
another box doing
# while [ 1 ] ; do ls -l / ; done
over an ssh link which is being carried on another wireless device on
the same box associated on to channel 6...
-Andy
On Wednesday 01 August 2007, Andy Green wrote:
> Somebody in the thread at some point said:
>
> >> Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this.
> >> I just noticed that when the first and only interface is a monitor interface
> >> the device was not being configured at all. This has now been fixed in rt2x00.git,
> >> so it will be part of the 2.0.5 release later today. :)
> >
> > Great, I will check for it on the serialmonkey site later and give it a go.
>
> Ah I saw it went to git.kernel.org
>
> Yes current rt2x00 git in there works fine for simple monitor mode
> now... thanks a lot for your hard work!
Excellent! Good to hear that is working completely now. :)
Ivo