On Sat, 2010-02-27 at 20:20 +0300, Alexander Gordeev wrote: > On Fri, 26 Feb 2010 10:33:17 -0800 > Inaky Perez-Gonzalez <inaky.perez-gonzalez at intel.com> wrote: > > > 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... > > No problem. I'm not good in WiMAX terminology in fact. > BTW do VNO and NSP ID mean the same? Maybe you can point me to some > good overview of these terms? I've found this thread: > http://www.mail-archive.com/wimax at linuxwimax.org/msg00735.html > > It tells that there are 3 entities: NAP, NSP and VNO. So "@yota.ru" > is a VNO? Interesting... > > > > > > 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? > > Well, sort of. I can try to connect. :) > BTW the connect operation splits in two parts: > * sync to the BS (i.e. connect to NAP) > * negotiate about the connection (i.e. connect to NSP) > > These are two separate requests. But I don't gather any additional info > between them. Dunno if this can help. > > > > > 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. > > Ok. > > > > > 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... > > Right, I only send "@yota.ru" and start to connect. So I've got my dongle now (thanks!). Do the Yota drivers have some sort of file of accepted NAPs? Obviously in Windows the Yota connect program doesn't find Clear (the local 2.5GHz WiMAX provider) but what I'd like to know is whether that's a limitation of the Windows connection manager or whether the device needs to be told to look for a different provider. Any idea? I'll be poking around with it in Linux pretty soon. Dan
