? Fri, 05 Mar 2010 22:32:20 -0800 Dan Williams <dcbw at redhat.com> ?????: > 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? I don't think so because it doesn't send any NAP ids to device. > 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. It's the second case. -- 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/20100311/fb8b9e83/attachment.pgp>
