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.
> > 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.
> rfkill()
Same thing here. Firmware disassembling showed a lot of possibilities
but we don't know how to use them.
> 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.
> disconnect()
Yes, this is available too.
> then the interactions with the authentication agent; standard-wised,
> the VNO selection is done once we connect to a NAP and when EAP is
> started and we say our NAI (myuserid at REALM). However, in your HW it
> seems it takes that before hand.
It always authenticates user using the dongle's MAC address.
--
Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.linuxwimax.org/pipermail/wimax/attachments/20100226/55bbaad9/attachment.pgp>
