* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem [not found] ` <4E820130.7080801@gmail.com> @ 2011-09-27 21:00 ` Larry Finger 2011-09-27 22:25 ` Stefan Zwanenburg 0 siblings, 1 reply; 9+ messages in thread From: Larry Finger @ 2011-09-27 21:00 UTC (permalink / raw) To: Stefan Zwanenburg; +Cc: 'Chaoming_Li', linux-wireless On 09/27/2011 12:00 PM, Stefan Zwanenburg wrote: > I've sent the below mail quite some time ago to Larry Finger and Chaoming Li, > but am now unsure if it has actually arrived. Also, I thought maybe I'm not > getting a response because of the fact I didn't CC the mailing list (which I > didn't because of the attachment; I thought that would be frowned upon). > Now, I don't want to come across as impatient, but it would mean a lot to me if > the source of the problem were to be found. > > My sincerest apologies if attachments don't belong on the mailing list, and/or > if this message is a duplicate! > > Stefan Zwanenburg > > -------- Original Message -------- > Subject: Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem > Date: Mon, 19 Sep 2011 23:06:23 +0200 > From: Stefan Zwanenburg <stefanhetzwaantje@gmail.com> > To: 李朝明 <chaoming_li@realsil.com.cn> > CC: 'Larry Finger' <Larry.Finger@lwfinger.net> > > > > On 09/19/2011 10:04 PM, Stefan Zwanenburg wrote: >> On 09/19/2011 06:41 AM, 李朝明 wrote: >>> Dear Sir: >>> >>> Yes, sniffer can help, Could you help to catch the authentication >>> and association packet and send it to me。 >>> >>> Best Regards， >>> lizhaoming >>> >> Find below the output of wpa_supplicant with the -ddd switch. If that is >> not the information you required (ie: you need even rawer logging or >> somesuch), please tell me what I need to do, or where I might find the >> information to do what I need to do. > So I got some help on how to sniff the association process. Please find > attached a dump of said process. Sorry to not answer earlier. I was busy and I also hoped that Chaoming would handle this part. I did a dump of the authentication and association process with my RTL8191SE and my AP. For both systems, the authentication packets are identical, as are the association request and response. The capability flags are identical. This is where the two sequences differ: My AP sends an action frame with No. Time Source Destination Protocol Info 9 0.010970 Netgear_be:2b:44 RealtekS_72:02:18 IEEE 802.11 Action, SN=2120, FN=0, Flags=........ Frame 9: 33 bytes on wire (264 bits), 33 bytes captured (264 bits) Arrival Time: Sep 27, 2011 14:47:33.529328000 CDT Epoch Time: 1317152853.529328000 seconds [Time delta from previous captured frame: 0.004135000 seconds] [Time delta from previous displayed frame: 0.004135000 seconds] [Time since reference or first frame: 0.010970000 seconds] Frame Number: 9 Frame Length: 33 bytes (264 bits) Capture Length: 33 bytes (264 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: wlan] IEEE 802.11 Action, Flags: ........ Type/Subtype: Action (0x0d) Frame Control: 0x00D0 (Normal) Version: 0 Type: Management frame (0) Subtype: 13 Flags: 0x0 Duration: 314 Destination address: RealtekS_72:02:18 (00:e0:4c:72:02:18) Source address: Netgear_be:2b:44 (c0:3f:0e:be:2b:44) BSS Id: Netgear_be:2b:44 (c0:3f:0e:be:2b:44) Fragment number: 0 Sequence number: 2120 IEEE 802.11 wireless LAN management frame Fixed parameters Action: 0x03 Category code: Block Ack (3) Action code: Add Block Ack Request (0x00) Dialog token: 0xee Block Ack Parameters: 0x1002 .... .... .... ...0 = A-MSDUs: Not Permitted .... .... .... ..1. = Block Ack Policy: Immediate Block Ack ..00 00.. = Traffic Identifier: 0x00 0001 0000 00.. .... = Number of Buffers (1 Buffer = 2304 Bytes): 64 Block Ack Timeout: 0x0000 Block Ack Starting Sequence Control (SSC): 0x0000 Your AP does not send such a packet. My STA responds with an ACK and another action frame: No. Time Source Destination Protocol Info 11 0.025115 RealtekS_72:02:18 Netgear_be:2b:44 IEEE 802.11 Action, SN=28, FN=0, Flags=........ Frame 11: 33 bytes on wire (264 bits), 33 bytes captured (264 bits) Arrival Time: Sep 27, 2011 14:47:33.543473000 CDT Epoch Time: 1317152853.543473000 seconds [Time delta from previous captured frame: 0.013897000 seconds] [Time delta from previous displayed frame: 0.013897000 seconds] [Time since reference or first frame: 0.025115000 seconds] Frame Number: 11 Frame Length: 33 bytes (264 bits) Capture Length: 33 bytes (264 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: wlan] IEEE 802.11 Action, Flags: ........ Type/Subtype: Action (0x0d) Frame Control: 0x00D0 (Normal) Version: 0 Type: Management frame (0) Subtype: 13 Flags: 0x0 Duration: 0 Destination address: Netgear_be:2b:44 (c0:3f:0e:be:2b:44) Source address: RealtekS_72:02:18 (00:e0:4c:72:02:18) BSS Id: Netgear_be:2b:44 (c0:3f:0e:be:2b:44) Fragment number: 0 Sequence number: 28 IEEE 802.11 wireless LAN management frame Fixed parameters Action: 0x03 Category code: Block Ack (3) Action code: Add Block Ack Response (0x01) Dialog token: 0xee Status code: Successful (0x0000) Block Ack Parameters: 0x1002 .... .... .... ...0 = A-MSDUs: Not Permitted .... .... .... ..1. = Block Ack Policy: Immediate Block Ack ..00 00.. = Traffic Identifier: 0x00 0001 0000 00.. .... = Number of Buffers (1 Buffer = 2304 Bytes): 64 Block Ack Timeout: 0x0000 This packet is followed by a Block Ack in both directions and then the EAPOL 1/4 is sent. I'm not familiar enough to know the significance of these differences, but I'm guessing that they may be the source of your problem. I have to go now, but if no one describes what we are seeing, I'll review the 802.11n specs and get back to you tomorrow. Larry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem 2011-09-27 21:00 ` 答复: 答复: 答复: RTL8192SE and 802.11n problem Larry Finger @ 2011-09-27 22:25 ` Stefan Zwanenburg 2011-09-28 4:56 ` Larry Finger 0 siblings, 1 reply; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-27 22:25 UTC (permalink / raw) To: Larry Finger; +Cc: 'Chaoming_Li', linux-wireless On 09/27/2011 11:00 PM, Larry Finger wrote: > I have to go now, but if no one describes what we are seeing, I'll > review the 802.11n specs and get back to you tomorrow. > > Larry I've taken a quick peek at the specs, and I'm afraid I can't be of any help there (I found out — again — I have great respect for you guys for reading those documents!). However, something just dawned on me, and I'm not sure if it is at all relevant here, but somehow, my NIC seems to be getting all kinds of different MAC addresses assigned (apparently randomly). I just checked my "persistent net" udev rules file (mind you, this file is automatically amended whenever a new NIC appears on my system), and there are 26(!) different rules for just my wireless interface, all with different MAC addresses. As you may have noticed from my dump of the association process, the MAC address in use is one with a vendor ID for some "Azurewave" interface. There are quite a few in the rules file for Realtek interfaces, but the one I mostly get is for an Azurewave vendor ID. I just tried setting a different MAC address (using ifconfig wlan0 hw ether 00:e0:4c:81:82:58) however it didn't change anything about my no 802.11n link situation (as I expected). So perhaps this little tidbit should be ignored for now. I just thought I'd let you know, in case this isn't a known problem. Regards, Stefan Zwanenburg ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem 2011-09-27 22:25 ` Stefan Zwanenburg @ 2011-09-28 4:56 ` Larry Finger 2011-09-28 23:28 ` Stefan Zwanenburg 0 siblings, 1 reply; 9+ messages in thread From: Larry Finger @ 2011-09-28 4:56 UTC (permalink / raw) To: Stefan Zwanenburg; +Cc: 'Chaoming_Li', linux-wireless On 09/27/2011 05:25 PM, Stefan Zwanenburg wrote: > On 09/27/2011 11:00 PM, Larry Finger wrote: >> I have to go now, but if no one describes what we are seeing, I'll >> review the 802.11n specs and get back to you tomorrow. >> >> Larry > I've taken a quick peek at the specs, and I'm afraid I can't be of any > help there (I found out — again — I have great respect for you guys for > reading those documents!). However, something just dawned on me, and I'm > not sure if it is at all relevant here, but somehow, my NIC seems to be > getting all kinds of different MAC addresses assigned (apparently > randomly). I just checked my "persistent net" udev rules file (mind you, > this file is automatically amended whenever a new NIC appears on my > system), and there are 26(!) different rules for just my wireless > interface, all with different MAC addresses. > As you may have noticed from my dump of the association process, the MAC > address in use is one with a vendor ID for some "Azurewave" interface. > There are quite a few in the rules file for Realtek interfaces, but the > one I mostly get is for an Azurewave vendor ID. > > I just tried setting a different MAC address (using ifconfig wlan0 hw > ether 00:e0:4c:81:82:58) however it didn't change anything about my no > 802.11n link situation (as I expected). So perhaps this little tidbit > should be ignored for now. > > I just thought I'd let you know, in case this isn't a known problem. The MAC address is read from EEROM in routines found in efuse.c, and should always be the same. If the value read is not a valid ethernet address, then a random one is set, which must be what is happening on your system. I'll get back to you on how to dump the entire efuse contents so that we can see what else might be wrong in its encoding. I will be out tomorrow, thus it will likely be Thursday before I can answer. Perhaps Chaoming will answer earlier. Larry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem 2011-09-28 4:56 ` Larry Finger @ 2011-09-28 23:28 ` Stefan Zwanenburg 2011-09-29 2:32 ` Stefan Zwanenburg 2011-09-29 3:28 ` Larry Finger 0 siblings, 2 replies; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-28 23:28 UTC (permalink / raw) To: Larry Finger; +Cc: 'Chaoming_Li', linux-wireless On 09/28/2011 06:56 AM, Larry Finger wrote: > The MAC address is read from EEROM in routines found in efuse.c, and > should always be the same. If the value read is not a valid ethernet > address, then a random one is set, which must be what is happening on > your system. I'll get back to you on how to dump the entire efuse > contents so that we can see what else might be wrong in its encoding. > I will be out tomorrow, thus it will likely be Thursday before I can > answer. Perhaps Chaoming will answer earlier. I had some time on my hands, so I tried to figure out how to dump the EEPROM data myself, and have done so using the following patch (based on linux-3.0.4): --- drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-07-22 04:17:23.000000000 +0200 +++ /home/psychotic/Desktop/rtl8192se_hw.c 2011-09-29 01:16:09.361978051 +0200 @@ -1645,6 +1645,13 @@ RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"), hwinfo, HWSET_MAX_SIZE_92S); + printk("RTL8192SE - got EEPROM data:"); + for (i = 0; i < HWSET_MAX_SIZE_92S; i++) { + if (i % 6 == 0) + printk("\n "); + printk("%02X ", hwinfo[i]); + } + eeprom_id = *((u16 *)&hwinfo[0]); if (eeprom_id != RTL8190_EEPROM_ID) { RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING, And here is the output I got right after inserting the rtl8192se module: Sep 29 01:07:02 localhost kernel: [ 1160.153407] RTL8192SE - got EEPROM data: Sep 29 01:07:02 localhost kernel: [ 1160.153412] 29 81 00 00 A9 16 Sep 29 01:07:02 localhost kernel: [ 1160.153419] 00 00 00 00 EC 10 Sep 29 01:07:02 localhost kernel: [ 1160.153425] 72 81 EC 10 72 81 Sep 29 01:07:02 localhost kernel: [ 1160.153431] 1C 4B D6 69 6A DC Sep 29 01:07:02 localhost kernel: [ 1160.153437] FF FF FF FF FF FF Sep 29 01:07:02 localhost kernel: [ 1160.153443] FF FF 01 FF 13 AA Sep 29 01:07:02 localhost kernel: [ 1160.153449] 03 02 20 80 02 B0 Sep 29 01:07:02 localhost kernel: [ 1160.153455] 06 91 A5 78 2A E4 Sep 29 01:07:02 localhost kernel: [ 1160.153461] 00 E0 4C FF FE 22 Sep 29 01:07:02 localhost kernel: [ 1160.153467] 55 88 C3 FF 84 75 Sep 29 01:07:02 localhost kernel: [ 1160.153473] 78 39 00 00 C1 8C Sep 29 01:07:02 localhost kernel: [ 1160.153478] 80 11 40 00 11 3C Sep 29 01:07:02 localhost kernel: [ 1160.153484] 03 00 10 20 00 00 Sep 29 01:07:02 localhost kernel: [ 1160.153490] 00 00 28 29 27 00 Sep 29 01:07:02 localhost kernel: [ 1160.153496] 00 00 28 28 28 00 Sep 29 01:07:02 localhost kernel: [ 1160.153502] 00 00 00 00 00 00 Sep 29 01:07:02 localhost kernel: [ 1160.153508] 00 00 00 00 00 04 Sep 29 01:07:02 localhost kernel: [ 1160.153514] 03 00 00 00 00 00 Sep 29 01:07:02 localhost kernel: [ 1160.153520] 00 01 00 00 00 00 Sep 29 01:07:02 localhost kernel: [ 1160.153526] 00 00 0E 00 04 11 Sep 29 01:07:02 localhost kernel: [ 1160.153531] 00 00 00 09 02 00 Sep 29 01:07:02 localhost kernel: [ 1160.153537] 02 00 I hope that saves you the time by not having to explain to me how to dump the EEPROM data, and that you (any of you =)) can find something useful in there. What I have been able to tell from this is that the MAC address my interface currently has is indeed the one saved in the EEPROM (1C:4B:D6:69:6A:DC). Don't know why it would ever have another one... Greetings, Stefan Zwanenburg ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem 2011-09-28 23:28 ` Stefan Zwanenburg @ 2011-09-29 2:32 ` Stefan Zwanenburg 2011-09-29 3:28 ` Larry Finger 1 sibling, 0 replies; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-29 2:32 UTC (permalink / raw) To: Larry Finger; +Cc: 'Chaoming_Li', linux-wireless On 09/29/2011 01:28 AM, Stefan Zwanenburg wrote: > I had some time on my hands, so I tried to figure out how to dump the > EEPROM data myself, and have done so using the following patch (based on > linux-3.0.4): > > --- drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-07-22 > 04:17:23.000000000 +0200 > +++ /home/psychotic/Desktop/rtl8192se_hw.c 2011-09-29 > 01:16:09.361978051 +0200 > @@ -1645,6 +1645,13 @@ > RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"), > hwinfo, HWSET_MAX_SIZE_92S); > > + printk("RTL8192SE - got EEPROM data:"); > + for (i = 0; i < HWSET_MAX_SIZE_92S; i++) { > + if (i % 6 == 0) > + printk("\n "); > + printk("%02X ", hwinfo[i]); > + } > + > eeprom_id = *((u16 *)&hwinfo[0]); > if (eeprom_id != RTL8190_EEPROM_ID) { > RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING, For posterity's sake, there was a slightly smaller workaround here, and it would be as in the following patch: --- drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-09-29 04:20:14.660831861 +0200 +++ drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-09-29 04:20:05.303831474 +0200 @@ -1642,7 +1642,7 @@ HWSET_MAX_SIZE_92S); } - RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"), + RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_EMERG, ("MAP\n"), hwinfo, HWSET_MAX_SIZE_92S); eeprom_id = *((u16 *)&hwinfo[0]); It's rather nasty though, as it pretends that dumping the EEPROM data is happening right before a fatal error has occurred. But there's really no other way, as using sysfs to set the "global_debuglevel" is not good enough because the EEPROM data is read right after the module is loaded (making it hard to set the debuglevel in time). If this info is useless to you, disregard it! Stefan Zwanenburg PS: the EEPROM data I mentioned in my previous message is still the same though, so I won't bother to repost it. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem 2011-09-28 23:28 ` Stefan Zwanenburg 2011-09-29 2:32 ` Stefan Zwanenburg @ 2011-09-29 3:28 ` Larry Finger [not found] ` <0EF5E594196F41B48B0B4D168B714838@realsil.com.cn> 1 sibling, 1 reply; 9+ messages in thread From: Larry Finger @ 2011-09-29 3:28 UTC (permalink / raw) To: Stefan Zwanenburg; +Cc: 'Chaoming_Li', linux-wireless Stefan, I dumped my EEPROM data and compared it with yours. The diffs are as follows: --- mine 2011-09-28 21:58:26.000000000 -0500 +++ yours 2011-09-28 21:58:27.000000000 -0500 @@ -1,9 +1,9 @@ 29 81 00 00 A9 16 00 00 00 00 EC 10 72 81 EC 10 72 81 -00 E0 4C 72 02 18 FF FF FF FF FF FF FF FF 01 FF 13 AA +1C 4B D6 69 6A DC FF FF FF FF FF FF FF FF 01 FF 13 AA 03 02 20 80 02 B0 06 91 A5 78 2A E4 00 E0 4C FF FE 22 55 88 C3 FF 84 75 78 39 00 00 C1 8C 80 11 40 00 11 3C -03 00 10 20 00 00 00 00 2C 29 2B 00 00 00 2D 2B 2C 00 -00 00 00 00 00 00 00 00 01 01 01 03 03 00 00 00 00 00 -00 00 00 00 00 00 00 00 0A 0A 03 11 00 00 00 0A 03 00 -02 00 +03 00 10 20 00 00 00 00 28 29 27 00 00 00 28 28 28 00 +00 00 00 00 00 00 00 00 00 00 00 04 03 00 00 00 00 00 +00 01 00 00 00 00 00 00 0E 00 04 11 00 00 00 09 02 00 +02 00 The data in the first 6 bytes at the beginning of line 2 is the MAC address. It is clearly encoded there and I do not understand how it can be misread. Chaoming - Any ideas to test? I think that the other differences are likely to be calibration difference between our two devices. BTW, --- MAP_from_mine 2011-09-28 21:58:26.000000000 -0500 +++ MAP_from_problem 2011-09-28 21:58:27.000000000 -0500 @@ -1,9 +1,9 @@ 29 81 00 00 A9 16 00 00 00 00 EC 10 72 81 EC 10 72 81 -00 E0 4C 72 02 18 FF FF FF FF FF FF FF FF 01 FF 13 AA +1C 4B D6 69 6A DC FF FF FF FF FF FF FF FF 01 FF 13 AA 03 02 20 80 02 B0 06 91 A5 78 2A E4 00 E0 4C FF FE 22 55 88 C3 FF 84 75 78 39 00 00 C1 8C 80 11 40 00 11 3C -03 00 10 20 00 00 00 00 2C 29 2B 00 00 00 2D 2B 2C 00 -00 00 00 00 00 00 00 00 01 01 01 03 03 00 00 00 00 00 -00 00 00 00 00 00 00 00 0A 0A 03 11 00 00 00 0A 03 00 +03 00 10 20 00 00 00 00 28 29 27 00 00 00 28 28 28 00 +00 00 00 00 00 00 00 00 00 00 00 04 03 00 00 00 00 00 +00 01 00 00 00 00 00 00 0E 00 04 11 00 00 00 09 02 00 02 00 BTW, the dump sent me has 1C:4B:D6:69:6A:DC as the MAC address. Obviously, the hardware had the correct MAC address. Wireshark does interpret that as Azurewav_69:6A:DC. The prefix 1C:4B:D6 apparently belongs to them. My device is translated as RealtekS_72:02:18, as 00:E0:4C means Realtek. Larry ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <0EF5E594196F41B48B0B4D168B714838@realsil.com.cn>]
* Re: 答复: 答复: 答复: 答复: RTL8192SE and 802.11n problem [not found] ` <0EF5E594196F41B48B0B4D168B714838@realsil.com.cn> @ 2011-09-29 23:15 ` Stefan Zwanenburg 2011-09-29 23:58 ` Stefan Zwanenburg 0 siblings, 1 reply; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-29 23:15 UTC (permalink / raw) To: 李朝明; +Cc: 'Larry Finger', linux-wireless On 09/29/2011 10:55 AM, 李朝明 wrote: > Dear Larry: > > I don't kown why this efuse is wrong, did Zwanenburg use the same > driver with yours ? Hi! I may be no Larry, but I just diffed the latest version of the drivers/net/wireless/rtlwifi directory (obtained from the github mirror of linus' repository) with the one from the kernel I'm currently running, and I don't notice a whole lot of changes (besides code cleanups and differences in the debugging macro "calls"), but there is something going on in efuse.c with no more "hoffset" variable in efuse_get_current size, but that shouldn't matter, as the variable was assigned but never used again. I also see there was a whole lot of work put into pci.c, as it looks it's had a revamp. I'm not sure it will fix my problems, but I'm going to try to run 3.1-rc4 and see if I can get an 802.11n link going. I'll get back to you on how that went later! Stefan Zwanenburg ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 答复: 答复: 答复: 答复: RTL8192SE and 802.11n problem 2011-09-29 23:15 ` 答复: " Stefan Zwanenburg @ 2011-09-29 23:58 ` Stefan Zwanenburg 0 siblings, 0 replies; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-29 23:58 UTC (permalink / raw) To: 李朝明; +Cc: 'Larry Finger', linux-wireless On 09/30/2011 01:15 AM, Stefan Zwanenburg wrote: > On 09/29/2011 10:55 AM, 李朝明 wrote: >> Dear Larry: >> >> I don't kown why this efuse is wrong, did Zwanenburg use the same >> driver with yours ? > Hi! > I may be no Larry, but I just diffed the latest version of the > drivers/net/wireless/rtlwifi directory (obtained from the github mirror > of linus' repository) with the one from the kernel I'm currently > running, and I don't notice a whole lot of changes (besides code > cleanups and differences in the debugging macro "calls"), but there is > something going on in efuse.c with no more "hoffset" variable in > efuse_get_current size, but that shouldn't matter, as the variable was > assigned but never used again. > I also see there was a whole lot of work put into pci.c, as it looks > it's had a revamp. I'm not sure it will fix my problems, but I'm going > to try to run 3.1-rc4 and see if I can get an 802.11n link going. > > I'll get back to you on how that went later! > > Stefan Zwanenburg Well, I just compiled 3.0-rc4, and I'm now running it, but alas, still no 802.11n link to my AP, and (perhaps unsurprisingly) the EEPROM that gets dumped upon detecting the PCI NIC is exactly the same as it was before, so there couldn't be some problem with the EFUSE reading code. I guess that leaves us with the possibility my AP is not sending some packets (see Larry's message about that) during the association, which makes the driver not work as it should... Is there anything else I can try to help you guys figure out what may be wrong? Stefan Zwanenburg PS: I'll keep running this kernel for a few days to see if I get the same problem as in mentioned in the discussion "3.1-rc6 + rtl8192se issue", even though I apparently don't have the very latest kernel source. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <4E67CE3F.8090405@gmail.com>]
[parent not found: <4E67CEA3.7020709@gmail.com>]
* Re: RTL8192SE and 802.11n problem [not found] ` <4E67CEA3.7020709@gmail.com> @ 2011-09-08 2:23 ` Larry Finger 2011-09-08 2:50 ` Larry Finger 0 siblings, 1 reply; 9+ messages in thread From: Larry Finger @ 2011-09-08 2:23 UTC (permalink / raw) To: Stefan Zwanenburg; +Cc: linux-wireless, 'Chaoming_Li' On 09/07/2011 03:05 PM, Stefan Zwanenburg wrote: > > * My NIC variant has the following ID: 10ec:8172. I suppose that means it's an > RTL8192SEvA2. I did not know this at the time of writing however. > * Kernel version: it's a vanilla kernel + gentoo patches (exact gentoo ebuild > version: 3.0.4). > * Driver: I'm using the one for the RTL8192SE that is currently in the kernel > tree, so no compat-wireless. > * Access point: 3Com 3CRWER300-73 with firmware version 1.12.06. > With kernel 3.0.4: 06:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller [10ec:8172] (rev 10) TCP_MAERTS TX Test: 29.57 33.17 37.99 38.61 37.38 35.34 37.42 14.04 36.08 34.95 TCP_MAERTS RX Test: 30.52 39.50 37.88 30.90 38.60 31.86 47.55 32.86 41.98 41.46 Results: TX: max 38.61, min 14.04. Mean 33.45(6.95) RX: max 47.55, min 30.52. Mean 37.31(5.36) TCP_STREAM TX Test: 32.11 33.20 39.19 32.24 43.94 15.74 27.74 32.75 32.85 33.12 TCP_STREAM RX Test: 35.45 34.24 35.68 34.28 35.23 31.15 30.75 36.01 35.07 35.08 Results: TX: max 43.94, min 15.74. Mean 32.29(6.93) RX: max 36.01, min 30.75. Mean 34.29(1.75) TCP_SENDFILE TX Test: 26.69 30.01 29.32 29.21 29.27 29.87 30.06 29.69 29.25 20.21 TCP_SENDFILE RX Test: 33.72 29.56 36.87 32.65 34.46 33.71 37.67 38.28 36.20 30.50 Results: TX: max 30.06, min 20.21. Mean 28.36(2.87) RX: max 38.28, min 29.56. Mean 34.36(2.79) finger@larrylap:~> iwconfig wlan0 wlan0 IEEE 802.11bgn ESSID:"lwfdjf-n" Mode:Managed Frequency:2.422 GHz Access Point: C0:3F:0E:BE:2B:44 Bit Rate=135 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=70/70 Signal level=-35 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 With kernel wireless-testing 3.1-rc4: TCP_MAERTS TX Test: 23.34 48.86 52.67 44.96 50.42112.86 41.24 46.60 50.81 45.24 TCP_MAERTS RX Test: 67.77 75.84 35.60 57.84 55.06 61.65 55.46 59.58 59.65 61.81 Results: TX: max 112.86, min 23.34. Mean 51.70(21.86) RX: max 75.84, min 35.60. Mean 59.03(9.76) TCP_STREAM TX Test: 61.92 61.14 57.27 62.02 58.43 61.41 61.34 62.39 61.45 59.49 TCP_STREAM RX Test: 23.95 39.50 32.49 53.00 44.30 43.82 48.37 45.50 50.54 50.27 Results: TX: max 62.39, min 57.27. Mean 60.69(1.62) RX: max 53.00, min 23.95. Mean 43.17(8.56) TCP_SENDFILE TX Test: 62.51 58.05 58.21 51.26 58.60 57.32 58.36 59.02 51.30 54.72 TCP_SENDFILE RX Test: 45.35 39.31 34.46 31.14 28.40 35.71 40.78 44.67 39.14 36.66 Results: TX: max 62.51, min 51.26. Mean 56.94(3.35) RX: max 45.35, min 28.40. Mean 37.56(5.16) finger@larrylap:~> iwconfig lo no wireless extensions. eth0 no wireless extensions. wlan8 IEEE 802.11bgn ESSID:"lwfdjf-n" Mode:Managed Frequency:2.422 GHz Access Point: C0:3F:0E:BE:2B:44 Bit Rate=135 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=70/70 Signal level=-35 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 It turns out the performance is quite a bit higher with 3.1-rc4 (actually 3.2 wireless) than it is with 3.0.4. If possible, could you please try the latest compat-wireless, either as a package or as downloaded source? In the meantine, I will bisect between the current wireless-testing and 3.0, and test the 3.1-rc4 aminline kernel. Larry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTL8192SE and 802.11n problem 2011-09-08 2:23 ` Larry Finger @ 2011-09-08 2:50 ` Larry Finger 2011-09-08 3:23 ` Stefan Zwanenburg 0 siblings, 1 reply; 9+ messages in thread From: Larry Finger @ 2011-09-08 2:50 UTC (permalink / raw) To: Stefan Zwanenburg; +Cc: linux-wireless, 'Chaoming_Li' Stefan, I did finish the complete set of tests with my RTL8191SEvB Wireless LAN Controller [10ec:8172] (rev 10). The results for the tests are as follows: TCP_MAERTS: kernel 3.0.4: Results: TX: max 38.61, min 14.04. Mean 33.45(6.95) RX: max 47.55, min 30.52. Mean 37.31(5.36) 3.1-rc4 - Mainline: Results: TX: max 57.70, min 42.90. Mean 52.79(3.92) RX: max 68.77, min 47.29. Mean 60.38(5.28) 3.1-rc4 - wireless-testing: Results: TX: max 112.86, min 23.34. Mean 51.70(21.86) RX: max 75.84, min 35.60. Mean 59.03(9.76) TCP_STREAM: Kernel 3.0.4: Results: TX: max 43.94, min 15.74. Mean 32.29(6.93) RX: max 36.01, min 30.75. Mean 34.29(1.75) Kernel 3.1-rc4 from mainline: Results: TX: max 59.73, min 23.48. Mean 47.59(12.33) RX: max 49.89, min 25.14. Mean 38.26(7.32) Kernel 3.1-rc4 from wireless-testing: Results: TX: max 62.39, min 57.27. Mean 60.69(1.62) RX: max 53.00, min 23.95. Mean 43.17(8.56) TCP_SENDFILE: Kernel 3.0.4: Results: TX: max 30.06, min 20.21. Mean 28.36(2.87) RX: max 38.28, min 29.56. Mean 34.36(2.79) Kernel 3.1-rc4 from mainline: Results: TX: max 70.25, min 2.64. Mean 42.59(18.30) RX: max 44.85, min 33.12. Mean 40.83(4.04) Kernel 3.1-rc4 from wireless-testing: Results: TX: max 62.51, min 51.26. Mean 56.94(3.35) RX: max 45.35, min 28.40. Mean 37.56(5.16) It seems that kernel 3.1-rc4 from mainline is quite a bit faster than 3.0.4, but I don't know why. The 3.1-rc4 driver from wireless-testing may be a bit quicker, but the difference is not that great. My next step will be to bisect the mainline tree to see if I can find a commit that has a big effect. Please open a bug at bugzilla.kernel.org on this issue, if you have not already done so, and send me the bug number. Larry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTL8192SE and 802.11n problem 2011-09-08 2:50 ` Larry Finger @ 2011-09-08 3:23 ` Stefan Zwanenburg 2011-09-08 3:42 ` Larry Finger 0 siblings, 1 reply; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-08 3:23 UTC (permalink / raw) To: Larry Finger; +Cc: linux-wireless, 'Chaoming_Li' On 09/08/2011 04:50 AM, Larry Finger wrote: > Stefan, > > I did finish the complete set of tests with my RTL8191SEvB Wireless > LAN Controller [10ec:8172] (rev 10). The results for the tests are as > follows: > > TCP_MAERTS: > > kernel 3.0.4: > > Results: TX: max 38.61, min 14.04. Mean 33.45(6.95) > RX: max 47.55, min 30.52. Mean 37.31(5.36) > > 3.1-rc4 - Mainline: > > Results: TX: max 57.70, min 42.90. Mean 52.79(3.92) > RX: max 68.77, min 47.29. Mean 60.38(5.28) > > 3.1-rc4 - wireless-testing: > > Results: TX: max 112.86, min 23.34. Mean 51.70(21.86) > RX: max 75.84, min 35.60. Mean 59.03(9.76) > > TCP_STREAM: > > Kernel 3.0.4: > > Results: TX: max 43.94, min 15.74. Mean 32.29(6.93) > RX: max 36.01, min 30.75. Mean 34.29(1.75) > > Kernel 3.1-rc4 from mainline: > > Results: TX: max 59.73, min 23.48. Mean 47.59(12.33) > RX: max 49.89, min 25.14. Mean 38.26(7.32) > > Kernel 3.1-rc4 from wireless-testing: > > Results: TX: max 62.39, min 57.27. Mean 60.69(1.62) > RX: max 53.00, min 23.95. Mean 43.17(8.56) > > TCP_SENDFILE: > > Kernel 3.0.4: > > Results: TX: max 30.06, min 20.21. Mean 28.36(2.87) > RX: max 38.28, min 29.56. Mean 34.36(2.79) > > Kernel 3.1-rc4 from mainline: > > Results: TX: max 70.25, min 2.64. Mean 42.59(18.30) > RX: max 44.85, min 33.12. Mean 40.83(4.04) > > Kernel 3.1-rc4 from wireless-testing: > > Results: TX: max 62.51, min 51.26. Mean 56.94(3.35) > RX: max 45.35, min 28.40. Mean 37.56(5.16) > > It seems that kernel 3.1-rc4 from mainline is quite a bit faster than > 3.0.4, but I don't know why. The 3.1-rc4 driver from wireless-testing > may be a bit quicker, but the difference is not that great. > > My next step will be to bisect the mainline tree to see if I can find > a commit that has a big effect. Please open a bug at > bugzilla.kernel.org on this issue, if you have not already done so, > and send me the bug number. > > Larry Before you continue down this path, I have to ask you something: do you think the rate of my connection would increase if I stress it enough? By this I mean: initially, it appears I have a (theoretical maximum) bitrate of 54Mbps upon connecting to my AP; will the bitrate increase when running something like netperf for long enough? If not, I'm not sure you understood my problem. I don't mind the bitrate so much if it weren't for the fact that I should be associating with my AP over an 802.11n link (since both my NIC and AP should be capable of this), which I cannot. The AP itself (which can display a list of its wireless clients including MAC addresses and link type) reports that I'm connected over an 802.11g link. I'd hate for you to put more time into this if we have indeed misunderstood one another. Anyway, I'm more than willing to try out the 3.1-rc4 mainline kernel if that would be of any help. However, it will have to wait until tomorrow, since it's pretty much the end of the night in my timezone, and I have a busy day tomorrow. I'll also file a bug report tomorrow, if I haven't heard back from you regarding our possible misunderstanding. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTL8192SE and 802.11n problem 2011-09-08 3:23 ` Stefan Zwanenburg @ 2011-09-08 3:42 ` Larry Finger [not found] ` <8117B559D4E64A83837479A8C342A5CA@realsil.com.cn> 0 siblings, 1 reply; 9+ messages in thread From: Larry Finger @ 2011-09-08 3:42 UTC (permalink / raw) To: Stefan Zwanenburg; +Cc: linux-wireless, 'Chaoming_Li' On 09/07/2011 10:23 PM, Stefan Zwanenburg wrote: > I cannot. The AP itself (which can display a list of its wireless > clients including MAC addresses and link type) reports that I'm > connected over an 802.11g link. > I'd hate for you to put more time into this if we have indeed > misunderstood one another. It is not a matter of "training". If the AP says it is a G connection, then the rate will never be more than 54 Mbps. > Anyway, I'm more than willing to try out the 3.1-rc4 mainline kernel if > that would be of any help. However, it will have to wait until tomorrow, > since it's pretty much the end of the night in my timezone, and I have a > busy day tomorrow. I'll also file a bug report tomorrow, if I haven't > heard back from you regarding our possible misunderstanding. I think it may be an incompatibility with that AP, but I will wait for Chaoming to check that. In any case, I would like to know what change increases the rate, thus I'll do the bisection. Larry ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <8117B559D4E64A83837479A8C342A5CA@realsil.com.cn>]
[parent not found: <4E6E537D.5060404@gmail.com>]
[parent not found: <24C6797004D84406B7564679CAE21531@realsil.com.cn>]
[parent not found: <4E74946A.3080206@gmail.com>]
[parent not found: <1903155944F64F00AC0C401593C20923@realsil.com.cn>]
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem [not found] ` <1903155944F64F00AC0C401593C20923@realsil.com.cn> @ 2011-09-19 20:04 ` Stefan Zwanenburg 0 siblings, 0 replies; 9+ messages in thread From: Stefan Zwanenburg @ 2011-09-19 20:04 UTC (permalink / raw) To: 李朝明; +Cc: 'Larry Finger', linux-wireless On 09/19/2011 06:41 AM, 李朝明 wrote: > Dear Sir: > > Yes, sniffer can help, Could you help to catch the authentication > and association packet and send it to me。 > > Best Regards， > lizhaoming > Find below the output of wpa_supplicant with the -ddd switch. If that is not the information you required (ie: you need even rawer logging or somesuch), please tell me what I need to do, or where I might find the information to do what I need to do. Initializing interface 'wlan0' conf '/home/psychotic/wpa.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/home/psychotic/wpa.conf' -> '/home/psychotic/wpa.conf' Reading configuration file '/home/psychotic/wpa.conf' ap_scan=1 ctrl_interface='DIR=/var/run/wpa_supplicant GROUP=wheel' Line: 3 - start of a new network block ssid - hexdump_ascii(len=10): 50 65 72 66 6f 72 61 74 6f 72 Perforator scan_ssid=1 (0x1) proto: 0x3 key_mgmt: 0x2 pairwise: 0x18 group: 0x18 PSK - hexdump(len=32): [REMOVED] Priority group 0 id=0 ssid='Perforator' netlink: Operstate: linkmode=1, operstate=5 Own MAC address: 1c:4b:d6:69:6a:dc wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=0 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=1 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=2 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=3 set_tx=0 seq_len=0 key_len=0 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 100000 usec EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: Supplicant port status: Unauthorized EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: Supplicant port status: Unauthorized EAPOL: Supplicant port status: Unauthorized ctrl_interface_group=10 (from group name 'wheel') Added interface wlan0 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added State: DISCONNECTED -> SCANNING Scan SSID - hexdump_ascii(len=10): 50 65 72 66 6f 72 61 74 6f 72 Perforator Starting AP scan for wildcard SSID nl80211: Scan SSID - hexdump_ascii(len=10): 50 65 72 66 6f 72 61 74 6f 72 Perforator nl80211: Scan SSID - hexdump_ascii(len=0): [NULL] Scan requested (ret=0) - scan timeout 10 seconds nl80211: Event message available nl80211: Scan trigger EAPOL: disable timer tick EAPOL: Supplicant port status: Unauthorized nl80211: Event message available nl80211: New scan results available Received scan results (8 BSSes) BSS: Start scan result update 1 BSS: Add new id 0 BSSID 80:c6:ab:1e:48:d3 SSID 'UPC0038938' BSS: Add new id 1 BSSID 00:14:7f:c6:a0:bc SSID 'SpeedTouch5E1151' BSS: Add new id 2 BSSID 00:18:f6:e9:22:07 SSID 'Thomson104ABB' BSS: Add new id 3 BSSID 00:23:cd:11:e9:c2 SSID 'Sloot' BSS: Add new id 4 BSSID 00:1e:c1:a2:01:5a SSID 'Perforator' BSS: Add new id 5 BSSID 00:1e:2a:06:c7:f8 SSID 'NETGEAR' BSS: Add new id 6 BSSID c0:c1:c0:20:c6:3f SSID 'Cisco36513' BSS: Add new id 7 BSSID 00:25:9c:df:0a:6d SSID 'Linksys-120n' New scan results available Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 80:c6:ab:1e:48:d3 ssid='UPC0038938' wpa_ie_len=28 rsn_ie_len=24 caps=0x411 skip - SSID mismatch 1: 00:14:7f:c6:a0:bc ssid='SpeedTouch5E1151' wpa_ie_len=24 rsn_ie_len=0 caps=0x411 skip - SSID mismatch 2: 00:18:f6:e9:22:07 ssid='Thomson104ABB' wpa_ie_len=28 rsn_ie_len=24 caps=0x411 skip - SSID mismatch 3: 00:23:cd:11:e9:c2 ssid='Sloot' wpa_ie_len=0 rsn_ie_len=24 caps=0x431 skip - SSID mismatch 4: 00:1e:c1:a2:01:5a ssid='Perforator' wpa_ie_len=0 rsn_ie_len=20 caps=0x411 selected based on RSN IE selected WPA AP 00:1e:c1:a2:01:5a ssid='Perforator' Automatic auth_alg selection: 0x1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 01 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 Cancelling scan request Trying to authenticate with 00:1e:c1:a2:01:5a (SSID='Perforator' freq=2442 MHz) No keys have been configured - skip key clearing State: SCANNING -> AUTHENTICATING EAPOL: External notification - EAP success=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - EAP fail=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portControl=Auto EAPOL: Supplicant port status: Unauthorized nl80211: Authenticate (ifindex=6) * bssid=00:1e:c1:a2:01:5a * freq=2442 * SSID - hexdump_ascii(len=10): 50 65 72 66 6f 72 61 74 6f 72 Perforator * IEs - hexdump(len=0): [NULL] * Auth Type 0 nl80211: Authentication request send successfully RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added nl80211: Event message available nl80211: MLME event 37 nl80211: MLME event frame - hexdump(len=30): b0 00 32 00 1c 4b d6 69 6a dc 00 1e c1 a2 01 5a 00 1e c1 a2 01 5a d0 3c 00 00 02 00 00 00 SME: Authentication response: peer=00:1e:c1:a2:01:5a auth_type=0 status_code=0 SME: Authentication response IEs - hexdump(len=0): [NULL] Trying to associate with 00:1e:c1:a2:01:5a (SSID='Perforator' freq=2442 MHz) State: AUTHENTICATING -> ASSOCIATING wpa_driver_nl80211_set_operstate: operstate 0->0 (DORMANT) netlink: Operstate: linkmode=-1, operstate=5 WPA: set own WPA/RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 nl80211: Associate (ifindex=6) * bssid=00:1e:c1:a2:01:5a * freq=2442 * SSID - hexdump_ascii(len=10): 50 65 72 66 6f 72 61 74 6f 72 Perforator * IEs - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 nl80211: Association request send successfully nl80211: Event message available nl80211: Ignored unknown event (cmd=19) nl80211: Event message available nl80211: MLME event 38 nl80211: MLME event frame - hexdump(len=55): 10 00 32 00 1c 4b d6 69 6a dc 00 1e c1 a2 01 5a 00 1e c1 a2 01 5a e0 3c 11 04 00 00 02 c0 01 08 82 84 8b 96 12 24 48 6c 32 04 0c 18 30 60 dd 07 00 0c 43 04 00 00 00 Association info event resp_ies - hexdump(len=25): 01 08 82 84 8b 96 12 24 48 6c 32 04 0c 18 30 60 dd 07 00 0c 43 04 00 00 00 freq=2442 MHz State: ASSOCIATING -> ASSOCIATED wpa_driver_nl80211_set_operstate: operstate 0->0 (DORMANT) netlink: Operstate: linkmode=-1, operstate=5 Associated to a new BSS: BSSID=00:1e:c1:a2:01:5a No keys have been configured - skip key clearing Associated with 00:1e:c1:a2:01:5a WPA: Association event - clear replay counter WPA: Clear old PTK EAPOL: External notification - portEnabled=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portValid=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - EAP success=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portEnabled=1 EAPOL: SUPP_PAE entering state CONNECTING EAPOL: enable timer tick EAPOL: SUPP_BE entering state IDLE Setting authentication timeout: 10 sec 0 usec Cancelling scan request RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added nl80211: Event message available nl80211: Ignore connect event (cmd=46) when using userspace SME RX EAPOL from 00:1e:c1:a2:01:5a RX EAPOL - hexdump(len=121): 01 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 0a 48 bf 66 e9 22 34 9a 54 97 4a d1 f4 0f 68 ea 96 50 bb 75 fd 8f 8d ae 98 95 06 c8 d6 60 fd b7 89 1b 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 16 dd 14 00 0f ac 04 3a d1 08 d5 c1 2d d5 21 fd b4 64 fb 3b 2e 1f 46 Setting authentication timeout: 10 sec 0 usec IEEE 802.1X RX: version=1 type=3 length=117 EAPOL-Key type=2 key_info 0x8a (ver=2 keyidx=0 rsvd=0 Pairwise Ack) key_length=16 key_data_length=22 replay_counter - hexdump(len=8): 00 00 00 00 00 00 0a 48 key_nonce - hexdump(len=32): bf 66 e9 22 34 9a 54 97 4a d1 f4 0f 68 ea 96 50 bb 75 fd 8f 8d ae 98 95 06 c8 d6 60 fd b7 89 1b key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 WPA: RX EAPOL-Key - hexdump(len=121): 01 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 0a 48 bf 66 e9 22 34 9a 54 97 4a d1 f4 0f 68 ea 96 50 bb 75 fd 8f 8d ae 98 95 06 c8 d6 60 fd b7 89 1b 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 16 dd 14 00 0f ac 04 3a d1 08 d5 c1 2d d5 21 fd b4 64 fb 3b 2e 1f 46 State: ASSOCIATED -> 4WAY_HANDSHAKE WPA: RX message 1 of 4-Way Handshake from 00:1e:c1:a2:01:5a (ver=2) RSN: msg 1/4 key data - hexdump(len=22): dd 14 00 0f ac 04 3a d1 08 d5 c1 2d d5 21 fd b4 64 fb 3b 2e 1f 46 WPA: PMKID in EAPOL-Key - hexdump(len=22): dd 14 00 0f ac 04 3a d1 08 d5 c1 2d d5 21 fd b4 64 fb 3b 2e 1f 46 RSN: PMKID from Authenticator - hexdump(len=16): 3a d1 08 d5 c1 2d d5 21 fd b4 64 fb 3b 2e 1f 46 RSN: no matching PMKID found WPA: Renewed SNonce - hexdump(len=32): d3 ce 10 ea a3 0b 3e b0 bc 40 91 fb f2 ee 00 a2 9e f6 a2 08 50 49 8b fe 94 93 d1 66 9c 62 92 7f WPA: PTK derivation - A1=1c:4b:d6:69:6a:dc A2=00:1e:c1:a2:01:5a WPA: PMK - hexdump(len=32): [REMOVED] WPA: PTK - hexdump(len=48): [REMOVED] WPA: WPA IE for msg 2/4 - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: Sending EAPOL-Key 2/4 WPA: TX EAPOL-Key - hexdump(len=121): 01 03 00 75 02 01 0a 00 00 00 00 00 00 00 00 0a 48 d3 ce 10 ea a3 0b 3e b0 bc 40 91 fb f2 ee 00 a2 9e f6 a2 08 50 49 8b fe 94 93 d1 66 9c 62 92 7f 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 7e 86 e7 f4 dd 37 0a c6 88 2a 45 79 ea 07 9c 2d 00 16 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 RX EAPOL from 00:1e:c1:a2:01:5a RX EAPOL - hexdump(len=155): 01 03 00 97 02 13 ca 00 10 00 00 00 00 00 00 0a 49 bf 66 e9 22 34 9a 54 97 4a d1 f4 0f 68 ea 96 50 bb 75 fd 8f 8d ae 98 95 06 c8 d6 60 fd b7 89 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f e3 04 00 00 00 00 00 00 00 00 00 00 00 00 00 72 62 5e ad 3f fa de fa a8 df 9c 8b 28 54 ac 52 00 38 af f7 5a c8 75 be 95 65 97 ce 28 db d4 84 fd 79 db 70 50 31 4e 48 5e 1b dc 04 fa c8 8f 88 ba 1f e8 55 04 60 a0 f2 a5 84 ca 78 bb de db 39 d3 18 f4 f9 26 1e 79 a0 e4 bf IEEE 802.1X RX: version=1 type=3 length=151 EAPOL-Key type=2 key_info 0x13ca (ver=2 keyidx=0 rsvd=0 Pairwise Install Ack MIC Secure Encr) key_length=16 key_data_length=56 replay_counter - hexdump(len=8): 00 00 00 00 00 00 0a 49 key_nonce - hexdump(len=32): bf 66 e9 22 34 9a 54 97 4a d1 f4 0f 68 ea 96 50 bb 75 fd 8f 8d ae 98 95 06 c8 d6 60 fd b7 89 1b key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key_rsc - hexdump(len=8): 3f e3 04 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): 72 62 5e ad 3f fa de fa a8 df 9c 8b 28 54 ac 52 WPA: RX EAPOL-Key - hexdump(len=155): 01 03 00 97 02 13 ca 00 10 00 00 00 00 00 00 0a 49 bf 66 e9 22 34 9a 54 97 4a d1 f4 0f 68 ea 96 50 bb 75 fd 8f 8d ae 98 95 06 c8 d6 60 fd b7 89 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f e3 04 00 00 00 00 00 00 00 00 00 00 00 00 00 72 62 5e ad 3f fa de fa a8 df 9c 8b 28 54 ac 52 00 38 af f7 5a c8 75 be 95 65 97 ce 28 db d4 84 fd 79 db 70 50 31 4e 48 5e 1b dc 04 fa c8 8f 88 ba 1f e8 55 04 60 a0 f2 a5 84 ca 78 bb de db 39 d3 18 f4 f9 26 1e 79 a0 e4 bf RSN: encrypted key data - hexdump(len=56): af f7 5a c8 75 be 95 65 97 ce 28 db d4 84 fd 79 db 70 50 31 4e 48 5e 1b dc 04 fa c8 8f 88 ba 1f e8 55 04 60 a0 f2 a5 84 ca 78 bb de db 39 d3 18 f4 f9 26 1e 79 a0 e4 bf WPA: decrypted EAPOL-Key key data - hexdump(len=48): [REMOVED] State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE WPA: RX message 3 of 4-Way Handshake from 00:1e:c1:a2:01:5a (ver=2) WPA: IE KeyData - hexdump(len=48): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 01 00 dd 16 00 0f ac 01 03 00 9f a8 6b 04 f7 5c 23 20 14 e0 8a bd 0e de 92 10 dd 00 WPA: RSN IE in EAPOL-Key - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 01 00 WPA: GTK in EAPOL-Key - hexdump(len=24): [REMOVED] WPA: Sending EAPOL-Key 4/4 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f 02 03 0a 00 00 00 00 00 00 00 00 0a 49 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 ca 0c ff 3c 6b 08 dd b6 71 12 6f 83 97 7f 33 4c 00 00 WPA: Installing PTK to the driver. wpa_driver_nl80211_set_key: ifindex=6 alg=3 addr=0xdc85b0 key_idx=0 set_tx=1 seq_len=6 key_len=16 addr=00:1e:c1:a2:01:5a EAPOL: External notification - portValid=1 State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE RSN: received GTK in pairwise handshake - hexdump(len=18): [REMOVED] WPA: Group Key - hexdump(len=16): [REMOVED] WPA: Installing GTK to the driver (keyidx=3 tx=0 len=16). WPA: RSC - hexdump(len=6): 3f e3 04 00 00 00 wpa_driver_nl80211_set_key: ifindex=6 alg=3 addr=0x450c7b key_idx=3 set_tx=0 seq_len=6 key_len=16 WPA: Key negotiation completed with 00:1e:c1:a2:01:5a [PTK=CCMP GTK=CCMP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:1e:c1:a2:01:5a completed (auth) [id=0 id_str=] wpa_driver_nl80211_set_operstate: operstate 0->1 (UP) netlink: Operstate: linkmode=-1, operstate=6 EAPOL: External notification - portValid=1 EAPOL: External notification - EAP success=1 EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state SUCCESS EAP: EAP entering state DISABLED EAPOL: SUPP_PAE entering state AUTHENTICATED EAPOL: Supplicant port status: Authorized EAPOL: SUPP_BE entering state IDLE EAPOL authentication completed successfully RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added EAPOL: startWhen --> 0 EAPOL: disable timer tick CTRL-EVENT-TERMINATING - signal 2 received Removing interface wlan0 wpa_driver_nl80211_deauthenticate wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=0 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=1 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=2 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x450c7b key_idx=3 set_tx=0 seq_len=0 key_len=0 wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0xdc7a80 key_idx=0 set_tx=0 seq_len=0 key_len=0 addr=00:1e:c1:a2:01:5a State: COMPLETED -> DISCONNECTED wpa_driver_nl80211_set_operstate: operstate 1->0 (DORMANT) netlink: Operstate: linkmode=-1, operstate=5 EAPOL: External notification - portEnabled=0 EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: Supplicant port status: Unauthorized EAPOL: SUPP_BE entering state INITIALIZE EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portValid=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - EAP success=0 EAPOL: Supplicant port status: Unauthorized No keys have been configured - skip key clearing BSS: Remove id 0 BSSID 80:c6:ab:1e:48:d3 SSID 'UPC0038938' BSS: Remove id 1 BSSID 00:14:7f:c6:a0:bc SSID 'SpeedTouch5E1151' BSS: Remove id 2 BSSID 00:18:f6:e9:22:07 SSID 'Thomson104ABB' BSS: Remove id 3 BSSID 00:23:cd:11:e9:c2 SSID 'Sloot' BSS: Remove id 4 BSSID 00:1e:c1:a2:01:5a SSID 'Perforator' BSS: Remove id 5 BSSID 00:1e:2a:06:c7:f8 SSID 'NETGEAR' BSS: Remove id 6 BSSID c0:c1:c0:20:c6:3f SSID 'Cisco36513' BSS: Remove id 7 BSSID 00:25:9c:df:0a:6d SSID 'Linksys-120n' Cancelling scan request Cancelling authentication timeout netlink: Operstate: linkmode=0, operstate=6 Thanks again! Stefan Zwanenburg ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-09-29 23:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4E77AECF.7090001@gmail.com>
[not found] ` <4E820130.7080801@gmail.com>
2011-09-27 21:00 ` 答复: 答复: 答复: RTL8192SE and 802.11n problem Larry Finger
2011-09-27 22:25 ` Stefan Zwanenburg
2011-09-28 4:56 ` Larry Finger
2011-09-28 23:28 ` Stefan Zwanenburg
2011-09-29 2:32 ` Stefan Zwanenburg
2011-09-29 3:28 ` Larry Finger
[not found] ` <0EF5E594196F41B48B0B4D168B714838@realsil.com.cn>
2011-09-29 23:15 ` 答复: " Stefan Zwanenburg
2011-09-29 23:58 ` Stefan Zwanenburg
[not found] <4E67CE3F.8090405@gmail.com>
[not found] ` <4E67CEA3.7020709@gmail.com>
2011-09-08 2:23 ` Larry Finger
2011-09-08 2:50 ` Larry Finger
2011-09-08 3:23 ` Stefan Zwanenburg
2011-09-08 3:42 ` Larry Finger
[not found] ` <8117B559D4E64A83837479A8C342A5CA@realsil.com.cn>
[not found] ` <4E6E537D.5060404@gmail.com>
[not found] ` <24C6797004D84406B7564679CAE21531@realsil.com.cn>
[not found] ` <4E74946A.3080206@gmail.com>
[not found] ` <1903155944F64F00AC0C401593C20923@realsil.com.cn>
2011-09-19 20:04 ` 答复: 答复: 答复: " Stefan Zwanenburg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).