On Fri, 2010-02-26 at 04:47 -0800, Alexander Gordeev wrote:
> On Thu, 25 Feb 2010 10:37:47 -0800
> Inaky Perez-Gonzalez <inaky.perez-gonzalez at intel.com> wrote:
>
> > On Sat, 2010-02-13 at 05:18 -0800, Alexander Gordeev wrote:
> > > Sorry for the delay...
> >
> > I'll join you there, got my brain split in many different areas now...
> >
> > > ? Tue, 09 Feb 2010 13:49:53 -0800
> > > Inaky Perez-Gonzalez <inaky.perez-gonzalez at intel.com> ?????:
> > >
> > > >
> > > > 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
> >
> > Could be EAP official methods...no, they look to weird (22 is not RFC
> > registered, 2 is EAP_NOTIFICATION). Magic :/
>
> Yes, this is most likely an index in some internal table in modem's
> firmware.
>
> > > values mean). Than it sets SSID to connect to (@yota.ru usually) and
> >
> > Oh, so that's the authentication realm; it's used in a more extensive
> > way as an SSID. The true "equivalent" off SSID in WiMAX would be the
> > NAP-ID, and then each NAP provides service for one or more
> > authentication realms (VNOs), yota.ru in this case.
>
> Well, I quite understand you. :)
> I don't remember when and why we first called this "SSID" so it's a
> jargon word in this case.
Sorry :/ I should have known...
> > > 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.
> >
> > I guess from the generic API point of view I am more interested on how
> > can we map the high level operations, which are:
> >
> >
> > scan() -> { list of NAPs / VNOs }
>
> Too bad but I still don't know how to do this. :(
> The official client software doesn't request any scan operations.
> Firmware disassembling showed that it is possible but we still can't
> make it work.
Well, then this would be stubbed -- hi, I take scan operations and I
only fake a of a single network.
Do you have a way to detect network presence?
> > rfkill()
>
> Same thing here. Firmware disassembling showed a lot of possibilities
> but we don't know how to use them.
Then it can be reported as always on. Not a problem, although ugly for
management purposes.
> > connect(NAP, EAP auth data)
>
> Seems there is no way to set NAP ID currently. EAP auth data is what we
> discussed above and there is also a request to connect to network.
Actually, I meant NSP, or a VNO...so when you tell it to connect, you
don't have to specify any NSP ID? just "connect" and it figures it out
and then uses the realm in EAP to select a VNO? Interesting...
> It always authenticates user using the dongle's MAC address.
That sounds like Clearwire, that's nice :)
Thanks
