• May 19, 2025, 02:45:06 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Author Topic: cyclic packet loss with wireless N  (Read 7293 times)

honvl

  • Level 1 Member
  • *
  • Posts: 4
cyclic packet loss with wireless N
« on: February 15, 2010, 05:06:30 AM »

I am getting cyclic packet loss in wireless N mode with the DIR-655. All firmware versions that I have tried including 1.33 have the same issue. Every fourth ping to the router will time out. When set to Wireless G only mode, the connection is stable. My wireless adapter is an Intel 4965AGN with recent drivers, and in wireless N mode the router is set to 20Mhz only. Does anyone have any ideas about this strange behavior?
Logged

EddieZ

  • Level 10 Member
  • *****
  • Posts: 2494
Re: cyclic packet loss with wireless N
« Reply #1 on: February 15, 2010, 10:41:51 AM »

I am getting cyclic packet loss in wireless N mode with the DIR-655. All firmware versions that I have tried including 1.33 have the same issue. Every fourth ping to the router will time out. When set to Wireless G only mode, the connection is stable. My wireless adapter is an Intel 4965AGN with recent drivers, and in wireless N mode the router is set to 20Mhz only. Does anyone have any ideas about this strange behavior?

could you let PING run for 30 sec or so and post the output?
Logged
DIR-655 H/W: A2 FW: 1.33

honvl

  • Level 1 Member
  • *
  • Posts: 4
Re: cyclic packet loss with wireless N
« Reply #2 on: February 19, 2010, 10:52:19 AM »

Pinging 192.168.0.1 with 32 bytes of data:
Request timed out.
Reply from 192.168.0.1: bytes=32 time=231ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Request timed out.
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Request timed out.
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Request timed out.
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Request timed out.
Logged

honvl

  • Level 1 Member
  • *
  • Posts: 4
Re: cyclic packet loss with wireless N
« Reply #3 on: February 23, 2010, 06:21:46 PM »

Solved. DIR-655 cannot handle the load of changing the wireless N MCS causing the packet loss. Workaround was to change the wireless rate from Best (automatic) to MCS 13 to reduce the load.
Logged

bigeyes0x0

  • Level 3 Member
  • ***
  • Posts: 163
Re: cyclic packet loss with wireless N
« Reply #4 on: February 23, 2010, 07:15:43 PM »

Or might be you have a unit with flaky radio, you might want to bring it to D-Link service for a check.
Logged

leowood

  • Level 1 Member
  • *
  • Posts: 13
Re: cyclic packet loss with wireless N
« Reply #5 on: February 23, 2010, 09:55:56 PM »

I am getting cyclic packet loss in wireless N mode with the DIR-655. All firmware versions that I have tried including 1.33 have the same issue. Every fourth ping to the router will time out. When set to Wireless G only mode, the connection is stable. My wireless adapter is an Intel 4965AGN with recent drivers, and in wireless N mode the router is set to 20Mhz only. Does anyone have any ideas about this strange behavior?

Maybe it caused by Intel 4965AGN auto power saving function, would you disable Intel adaptor power saving then try again? pls check below link for detail

http://www.intel.com/support/wireless/wlan/sb/cs-006205.htm
Logged

honvl

  • Level 1 Member
  • *
  • Posts: 4
Re: cyclic packet loss with wireless N
« Reply #6 on: February 24, 2010, 02:16:25 AM »

Adapter power saving was not on. I'm using a different adapter now based on Ralink 27xx chipset and it had the same issue until I did that fix.
Logged