#27 lost essid with marwell libertas

closed
nobody
None
5
2012-10-06
2006-11-18
psa
No

Controller:
Asus A8V-E Deluxe buildin: Marwell 88E8053/88W8000G

ndiswarpper 1.28 (gcc 3.4)

Driver:
mrv8ka51.inf from Asus download:
;===========================================================================
;
; Windows XP, 2000 NDIS driver INF for Libertas 802.11b/g Wireless
; Copyright (C) 2003 Marvell Semiconductor, Inc.
;
;===========================================================================
[Version]
Signature = "$Windows NT$"
Compatible = 1
Class=Net
ClassGUID={4D36E972-E325-11CE-BFC1-08002BE10318}
Provider=%MRVL%
CatalogFile=mrv8knet.cat
DriverVer=05/20/2004,2.3.0.19

Linux:
dist: debian sarge
kernel 2.6.14.1

Problem:
I need to use it in Ad-hoc mode (since no master available). Every time other members are closed down it looses essid i.e. it goes to off/any (so I need to set manually again). However I would like to keep it till I manually close the interface.

Suggestion:
When ever connection is closed (by the driver) and it is on ad-hoc mode and essid has been previously set (by iwconfig ioctl and stored in wnd->essid) and essid in the windows driver is lost (miniport_query_info(wnd, OID_802_11_SSID, ...) gives empty) it is automatically set again (miniport_set_info(wnd, OID_802_11_SSID,...) from wnd->essid).

This shouldn't break anything else, and, I believe, is more desirable behavior generally.

Enclosed is a patch that I made for myself. Should be ok, and works fine with me. There's also some essid debugin possibilities added.

Discussion

<< < 1 2 (Page 2 of 2)
  • Logged In: YES
    user_id=918798
    Originator: NO

    About the ndis driver. I understand. However window driver behavior
    shouldn't be the standard. I don't know if it is specified anywhere, but
    the native linux driver behavior should be the guideline. ndiswrapper is
    really an emulator.

    Hmm, really? Didn't know.

    It's job is to make the windows driver look like a
    linux driver.

    Thanks for the explanation. If only you told me this years ago, it would've helped me (and the project)!

     
  • psa
    psa
    2006-11-21

    Logged In: YES
    user_id=1261271
    Originator: YES

    Sorry, if I offended you. That sure was not my intention. I admit I was stating the obvious, and could have formulated it better. It was in the context of the argument I was making. In essence you were arguing that, since windows driver doesn't keep the values, the ndiswrapper might not to need to do it either. My point was, well you know what it was.

    Anyway I checked with Jean Tourrilhes (author and maintainer of the linux wireless extension API), and he confirmed that the desired behavior is keeping the values over disassociation (mail included on the bottom).

    The latest svn version works fine with me (except there was a typo in set_infra_mode():wnd->infrastructure_mode = prev_mode; I changed prev_mode to mode).

    But because of the 'keep values principle' I experimented with keeping the essid over mode change. And I thumbled into something else. Earlier I stated the the driver looped when changing mode casing iwconfig to go heyway. I now discovered that that was only part of the truth:

    First, If there is no other node in the corresponding mode with the same essid available, the windows driver resets essid to empty. So after the driver was set to managed, it kept trying to set essid to its previous value. Since there was no AP available with that essid, the windows driver kept reseting essid causing the driver loop till also wnd->infrastructure_mode was set. However this is essentially not the reason for for iwconfig going hayway.

    Secondly, there is a problem that is totaly independend of the matter of keeping essid, or any changes made for that. It was the delay for things happening:

    I took the original 1.28 source. Following happend:
    modprobe ndiswarapper
    -- here it automatically found an AP, and essid (not myessid) was set from line (this connection works)
    iwconfig wlan0 essid myessid

    and iwconfig goes heyway. I did the same with debuging on (2). Same thing happened. But the driver did not loop, it only sat in miniport_set_info() (obviusly while driver was trying to find AP with myessid).

    So next I added (to original 1.28 source) a delay in the end of set_infra_mode, and entered

    iwconfig wlan0 mode ad-hoc

    I tryed with all three:

    do{unsigned long i = 3000000000u; while(i--);}while(0);
    msleep(5000);
    msleep_interruptable(5000);

    All gave the same result, iwconfig went heyway. Actually I found out that it was not at all iwconfig that caused the output of newlines and shell printing loads of prompts. If I moved mouse over other xterm it happened there. Then I tryed entering 'iwconfig wlan0 mode ad-hoc' with mouse middle button without pressing 'enter'. Nothing happend. So for same reason if that ioctl takes longer, last pressed key starts to repeat. I found that problem occured only if the mleep was after

    res = miniport_set_int(wnd, OID_802_11_INFRASTRUCTURE_MODE, mode);
    

    Also it appears only the first time after loading the module. Something funny happens with interrupts.
    I will look at it farther.


    On Tue, Nov 21, 2006 at 01:02:12AM +0200, Pekka Sarnila wrote:

    Hi,

    It looks like you are pretty much defining the linux wireless API. Is
    there anywhere discription of the behavior behind the calls (besides the
    obvious).

    In particular I'm looking answer for the following question:

    If you set mode to ad-hoc and then essid, key, etc. Can you expect those
    values to remain after disassociation after last node closing, or do you
    need to restore them trough the API? I know, at least in some drivers
    they remain. But is it per driver/hw, or is there a rule? If not should
    there be?

    Pekka Sarnila

    Those values are permanent until you change them through the
    

    API, therefore they should remain after disassociation. But, as you
    mention, all driver/firmware seems to have quirks in ad-hoc mode,
    which are usually more problematic than just the value changing...
    Good luck...

    Jean
    

     
  • Logged In: YES
    user_id=918798
    Originator: NO

    In essence you were arguing that, since windows driver doesn't keep the values, the
    ndiswrapper might not to need to do it either.

    No, I didn't! I only said ndiswrapper can do somethings (that native Linux drivers do) and others it can't. I didn't say it doesn't need to.

    My latest patch (before I replied last) would clear essid, not change infrastructure mode.

    Before you hack more on this, please read NDIS to know what the Windows drivers expect and what they do. Otherwise, you (me, and users) will spend long time trying to get this working properly.

     
  • psa
    psa
    2006-11-22

    Logged In: YES
    user_id=1261271
    Originator: YES

    Ok, I misunderstood, sorry.

    Anyway, following I found out(happens both in the original 1.28 with no patches and latest svn):

    When first time after loading the module you do something (with iwconfig) that makes the driver to try to connect without succes, it stays inside miniport command for few seconds. If during that first ioctl after loading module it blocks for any reason during or after that call to miniport, keyboard interrupt is disabled till the ioctl returns to user.

    That's why the last key repeats:

    • command (iwconfig ...) is typed and enter pressed.
    • the 'enter key down' starts the command immediatly
    • miniport is called and blocks, and keyboard is disabled
    • the 'enter key up' does not come trough to X and X thinks enter key is still down
    • X start to generate key repeat (timer interrupt works) resulting newline repeating
    • miniport returns - ioctl returns
    • keybord interrupt is enabled, and 'enter key up' is delivered
    • X stops repeating.

    Otherwise command has done what it should.

    Following blocking ioctls do not block the keyboard.

    So there is some interrupt bug in the ndiswrapper.

    Since this has nothing to do with the original matter of this feature request, should a separate bug report be opened?

    As to NDIS, can you point me to docs.

     
  • Logged In: YES
    user_id=918798
    Originator: NO

    What is status about it? Does latest svn work for you or not?

     
  • Logged In: YES
    user_id=918798
    Originator: NO

    As I understand, the original issue has been fixed in SVN. If any other issues remain, file a new request.

     
  • psa
    psa
    2007-01-09

    Logged In: YES
    user_id=1261271
    Originator: YES

    In svn iw_ndis.c set_infra_mode() is still missing the line for updating wnd->infrastructure_mode. It is critically refered to in wrapndis.c link_status_handler(). After adding that, it works ok.

                        add_wep_key(wnd, wnd->encr_info.keys[i].key,
                                    wnd->encr_info.keys[i].length, i);
        }
    
    • wnd->infrastructure_mode = mode;
      TRACEEXIT2(return 0);
      }

    Ps my motherboard broke down (fan stopped and over heated), so can't test any longer. But need for above change I had tested before it happened.

     
<< < 1 2 (Page 2 of 2)