rt73usb-add-bluenext-148f-2573
PATCH 1/1 rt73usb-add-bluenext-148f-2573
Add device ID for cheapo BlueNext rt2571-based stick BN-WD54G
---
drivers/net/wireless/rt73usb.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/net/wireless/rt73usb.c +2 -0
@@ -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) },
Quoted 13 lines · warmcat
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(-)drivers/net/wireless/rt73usb.c +0
-0
drivers/net/wireless/rt73usb.c static struct usb_device_id rt73usb_device_table[] = { · line 1818
Quoted 5 lines
drivers/net/wireless/rt73usb.c +2
-0@@ -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
Quoted 7 lines · Somebody in the thread at some point
drivers/net/wireless/rt73usb.c static struct usb_device_id rt73usb_device_table[] = { · line 1818
Quoted 2 lines
drivers/net/wireless/rt73usb.c +2
-0+/* 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
Quoted 7 lines · Andy Green
Quoted 5 lines · Somebody in the thread at some point
drivers/net/wireless/rt73usb.c static struct usb_device_id rt73usb_device_table[] = { · line 1818
Quoted 2 lines
drivers/net/wireless/rt73usb.c +2
-0+/* BlueNEXT */ + { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },This USB ID is already in the List under the Label "Ralink"
Quoted 7 lines
Quoted 2 lines
/* 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.
:)
Quoted 2 lines
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
Quoted 5 lines · Somebody in the thread at some point
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
Quoted 2 lines
Are there known problems with the monitor mode? It seems incomplete even with one virtual interface, eg
Sounds awfully familiar. :(
Quoted 13 lines
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
Quoted 2 lines
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?
Quoted 4 lines
# while [ 1 ] ; do ls -l / ; doneover 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
Quoted 4 lines · Somebody in the thread at some point
Quoted 2 lines
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.
Quoted 1 line
At which rate should the other box be sending the frames?
54Mbps, I am a couple of metres from the AP.
Quoted 8 lines
Quoted 4 lines
# while [ 1 ] ; do ls -l / ; doneover 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:
Quoted 6 lines
echo 16 >
csr_offset
catcsr_valueThis will read the
TXRX_CSR0register 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
Quoted 3 lines
Quoted 1 line
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. ;)
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
# while [ 1 ] ; do ls -l / ; doneover 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:
Quoted 8 lines
Quoted 6 lines
echo 16 >
csr_offset
catcsr_valueThis will read the
TXRX_CSR0register 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.
Quoted 19 lines
However, I added the following debug line inside the loop at
rt2x00_dev.cfunction
void rt2x00lib_rxdone(structdata_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
Quoted 4 lines
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).
Quoted 5 lines
after the echo, catting that spews
0x007eb162repeatedly 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
Quoted 6 lines · Somebody in the thread at some point
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 againstrate->valwhich means that it won't find the rate and assume the lowest possible rate. I'll fix this by always setting therate->valvalue instead (It isn't
really
Quoted 1 line
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...
Quoted 10 lines
#define
TXRX_CSR0_DROP_CRCFIELD32(0x00020000)
#defineTXRX_CSR0_DROP_PHYSICALFIELD32(0x00040000)
#defineTXRX_CSR0_DROP_CONTROLFIELD32(0x00080000)
#defineTXRX_CSR0_DROP_NOT_TO_MEFIELD32(0x00100000)
#defineTXRX_CSR0_DROP_TO_DSFIELD32(0x00200000)
#defineTXRX_CSR0_DROP_VERSION_ERRORFIELD32(0x00400000)
#defineTXRX_CSR0_DROP_MULTICASTFIELD32(0x00800000)
#defineTXRX_CSR0_DROP_BORADCASTFIELD32(0x01000000)
#defineTXRX_CSR0_DROP_ACK_CTSFIELD32(0x02000000)
Quoted 2 lines
Which means it will only pass multicast, broadcast and
ACK_CTSframes. :S Always dropping CRC errors is correct, since enabling that will
greatly upset
Quoted 1 line
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.
Quoted 7 lines
To see if it helps try:
echo 16 >
csr_offset
echo0x0002b162>csr_valueThis 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
Quoted 1 line
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)
Quoted 4 lines
Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvs
-Andy
Quoted 8 lines · Andy Green
Quoted 6 lines · Somebody in the thread at some point
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 againstrate->valwhich means that it won't find the rate and assume the lowest possible rate. I'll fix this by always setting therate->valvalue instead (It isn't
Quoted 5 lines
really
Quoted 1 line
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! :)
Quoted 12 lines
Quoted 10 lines
#define
TXRX_CSR0_DROP_CRCFIELD32(0x00020000)
#defineTXRX_CSR0_DROP_PHYSICALFIELD32(0x00040000)
#defineTXRX_CSR0_DROP_CONTROLFIELD32(0x00080000)
#defineTXRX_CSR0_DROP_NOT_TO_MEFIELD32(0x00100000)
#defineTXRX_CSR0_DROP_TO_DSFIELD32(0x00200000)
#defineTXRX_CSR0_DROP_VERSION_ERRORFIELD32(0x00400000)
#defineTXRX_CSR0_DROP_MULTICASTFIELD32(0x00800000)
#defineTXRX_CSR0_DROP_BORADCASTFIELD32(0x01000000)
#defineTXRX_CSR0_DROP_ACK_CTSFIELD32(0x02000000)Quoted 2 lines
Which means it will only pass multicast, broadcast and
ACK_CTSframes. :S Always dropping CRC errors is correct, since enabling that will
Quoted 7 lines
greatly upset
Quoted 1 line
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. :)
Quoted 5 lines
Quoted 5 lines
To see if it helps try:
echo 16 >
csr_offset
echo0x0002b162>csr_value
Quoted 7 lines
Quoted 2 lines
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
Quoted 1 line
why those bits weren't cleared when enabling the interface in monitor
mode.
Yes, that seems to have done it, thanks
Excellent :)
Quoted 4 lines
Quoted 4 lines
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
Hi,
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvs
Quoted 7 lines
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
Quoted 10 lines · Somebody in the thread at some point
Hi,
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvsOk, 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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 6 lines · Somebody in the thread at some point
Quoted 4 lines
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
Quoted 7 lines · Andy Green
Quoted 5 lines · Somebody in the thread at some point
Quoted 4 lines
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. :)
Quoted 6 lines
Quoted 1 line
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
Quoted 6 lines · Somebody in the thread at some point
echo 16 >
csr_offset
catcsr_valueThis will read the
TXRX_CSR0register 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