A (very) brief tour of the OLPC 802.11s device class in NM r3246

Mon Aug 4 09:29:39 EDT 2008

On Mon, Jun 16, 2008 at 11:11:13PM -0400, Michael Stone wrote:
> Sjoerd and I started dissecting our NM-0.6 divergence so that we can
> begin porting that necessary pieces of that divergence to NM-0.7.
> Several highlights from our reading of two important files follow.
> NM-specific terminology is /emphasized/.

I found this email very helpful.  Thanks for sending it.

>   * The flag-file MESH_STEP_FILE (/etc/NetworkManager/mesh-step)
>     which can be used to alter the initial state of the aforementioned
>     connectivity state machine.
>         http://tinyurl.com/4ltm2u

Thanks for pointing this out.  The filename is actually
/etc/NetworkManager/mesh-start , in case people don't follow the link.

To highlight the import of this file, basically every time your XO
wakes up from sleep NM is going to start looking for a school server
unless this behavior is overridden by the contents of this file.  The
file is read wheneven NM is started.  If you're G1G1 like me, you've
not got a school server but you have plenty of APs[1].  If you do:

cat > /etc/NetworkManager/mesh-start <<EOF
infra
EOF
/etc/init.d/NetworkManager restart

...at a shell prompt, then you'll tell NM to look for an AP first,
when it wakes up.  This will save you 60 seconds (20 per each of 3
mesh channels tried) when you resume and NM wakes up the network[2].

There is unfortunately one disadvantage: this doesn't work.  I mention
this to save others the hassle of finding it out for themselves, but
as we are going to NM 0.7 very soon I don't think we'll want to fix
them (so I haven't opened any tickets).

The first problem is that doing what I mention above doesn't actually
save you any time, for some unknown reason[3].

The second problem is that NM will crash (in
real_act_stage3_ip_config_start() line 2024) if you have put "infra"
in the file and then try to activate the mesh with a specific channel.
I don't know why, but after a quick scan for "self->priv->step" in
NM's olpc-specific code I quoted Michael's mention of above, I find
line 1772 to be suspicious, as well as line 2226.  But I really can't
see the wood for the trees on this one, but I know I can get my NM to
segfault[4] :).

I look forward NM 0.7 when I can tweak the NM state machine in this
promising way.  We might consider making this setting the default for
G1G1 machines/builds if we can get it to work.

> Michael

Martin

1. Future Sugar Control Panel option?

2. I'm not sure why we have NM re-doing its scan process after resume,
given the goal of having the mesh / radio active during sleep, but I'm
sure it's been thought out.  I can think of pros and cons.

3. I'm sure someone more au fait with NM could tell more quickly than
I.  I can see from /var/log/messages that "infra" is parsed correctly
(and I can tell from [4], too), but we start off with msh0 activation
anyway.  I'd post the logs if we weren't going to NM0.7 soon.

4. It looks kind of like this (note the -1 is because we haven't
specified a mesh_step in the dbus call, which would probably work
around this issue (clearly any non-2 step would be fine)):

Aug  2 21:45:06 xo NetworkManager: <info>  User Switch: /org/freedesktop/NetworkManager/Devices/msh0, channel 6, step -1
Aug  2 21:45:06 xo NetworkManager: <info>  Deactivating device msh0.
[...shutdown of existing interfaces omitted...]
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) started...
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) Stage 1 of 5 (Device Prepare) scheduled...
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) Stage 1 of 5 (Device Prepare) started...
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) Stage 2 of 5 (Device Configure) scheduled...
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) Stage 1 of 5 (Device Prepare) complete.
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) Stage 2 of 5 (Device Configure) starting...
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0/mesh) level 2: Infrastructure AP.
[...previous line looks weird to me because of the "msh0/mesh" appellation...]
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0/mesh) Stage 2 of 6 (Device Configure) looking for a mesh on channel 6.
Aug  2 21:45:06 xo NetworkManager: <info>  Activation (msh0) Stage 2 of 5 (Device Configure) complete.
Aug  2 21:45:07 xo kernel: [56505.516355] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug  2 21:45:09 xo kernel: [56506.889928] ADDRCONF(NETDEV_CHANGE): msh0: link becomes ready
Aug  2 21:45:09 xo NetworkManager: <info>  msh0: Got association; scheduling association handler
Aug  2 21:45:09 xo NetworkManager: <info>  msh0: got association event from driver.
Aug  2 21:45:09 xo NetworkManager: <info>  Activation (msh0) Stage 3 of 5 (IP Configure Start) scheduled.
Aug  2 21:45:09 xo NetworkManager: <info>  Activation (msh0) Stage 3 of 5 (IP Configure Start) started...
Aug  2 21:45:09 xo NetworkManager: <info>  msh0: real_act_stage3_ip_config_start():2023 unhandled step 2
Aug  2 21:45:09 xo NetworkManager: <WARN>  nm_signal_handler(): Caught signal 6.  Generating backtrace...
[...ugly backtrace follows...]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080804/cfb10044/attachment.sig>