Re: Problems associating with RTL8188CE

[Seth Forshee <seth.forshee@canonical.com>]

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