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 Sun, Mar 22, 2009 at 07:54:16PM -0400, Mike Kershaw wrote:
> On Fri, Mar 20, 2009 at 10:06:49PM +0100, G?bor Stefanik wrote:
> > 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)
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
--
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hin-Tak Leung ha scritto:
>
> 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.
>
> 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-----
>
> 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=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
On Fri, Mar 20, 2009 at 2:30 PM, Info[at]Giuppi <[email protected]> wrote=
:
> Hin-Tak Leung ha scritto:
>>
>> You are somewhat wrong about Realtek's position - I am speaking as o=
ne
>> 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, th=
ey
>> 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).
>>
>>
> I'm talking about rtl8187 B chipset which seems different from the fi=
rst
> one rtl8187 L
> In realtek drivers dowload page I can't see a linux version for rtl81=
87b
> 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
> About them being co-operative, so that makes a right choise to buy th=
eir
> hardware at least!
> I don't know who you people are, nice to meet you now. I just felt th=
e
> need to share a question with you and since I'm inexperienced perhaps=
I
> tend to confuse things trying to explain myself.
>>>> 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 t=
he
>>> 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=3Dr8187
>>
>> 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 conside=
r
>> 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
> 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
> to be in the compat-wireless driver.
> New drivers seem to natively support monitor mode. I've put the devic=
e
> in monitor mode. While in monitor mode, the driver has some issues
> handling WEP protected networks. Other networks are shown correctly i=
n
> monitor mode.
> If you're asking on which bases I say that, I've anticipated the answ=
er
> 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 ou=
t 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.
> Each access point sends about ten beacons per second at the lowest ra=
te
> (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
> 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
> understand this is a normal behaviour.
> Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
> the body of a message to [email protected]
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=
ml
>
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. :-)
Hin-Tak Leung ha scritto:
>
> You are somewhat wrong about Realtek's position - I am speaking as on=
e
> 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
> 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
> 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.
>>> On a different issue - I think such adaptation are frown upon and w=
ill
>>> 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.
>>> =20
>> 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 i=
t
>> 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
>> time to check if I'm wrong.
>> =20
>
> 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=3Dr8187
>
> 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
On Fri, Mar 20, 2009 at 10:06:49PM +0100, G?bor Stefanik wrote:
> 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
--
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.
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=
:
> Hin-Tak Leung ha scritto:
>>
>> You are somewhat wrong about Realtek's position - I am speaking as o=
ne
>> 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, th=
ey
>> 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).
>>
>>
> I'm talking about rtl8187 B chipset which seems different from the fi=
rst
> one rtl8187 L
> In realtek drivers dowload page I can't see a linux version for rtl81=
87b
> 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
> About them being co-operative, so that makes a right choise to buy th=
eir
> hardware at least!
> I don't know who you people are, nice to meet you now. I just felt th=
e
> need to share a question with you and since I'm inexperienced perhaps=
I
> tend to confuse things trying to explain myself.
>>>> 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 t=
he
>>> 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=3Dr8187
>>
>> 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 conside=
r
>> 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
> 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
> to be in the compat-wireless driver.
> New drivers seem to natively support monitor mode. I've put the devic=
e
> in monitor mode. While in monitor mode, the driver has some issues
> handling WEP protected networks. Other networks are shown correctly i=
n
> monitor mode.
> If you're asking on which bases I say that, I've anticipated the answ=
er
> 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 ou=
t 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.
> Each access point sends about ten beacons per second at the lowest ra=
te
> (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
> 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
> understand this is a normal behaviour.
> Thanks
>
On Thu, Mar 19, 2009 at 11:28 PM, Info[at]Giuppi <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hin-Tak Leung ha scritto:
>>
>> 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.
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).
>> 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.
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)
On Wed, Mar 18, 2009 at 5:23 PM, Info[at]Giuppi <[email protected]> wrote=
:
> I have a rtl8187B usb dongle, works pretty well with new driver rtl81=
87.
> 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
> 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
> 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.