libicd-network-wpa

Long story short: I'm releasing under the GPL an alpha-quality icd
network plugin which uses wpa_supplicant. Code is at
http://svn.javispedro.com/libicd-network-wpa/trunk/ .


After having bought a N810, I got hit very hard with #1635 (
https://bugs.maemo.org/show_bug.cgi?id=1635 , Eduroam (EAP-TTLS+PAP)
WiFi auth; apologies for my desperate message there) -- seeing it was
a "low" priority request by then, I decided I would try and fix this
by myself.
Searching through this list, I found a cx3110x patch which made it
compatible with wpa_supplicant, and some GPL-released icd headers
which made it possible to write a icd module.

What the module is doing:
- It replaces libicd-network-wlan & libicd-network-eap (I've defined a
new network_type, "WPA", whose only modules are wpa, ipv4 and ipv6) .
It does not replace wlancond though, I'm using it for powersaving.
- While searching, it initiates a wlancond-managed active ssid scan to
each of the configured networks.
- On link_up, it calls wlancond 'settings_and_connect' d-bus method to
initialize the interface and enable powersaving features.
- On post_link_up, it spawns wpa_supplicant, then uses settings from
gconf to configure it via D-Bus, then waits for it to enter state
"COMPLETED" (aka connected).
- On pre_link_down, it kills wpa_supplicant.
- On link_down, it calls wlancond's 'disconnect'.
- If It gets a "DISCONNECTED" event from wpa_supplicant, It sets up a
100 second timeout. If wpa_supplicant goes up again (roaming?) then
the timeout is removed. If it doesn't, then it tells icd to close the
connection.

How:
-Patched cx3110x. It is only partially patched so that it does still
work with libicd-network-wlan.
-Patched/"borked" wpa_supplicant. It now works with the partially
patched cx3110x, and also does active ssid scans OK.
-Patched wlancond. I needed a "I'm already reading wireless events by
myself, no need to bother me with d-bus events and no need to take
down the wireless interface for me, just set powersave" mode, which I
implemented.
- libicd-network-wpa.so .

Right now the code is on my private repository, at
http://svn.javispedro.com/libicd-network-wpa/trunk/ ,
but I might later create a garage project for it.
I'm new to Maemo (and glib, d-bus) development, with my previous
coding experience being mostly PalmOS development, so please pardon me
if my code is a mess. It was also born as (and it still mostly is) a
hack.

Now, the questions:
- Does this design seem OK to you?
- Some maemo applications seem to have WLAN_ADHOC & WLAN_INFRA
network_types hardcoded, and won't auto-download on connect event if
the current network_type is not one of those. The built-in mail
application comes to mind.
- I've yet to come with the right "rssi -> signal" formula, and I'm
having problems with the link_status callback. May I ask for better
documentation on this? I also don't understand what search_lifetime
and search_interval on network_api.h are for.

And I guess that's all I wanted to ask for. Thank you for your time.
Hope I didn't botch anything, and sorry for grammar issues.
And thanks Quim for looking at #1635 (at least Harmattan will get PAP
support out of the box!).

Hi,

On Mon, 2009-03-02 at 15:55 +0100, ext Javier S. Pedro wrote:
> Long story short: I'm releasing under the GPL an alpha-quality icd
> network plugin which uses wpa_supplicant. Code is at
> http://svn.javispedro.com/libicd-network-wpa/trunk/ .

Great work! Thanks for the network module!

> - On link_up, it calls wlancond 'settings_and_connect' d-bus method to
> initialize the interface and enable powersaving features.
> - On post_link_up, it spawns wpa_supplicant, then uses settings from
> gconf to configure it via D-Bus, then waits for it to enter state
> "COMPLETED" (aka connected).
> - On pre_link_down, it kills wpa_supplicant.
> - On link_down, it calls wlancond's 'disconnect'.
> - If It gets a "DISCONNECTED" event from wpa_supplicant, It sets up a
> 100 second timeout. If wpa_supplicant goes up again (roaming?) then
> the timeout is removed. If it doesn't, then it tells icd to close the
> connection.

> - Does this design seem OK to you?

This looks 100% correct from an icd2 point of view.

One thing you should add to the code: if you already have a WLAN
connection ongoing and icd2 calls the link up function again, make the
module reply with the ICD_NW_TOO_MANY_CONNECTIONS icd network status in
the callback. This makes icd2 (the framework) figure out that this
particular network is limited to one connection at a time and it also
makes switching from one WLAN to another work correctly. The
ICD_NW_TOO_MANY_CONNECTIONS status must be returned by every network
module (layer) that supports only one connection at a time in order to
keep icd2 on track of things.

> - I've yet to come with the right "rssi -> signal" formula,

Maybe a linear conversion could be good enough for starters, e.g. full
10 with the lowest rssi that can use 54Mbit and 1 when the only option
is 1Mbit?

> and I'm
> having problems with the link_status callback. May I ask for better
> documentation on this?

This one?

typedef void (*icd_nw_link_stats_cb_fn) (const gpointer
link_stats_cb_token,
const gchar *network_type,
const guint network_attrs,
const gchar *network_id,
guint time_active,
gint signal,
gchar *station_id,
gint dB,
guint rx_bytes,
guint tx_bytes);

The first gpointer and the 3 network_* parameters are the same as
received in the icd_nw_link_stats_fn. This of course assumes that the
network whose stats are queried is the one connected, but this is
handled by icd2 as long as the network module does not support more than
one connection at a time. The time_active you can set to zero, the ipv4
network module will handle it anyway. Signal is the rssi converted to
any of the ICD_NW_LEVEL_*, station id is the MAC address and dB the rssi
value. rx and tx bytes you can pass as zero, the ipv4 network module
provides them too. Unfortunately I feel like I'm repeating the .h file.
Please tell what more information you need.

> I also don't understand what search_lifetime
> and search_interval on network_api.h are for.

Search lifetime is the time in seconds the network is kept cached by
icd2, search interval is the time in seconds after which a new network
scan is to be triggered by icd2. With this setup not all networks need
to be found in every scan; this is especially true if search_lifetime =
2 * search_interval + the amount of seconds it takes to scan. icd2
checks that the search interval is less than the search lifetime when
loading your module.


HTH,

Patrik

2009/3/3 Patrik Flykt <Patrik.Flykt@nokia.com>:
> One thing you should add to the code: if you already have a WLAN
> connection ongoing and icd2 calls the link up function again, make the
> module reply with the ICD_NW_TOO_MANY_CONNECTIONS icd network status in
> the callback.

Hey, thanks! icd2 never tried to call link_up while the connection was
up during my so far two week "field test", but good to be on the safe
side.

>> and I'm
>> having problems with the link_status callback. May I ask for better
>> documentation on this?
>
> Please tell what more information you need.
>

I noticed the problem is that the UI is not calling the status
function upon clicking on the icd status bar icon. The "connection
status application" does indeed call my status function, but neither
the status bar "tooltip" nor the connection status application show
the "signal" bar.

Minor problem tough.

> Search lifetime is the time in seconds the network is kept cached by
> icd2, search interval is the time in seconds after which a new network
> scan is to be triggered by icd2.

Thanks again. Putting sane values there fixed a problem I had with icd
retrying the connection forever.



Right now the whole thing seems to work (I've been using it for two
weeks -- my biggest gripe is modest not autodownloading mail) but It's
difficult to distribute/install, as it requires replacing cx3110x.ko
a.k.a. flashing the initfs. I guess it would be possible to "hack"
wpa_supplicant (yet again) so that it works with the pristine
cx3110.ko, but I'm not a wireless-extensions guru.

In diablo (which I assume to be the targeted demographic as this is an icd2
plugin), you can "mount -o remount, rw /mnt/initfs". But you can also use an
cx3110x stored locally. "rmmod cx3110x; insmod <new cx3110x>; chroot
/mnt/initfs wlan-cal"

HTH

On 3/10/09, Javier S. Pedro
<javispeter+maemo@gmail.com<javispeter%2Bmaemo@gmail.com>>
wrote:

> Right now the whole thing seems to work (I've been using it for two
> weeks -- my biggest gripe is modest not autodownloading mail) but It's
> difficult to distribute/install, as it requires replacing cx3110x.ko
> a.k.a. flashing the initfs. I guess it would be possible to "hack"
> wpa_supplicant (yet again) so that it works with the pristine
> cx3110.ko, but I'm not a wireless-extensions guru.
>
>

Hi,

On Tue, 2009-03-10 at 23:08 +0100, ext Javier S. Pedro wrote:

> neither the status bar "tooltip" nor the connection status application
> show the "signal" bar.

Hmm, interesting. They should request icd2 once a second for the updated
status, which would make icd2 query your network module. Maybe there's a
bug/feature when the network has a different type from WLAN_*...

> Thanks again. Putting sane values there fixed a problem I had with icd
> retrying the connection forever.

Also interesting. Those should not have anything to do with retrying a
connection. Could you file a hopefully detailed bug report to Bugzilla?

> I guess it would be possible to "hack"
> wpa_supplicant (yet again) so that it works with the pristine
> cx3110.ko, but I'm not a wireless-extensions guru.

There's also the option of using the open source wl1251(sp?) WLAN
driver, but that one still needs love and nutrients in order to replace
the cx* one.

Cheers,

Patrik

ext Javier S. Pedro wrote:
> 2009/3/3 Patrik Flykt <Patrik.Flykt@nokia.com>:
>
>> One thing you should add to the code: if you already have a WLAN
>> connection ongoing and icd2 calls the link up function again, make the
>> module reply with the ICD_NW_TOO_MANY_CONNECTIONS icd network status in
>> the callback.
>>
>
> Hey, thanks! icd2 never tried to call link_up while the connection was
> up during my so far two week "field test", but good to be on the safe
> side.
>

IIRC, the link_up function will be called again if the user tries to
switch to another network (IAP) that uses the same net module. icd2
will try to connect to the new IAP before closing the connection to the
previous one. Maybe Patrik can correct me if I'm wrong.

--
Cheers,
Luca.

2009/3/12 Patrik Flykt <Patrik.Flykt@nokia.com>:
> Hmm, interesting. They should request icd2 once a second for the updated
> status, which would make icd2 query your network module. Maybe there's a
> bug/feature when the network has a different type from WLAN_*...

Some built-in apps are doing just that (strcmping network_type with
WLAN_). That's not a problem (I can choose a new network_type easily)
but applications explicitly looking for "WLAN_INFRA" are (e.g. 'grep
WLAN_INFRA /usr/bin/modest.launch' matches).

I will later try switching the module's network_type to WLAN_WPA or
something like that, and get a full list of applications with
hardcoded WLAN_INFRA/WLAN_ADHOC.

>> Thanks again. Putting sane values there fixed a problem I had with icd
>> retrying the connection forever.
>
> Also interesting. Those should not have anything to do with retrying a
> connection. Could you file a hopefully detailed bug report to Bugzilla?

My fault -- I originally put some _really_ large timeout there, so
even after having been disconnected, icd thought the network was still
there, and tried to connect again. I believe this is reasonable icd
behavior according to the description you gave me.



Thank you all for your answers -- the NIT is now a much more useful
device for me :) . I will open an ITT thread with install/usage
instructions for this someday.