On Tue, Jun 24, 2008 at 02:56:15PM -0400, Dan Williams wrote: > 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 :) Thanks, i guess :)
> 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). For the most part it seems a lot easier then it was in 0.6 and i don't seem to actually have to break down the seperation too much. Also i'm trying to move all of the policy work out of NM itself, which should make some things a lot easier. > > 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. > > > 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. The mesh device replies Invalid argument if you do that. But there seems to be no need to switch modes on the msh0 device, so that's fine. Changing frequencies on the msh0 device instead of the eth0 device seems to confuse things somewhat. http://dev.laptop.org/ticket/5481 has the details :( > > * 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. I'm setting the ESSID on the msh0 interface indeed. But i never get an association event on it.. While i even get an association event on eth0 when it's not up (but with msh0 being up obviously) :) Seems i've got some more bugs to file Thanks for the explanation! Sjoerd -- Ya'll hear about the geometer who went to the beach to catch some rays and became a tangent ? _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
