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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel