Search Linux Wireless

Re: rtl8187 bug report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <info@xxxxxxxxxx> wrote:
> Hin-Tak Leung ha scritto:
>>
>> 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).
>>
>>
> I'm talking about rtl8187 B chipset which seems different from the first
> one rtl8187 L
> In realtek drivers dowload page I can't see a linux version for rtl8187b
> so as a normal user I think there's no official support
> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=1&PFid=1&Level=6&Conn=5&DownTypeID=3&GetDown=false&Downloads=true#RTL8187B
> About them being co-operative, so that makes a right choise to buy their
> 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 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)
>>
>>
> Talking about those links, the one I should follow is this one
> http://www.aircrack-ng.org/doku.php?id=r8187b 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 - "raw 802.11 frames
> packet capturing software" called airodump-ng. It "writes 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.
> 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=airodump-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 can't
> understand this is a normal behaviour.
> Thanks
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux