Packet to client x reached max retries, removing the client

Unanswered Question
Apr 16th, 2009

I routinely get this error for just a couple of clients on my AP-and they often get disconnected as a result. Updating the firmware/driver on these clients is not an option (proprietary systems) and a carrier busy test shows I'm fine. After much searching though, I found the “packet retries 128 drop-packet” command at http://www.cisco.com/en/US/products/hw/wireless/ps4555/products_qanda_item09186a0080094cdc.shtml and this has resolved the issue. My question is, does anyone know the pros and cons of using this command? I'm assuming there must be some cons to this magic command or Cisco would have made it the default.

Thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
jeff.kish Thu, 04/16/2009 - 07:52

When a client roams, it's supposed to send the AP a disassociation packet with information about the roam. However, if a client simply shuts down or otherwise roams and is unable to deliver this packet, the AP needs to know to clear it out somehow. As such, when a packet is sent to a client X number of times, and the client never responds, the AP assumes that the client is no longer associated and drops it.

Increasing the amount of retries is probably not a terrible idea. The "problem" is that it will take an AP much longer to decide that a client is no longer there. The only disadvantage I can think of is that the client will remain in the association table longer, and this is only a problem if you have a client limitation on the AP. Your AP will also repeat a packet 128 times to a client that isn't there, thus consuming bandwidth. But 128 packets isn't exactly a ton.

Really, it's just a matter of keeping things clean and tidy. You want your APs to know when a client is no longer there, but you don't want it to prematurely drop your clients. I would try to reduce it as much as possible while still maintaining client associations.

Jeff

Daniel M Thu, 04/16/2009 - 08:16

Jeff,

Thanks for the excellent explanation. By default, the AP is configured for packet retries 64, and no drop-packet-so I assume after 64 retires, the client is disassociated. As such, does drop-packet mean the client will never be disassociated unless the AP receives a disassociation packet from a client? Or is there yet another mechanism that the AP uses for this? While I'm not too concerned about this, the AP also has an SSID for guests-and since this command is set at the radio level and not the SSID level, I now have some concern about the association table filling due to the varied guests.

Thanks again.

jeff.kish Thu, 04/16/2009 - 12:46

I'm not sure what "drop-packet" does. What's the full command? I couldn't find it on my AP.

I'd try to fine-tune the setting a bit. Maybe try 90 packets, then 80... just keep lowering it until you see drops again. Then increase by 5 or 10 and leave it there. And I wouldn't worry about the clients in the association table unless you're limiting the clients that are allowed on an SSID. If issues develop, keep this config in mind, but I highly doubt you'll see any issues.

Daniel M Thu, 04/16/2009 - 13:15

I will start playing with the number of retries. The full command is “packet retries 128 drop-packet,” but you can omit drop-packet from the command as well.

Thanks for your thoughts/insight.

CSCO11178125 Thu, 08/15/2013 - 02:40

Hello!

I have found this problem too. The MAC-address is from Macbook.

Packet to client xxxx.xxxx.xxxx reached max retries, removing the client

I solved it via:

interface Dot11Radio0

rts threshold 512

rts retries 128

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode