RTL8192SE and 802.11n problem
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 31 lines · Stefan Zwanenburg
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 <[email protected]>
To: 李朝明 <[email protected]>
CC: 'Larry Finger' <[email protected]>Quoted 9 lines · Stefan Zwanenburg
Quoted 8 lines · 李朝明
Dear Sir:
Yes, sniffer can help, Could you help to catch the authentication
and association packet and send it to me。Best Regards，
lizhaoming
Quoted 6 lines
Quoted 4 lines
Find below the output of
wpa_supplicantwith 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): 0x0000Your 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: 0x0000This 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
Quoted 4 lines · Larry Finger
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
Quoted 19 lines · Stefan Zwanenburg
Quoted 4 lines · Larry Finger
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.
Quoted 6 lines
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
Quoted 7 lines · Larry Finger
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
Quoted 12 lines · Stefan Zwanenburg
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.c2011-07-22
04:17:23.000000000 +0200
+++/home/psychotic/Desktop/rtl8192se_hw.c2011-09-29
01:16:09.361978051 +0200(quoted diff) +0
-0@@ -1645,6 +1645,13 @@ RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"), hwinfo, HWSET_MAX_SIZE_92S);
Review line 1657
Quoted 10 lines
(quoted diff) +7
-0+ 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.
Stefan,
I dumped my EEPROM data and compared it with yours. The diffs are as follows:
yours 2011-09-28 21:58:27.000000000 -0500 renamed from mine 2011-09-28 21:58:26.000000000 -0500 +5 -5
@@ -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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · 李朝明
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
Quoted 18 lines · Stefan Zwanenburg
Quoted 4 lines · 李朝明
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 thedrivers/net/wireless/rtlwifidirectory (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 inefuse.cwith no more "hoffset" variable inefuse_get_currentsize, 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 intopci.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.
Quoted 3 lines
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.