rtl8187 bug report
I have a rtl8187B usb dongle, works pretty well with new driver rtl8187. Thanks for the great job you're doing.
The problem comes when I try to handle my WEP protected network in monitor mode.
It becomes really slow in finding/showing the network and when it appears in the list, no activity
is detected. I mean beacons or data remains at 0 in the airodump-ng screen (from latest svn aircrack-ng suite)
Everything works fine in managed mode and the network is easily detected and i can connect too.
I also have a rt73usb device and this one works as expected.
I'm currently using ubuntu-backport modules but I've also tryed the compat-wireless package dated 17 march
kernel version 2.6.27-13-generic
On Wed, Mar 18, 2009 at 5:23 PM, Info[at]Giuppi <[email protected]> wrote= :
Quoted 1 line
I have a rtl8187B usb dongle, works pretty well with new driver rtl81=
87.
Quoted 10 lines
Thanks for the great job you're doing.
The problem comes when I try to handle my WEP protected network in monitor mode.
It becomes really slow in finding/showing the network and when it appears in the list, no activity
is detected. I mean beacons or data remains at 0 in the airodump-ng screen (from latest svn aircrack-ng suite)Everything works fine in managed mode and the network is easily detec=
ted
Quoted 10 lines
and i can connect too.
I also have a rt73usb device and this one works as expected.
I'm currently using ubuntu-backport modules but I've also tryed the compat-wireless package dated 17 march
kernel version 2.6.27-13-generic--
To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
Quoted 3 lines
the body of a message to [email protected]
More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
I am not familiar with aircrack-ng, but I believe it can be used with a modified version of the vendor rtl8187 driver, (and the aircrack-ng people hosts a modified version of the vendor driver on their web site). I have not actually looked at their modification so I have no idea what modification is required for aircrack-ng to work well, but I believe *some* adaptation is required?
On a different issue - I think such adaptation are frown upon and will not make it into the standard kernel, due to its nature of typical usage in a controversal scenario. Maybe other wireless dev people, especially Herton and Larry, can advise.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hin-Tak Leung ha scritto:
Quoted 7 lines
I am not familiar with aircrack-ng, but I believe it can be used with a modified version of the vendor rtl8187 driver, (and the aircrack-ng people hosts a modified version of the vendor driver on their web site). I have not actually looked at their modification so I have no idea what modification is required for aircrack-ng to work well, but I believe *some* adaptation is required?
RTL8187B has no official linux support by the vendor. The driver you're referencing to has been adapted by one guy and "works" for old kernel versions only.
I'm very happy with this new rtl8187. The problem in not related to the aircrack-ng software. I'm just saying I think there's something wrong with WEP networks in monitor mode. Using a tool from the suite to scan local wireless networks I've found out that strange behaviour only with WEPs.
Quoted 5 lines
On a different issue - I think such adaptation are frown upon and will not make it into the standard kernel, due to its nature of typical usage in a controversal scenario. Maybe other wireless dev people, especially Herton and Larry, can advise.
As far as I know there are no adaptations needed. Wanted or not, it already works in those "controversal scenario".
The rt73usb driver comes from the same compat-wireless package and it hasn't that problem, for example. The rtl8187 driver itself works great for networks other than WEP.
Thanks very much for your reply, I hope some of the devs can take the time to check if I'm wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknC1S8ACgkQzDOyiWU13FC8AgCdG2mv/xMPGIg13YsM9o3V5ZeT e4AAn16SMsX081bPc4eK9RdddMZ3Nu01
=vAo1
-----END PGP SIGNATURE-----
Quoted 11 lines · Info[at]Giuppi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hin-Tak Leung ha scritto:
Quoted 7 lines
I am not familiar with aircrack-ng, but I believe it can be used with a modified version of the vendor rtl8187 driver, (and the aircrack-ng people hosts a modified version of the vendor driver on their web site). I have not actually looked at their modification so I have no idea what modification is required for aircrack-ng to work well, but I believe *some* adaptation is required?
Quoted 8 lines
RTL8187B has no official linux support by the vendor. The driver you're referencing to has been adapted by one guy and "works" for old kernel versions only.
I'm very happy with this new rtl8187. The problem in not related to the aircrack-ng software. I'm just saying I think there's something wrong with WEP networks in monitor mode. Using a tool from the suite to scan local wireless networks I've found out that strange behaviour only with WEPs.
You are somewhat wrong about Realtek's position - I am speaking as one of the 3 current maintainers of the new rtl8187 code, by the way, if you didn't know that... - Realtek staff have been quite co-operative, and while the vendor driver is behind and have some other issues, they have regular releases through OEM channels. (there is also a chance that the "one guy" you refer to is me - at least 3 people had tried to port the vendor driver forward).
Quoted 4 lines
Quoted 4 lines
On a different issue - I think such adaptation are frown upon and will not make it into the standard kernel, due to its nature of typical usage in a controversal scenario. Maybe other wireless dev people, especially Herton and Larry, can advise.
Quoted 8 lines
As far as I know there are no adaptations needed. Wanted or not, it already works in those "controversal scenario".
The rt73usb driver comes from the same compat-wireless package and it hasn't that problem, for example. The rtl8187 driver itself works great for networks other than WEP.Thanks very much for your reply, I hope some of the devs can take the time to check if I'm wrong.
According to http://www.aircrack-ng.org/doku.php?id=rtl8187 , two small patches are recommended.
vs the vendor driver, which needs one rather big patch:
http://www.aircrack-ng.org/doku.php?id=r8187
The fragmentation patch applies to both rtl8187 anf rt73usb, but the injection patch is rtl8187-specific. If the latter works better for you and have no detrimental effect on "normal" usage, we can consider putting it in. (it looks a bit wrong though)
Hin-Tak Leung ha scritto:
Quoted 2 lines
You are somewhat wrong about Realtek's position - I am speaking as on=
e
Quoted 3 lines
of the 3 current maintainers of the new rtl8187 code, by the way, if you didn't know that... - Realtek staff have been quite co-operative, and while the vendor driver is behind and have some other issues, the=
y
Quoted 2 lines
have regular releases through OEM channels. (there is also a chance that the "one guy" you refer to is me - at least 3 people had tried t=
o
Quoted 3 lines
port the vendor driver forward).
=20
I'm talking about rtl8187 B chipset which seems different from the firs= t
one rtl8187 L
In realtek drivers dowload page I can't see a linux version for rtl8187= b
so as a normal user I think there's no official support
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=3D1&PNid=3D=
1&PFid=3D1&Level=3D6&Conn=3D5&DownTypeID=3D3&GetDown=3Dfalse&Downloads=3D= true#RTL8187B
About them being co-operative, so that makes a right choise to buy thei= r
hardware at least!
I don't know who you people are, nice to meet you now. I just felt the need to share a question with you and since I'm inexperienced perhaps I tend to confuse things trying to explain myself.
Quoted 1 line
Quoted 1 line
Quoted 1 line
On a different issue - I think such adaptation are frown upon and w=
ill
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
not make it into the standard kernel, due to its nature of typical usage in a controversal scenario. Maybe other wireless dev people, especially Herton and Larry, can advise.
=20As far as I know there are no adaptations needed. Wanted or not, it already works in those "controversal scenario".
The rt73usb driver comes from the same compat-wireless package and i=
t
Quoted 4 lines
Quoted 4 lines
hasn't that problem, for example. The rtl8187 driver itself works great for networks other than WEP.
Thanks very much for your reply, I hope some of the devs can take th=
e
Quoted 8 lines
Quoted 2 lines
time to check if I'm wrong.
=20According to http://www.aircrack-ng.org/doku.php?id=3Drtl8187 , two small patches are recommended.
vs the vendor driver, which needs one rather big patch:
http://www.aircrack-ng.org/doku.php?id=3Dr8187
Quoted 6 lines
The fragmentation patch applies to both rtl8187 anf rt73usb, but the injection patch is rtl8187-specific. If the latter works better for you and have no detrimental effect on "normal" usage, we can consider putting it in. (it looks a bit wrong though)
=20
Talking about those links, the one I should follow is this one
http://www.aircrack-ng.org/doku.php?id=3Dr8187b and the driver download offered is r8187b-2.6.25-hirte.tar.bz2 since rtl8187 version L seems different from version B. But that's not my point.
I'm not complaining neither about fragmentation nor any injection patch to be in the compat-wireless driver.
New drivers seem to natively support monitor mode. I've put the device in monitor mode. While in monitor mode, the driver has some issues handling WEP protected networks. Other networks are shown correctly in monitor mode.
If you're asking on which bases I say that, I've anticipated the answer telling you I've used a - svn updated version of - "=EF=BB=BFraw 802.11=
frames
packet capturing software" called airodump-ng. It "=EF=BB=BFwrites out = a text
file containing the details of all access points and clients seen". As I can see, beacons - "Number of announcements packets sent by the AP= =2E
Each access point sends about ten beacons per second at the lowest rate (1M), so they can usually be picked up from very far" - from WEP networks aren't detected at all.
Parts between " " are from
http://www.aircrack-ng.org/doku.php?id=3Dairodump-ng just to let you kn= ow
what I've read about and I'm referencing to.
Maybe this makes my delirium clearer, maybe I miss something and I can'= t
understand this is a normal behaviour.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
The new in-kernel code is rtl8187+rtl8187b together (and I am supposed to be familiar with it, for reasons I already explained); Realtek offers two separate vendor drivers for 8187(L) and 8187B - the most current of the former I can find in my hard disc (from an OEM web site) has a release date of 1217.2008,
whereas for the latter is 0708.2008, and from OEM 0611.2008. One is 3 months old, and the other 8-9 months old - both are quite recent by any standard. The device is usually rebranded (and *not* sold through retail), so the driver is distributed through OEM rebranded channels, as I already said.
I am not sure what can be done here - the problem you said you have is not exactly well-defined, and your specific usage of the driver is not something I want to try/experiment myself - so I'll let others think about it. As I said, if the injection patch does anything useful for you, we can take this further...
On Fri, Mar 20, 2009 at 1:30 PM, Info[at]Giuppi <[email protected]> wrote= :
Quoted 3 lines
Hin-Tak Leung ha scritto:
Quoted 2 lines
You are somewhat wrong about Realtek's position - I am speaking as o=
ne
Quoted 2 lines
Quoted 2 lines
of the 3 current maintainers of the new rtl8187 code, by the way, if you didn't know that... - Realtek staff have been quite co-operative=
,
Quoted 1 line
Quoted 1 line
and while the vendor driver is behind and have some other issues, th=
ey
Quoted 2 lines
Quoted 2 lines
have regular releases through OEM channels. (there is also a chance that the "one guy" you refer to is me - at least 3 people had tried =
to
Quoted 4 lines
Quoted 3 lines
port the vendor driver forward).
I'm talking about rtl8187 B chipset which seems different from the fi=
rst
Quoted 2 lines
one rtl8187 L
In realtek drivers dowload page I can't see a linux version for rtl81=
87b
Quoted 2 lines
so as a normal user I think there's no official support
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=3D1&PNi=
d=3D1&PFid=3D1&Level=3D6&Conn=3D5&DownTypeID=3D3&GetDown=3Dfalse&Downlo= ads=3Dtrue#RTL8187B
Quoted 1 line
About them being co-operative, so that makes a right choise to buy th=
eir
Quoted 2 lines
hardware at least!
I don't know who you people are, nice to meet you now. I just felt th=
e
Quoted 1 line
need to share a question with you and since I'm inexperienced perhaps=
I
Quoted 2 lines
tend to confuse things trying to explain myself.
Quoted 1 line
Quoted 1 line
Quoted 1 line
On a different issue - I think such adaptation are frown upon and =
will
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
not make it into the standard kernel, due to its nature of typical usage in a controversal scenario. Maybe other wireless dev people, especially Herton and Larry, can advise.
As far as I know there are no adaptations needed. Wanted or not, it already works in those "controversal scenario".
The rt73usb driver comes from the same compat-wireless package and =
it
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
hasn't that problem, for example. The rtl8187 driver itself works great for networks other than WEP.
Thanks very much for your reply, I hope some of the devs can take t=
he
Quoted 11 lines
Quoted 11 lines
Quoted 2 lines
time to check if I'm wrong.
According to http://www.aircrack-ng.org/doku.php?id=3Drtl8187 , two small patches are recommended.
vs the vendor driver, which needs one rather big patch:
http://www.aircrack-ng.org/doku.php?id=3Dr8187The fragmentation patch applies to both rtl8187 anf rt73usb, but the injection patch is rtl8187-specific. If the latter works better for you and have no detrimental effect on "normal" usage, we can conside=
r
Quoted 5 lines
Quoted 3 lines
putting it in. (it looks a bit wrong though)
Talking about those links, the one I should follow is this one
http://www.aircrack-ng.org/doku.php?id=3Dr8187b and the driver downlo=
ad
Quoted 4 lines
offered is r8187b-2.6.25-hirte.tar.bz2 since rtl8187 version L seems different from version B. But that's not my point.
I'm not complaining neither about fragmentation nor any injection pat=
ch
Quoted 2 lines
to be in the compat-wireless driver.
New drivers seem to natively support monitor mode. I've put the devic=
e
Quoted 2 lines
in monitor mode. While in monitor mode, the driver has some issues handling WEP protected networks. Other networks are shown correctly i=
n
Quoted 2 lines
monitor mode.
If you're asking on which bases I say that, I've anticipated the answ=
er
Quoted 1 line
telling you I've used a - svn updated version of - "=EF=BB=BFraw 802.=
11 frames
Quoted 1 line
packet capturing software" called airodump-ng. It "=EF=BB=BFwrites ou=
t a text
Quoted 2 lines
file containing the details of all access points and clients seen". As I can see, beacons - "Number of announcements packets sent by the =
AP.
Quoted 1 line
Each access point sends about ten beacons per second at the lowest ra=
te
Quoted 4 lines
(1M), so they can usually be picked up from very far" - from WEP networks aren't detected at all.
Parts between " " are from
http://www.aircrack-ng.org/doku.php?id=3Dairodump-ng just to let you =
know
Quoted 2 lines
what I've read about and I'm referencing to.
Maybe this makes my delirium clearer, maybe I miss something and I ca=
n't
Quoted 3 lines
understand this is a normal behaviour.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 20, 2009 at 2:30 PM, Info[at]Giuppi <[email protected]> wrote= :
Quoted 3 lines
Hin-Tak Leung ha scritto:
Quoted 2 lines
You are somewhat wrong about Realtek's position - I am speaking as o=
ne
Quoted 2 lines
Quoted 2 lines
of the 3 current maintainers of the new rtl8187 code, by the way, if you didn't know that... - Realtek staff have been quite co-operative=
,
Quoted 1 line
Quoted 1 line
and while the vendor driver is behind and have some other issues, th=
ey
Quoted 2 lines
Quoted 2 lines
have regular releases through OEM channels. (there is also a chance that the "one guy" you refer to is me - at least 3 people had tried =
to
Quoted 4 lines
Quoted 3 lines
port the vendor driver forward).
I'm talking about rtl8187 B chipset which seems different from the fi=
rst
Quoted 2 lines
one rtl8187 L
In realtek drivers dowload page I can't see a linux version for rtl81=
87b
Quoted 2 lines
so as a normal user I think there's no official support
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=3D1&PNi=
d=3D1&PFid=3D1&Level=3D6&Conn=3D5&DownTypeID=3D3&GetDown=3Dfalse&Downlo= ads=3Dtrue#RTL8187B
Quoted 1 line
About them being co-operative, so that makes a right choise to buy th=
eir
Quoted 2 lines
hardware at least!
I don't know who you people are, nice to meet you now. I just felt th=
e
Quoted 1 line
need to share a question with you and since I'm inexperienced perhaps=
I
Quoted 2 lines
tend to confuse things trying to explain myself.
Quoted 1 line
Quoted 1 line
Quoted 1 line
On a different issue - I think such adaptation are frown upon and =
will
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
not make it into the standard kernel, due to its nature of typical usage in a controversal scenario. Maybe other wireless dev people, especially Herton and Larry, can advise.
As far as I know there are no adaptations needed. Wanted or not, it already works in those "controversal scenario".
The rt73usb driver comes from the same compat-wireless package and =
it
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
hasn't that problem, for example. The rtl8187 driver itself works great for networks other than WEP.
Thanks very much for your reply, I hope some of the devs can take t=
he
Quoted 11 lines
Quoted 11 lines
Quoted 2 lines
time to check if I'm wrong.
According to http://www.aircrack-ng.org/doku.php?id=3Drtl8187 , two small patches are recommended.
vs the vendor driver, which needs one rather big patch:
http://www.aircrack-ng.org/doku.php?id=3Dr8187The fragmentation patch applies to both rtl8187 anf rt73usb, but the injection patch is rtl8187-specific. If the latter works better for you and have no detrimental effect on "normal" usage, we can conside=
r
Quoted 5 lines
Quoted 3 lines
putting it in. (it looks a bit wrong though)
Talking about those links, the one I should follow is this one
http://www.aircrack-ng.org/doku.php?id=3Dr8187b and the driver downlo=
ad
Quoted 4 lines
offered is r8187b-2.6.25-hirte.tar.bz2 since rtl8187 version L seems different from version B. But that's not my point.
I'm not complaining neither about fragmentation nor any injection pat=
ch
Quoted 2 lines
to be in the compat-wireless driver.
New drivers seem to natively support monitor mode. I've put the devic=
e
Quoted 2 lines
in monitor mode. While in monitor mode, the driver has some issues handling WEP protected networks. Other networks are shown correctly i=
n
Quoted 2 lines
monitor mode.
If you're asking on which bases I say that, I've anticipated the answ=
er
Quoted 1 line
telling you I've used a - svn updated version of - "=EF=BB=BFraw 802.=
11 frames
Quoted 1 line
packet capturing software" called airodump-ng. It "=EF=BB=BFwrites ou=
t a text
Quoted 2 lines
file containing the details of all access points and clients seen". As I can see, beacons - "Number of announcements packets sent by the =
AP.
Quoted 1 line
Each access point sends about ten beacons per second at the lowest ra=
te
Quoted 4 lines
(1M), so they can usually be picked up from very far" - from WEP networks aren't detected at all.
Parts between " " are from
http://www.aircrack-ng.org/doku.php?id=3Dairodump-ng just to let you =
know
Quoted 2 lines
what I've read about and I'm referencing to.
Maybe this makes my delirium clearer, maybe I miss something and I ca=
n't
Quoted 4 lines
understand this is a normal behaviour.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=
ml
Quoted 1 line
Hi!
Could you please test if you can see packets originating from your network in Kismet or Wireshark?
Also, did you use the included airmon-ng script to enable monitor mode, or did you just do "ifconfig wlan0 down; iwconfig wlan0 mode monitor, ifconfig wlan0 up"? (The two are significantly different, as airmon-ng uses iw/nl80211 to enable monitor mode on a separate interface - it would be good if you tried it both ways.)
Thanks,
G=C3=A1bor (.NetRolller 3D)
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) --
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines
Hi!
Could you please test if you can see packets originating from your network in Kismet or Wireshark?
Also, did you use the included airmon-ng script to enable monitor mode, or did you just do "ifconfig wlan0 down; iwconfig wlan0 mode monitor, ifconfig wlan0 up"? (The two are significantly different, as airmon-ng uses iw/nl80211 to enable monitor mode on a separate interface - it would be good if you tried it both ways.)
Quoted 6 lines
Thanks,
G=E1bor (.NetRolller 3D)--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
A short summary of my first quick test.
I use airmon-ng script to enable monitor mode. iw tool is version 0.9.9-nogit. No beacons from wep networks are shown. I've downloaded a couple of so called "security distros", backtrack4 and nubuntu, shipped with rtl8187. Same behaviour about weps.
I haven't had the time to investigate the "old way" of enabling monitor mode on those live cd.
I've followed your advice about "ifconfig wlan0 down; iwconfig wlan0 mo= de
monitor, ifconfig wlan0 up" on my ubuntu installation. My surprise to see beacons growing from the wep network.
Kismet works fine, too.
With wlan0 in monitor mode, I've used airmon-ng to create a mon0 monitor interface, just to see what could happen. And the result was mon0 worked fine, too.
So I've disconnected the usb dongle and unloaded possible related modules by hand and by "make unload" from compat wireless setup scripts.
Then I've reconnected the usb device and created the mon0 interface with airmon-ng, this time without enabling monitor mode on wlan0. mon0 still worked fine. I'll check again after a system reboot.
I hope that makes any sense to you. Thanks for your reply
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · G?bor Stefanik
Could you please test if you can see packets originating from your network in Kismet or Wireshark?
Also, did you use the included airmon-ng script to enable monitor mode, or did you just do "ifconfig wlan0 down; iwconfig wlan0 mode monitor, ifconfig wlan0 up"? (The two are significantly different, as airmon-ng uses iw/nl80211 to enable monitor mode on a separate interface - it would be good if you tried it both ways.)
I have actually seen similar problems with the 8187 (unknown if it is B or L - the drivers think it's B, but the production run of the hardware is NORMALLY L and may have recently changed; I have known-B generic cards and maybe-B Alfa cards)
Kismet currently still uses setsiociwmode to set monitor mode on at interface, it only uses nl80211 when you're starting a device with an aux vap for rfmon.
I haven't been able to narrow down the trigger, but I've seen current (.28 + compat-wireless 02-05 and 03-16) drivers stop reporting any packets from the device a few minutes into run. It isn't linked to changing channel (tested with and without), and I've been told that when it happens on multi-card systems it disables all other cards as well (ath5k in this case).
Symptoms are the card stops reporting packets in monitor mode; tcpdump also stops showing packets, ifdown/ifup doesn't reset the card to a working state.
This occurs with a single VAP being set to down/monitor/up.
-m
Signature · 4 lines
Mike Kershaw/Dragorn <[email protected]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 Todays lesson is always to ignore your feelings and listen to the robot head.
Quoted 9 lines · Mike Kershaw
Quoted 7 lines · G?bor Stefanik
Could you please test if you can see packets originating from your network in Kismet or Wireshark?
Also, did you use the included airmon-ng script to enable monitor mode, or did you just do "ifconfig wlan0 down; iwconfig wlan0 mode monitor, ifconfig wlan0 up"? (The two are significantly different, as airmon-ng uses iw/nl80211 to enable monitor mode on a separate interface - it would be good if you tried it both ways.)
Quoted 4 lines
I have actually seen similar problems with the 8187 (unknown if it is B or L - the drivers think it's B, but the production run of the hardware is NORMALLY L and may have recently changed; I have known-B generic cards and maybe-B Alfa cards)
I am NOT seeing this behavior under 2.6.29 so far (~1hr test) with channel hopping enabled (siocsiwchan, nothing fancy) at 3x a second, single rfmon vap set via siociwmode.
-m
Signature · 10 lines
Mike Kershaw/Dragorn <[email protected]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 "Hostility towards Microsoft is not difficult to find on the Net, and it blends two strains: resentful people who feel Microsoft is too powerful, and disdainful people who think it's tacky. This is all strongly reminiscent of the heyday of Communism and Socialism, when the bourgeoisie were hated from both ends: by the proles, because they had all the money, and by the intelligentsia, because of their tendency to spend it on lawn ornaments." -- Neal Stephenson