Hello,
I'm attempting to use an rtl8192cu based USB wifi adapter in Access
Point mode with the hostapd software on a very small 3-chip iMX233 ARM
system. I can run the adapter fine using the driver in station mode
and I'm able to connect to wifi network. However, I'm not having much
luck running the adapter in Access Point mode. I've seen hints in the
Linux Wireless email archives that there seems to be issues with the
rtlwifi/rtl8192cu driver in access point mode. Has anyone had success
with this driver in access point mode?
Basically, a remote station (a Windows laptop in this case) can
connect to the rtl8192cu based access point configured as an open
network. However, I'm unable to ping from the laptop to the access
point or back the other way. Using tcpdump on the access point, I can
see the ARP requests from the laptop arriving on the access point and
the response being sent, but the laptop never seems to receive the ARP
response. Likewise, the ARP requests from the access point never seem
to arrive at laptop. However, if I manually create entries in the ARP
tables for each device, I can then ping and other traffic will begin
to flow over the wireless connection without apparent problems -- even
subsquent ARP requests are passed. It's almost as if regular IP
packets can be transmitted from the station, but ARP type packets
won't flow until IP packets have proceeded the ARP packets which won't
occur until the ethernet/IP addressing has been resolved.
I'm currently using a very recent compat-wireless driver from
2012-07-03 with an older 2.6.35 kernel. I've tried at least three
prior versions of the rtlwifi/rtl8192cu driver (between 2.6.35 to
3.5), but they all exhibit the same symptom.
Any hints on where I can begin debugging the issue?
Thanks,
Mike Thompson
I'll see what I can do to set up wireshark or kismit. Also, as
suggested in the IRC forum I'm going to try to switch to debugging the
rtl8192cu driver on a PC where I'll have a lot more tools available to
analyze debug output from the driver.
I'll write back to this thread once I have more information what might
be happening to the ARP packets.
Thanks,
Mike Thompson
On Wed, Aug 8, 2012 at 7:59 AM, Larry Finger <[email protected]> wrote:
> Do you have a 3rd system that can use wireshark or kismet to capture the
> data on the air? That way we would know if the ARP responses are being lost
> inside rtl8192cu, or if they are just being badly formatted and being
> rejected by the laptop's receiver.
>
> Larry
>
On 08/08/2012 02:53 AM, Mike Thompson wrote:
> Hello,
>
> I'm attempting to use an rtl8192cu based USB wifi adapter in Access
> Point mode with the hostapd software on a very small 3-chip iMX233 ARM
> system. I can run the adapter fine using the driver in station mode
> and I'm able to connect to wifi network. However, I'm not having much
> luck running the adapter in Access Point mode. I've seen hints in the
> Linux Wireless email archives that there seems to be issues with the
> rtlwifi/rtl8192cu driver in access point mode. Has anyone had success
> with this driver in access point mode?
>
> Basically, a remote station (a Windows laptop in this case) can
> connect to the rtl8192cu based access point configured as an open
> network. However, I'm unable to ping from the laptop to the access
> point or back the other way. Using tcpdump on the access point, I can
> see the ARP requests from the laptop arriving on the access point and
> the response being sent, but the laptop never seems to receive the ARP
> response. Likewise, the ARP requests from the access point never seem
> to arrive at laptop. However, if I manually create entries in the ARP
> tables for each device, I can then ping and other traffic will begin
> to flow over the wireless connection without apparent problems -- even
> subsquent ARP requests are passed. It's almost as if regular IP
> packets can be transmitted from the station, but ARP type packets
> won't flow until IP packets have proceeded the ARP packets which won't
> occur until the ethernet/IP addressing has been resolved.
>
> I'm currently using a very recent compat-wireless driver from
> 2012-07-03 with an older 2.6.35 kernel. I've tried at least three
> prior versions of the rtlwifi/rtl8192cu driver (between 2.6.35 to
> 3.5), but they all exhibit the same symptom.
>
> Any hints on where I can begin debugging the issue?
Do you have a 3rd system that can use wireshark or kismet to capture the data on
the air? That way we would know if the ARP responses are being lost inside
rtl8192cu, or if they are just being badly formatted and being rejected by the
laptop's receiver.
Larry
On Wed, Aug 8, 2012 at 7:59 AM, Larry Finger <[email protected]> wrote:
> Do you have a 3rd system that can use wireshark or kismet to capture the
> data on the air? That way we would know if the ARP responses are being lost
> inside rtl8192cu, or if they are just being badly formatted and being
> rejected by the laptop's receiver.
>
> Larry
I spent quite a while today getting a third system setup with kismet
(to capture wifi packets) and wireshark (to parse the captured data)
to try and understand what is happening to ARP packets after a station
connects with an rtl8192cu access point.
As best I can tell, I believe the ARP responses are getting lost in
the rtl8192cu driver (or higher level driver). With kismet, I can see
the ARP request wifi packets and the same packets in tcpdump on the
access point. In tcpdump I also see the ARP reply, but looking at the
kismet data I never to see the ARP replies as wifi packets.
Below is what the tcpdump output on the access point looks like with
the request and reply:
192.168.2.1 is the access point
192.168.2.12 is the laptop
06:37:54.692374 ARP, Request who-has 192.168.2.1 tell 192.168.2.12, length 28
06:37:54.692343 ARP, Request who-has 192.168.2.1 tell 192.168.2.12, length 28
06:37:54.692937 ARP, Reply 192.168.2.1 is-at 48:02:2a:87:de:80 (oui
Unknown), length 28
06:37:56.053595 ARP, Request who-has 192.168.2.1 tell 192.168.2.12, length 28
06:37:56.053595 ARP, Request who-has 192.168.2.1 tell 192.168.2.12, length 28
06:37:56.054158 ARP, Reply 192.168.2.1 is-at 48:02:2a:87:de:80 (oui
Unknown), length 28
The wifi traffic at the same time from kismet is below:
"56","40.857513","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
"57","40.859533","","Hewlett-_59:0b:c5
(RA)","802.11","42","Acknowledgement, Flags=........"
"58","40.861631","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
"59","41.858298","","Hewlett-_59:0b:c5
(RA)","802.11","42","Acknowledgement, Flags=........"
"60","41.860352","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
"61","42.856317","","Hewlett-_59:0b:c5
(RA)","802.11","42","Acknowledgement, Flags=........"
"62","42.858489","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
"63","44.515521","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
"64","44.516703","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
"65","44.519614","Hewlett-_59:0b:c5","Broadcast","ARP","92","Who has
192.168.2.1? Tell 192.168.2.12"
I've put the kismet logs at the following URLs:
http://home.comcast.net/~michael.p.thompson/rtl8192cu/kismet_packet_dump.csv
http://home.comcast.net/~michael.p.thompson/rtl8192cu/kismet_packet_dump.pcapdump
I guess the next step is to put tracing breadcrumbs in the rtl8192cu
driver code where packets are sent out and make sure the ARP responses
are getting to the driver and perhaps see where they might be getting
tossed.
BTW, something I find curious in the rtlwifi drivers is that in file
ps.c in functions rtl_ips_nic_on() and rtl_ips_nic_off_wq_callback()
there is the following code:
if (mac->opmode != NL80211_IFTYPE_STATION)
return;
Does this imply that if the driver is in access point or adhoc mode
that the nic will not be turned on and off? I'm wondering if the
packets are flowing, but the transmitter is not being turned on when
it should when driver is in access point mode. I did try to remove
this test, but it didn't seem to impact the symptoms.
Mike