WAP200 not passing LAN unicasts to wireless clients

Unanswered Question
Sep 4th, 2009

Hi everyone,

I am reposting from this forum:  http://www.linksysinfo.org/forums/showthread.php?t=59895

From:  Dopfish

Hi, I'm having problems with the Linksys WAP200. When using WPA/WPA2 Enterprise the client hangs for about 60 seconds trying to obtain an IP after successful authentication. Accesspoints from other vendors don't show this behavior.

I did a tcpdump and comapred a working accesspoint from a different vendor to the WAP200, and it seems the WAP200  is discarding the DHCP offers that are sent via unicast. When the dhcp server sends a offer via broadcast after 65 seconds, it reaches the client and all goes well.

This is clearly buggy since the accesspoint seems to be filtering out the DHCP replies, is there an option to fix this? Or any tips on keywords I could use to find some help via google?

I can't imaging I'm the only person out there using WPA/WPA2 Enterprise and DHCP?

From:  thebeck

I am having the same problem.  Firmware 1.0.22.

Folks from Cisco, any chance you can confirm this?  I am noticing that it is not just DHCP unicast traffic that is being dropped, but pretty much all unicast LAN traffic is not making its way to the wireless clients that are connected to the WAP200.

My setup is as follows:

Firmware:  1.0.22  (I did reset to factory defaults after installing the firmware)

No VLAN's.

Security:  WPA2-Personal

Wireless Network Mode:  G-only

Wireless Channel:  10  (hard-set)

Key Renewal Timeout:  99,999 seconds

CTS Protection Mode:  Disabled

BSSBasicRateSet:  G-only

Power Output:  100%

Beacon Interval:  100

DTIM Interval:   1

RTS Threshold:  2347

Fragmentation Threshold:  2346

Router:  RVS4000 (Firmware:  1.2.11)

P.S.  Is this related to the following thread:  https://www.myciscocommunity.com/message/14725

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
David Hornstein Sun, 09/06/2009 - 09:09

Hi thebeck,

I notice in the wireless setting above, you mention WPA-Personal  and not WPA-Enterprise, is that a mistake?

I also notice that you must be using a unix server of some kind (probably Linux) to perform the radius authentication of the WAP user.

I am guessing that you have also setup DHCP services on the unix server?

Have you disabled the DHCP on the  RVS4000 or have setup DHCP relay to this Unix server, is that correct?  (As a dhcp relay usually results in a unicast response)

It sure makes sense for that Unix server to be doing both the Radius authentication services associated with WPA2-Enterprise and also  DHCP services, I'm guessing (hoping) that is what you are doing ? If this is the case turn off DHCP on the RVS4000 and give it a go on the unix platform. .

regards Dave

thebeck76 Mon, 09/07/2009 - 14:16

Hi Dave,

Thank you for getting back to me.  I am, indeed, running a WPA2-Personal Wifi environment.  I do not have a RADIUS server.  My RVS4000 is configured as the DHCP server in my network.  My network is a home-office connected with three (3) other office locations, of which all are using the RVS4000's VPN tunnel capability (by the way, the VPN tunnel between the locations is woking great!).

My laptop, which is a Dell D620, usually takes about 45+ seconds to obtain an IP address.  This time is measured as the duration between when I turn on the wireless radio and when the wifi software on the laptop reports that it is connected (i.e., by showing a small popup window with the IP address).  Between that time, doing a ping in a command prompt to the gateways yields no route to host.  As soon as I am connected, the pings return (again, after ~45+ seconds).

Other network discovery services that I use (i.e., UPnP, mDNS, iTunes Server, etc.) seem to take forever to resolve (leading me to believe that unicast and/or multicast broadcast packets are not getting through).

When I hardwire into the RVS4000, all my network discovery services work extremely well and DHCP allocation takes a fraction of a second.

Considering this, do you suspect there is an issue with my WAP200?

David Hornstein Mon, 09/07/2009 - 17:01

Hi Thebeck,

The 45 seconds sounds like the bootup time for the WAP200, so i am not concerned about that.

Just out of interest, from your wireless PC try the following and write down the  average response times for each of these three steps.

step 1.   from your wireless PC command line,   ping the RVS4000 LAN IP address

average response time=

average for mine from wireless PC to Router=  average 2 ms

step 2.  From your wireless PC command line, ping to your DNS server on the internet

average response time=

average for mine from wireless PC to DNS server=  average 17 ms

step 3.  On the RVS4000 Administration>Diagnostics tab,  ping the same DNS server in step 2

average response time=

  average for mine from RVS4000=  average 22 ms ( that's a bit wierd i only did it once)

Paste the results of the windows command line option     ipconfig /all

What do you mean by the statement you are running mDNS on your wireless PC ?

regards Dave

thebeck76 Thu, 09/10/2009 - 19:47

Hi Dave,

Thank you for the reply.  Sorry for the delay on my end.  I have been traveling.  Below are the ping results you requested.  Can you please help me understand what you mean by "bootup time?"

In regards to mDNS, I do a lot of work on PC and Mac.  The mDNS services on my network take forever to resolve from my Mac when over wireless, but resolve immeidately when hard wired to the RVS4000.  Any thoughts as to why?

Regards,

thebeck

Step 1:  Wireless PC to Router

C:\>ping 192.168.150.1

Pinging 192.168.150.1 with 32 bytes of data:

Reply from 192.168.150.1: bytes=32 time=41ms TTL=64
Reply from 192.168.150.1: bytes=32 time=7ms TTL=64
Reply from 192.168.150.1: bytes=32 time=10ms TTL=64
Reply from 192.168.150.1: bytes=32 time=7ms TTL=64

Ping statistics for 192.168.150.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 41ms, Average = 16ms

Step 2:  Wireless PC to DNS Server

C:\>ping 68.87.76.182

Pinging 68.87.76.182 with 32 bytes of data:

Reply from 68.87.76.182: bytes=32 time=39ms TTL=59
Reply from 68.87.76.182: bytes=32 time=27ms TTL=59
Reply from 68.87.76.182: bytes=32 time=23ms TTL=59
Reply from 68.87.76.182: bytes=32 time=29ms TTL=59

Ping statistics for 68.87.76.182:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 39ms, Average = 29ms

Step 3:  Router to DNS Server

PING 68.87.76.182 (68.87.76.182): 60 data bytes
68 bytes from 68.87.76.182: icmp_seq=0 ttl=60 time=17.5 ms
68 bytes from 68.87.76.182: icmp_seq=1 ttl=60 time=10.6 ms
68 bytes from 68.87.76.182: icmp_seq=2 ttl=60 time=13.1 ms

--- 68.87.76.182 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 10.6/13.7/17.5 ms

Step 1:  Wireless Mac to Router

/$ ping 192.168.150.1

PING 192.168.150.1 (192.168.150.1): 56 data bytes

64 bytes from 192.168.150.1: icmp_seq=0 ttl=64 time=6.569 ms

64 bytes from 192.168.150.1: icmp_seq=1 ttl=64 time=6.059 ms

64 bytes from 192.168.150.1: icmp_seq=2 ttl=64 time=6.612 ms

64 bytes from 192.168.150.1: icmp_seq=3 ttl=64 time=6.692 ms

^C

--- 192.168.150.1 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/ang/max/stddev = 6.059/6.483/6.692/0.249 ms

Step 2:  Wireless Mac to DNS Server

/$ ping 68.87.76.182

PING 68.87.76.182 (68.87.76.182): 56 data bytes

64 bytes from 68.87.76.182: icmp_seq=0 ttl=64 time=19.466 ms

64 bytes from 68.87.76.182: icmp_seq=1 ttl=64 time=17.529 ms

64 bytes from 68.87.76.182: icmp_seq=2 ttl=64 time=34.397 ms

64 bytes from 68.87.76.182: icmp_seq=3 ttl=64 time=23.429 ms

^C

--- 192.168.150.1 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/ang/max/stddev = 17.529/23.705/34.397/6.529 ms

David Hornstein Sat, 09/12/2009 - 08:27

Hi Thebeck,

I was hoping to see if your ping response times was indicative  of a transport problem between the WAP and router.  The results sure didn't indicate  any problem at all. So i have to guess at this point that the problem has to do with application rather than transport.

I think you may have to resort to looking at the packet trace on the MAC.

Can you download a copy of wireshark that will work on the Apple MAC and collect a capture which we can have a look at, when you try to renew DHCP?

Also, you mentioned this doesn't happen when the MAC is connected directly to the router.

For the sake of comparison, can you also make a second capture, named Good_DHCP, which will be  a successful DHCP renew from the MAC when connected directly to the router?

Don't need to capture too much.

Your comments concerning something slowing down broadcasts and multicasts on the WAP200.  I'm a bit skeptical at the moment regarding your statement, because part of the product or routing locally at Layer 3 is sending out ARP broadcasts.  If broadcasts didn't work, you wouldn't be able to route at layer 2 or 3.

Unfortunately we have to resort to seeing what's happening on a wireshark capture of a DHCP release and renew on the MAC. :-)

regards Dave

Actions

This Discussion