NWA Development and Sources?

[D. Gassen]

Sorry for the late answer... I was trying some stuff...

On Mar 11, 2010, at 19:22 , Nicola Mfb wrote:

> [...]
>>>> I really like the concept of it (love it, actually) but not being able to connect to WEP "secured" networks is not that great. I cannot find any sources for it.
>>> 
>>> Are you able to connect to your WEP network using wpa_supplicant
>>> manually? in that case NWA should work or it needs a trivial fix.
>> 
>> I do get
>> 
>>> AppletController "Cannot set network options
>>> Did not receive correct message arguments."
>>> Unaccepted options: QMap(("key_mgmt", QVariant(QString, "WEP") ) ( "priority" ,  QVariant(QString, "0") ) ( "ssid" ,  QVariant(QString, "bishop") ) ( "wep_key0" ,  QVariant(QString, "**************************") ) ( "wep_key1" ,  QVariant(QString, "") ) ( "wep_key2" ,  QVariant(QString, "") ) ( "wep_key3" ,  QVariant(QString, "") ) ( "wep_tx_keyidx" ,  QVariant(QString, "0") ) )
>>> AppletController cannot add network QVariant(QString, "GWN") QVariant(, )
> 
> Thats a dbus error reply from wpa_supplicant.
> Just guessing (I cannot check now) try to remove empty wep keys from
> .nwa.conf, or in general remove from it pair values in "Unaccepted
> options" that are not present in your wpa_supplicant.conf.

Ok, I tried the following:

1. Removed the attributes wep_key1, wep_key2 and wep_key3 in .nwa.conf

2. Set the attributes wep_key1, wep_key2 and wep_key3 to the same value as wep_key0 in .nwa.conf

3. Moved my /etc/wpa_supplicant/wpa_supplicant.conf out of the way

None of these, unfortunately, did make any difference.

Could it maybe be because I give the key as a hex string (26 characters)? Do I have to prefix it with something to indicate it's a hex string? (I tried "0x..." but that didn't work either)

Btw, is there *any* documentation on the dbus interface of wpa supplicant? The only thing I could find was this statement:

> The wpa_supplicant dbus interface isn't particularly well documented [...]

> [...]
> 
>> I do actually have problems with the ar6000 driver if I do *not* blacklist it (in /etc/modprobe.d/blacklist). I do see kernel panics in the syslog and Wifi usually does not work (fsoraw fails to aquire the WiFi resource and I don't get the eth0 interface). I *seem* to have less problems if I load the driver later manually.
>> 
>> I am running andy-tracking 3db70757d6fabb17 with my own config (DEBUG options disabled) but I have the same results with the current kernel from SHR-U. Is that aforementioned patch included?
> 
> Not yet.

Paul's patch did make a big difference in the stability of the driver, however, I also needed
Hm, blacklisting didn't help. The driver stopped working for me later that day. It seems that Paul's patch made the driver more stable once it's working (have yet to see a PANIC).

The problem that I encountered with the ar6000 driver seems to be described here:

> http://docs.openmoko.org/trac/ticket/2327

and when I added the suggested patch the driver loaded pretty well.

Dirk



> 
>    Niko
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community