5G Client packets dropped (packet size exceeded?) on 7982 in standalone bridge mode

  • 1
  • Question
  • Updated 1 year ago
I've got 4 7982 boxes running in stand-alone bridge mode, and have been running okay, however this morning I suddenly had seemingly everyone connecting to one of the WAPs no longer get any connectivity on their Macs (which all seemed to be connected using 5G).

To be clear, a connection to the access point was established successfully, but they weren't receiving any traffic.

My old laptop I use for admin work is a 2.4G-only capable machine, and that had no problem, so presumably it was only a 5G issue.

Looking at the logs, I saw a lot of lines like:

user.debug kernel: [bridge forward] packet size(1508) exceed dev(eth1) mtu(1500)... drop it... 
user.debug kernel: [bridge forward] packet size(1502) exceed dev(eth1) mtu(1500)... drop it... 
user.debug kernel: [bridge forward] packet size(1508) exceed dev(eth1) mtu(1500)... drop it... 
user.debug kernel: [bridge forward] packet size(1508) exceed dev(eth1) mtu(1500)... drop it... 

where eth1 is:

1 eth1 None Up Up 1000Mbps full 10/100/1000

Trunk Port, Bridge to WAN, 802.1X disabled.

Running firmware is 9.7.1.0.32.

I checked the MTU of a couple of the clients, and they were all set to 1500.

The 7982 is connected to a Cisco SGE2010 which does *not* have Jumbo Frames enabled, and no network devices were being administrated at the time.

Restarting the WAP made the problem go away, however I would like to get to the bottom of this to avoid it happening in future.
Photo of Adam Bolte

Adam Bolte

  • 4 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 716 Posts
  • 151 Reply Likes
first upgrade the AP to 9.8.2.0.15.
are there other logs apart from what you posted above?
you mentioned only one AP was impacted out of 4, how are the other AP's different? i mean in terms of fimware version, config, do you see those logs in those other AP's too?

if problematic AP is running on channefly or smartselect then disable it for testing and observe.
(Edited)
Photo of Adam Bolte

Adam Bolte

  • 4 Posts
  • 0 Reply Likes
The other access points are all good. So was this one until suddenly it was not. There were no other log messages of note on the AP with the problem.

I did see the log on two other WAPs when I searched for it, but they happened very rarely. One WAP had two of those in its history, and the other had three. However when we experienced the failure, there were many such messages on that specific WAP.

I'll give upgrading a go.
Photo of smaldo

smaldo

  • 2 Posts
  • 0 Reply Likes
Hi, we're seeing the same issue.

Did you find a resolution?

Thanks.
Photo of Adam Bolte

Adam Bolte

  • 4 Posts
  • 0 Reply Likes
No. We have tried different firmwares as suggested, without success. It happens probably once every month on average, and we just have to reboot it when it occurs.

Quite frustrating, since consumer-grade WAPs are generally more reliable and about 10% of the cost.
Photo of smaldo

smaldo

  • 2 Posts
  • 0 Reply Likes
Thanks for your reply Adam. We've done all the usual to fix the issue but still experience the problem every few weeks.

Easier to throw the APs in the bin and get a cheapo replacement....
Photo of Adam Bolte

Adam Bolte

  • 4 Posts
  • 0 Reply Likes
One odd thing about the issue is that it only happens on one of our WAPs. All are configured in stand-alone, all configured to work the same way. Makes me suspect the issue could be with hardware... but no suggestion it's faulty from Ruckus, and I can't reproduce the problem easily to demonstrate or verify the issue has been resolved. The WAP has the worst kind of problem basically.