On Mon, Nov 21, 2011 at 08:20:08PM -0600, Seth Forshee wrote: > On Mon, Nov 21, 2011 at 08:01:50PM -0600, Larry Finger wrote: > > On 11/21/2011 12:56 PM, Seth Forshee wrote: > > >On Mon, Nov 21, 2011 at 12:34:52PM -0600, Larry Finger wrote: > > >>On 11/21/2011 12:13 PM, Seth Forshee wrote: > > >>> > > >>>I've uploaded the capture along with the logs to > > >>>http://people.canonical.com/~sforshee/rtl8188ce/. > > >> > > >>Unfortunately, I do not have permission to access the pcap file. The > > >>other two are OK, but not the one of interest. > > > > > >Sorry about that, didn't notice the lack of permissions. Fixed now. > > > > I got it now. I would like one other piece of information - what is > > the MAC address of your RTL8188CE device? It is not found in any of > > the dmesg logs that I have. > > 7c:4f:b5:c7:a5:53 Larry, I've been trying to look into this myself over the last couple of days, but I'm still trying to learn all of this 802.11 stuff. I've kind of hit the limit of what knowledge I've acquired so far, so I'd appreciate it if you could look at my findings and offer suggestions. What I'm doing is running wpa_supplicant manually to try and initiate a connection while monitoring the traffic with wireshark on a separate machine. What I'm seeing is that when the rtl8192ce device sends a probe request or authentication request, the majority of the time the AP sends a response but the adapter fails to ack the response (I don't see the ack in the wireshark capture, and the AP resends the probe response several times). The logs show timeouts that correspond to the types of responses that aren't being acked. It's as if the adapter doesn't see the responses at all. I have another AP that the rtl8192ce doesn't have any problems associating with, so I also captured a trace with wireshark when associating to that AP. I didn't see much that differed except that the probe response frame with the problematic AP is about 350 bytes longer (due to additional information elements). Something else that I noticed is that with the problematic AP, inactive power save seems to kick in shortly afer sending the probe/authentication requests. I wondered if this might be behind the issues, but loading the module with ips=0 makes no difference. Any suggestions on what might be going wrong or next steps for debugging? Thanks, Seth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html