Sorry for the delay... ? Tue, 09 Feb 2010 13:49:53 -0800 Inaky Perez-Gonzalez <inaky.perez-gonzalez at intel.com> ?????: > On Tue, 2010-02-09 at 15:29 +0300, Alexander Gordeev wrote: > > Hi Inaky, > > > > On Mon, 08 Feb 2010 14:47:31 -0800 > > Inaky Perez-Gonzalez <inaky.perez-gonzalez at intel.com> wrote: > > > > > > > > Hello Alexander > > > > > > On Sun, 2010-02-07 at 03:55 -0700, Alexander Gordeev wrote: > > > > > > > I'm the author of madwimax > > > > (http://code.google.com/p/madwimax/). I was thinking about the > > > > future of my project :) and it seems that the only way forward > > > > is to integrate it into the Linux-wimax stack somehow: > > > > > > > > * by porting drivers to the kernel > > > > > > > > It's good but it will effectively prevent people from using > > > > drivers on some wireless routers with an old 2.4 kernel which > > > > is very popular now. > > > > > > Geee .. 2.4 :) > > > > Kudos goes to Broadcom and their binary blobs :) > > > > > > * by allowing user-space drivers to be managed by Intel WiMAX > > > > network service > > > > > > > > Is there any opportunity for this? AFAIK, it uses D-Bus, so > > > > adding some D-Bus interface for user-space drivers would be not > > > > very hard, right? > > > > > > Well, this code is extremely Intel specific and the long term plan > > > would be to ditch it in favor of a generic service. However, that > > > is currently in the "until somebody has time to work on it", as > > > no other devices are coming forward with need for support. > > > > OK, thanks for this info! > > Then the user-space port will only remain for wireless routers and > > we'll move to the kernel. > > > > > That said, it'd be extremely difficult to modify it to work with > > > your driver. How high is the mad driver in the stack level? Does > > > it connect to NAPs or to NSPs? > > > > Well, from what I've seen so far the dongle supports only > > connecting to NSPs. :( This device is still a black box. However, > > other devices are coming. > > Can you give an outline of the HCI of the device? We need to design a > new kernel API for managing NSP-based devices then. The one I have in > the op_nap_scan branchs is for NAP-level devices. Well, it sends and receives data through two bulk pipes. Sending and receiving data is asynchronous. I.e. one can send n request and then receive n responses. Requests and responses look like this most of the time: header, major number, minor number, data length, data. Response always has the same major number as the request and minor number is requests minor + 1. So you don't have to keep requests to analyze responses. Initially my driver reads some valuable info like MAC-address, chip and firmware info, authentication method (this means in fact two values: auth policy = 0x22 and auth method = 2 - and I don't know what these values mean). Than it sets SSID to connect to (@yota.ru usually) and tries to connect. When it passes states SYNC->NEGO->NORMAL the associated tap interface is enabled and you can start to send packets. Packets look like this: header, full Ethernet frame. One packet always goes in one bulk transfer. Of course, this is not a full description. There are other small details. -- Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: <http://lists.linuxwimax.org/pipermail/wimax/attachments/20100213/26405544/attachment.pgp>
