Re: interactions between OLPC wifi and mesh interfaces



Hi,

> I'm a little stuck with one issue reimplementing the OLPC mesh device
> support.
>
> 1. When the user is connected to a standard network through eth0, and
> then they request a connection to a mesh network on msh0, eth0 should
> disconnect and go quiet before the mesh connection starts to happen.
>
> 2. When the user is on a mesh through msh0 and requests connection to a
> real network through eth0, the mesh should disconnect itself.
>
> How was this implemented in the NM-0.6 solution? It seemed to work
> there.
>
>
> For (1) I added code into stage1_prepare in the mesh device. It checks
> to see if the companion is activated, if so it calls
> nm_device_state_changed() to make it NM_DEVICE_STATE_DISCONNECTED.
>
> This almost works. I connect to an IBSS, and then the mesh. The above
> code disconnects from the IBSS and starts the mesh connection process.
> However NM is still treating the devices as separate, so very quickly it
> tries to look for a connection to apply to eth0 again. It finds the same
> one (which Sugar's settings implementation is advertising as a network
> that should be autoconnected to) and then we end up with a mess where
> we're trying to connect to a mesh and an IBSS simultaneously.
>
> Switching eth0 to NM_DEVICE_STATE_UNAVAILABLE didn't help, it just got
> back on its feet in the same way.
>
> Thoughts?

In the basic testing I've done on 8.2.1 I'm  not sure it disconnects
from the mesh when connecting to a standard network. I had problems
when connecting to my AP until I worked out I had to put the mesh on
the same channel as my AP. Once I did that I could connect to the AP
fine but the mesh channel still throbbed in the Neighbourhood to show
it was on that connection.

Peter


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]