Thread: [Ndiswrapper-general] Atheros 5211
Status: Beta
Brought to you by:
pgiri
From: Giridhar P. <gi...@lm...> - 2004-05-23 15:14:00
|
The CVS now has support for Atheros 5211. I have tested this with Orinoco Proxim 802.11a/b card (pci id: 168c:0012). I have used the drivers that came with the CD as I couldn't find the drivers on the net. If anyone has Atheros 5211 chipset and want to give CVS a spin and give feedback, we can either announce that it works or see if it needs any fixing. Thanks, Giri |
From: Jan K. <jan...@we...> - 2004-05-24 17:03:36
|
Giridhar Pemmasani wrote: > The CVS now has support for Atheros 5211. I have tested this with > Orinoco Proxim 802.11a/b card (pci id: 168c:0012). I have used the > drivers that came with the CD as I couldn't find the drivers on the > net. If anyone has Atheros 5211 chipset and want to give CVS a spin > and give feedback, we can either announce that it works or see if it > needs any fixing. > Well, there are some improvements, but it is still not working with my driver :(. I recently installed the latest drivers version for the IBM 802.11a/b/g Wireless LAN Mini PCI card sold for R40 Thinkpads and some other models (see http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-52527). The result was an immediate crash during insmod, this is now solved! But - and here are the bad news - ndiswrapper crashes on: o packet reception or transmission (not yet clear which case, the EIP is interestingly 0x13131313 - any known pattern?) o multiple "iwconfig <dev> essid XYZ" commands And it is still not possible to persuade my driver to switch to ad-hoc mode... Regarding the last point, I had the suspicion that some unresolved registry entries were the reason. But even after fixing NdisReadConfiguration() (must be case insensitive, see nocase.patch) and hacking some entries which are available under Windows, the problem still remains. I also attached a small patch to use the latest gcc that comes with SuSE 9.1 with older 2.4 kernels (here: 2.4.21). If I'll find some time, I will try to dig deeper after the first crash. But it is difficult for me to debug, because - I think I already complaint before - my notebook has no serial port for a kernel debugger, and I don't own an access point let the driver attach at all... Greetings, Jan |
From: Giridhar P. <gi...@lm...> - 2004-05-24 17:47:55
|
On Mon, 24 May 2004 19:03:22 +0200, Jan Kiszka <jan...@we...> said: Jan> o packet reception or transmission (not yet clear which case, Jan> the EIP is interestingly 0x13131313 - any known pattern?) This is fixed in cvs. Wait a little while and upgrade to cvs. We use various patterns to identify what could be the problem (since we can't debug the code, we have to rely on these tricks). In this case NdisMSendResourceAvailable function is supposed to be initialized where 0x13131313 was. Jan> o multiple "iwconfig <dev> essid XYZ" commands Jan> And it is still not possible to persuade my driver to switch to Jan> ad-hoc mode... This is the only problem I see now. Apparently this driver doesn't like to associate with my AP (in Managed mode). It takes a few attempts before it associates. After that, even removing and inserting the module etc is not a problem; it associates easily. But right after booting, it takes a few attempts. If the card is inserted before loading the module, I seem to have better luck. Jan> Regarding the last point, I had the suspicion that some Jan> unresolved registry entries were the reason. But even after Jan> fixing NdisReadConfiguration() (must be case insensitive, see Jan> nocase.patch) and hacking some entries which are available Jan> under Windows, the problem still remains. I modified the conf file so it only uses 802.11b mode etc. I will try the case insensitive patch. Jan> I also attached a small patch to use the latest gcc that comes Jan> with SuSE 9.1 with older 2.4 kernels (here: 2.4.21). Jan> If I'll find some time, I will try to dig deeper after the Jan> first crash. But it is difficult for me to debug, because - I Jan> think I already complaint before - my notebook has no serial Jan> port for a kernel debugger, and I don't own an access point let Jan> the driver attach at all... Well, I saved you all the trouble :-) I couldn't get it to crash after I fixed the above problems. If you can figure out why the card doesn't like associating, it would be great. Thanks for the patches, Giri |
From: Jan K. <jan...@we...> - 2004-05-24 18:41:45
Attachments:
smime.p7s
|
> On Mon, 24 May 2004 19:03:22 +0200, Jan Kiszka <jan...@we...> said: > Jan> o packet reception or transmission (not yet clear which case, > Jan> the EIP is interestingly 0x13131313 - any known pattern?) > > This is fixed in cvs. Wait a little while and upgrade to cvs. > Great, will check this tomorrow at work again! > Jan> o multiple "iwconfig <dev> essid XYZ" commands > Jan> And it is still not possible to persuade my driver to switch to > Jan> ad-hoc mode... > > This is the only problem I see now. Apparently this driver doesn't > like to associate with my AP (in Managed mode). It takes a few > attempts before it associates. After that, even removing and inserting > the module etc is not a problem; it associates easily. But right after > booting, it takes a few attempts. If the card is inserted before > loading the module, I seem to have better luck. > Mmmh, associating with the AP at work was a question of milliseconds in my case. > > Well, I saved you all the trouble :-) I couldn't get it to crash after > I fixed the above problems. If you can figure out why the card doesn't > like associating, it would be great. > It seems that the driver simple swallows the OID to switch to ad-hoc. There is no error issued, but when you ask again, the device is still in managed mode. I'm not able to sniff the "pure air", i.e. the raw packets, and the counterpart at home is unfortunenately also still a Windows box which simple says that there is no other station around. Will keep on experimenting. Jan |
From: Giridhar P. <gi...@lm...> - 2004-05-24 18:15:05
|
On Mon, 24 May 2004 19:03:22 +0200, Jan Kiszka <jan...@we...> said: Jan> fixing NdisReadConfiguration() (must be case insensitive, see Jan> nocase.patch) and hacking some entries which are available Jan> under Windows, the problem still remains. Could you point which NDIS document says it should be case insensitive comparison? It seems to help, but we need to make sure we don't break other drivers in the process. -- Giri |
From: Jan K. <jan...@we...> - 2004-05-24 18:42:23
Attachments:
smime.p7s
|
Giridhar Pemmasani schrieb: > On Mon, 24 May 2004 19:03:22 +0200, Jan Kiszka <jan...@we...> said: > > Jan> fixing NdisReadConfiguration() (must be case insensitive, see > Jan> nocase.patch) and hacking some entries which are available > Jan> under Windows, the problem still remains. > > Could you point which NDIS document says it should be case insensitive > comparison? It seems to help, but we need to make sure we don't break > other drivers in the process. > Well, not stated clearly in the API descriptions. I think the registry paths are resolved just like any other Windows path - case-insensitive. I found an article on my MSDN CD about the Registry Editor. On sentence states: "The Registry preserves case as you type it for any entry but ignores case in evaluating the data. The names are case-insensitive." So, my patch should do no harm to any other driver which already work. :) Jan |