Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#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

  • psa
    psa
    2006-11-18

    diffs for a patch

     
    Attachments
  • psa
    psa
    2006-11-19

    Logged In: YES
    user_id=1261271
    Originator: YES

    Don't use the ndis.diff. It was lacking some checks to prevent syncing essid to cause driver to loop or hang when mode was changed from ad-hoc to managed, or unloding the driver, while essid being other than off/any.

    That is fixed in ndis2.diff enclosed.

     
  • psa
    psa
    2006-11-19

     
    Attachments
  • Logged In: YES
    user_id=918798
    Originator: NO

    I committed a much cleaner / simpler version to svn. Test that and give feedback.

    I am not sure if this interferes with other drivers. I think it should be possible to implement this in user space, instead of in ndiswrapper, so I may remove this patch before releasing it. I am not aware of any user space application that can set essid when association is lost. But you may want to take look at iwevent and adapt it for your needs.

     
  • Logged In: YES
    user_id=918798
    Originator: NO

    Another reason for not going ahead with this: If the node uses encryption, simply setting essid is not enough - keys must be restored, as Windows driver throws away keys. It is possible to set the (WEP only?) keys along with essid; not sure what other implications this means.

     
  • psa
    psa
    2006-11-20

    diff against svn

     
    Attachments
  • psa
    psa
    2006-11-20

    Logged In: YES
    user_id=1261271
    Originator: YES

    No good yet.

    If in ad-hoc mode and 'carrier_ok' you run 'iwconfig wlan0 mode managed' following happens. In 'set_infra_mode' the mode is set first by 'miniport_set_int(wnd, OID_802_11_INFRASTRUCTURE_MODE, mode);'. That trikkers immediatly NdisMIndicateStatus -> wrap_ndis_worker -> link_status_handler. Since 'wnd->infrastructure_mode' has not yet changed the 'set_essid(wnd, wnd->essid.essid, wnd->essid.length);' is called causing driver to loop. iwconfig goes hayway: shell prints plenty of prompts.

    There are three possible fixes:

    1. Lookup the mode also from windows driver (miniport_set_int(wnd, OID_802_11_INFRASTRUCTURE_MODE,...))

    2. Change 'set_infra_mod()':
      tmpmode = wnd->infrastructure_mode;
      wnd->infrastructure_mode = mode;
      res = miniport_set_int(wnd, OID_802_11_INFRASTRUCTURE_MODE,...);
      if(res) {
      wnd->infrastructure_mode = tmpmode;
      ...
      }

    3. set wnd->essid empty in set_infra_mode before changing mode.

    Since 3. is clearly better than my 'closing' flag when unloading, it would seem the best way here too.
    Actually it should be emptied anyway whenever mode is changed. Diff enclosed.

    As a note: in case of line causing disassociation, without the code in NdisMIndicateStatus

        case NDIS_STATUS_MEDIA_DISCONNECT:
    

    --> if (!netif_carrier_ok(wnd->net_dev))
    --> break;
    netif_carrier_off(wnd->net_dev);

    the driver would loop if setting essid is attemted before 'windows driver essid' is empty. Since that piece of code does not exist in 1.28, I added that check. But now it isn't needed.

    As to whether to keep this fix here or in userspace. I don't like the idea of userspace. First, the native linux wifi drivers (at least the ones I have used) do not loose essid even with last node disassociating. Second, it would require some new kind of iwdaemon that would be needed only in some cases. Third, in order to avoid the problems similar to discussed above, iwconfig should communicate with that daemon or some strange trikkery should be added to the driver. And how about the unloading the module while such deamon would be running. It would seem a new event should be added to the driver for that. And lastly, I think there are many who would like to have their local wireless network, as I do, so that the desktop linux machine is setup as a router for (a) laptop(s) without needing open the connecttion manually on the desktop, and to whom security by fixed ip-addresses and key is enough. Since there are plenty of motherboards using wifi chips that have only ndisdriver (working with ndiswrapper) and thus no master mode, this sollution is the only way. Requiring installing and configuring some extra daemon would unnecessarily complicate the setup.

    This fix here is so much simpler.

    In case emptying essid is a feature of only some ndis windows drivers, it might be good the have the driver also check if the essid has actually been lost (as in my suggestion) to avoid unnecessary action with ndis drivers that don't loose it.

     
  • psa
    psa
    2006-11-20

    Logged In: YES
    user_id=1261271
    Originator: YES

    I'm using keys. No problem, key is not lost!

     
  • Logged In: YES
    user_id=918798
    Originator: NO

    I first committed patch to remember/set infrastructure mode and later with resetting essid. Let me know if latest svn works.

    Just because your driver doesn't clear keys doesn't mean all drivers won't. NDIS says drivers should clear keys after disassociation. This is why fixing this in ndiswrapper is not quite correct and that is why I am not sure I will keep this. First of all, if any drivers have issues with this, I have to drop it. Some things can be emulated in ndiswrapper as per Linux drivers, others can't be.

     
  • psa
    psa
    2006-11-20

    Logged In: YES
    user_id=1261271
    Originator: YES

    Ok, I'll try it tomorrow (no time today).

    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. It's job is to make the windows driver look like a linux driver. Though I'm afraid it is insidental firmware behavior that determines it in real life. Still, I like the concept of kind of ad-hoc "AP".

     
  • 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.