It is currently Wed Dec 12, 2018 2:38 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Dec 02, 2018 12:25 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
Oops, I've found a logging error where 3-step WINDOW-read had collided with a WMI-event:
Code:
   bad:
Read  Mem[00520001] = 00520000                    ;this is a logging error (the 3-step MemRead had collided with REGDOMAIN event)
Read  Func[1:00400] = Len:0001x0010 00 00 04 00 0F 00 0F 00 00 00 00 00 00 BC 1A 91
Read  Func[1:00474] = Len:0001x0004 A0 B2 52 00   ;this is final step of above mis-logged MemRead
Write Mem[0052B2A0] = 00000002
   correct:
Read  Mem[005200...                               ;ReadMem addr.msbs (then gets interrupted by event...)
Read  Func[1:00F80] = Len:0001x0080 01 02 0E 00 08 00 06 10 48 03 00 80 02 06 00 00 00 00 00 00   ;REGDOMAIN event
Write Func[1:0047C] = Len:0001x0001 00            ;ReadMem addr.lsb ;[......00]
Read  Func[1:00400] = Len:0001x0010 00 00 04 00 0F 00 0F 00 00 00 00 00 00 3C 1A 11
Read  Func[1:00474] = Len:0001x0004 A0 B2 52 00   ;ReadMem data  ;Mem[00520000] = 0052B2A0
Write Mem[0052B2A0] = 00000002

The problem happened only in that one location, and no idea why Nintendo/Atheros had interrupted the read, it wouldn't make much of a difference to process the event after completing the read.

The good news is that everything up to including the above event & mem accesses are same as wifi initialization in launcher - which is already implemented in unlaunch, so I've cleaned up the unlaunch code a bit, and then I can re-use it in wifiboot.

Two small differences that I have spotted are (probably more related to AR6002 vs AR6013, rather than Launcher vs Browser):
With Launcher/AR6002, I had observed WLAN_SYSTEM_SLEEP [0040C4h]=1Ch/1Dh, but in Browser/AR6013 it's 0Ch/0Dh, maybe the bit4 is initially zero (or completely missing) in newer hardware.
With Launcher/AR6002, I got REGDOMAIN value 80000188h, but Browser/AR6013 gets 80000348h. With that difference, it's more clear what the value is supposed to mean (in the wifi firmware "RGBD" DataSet, 0188h is "JP" and 0348h is "US") (which is both wrong because I am elsewhere, and I have a european console anyways; also, the REGDOMAIN is thrown only after initialization, ie. there is no further such event with actual country code after connecting to an access point) (bottom line is that they must have hardcoded the firmwares with random country codes... or stored random country codes in the wifi EEPROM).

After the above stuff, Launcher is sending a WMI_SET_SCAN_PARAMS_CMD for whatever reason, and does then complete the wifi init by disabling wifi IRQs.

And the Browser is instead sending four other WMI commands, and then repeatedly sends six WMI commands (per channel scanned) until receiving a beacon matching to the access points in system settings. At that point it's sending a dozen more commands for connecting to the access point.
That's all looking very simple (much easier as for NDS wifi, where one had to construct the scanning/connect managment frames manually).

And if that's working, next would be exchanging four DHCP data packets. And if that's working... ideally, all other data packets might be already working, too - and the project would be finished (much earlier than expected).
On the other hand, things like error handling and retries might cause unexpected extra troubles, so it might take some more weeks/months until everything is stable.


Top
 Profile  
 
PostPosted: Tue Dec 04, 2018 11:43 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
Things are getting better, and worse.

The good thing is that I've got a better understanding of the MBOX Transfer headers.

Leaving apart the initial six handshakes: All further MBOX blocks with [00h]=00h are essentially ACK's for confirming that one has written a Command or Data packet (or maybe confirming that it was written AND processed).
That feature appears to be optional, depending [01h] of the written Command/Data. If it's 00h then no ACK is generated, if it's 01h then one ACK is generated for Commands, and - oddly - two ACKs for Data.
For Commands it's always [01h]=01h (=want ACK), but it might be possible to disable ACKs via [01h]=00h (not tested yet).
For Data it's sometimes [01h]=01h, and sometimes [01h]=00h, even for identical data packet types (eg. some http GET's are sent with ACK requested, and other http GET's without).

The bad thing is BYTE[04h] of received stuff is containing a Length of Extra Data appended at the end of the MBOX. This is usually 08h or 0Ch bytes (or maybe 00h exist, too, don't remember exactly).
For example, one can see that in WMIX_HB_CHALLENGE_RESP_EVENT, the event parameters have fixed length (8 bytes). But the total length at [02h] varies (0016h or 001Ah), and the extra length varies accodingly (08h or 0Ch).
That extra data does usually (or always) start with 02h,06h. And it's then followed by 6 or 10 bytes with whatever content.

Discovering those unknown purpose extra bytes is a bit unpleasant. I had just thought that I had understood the protocol - and then that! : /

The BYTE[05h] of received stuff might be some flags (or a negative value?). One theory is that one of the flags might indicate that the MBOX contains at least one more packet(s) - so one could issue further MBOX reads until the flag goes off.
At least the log does look a bit like that (there are some continous MBOX reads without checking the [1:00400] status bytes). Other theory would be that the ARM-CPU-IRQ flag is checked instead of [1:00400], but I think IRQ acknowledges should be then visible in the log.

I've also started looking at the old NDS wifi source code. It's mostly the ARM7 code that would need to be changed for DSi wifi. And at least half of that code could be probably completely removed. The trick would be not to remove important & still needed parts.
And the other issue is that most of the NDS code is IRQ driven - which is good - but it's also making the program flow a good bit more confusing (as opposed to a much easier design like using a simple loop for channel-scanning, followed by a mainloop for forwarding data to ARM9).


Top
 Profile  
 
PostPosted: Tue Dec 04, 2018 1:33 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
PS. Here's a newer version of the wifi-log.txt file, with several annotations, and with 80h-byte padding removed in most cases (at least in the first half of the log) (some of the larger data packets still have the padding, and the DBGLOG events do so, too).
Attachment:
wifi-v2.txt [249.99 KiB]
Downloaded 6 times

EDIT: Grumph, some of the scanning events contain "01 00 xx xx FF FF 04 10 ..." in MBOX.
That's with [04h]=FFh, in that special case [04h] is apparently something other than length of Extra Data.


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 10:20 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
I've implemented channel scanning and access point connection in past some days. The first thing done was removing the whole ARM7 code from wificode/dswifi, as well as W_xxx constants for the NDS-WIFI hardware registers. That worked surprisingly well, throwing only a few errors on missing 'public' functions/constants:
Code:
  arm7_installWifiFIFO
  arm7_wifiValue32Handler   ;this includes Init (from ARM9 via FIFO)
  arm7_Wifi_Update
  arm7_Wifi_Deinit
  arm7_Wifi_Interrupt
  IRQ_WIFI (add IRQ2_DSI_WIFI, and don't forget adding IRQ2_ALL)
For the DSi, I've made a new "Init" function, it's basically a copy of the wifi init code from unlaunch, except without wifi firmware uploading in the BMI stage. However, I guess I can remove that whole stuff in final version as unlaunch (or launcher) are already doing the same initialization, so it would be pointless to repeat the same initialization in the .dsi title (although the DSi browser is doing right that, but pointless is a also good term to describe the DSi browser after all).

Next, I've sent a few WMI init commands (as done by the browser), and then the WMI commands for channel scanning, and passed the scanning's WMI events to the old ARM7 code (here resurrection a code snipped from the removed ARM7 stuff). That worked so well that the ARM9 did display the name of my access point right away (which I am still buffled about, I didn't even have had the Wifi_Update function implemented at that time, which, I thought it were needed to setup some state variables for being in scanning mode).

Then I've added WMI connect commands, and changed them to use the channel number and access point details from the scanning steps (and matching wifi password from wifi FLASH memory). And learned some things alongsides:
-- Connect error (eg. bad password) throws DISCONNECT event (instead of CONNECT event).
-- My DSi has only channel 1-11 enabled (trying to scan channel 12,13,14 via SET_CHANNEL_PARAMS throws CMDERROR event).
-- WEP uses only key0, but seems to require dummy CIPHER values for WEP key1-3 (else CONNECT throws ERROR_REPORT event).
-- Receiving data/events bigger than one 80h-byte-block does require "CMD12" enabled in SDIO_STOP_INTERNAL_ACTION bit8 (although, CMD12 shouldn't actually exist for SDIO; ie. the bit probably rather means "stop at end" than literally sending CMD12 in this case).

Obscure 8 or 12 bytes appended at the end of the received data:
The 8 bytes are containing lookahead for the next MBOX packet (so one won't need to manually read the RX_LOOKAHEAD0 register). That's good for knowing if one can read another MBOX packet right away (and also for knowing the length of that packet). The 8 bytes are "02h,06h, AAh, lookahead[4], 55h". If there's no lookahead available yet, then the 8 bytes are often appened nonetheless, but with 00h/00h instead of AAh/55h (and with garbage[4] instead of lookahead[4]).

The other 4 bytes (the first 4 bytes when having 12 bytes appended) contain ACK info, either cmd.ack or data.ack. I am not entirely sure what is ack'ed there (cmd/data received, or cmd/data received AND processed AND delivered). But... whatever it's meant to mean... I am taking it as confirmation that one can send more cmd/data after the corresponding cmd.ack/data.ack. That's useful because the Function 1 status registers contain a lot of info on RX state (flags, lookahead, etc), but little info on TX state (I've merely found a TX overflow flag, which would mean that one would NEED to send data for determining if an overflow would occur).

The length of above 8 or 12 bytes is indicated as [04h]=08h or [04h]=0Ch. And, unlike as one might expect, absence of that bytes isn't indicated by [04h]=00h. Instead, that's indicated as [01h]=00h and [04h]=garbage. Which, I think it's really just garbage, it's often [04h]=00h, or sometimes [04h]=FFh, and I've even seen [04h]=5Eh once.

Next stuff on Todo list
Scanning and connection are working fine so far (and they are meanwhile already done on IRQ level). Next will be forwarding Data packets to/from ARM9. I hope to get that working tomorrow (or even today). It looks easy enough, the main issue is parsing the MBOX headers to NDS-style headers for the ARM9 code. The extra obstacle is that ARM9 packets are stored in ring-buffers, which may need address wrapping once and then.

For the packet size, officially, wifi frame bodies can be up to 2312 (908h) bytes, plus some header/checksum bytes. I was concerned that this could conflict with the MBOX size of 800h bytes, possibly needing to split larger packets somehow. But I do now think the issue doesn't exist in practice, because the network MTU is usually set to about 1400 bytes (DSi firmware allows to select 1500 bytes as maximum). MTU is short for "Max Transmission Unit".

And some confusing oddities
Apropos weird abbreviations. The RSSI (Received Signal Strength Indicator) in the MBOX header appears to be actually what Atheros is referring to as SNR (Signal to Noise Ratio). RSSI and SNR are widely used confusing terms expressed in decibels (whereas, my understanding is that "decibel" is tech slang for "meaningless virtual unit"; similar to percents, but leaving it unspecified whether the units are counted in per cents, or per volt, or per watt, or per milliwatt, or per whatver). The best SNR explanatation that I've found is explaining that the Signal to Noise Ratio "isn't actually a ratio" (it's an offset between signal level and noise level, ie. computed by substracting two values, not by dividing them).

The relation between RSSI and SNR can be seen in the WMI_BSSINFO_EVENT structure. Or actually, there are two structures:
An old 10h-byte structure with both RSSI and SNR (this format is used by DSi).
A new 0Ch-byte structure with SNR only (this format is implemented in DSi, too, but seems to be left unused).
For the new 0Ch-byte format, Atheros does advise to compute the missing RSSI value as "rssi=snr-95" (in result, RSSI should be a negative number, assuming SNR being 0..60). Going by the values spotted in the wifi log, the same formula is also used for the old 10h-byte format, though with a weird and possibly bugged corner case:

The SNR is/was believed to be in range 0..60 (00h..3Ch) on Atheros hardware. But I've also spotted a BSSINFO event with SNR=FCh, which, I guess it's meant to be "-4" (even though that would mean that the signal was weaker than the noise level; or at least weaker than the virtually assumed noise). On the other hand, Atheros seems to see SNR=FCh as "+252", at least they somehow ended up with storing RSSI=009Dh in the 10h-byte event structure (I guess they just didn't know about using 8bit-to-16bit sign-extension, either that, or somebody is operating a megawatt Wifi network in the closer neighborhood, on one of the Jupiter moons, for example).


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 11:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20854
Location: NE Indiana, USA (NTSC)
A "bel" is a 10 to 1 ratio in power. A "decibel" is one-tenth of a bel, or a 10^.1 = 1.26:1 ratio in power. If the signal to noise ratio is 6 decibels, then the signal power divided by the noise power is 10^.6 = 3.98:1.


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 3:22 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
I've looked at the wikipedia page after writing the above post, too. As I understand it now: The difference between "percent" and "decibel" is that percents are linear, and decibels are logarithmic (ie. 2db is more than twice as much as 1db) (*).
Ah, then, that sounds as if SNR is actually a "ratio" despite of having it calculated by subtracting "signal-noise". Hmmm, that logarithmic stuff is confusing and exceeds my daily add/sub/shift/and/or/xor maths.

Okay, and a difference of 256db means factor 10^(25.6)? Then, that's funny, with the wrong sign-extension, the difference between -4db and +252db is 256db. And, assuming that an average access point is using 1 watt for transmitting signals... the BSSINFO event from Atheros is telling me that there's a "39810 billion terawatt" access point right next door? That might be reason of concern for most people living on this planet (coincidentally, the energy emitted by the sun is just about 10x higher).

But back to DSi Wifi: The code for sending TX Data is theoretically working now (still untested because I have no code for receving RX Data responses yet). I am hoping that it will be up to 25 times faster than the old 2Mbit/s NDS wifi. Or maybe 10^25.6 times faster. Or so. Something like that. Just hope that it won't end up being slower than before!

(*) and the other differences are that the reference point is called "100%" for percents, and 1db "0db"for decibels; and that it isn't frowned upon to exceed the reference point in the latter case.


Last edited by nocash on Sun Dec 09, 2018 5:15 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 3:30 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7817
Location: Seattle
nocash wrote:
And, assuming that an average access point is using 1 watt for transmitting signals
802.11 power ratings are usually measured in dBuV, decibels relative to 1 microvolt transmitted/received signal.


Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 3:45 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
Does that make a difference on the estimated power consumption? I guess that the transmitter energy is something in range of watts, even if the receiver sees only some microwatts or microvolts of that signal. But either way, factor X for received power implies factor X for transmitted power, doesn't it?

That, assuming that the access point is really located somewhere next door (if it's more than a few 100 meters away, then it's probably broadcasting using the power of more than a thousand of suns).


Last edited by nocash on Sun Dec 09, 2018 3:53 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Dec 09, 2018 3:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7817
Location: Seattle
Decibels (and Bels) are always a relative measurement: there's no universal 0. You can't talk about 1 dB as some absolute quantity: instead you have to have a defined 0 reference.

Hence dBuV. The ratio relative to 1 microvolt.

802.11 access points transmit somewhere around 100mW. q.v. https://wlan1nde.wordpress.com/2014/11/ ... ower-etsi/

And the numbers exposed to the end user are usually actually displayed as the absolute value of the dBmW - "90" means "-90dBmW"


Top
 Profile  
 
PostPosted: Mon Dec 10, 2018 7:53 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
Success! And Failure!
Data RX/TX is implemented & sending/receiving DHCP packets is working. After passing the DHCP stage, it's been waiting for a .nds/.dsi file to be uploaded from PC to DSi via UDP/TCP packets, and that upload worked right away, too.
Only, the DSi transfer speed doesn't look any faster than old NDS wifi, well, at least it doesn't look much slower either (I'll need to display some "Kbyte/second" indicator to be sure). Anyways, it's definetly miles away from being 25x faster.
The issue might be just that my 32bit ARM7 code is too slow because it's using code/data in uncached Main RAM, that could be fixed by using faster memory & more DMA transfers. If that doesn't help then it might be related to atheros bitrate/fixrates/framerate/pstream settings or the like. Or maybe some IRQ handlers aren't called often enough to process incoming data.


Top
 Profile  
 
PostPosted: Tue Dec 11, 2018 3:55 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 729
NDS-Wifi upload speed is about 110 Kbyte/s (ideally should be 200Kbyte/s).
DSi-Wifi upload speed is about 150 Kbyte/s (ideally should be 5000Kbyte/s).

That's both not so good. At least DSi is slightly "faster" than NDS, but it's ways slower than it should be. One problem is that if I try to use DMA or faster memory, then transfers stop working, or become unreliable/slower. I thinks that's related to the SDIO hardware: SDIO commands can have multiple 80h-byte blocks, and it seems that one must wait for "something" between separate blocks.
As for "something", that's unfortunately unknown. Looking at DSi browser, it's using NDMA with SDIO_DATA32 mode for dealing with multiple blocks, so that's probably the way to go, hoping that NDMA will automatically use the correct timings. If there's a way to poll any "next block ready" flags for manual timings then I don't know about it yet.

For now, I switched to some other stuff: The code is now auto-detecting if the DSi's SDIO registers exist (and are enabled), and automatically switches between NDS-Wifi and DSi-Wifi accordingly. That's working... but brought up another small problem: The program currently tends to hang after upload's on NDS consoles (or DSi's in NDS mode). I didn't have had that problem some months ago, looks as if some newer changes have broken NDS compatibility.

Next Problem: My new DSi-Wifi code was for WEP only, so I've logged initialization for open networks and WPA networks today.
Open network is simple: It does simply skip the four ADD_CIPHER_KEY commands, and sends the CONNECT command (with only three parameter bytes different as than for WEP).

WPA network is nightmarish. It's ways more complicated than WEP. For WEP one just uses ADD_CIPHER_KEY and CONNECT, and everything is done automatically. Theoretically, WPA should work the same, but instead, it's using CONNECT (without setting any cipher keys yet), and then it's using twelve Data RX/TX commands for manually exchanging data with the access point, and throws in two ADD_CIPHER_KEY commands inbetween of that data transfers. And worst, the WPA password doesn't show up anywhere in that process, apparently one is supposed to encrypt the password manually (or convert it to SHA256 or so) (the ADD_CIPHER_KEY commands have key length set to 32 bytes, despite of the actual ASCII password being shorter).

Below is the WPA connection sequence. Please let me know if somebody can make sense of it, or can point me on helpful documents or source code! The CMD/EVENT stuff is more or less clear (apart from ADD_CIPHER_KEY_CMD not containing plaintext passwords). But I've no idea what the twelve "Data #1..#12" packets are supposed for. At the moment, I am feeling a bit overhelmed by unexpected problems - I hope some of it will sort out tomorrow.
Code:
connection details:
 access point:     fritzbox (with SSID "ead")
 encryption:       WPA-PSK(TKIP)
 password:         ernstaugustdeich
 modus:            infrastruktur
 groupkeyinterval: 3600 seconds
 MAC for DSi       mm mm mm mm mm mm
 MAC for AP        aa aa aa aa aa aa
 MAC for router    bb bb bb bb bb bb

MBOX traffic for sdio_connect sequence:
 (preceeded by usual channel scanning stuff)
 Write WMI_TARGET_ERROR_REPORT_BITMASK_CMD +2008h    01 01 06 00 08 20  22 00 7F 00 00 00
 Write WMI_SET_BSS_FILTER_CMD                        01 01 0A 00 00 00  09 00 00 00 00 00 00 00 00 00
 Write WMI_SET_PROBED_SSID_CMD                       01 01 25 00 00 00  0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Write WMI_SET_SCAN_PARAMS_CMD                       01 01 16 00 00 00  08 00 FF FF FF FF FF FF C8 00 C8 00 00 05 C8 00 00 00 00 00 00 00
 Write WMI_SET_CHANNEL_PARAMS_CMD                    01 01 08 00 00 00  11 00 00 00 02 01 9E 09
 Write WMI_SET_BITRATE_CMD                           01 01 05 00 00 00  00 F0 FF 00 00
 Write WMI_SET_AP_PS_CMD                             01 01 06 00 00 00  48 00 01 A4 F7 FF
 Write WMI_SYNCHRONIZE_CMD                           01 01 03 00 00 00  04 00 00
 Write WMI_SET_POWER_MODE_CMD                        01 01 03 00 00 00  12 00 02
 Write WMI_SYNCHRONIZE_CMD                           01 01 03 00 00 00  04 00 00
 Write WMI_CREATE_PSTREAM_CMD                        01 01 41 00 00 00  05 00 14 00 00 00 14 00 00 00 7F 96 98 00 FF FF FF FF 00 00 00 00 00 45 01 00 00 45 01 00 00 45 01 00 00 00 00 00 00 00 00 00 80 8D 5B 00 00 20 00 00 00 00 00 00 D0 80 D0 00 00 02 FF 01 00 05 00
 Write WMI_SET_WSC_STATUS_CMD                        01 01 03 00 00 00  41 00 00
 Write WMI_SET_DISCONNECT_TIMEOUT(_CMD)              01 01 03 00 00 00  0D 00 02
 Write WMI_SET_TKIP_COUNTERMEASURES_CMD  !!!         01 01 03 00 00 00  20 00 00
 Write WMI_SET_BSS_FILTER_CMD                        01 01 0A 00 00 00  09 00 00 00 00 00 00 00 00 00
 Write WMI_SET_SCAN_PARAMS_CMD                       01 01 16 00 00 00  08 00 FF FF FF FF FF FF C8 00 C8 00 00 05 C8 00 00 00 00 00 00 00
 Write WMI_SET_CHANNEL_PARAMS_CMD +2008h             01 01 08 00 08 20  11 00 00 00 02 01 9E 09
 Write WMI_SET_KEEPALIVE_CMD                         01 01 03 00 00 00  3D 00 00
 Write WMI_CONNECT_CMD      ;<----------             01 01 36 00 00 00  01 00 01 01 03 03 00 03 00 03 65 61 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9E 09 aa aa aa aa aa aa 00 00 00 00   ;connect to "ead"
 Read  WMIX_DBGLOG_EVENT                             01 00 E2 05 00 00  10 10 08 30 00 00 00 00 00 00 F1 05 2C 44 08 30 00 00 2C 06 29 84 07 00 00 00 14 00 00 00 2C 06 06 A4 ...
 Write WMIX_HB_CHALLENGE_RESP_CMD          +0101h    01 01 0E 00 01 01  2E 00 08 20 00 00 02 00 00 00 00 00 00 00
 Read  WMIX_HB_CHALLENGE_RESP_EVENT                  01 02 16 00 08 00  10 10 07 30 00 00 02 00 00 00 00 00 00 00 02 06 00 00 02 0C 00 00
 Delay 0009 till IRQ
 Read  WMI_CONNECT_EVENT    ;<----------             01 02 7F 00 08 00  02 10 9E 09 aa aa aa aa aa aa 64 00 64 00 01 00 00 00 1A 31 16 DD 18 00 50 F2 01 01 00 00 50 F2 02 01 00 00 50 F2 02 01 00 00 50 F2 02 00 00 11 04 01 00 00 03 65 61 64 01 08 82 84 8B 0C 12 96 18 24 32 04 30 48 60 6C DD 16 00 50 F2 01 01 00 00 50 F2 02 01 00 00 50 F2 02 01 00 00 50 F2 02 51 04 00 00 01 C0 01 08 82 84 8B 0C 12 96 18 24 32 04 30 48 60 6C 00 02 06 00 00 00 00 00 00    ;for "ead"
 Read  Data #1 read                                  02 02 83 00 08 F4  3B 00 mm mm mm mm mm mm aa aa aa aa aa aa 00 6B AA AA 03 00 00 00 88 8E 01 03 00 5F FE 00 89 00 20 00 00 00 00 00 00 00 01 0A E4 4D E8 8F 91 BA DA 89 73 78 7E 46 AF 28 97 9E C7 97 80 A7 20 4B 53 71 F6 27 F7 62 A7 B4 D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 06 00 A5 A5 01 00 00
 Write Data #2 write                                 02 00 93 00 00 00  00 1C aa aa aa aa aa aa mm mm mm mm mm mm 00 83 AA AA 03 00 00 00 88 8E 01 03 00 77 FE 01 09 00 20 00 00 00 00 00 00 00 01 B1 F9 1C 00 66 00 55 8F 42 F7 07 F4 00 01 10 01 01 27 40 00 00 00 00 00 7F 06 9C 6C FF 2F B6 C7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1B 1E 61 E7 C3 1F CF 0D 88 9F 7B E9 27 4B 80 AA 00 18 DD 16 00 50 F2 01 01 00 00 50 F2 02 01 00 00 50 F2 02 01 00 00 50 F2 02
 Read  Data #3 read                                  02 02 A1 00 0C F4  3B 00 mm mm mm mm mm mm aa aa aa aa aa aa 00 85 AA AA 03 00 00 00 88 8E 01 03 00 79 FE 01 C9 00 20 00 00 00 00 00 00 00 02 0A E4 4D E8 8F 91 BA DA 89 73 78 7E 46 AF 28 97 9E C7 97 80 A7 20 4B 53 71 F6 27 F7 62 A7 B4 D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 7A 4F 98 41 29 D5 BF 43 04 58 74 E2 3E 8E 10 00 1A DD 18 00 50 F2 01 01 00 00 50 F2 02 01 00 00 50 F2 02 01 00 00 50 F2 02 00 00 01 02 02 01 02 06 00 14 00 0A 00 00
 Write Data #4 write                                 02 00 7B 00 00 00  00 1C aa aa aa aa aa aa mm mm mm mm mm mm 00 6B AA AA 03 00 00 00 88 8E 01 03 00 5F FE 01 09 00 20 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 95 53 EE 13 CE 18 28 7C 50 87 C1 78 54 67 E4 B7 00 00
 Write WMI_SYNCHRONIZE_CMD                           01 01 03 00 00 00  04 00 01
 Write Data #5 write n/a +0204h                      02 01 02 00 00 00  04 02
 Write Data #6 write n/a +0204h                      02 00 02 00 00 00  04 02
 Write WMI_ADD_CIPHER_KEY_CMD      ;<---             01 01 2F 00 00 00  16 00 00 03 00 20 00 00 00 00 00 00 00 00 07 A2 68 3A DF B2 B5 29 2F 82 70 8E 0F C0 CB 0E 9B 5F AE 0F 0F EB 79 18 F2 BC 3A FA EA 12 FB 3C 03
 Read   (handshake with len=0Eh) (acklen=4) (!!!)    00 02 0E 00 0E 00  01 04 01 01 02 01 02 06 00 00 00 00 00 00  ;(this isn't WPA related, just interesting because it does deliver a "Cmd.ack" and "Data.ack" in the same packet)
 Write WMI_SYNCHRONIZE_CMD                           01 01 03 00 00 00  04 00 01
 Read  Data #7 read                                  02 02 A3 00 08 F4  3B 00 mm mm mm mm mm mm aa aa aa aa aa aa 00 8B AA AA 03 00 00 00 88 8E 01 03 00 7F FE 03 A1 00 20 00 00 00 00 00 00 00 03 0A E4 4D E8 8F 91 BA DA 89 73 78 7E 46 AF 28 97 9E C7 97 80 A7 20 4B 53 71 F6 27 F7 62 A7 B4 D8 9E C7 97 80 A7 20 4B 53 71 F6 27 F7 62 A7 B4 DA 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 0D 67 18 1E B2 81 48 02 9D 84 6A 0B DC 03 48 00 20 04 4C 38 D8 37 85 D8 75 D2 C7 AD 15 F9 F8 32 78 96 BE 01 97 0C 5F 9F A9 6E B6 9C 5B 3C 3C 5B 16 02 06 00 DB 2A 92 8A 00
 Write WMI_SYNCHRONIZE_CMD                           01 01 03 00 00 00  04 00 01
 Write Data #8 write n/a +020Dh                      02 00 02 00 00 00  0D 02
 Write Data #9 write n/a +0209h                      02 00 02 00 00 00  09 02
 Write WMI_ADD_CIPHER_KEY_CMD      ;<---             01 01 2F 00 00 00  16 00 02 03 01 20 00 00 00 00 00 00 00 00 44 9B 5A DC 41 27 79 2E ED 65 AA 1F D3 65 36 2F 02 A4 1B DD B8 2B 2F 39 84 D0 69 6F 46 E4 55 53 03
 Write WMI_SYNCHRONIZE_CMD                           01 01 03 00 00 00  04 00 01
 Write Data #10 write                                02 00 7B 00 00 00  00 1C aa aa aa aa aa aa mm mm mm mm mm mm 00 6B AA AA 03 00 00 00 88 8E 01 03 00 5F FE 03 21 00 20 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70 A2 B7 B0 78 07 D3 67 C8 1B C9 ED 4B 55 20 E1 00 00
 Delay 001A till IRQ
 Read  WMI_NEIGHBOR_REPORT_EVENT                     01 02 16 00 0C 00  08 10 01 aa aa aa aa aa aa 00 01 02 02 01 02 06 00 00 1A 31 16 00
 Delay 0010 till heartbeat
 Write WMIX_HB_CHALLENGE_RESP_CMD          +0101h    01 01 0E 00 01 01  2E 00 08 20 00 00 03 00 00 00 00 00 00 00
 Read  WMIX_HB_CHALLENGE_RESP_EVENT                  01 02 16 00 08 00  10 10 07 30 00 00 03 00 00 00 00 00 00 00 02 06 00 00 1A 31 16 00
 Delay 0006 till IRQ
 Read  Data #11 read                                 02 02 4E 00 08 00  3B 00 01 00 5E 00 00 01 bb bb bb bb bb bb 00 36 AA AA 03 00 00 00 08 00 46 00 00 20 00 00 40 00 01 02 43 2D C0 A8 01 01 E0 00 00 01 94 04 00 00 11 0A EE F5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 06 00 CC 65 A2 27 00
 Delay 000B till IRQ
 Read  Data #12 read                                 02 02 40 00 08 7F  3C 00 01 00 5E 7F FF FA 00 1A 4F 66 FF 41 00 28 AA AA 03 00 00 00 08 00 46 00 00 20 00 00 40 00 01 02 33 2E C0 A8 01 07 EF FF FF FA 94 04 00 00 16 00 FA 04 EF FF FF FA 02 06 00 25 16 2F E3 00
 (followed by usual DHCP stuff)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group