Setting up the mesh device

[Dan Williams]

On Tue, 2008-06-24 at 19:42 +0100, Sjoerd Simons wrote:
> Hi,
> 
>  I'm currently working on adding support for the olpc mesh device to NM 0.7.

I feel sorry for you :)  In some ways 0.7 has made it a lot better for
you (concurrent device support) and in other ways it's made it a bit
harder (more encapsulation of devices due to a well-thought-out object
model).

>  From what i understand from David Woodhouse we should be able to really use
>  it as two seperated devices these days (with the obvious constraint that it
>  shares the radio ofcourse). Some testing shows that i can indeed use the mesh
>  while the eth0 is completely unconfigured.
> 
>  Now when configuring the msh0 device NM 0.6 does the following:
>    0. Set eth0 in ad-hoc mode
>    1. Set eth0's essid to olpc-mesh
>    2. Wait for an association event on eth0
>    3. Continue with ip configuration.

It was done on eth0 because at the time it was implemented, common
attributes were defined to be set on ethX and were removed from mshX
entirely.  Due to discussions late last year, they got added back to the
mshX interfaces, but there was no functional break and thus no need to
update NM.

You can now set the parameters directly on the mshX device.

>  Which makes me wonder about the following things:
>    * Why is the eth0 device set in ad-hoc mode?

See above.  Should need this any more, the mesh device should be set
adhoc now instead.

>    * In what way is the olpc-mesh essid special for eth0?

It's not, but setting an SSID is the way in WEXT that you say "do this
all for me".  So the card will technically not be set up how you want it
until you set the SSID.  You can simply set the SSID on the mesh
interface now and not on the eth interface.

>    * What's the actual meaning of the association event on eth0 for the msh0
>      and why should we wait on it. And if it's important, why is this event on
>      eth0 instead of msh0 ?

You need to wait for the association event before going ahead with any
additional configuration, because that's the signal that the firmware
has joined the right IBSS and that it's set up to send and receive
traffic.  I don't know offhand if the firmware sends the association
event on the mesh interface these days; it used to, and it should, if
the SIOCSIWESSID command is done on the mesh interface.  If it doesn't
do this, then the driver should be changed to fix that and ensure that
commands sent to the mesh interface return events there and not on ethX.

Dan