integrating user-space drivers and Intel WiMAX network service

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :/

> 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.

> 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 }
rfkill()
connect(NAP, EAP auth data)
disconnect()

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.








[Index of Archives]     [Linux Kernel]     [Linux Wireless]     [Linux Bluetooth]     [Linux Netdev]     [Linux Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux