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
