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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
