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?

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

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

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