Buffer Memory and Dropped Packets

[KebabFan]

Hello,

For the past few months I've been dealing with some Wifi connection issues (possibly multiple at once) on my AX88U (firmware version: 388.1) router.
The issue in question, is when the router has booted up and the wifi access point is visible, a device usually can connect no problem. After a few hours/days, when more devices have connected, if that device disconnects then attempts to reconnect, it will fail. It will mostly fail before "Obtaining an IP Address" is shown but sometimes after.

Things I have tried:
- Multiple Factory Resets.
- Changing routers to an old AC86U.
- Changing the IP addresses used from 10.1.x.x to 192.168.x.x
- Reverting the firmware to version 384.14

Note: Changing the router and IP addresses, appeared to fix the issue, but after a few days the issue resurfaced.


So, why am i posting?
I have two question to hopefully get answered that may or may not relate to my issue.

1. Is it normal to have a 0.00 MB buffer? If not, how do I set the buffer size? (photo attached below) (I think it might be because I think that measurement might be in real-time)
2. How can I determine what the reason for all the dropped packets on both wireless interfaces is? (photo attached below) (eth6 =2.4Ghz, eth7 =5Ghz)


Any additional information is appreciated
Thank you

 

[drinkingbird]

Hello,

For the past few months I've been dealing with some Wifi connection issues (possibly multiple at once) on my AX88U (firmware version: 388.1) router.
The issue in question, is when the router has booted up and the wifi access point is visible, a device usually can connect no problem. After a few hours/days, when more devices have connected, if that device disconnects then attempts to reconnect, it will fail. It will mostly fail before "Obtaining an IP Address" is shown but sometimes after.

Things I have tried:
- Multiple Factory Resets.
- Changing routers to an old AC86U.
- Changing the IP addresses used from 10.1.x.x to 192.168.x.x
- Reverting the firmware to version 384.14

Note: Changing the router and IP addresses, appeared to fix the issue, but after a few days the issue resurfaced.


So, why am i posting?
I have two question to hopefully get answered that may or may not relate to my issue.

1. Is it normal to have a 0.00 MB buffer? If not, how do I set the buffer size? (photo attached below) (I think it might be because I think that measurement might be in real-time)
2. How can I determine what the reason for all the dropped packets on both wireless interfaces is? (photo attached below) (eth6 =2.4Ghz, eth7 =5Ghz)


Any additional information is appreciated
Thank you

I think that means nothing is currently buffered which is good. Not positive on that though.

It is normal to see some loss on wireless interfaces but that seems excessive, your drops are higher than the total packets which makes no sense. Maybe a cosmetic issue.

But if you've had this issue with multiple routers, code versions, etc there seems to be something else at play. Do you have QOS, custom scripts, anything like that? What shows in the log when a client is trying to reconnect but not able to?

 

[KebabFan]

Ok, then Ill just monitor the buffer to see if it changes with an increase in workload.

As for the QoS, Custom Script and other stuff? None of that is enabled or used.
When ever I have factory reset the router the only settings I configure are the VPN Client, adding devices to the DHCP Manual Assignment list, changing the Wifi Channels to less congested ones and setting the IP Address Range.

This is the log when a device tries to reconnect and fails:

Feb 1 12:11:54 wlceventd: wlceventd_proc_event(505): eth6: Auth EC:FA:BC:5E:C1:55, status: Successful (0)
Feb 1 12:11:54 wlceventd: wlceventd_proc_event(534): eth6: Assoc EC:FA:BC:5E:C1:55, status: Successful (0)
Feb 1 12:11:54 hostapd: eth6: STA ec:fa:bc:5e:c1:55 IEEE 802.11: associated
Feb 1 12:11:54 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Feb 1 12:11:58 kernel: DROP IN=ppp0 OUT= MAC= SRC=219.78.245.194 DST=60.241.210.145 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=43665 DF PROTO=TCP SPT=53856 DPT=22596 SEQ=260751269 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (0204059C0103030801010402) MARK=0x8000000
Feb 1 12:11:58 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind F4:CF:A2:34:40:E8, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 1 12:11:58 wlceventd: wlceventd_proc_event(486): eth6: Disassoc F4:CF:A2:34:40:E8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 1 12:11:58 wlceventd: wlceventd_proc_event(486): eth6: Disassoc F4:CF:A2:34:40:E8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 1 12:11:58 hostapd: eth6: STA f4:cf:a2:34:40:e8 IEEE 802.11: disassociated
Feb 1 12:11:58 hostapd: eth6: STA f4:cf:a2:34:40:e8 IEEE 802.11: disassociated
Feb 1 12:11:58 hostapd: eth6: STA f4:cf:a2:34:40:e8 IEEE 802.11: disassociated
Feb 1 12:12:00 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind EC:FA:BC:5E:C1:55, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 1 12:12:00 hostapd: eth6: STA ec:fa:bc:5e:c1:55 IEEE 802.11: disassociated
Feb 1 12:12:00 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind EC:FA:BC:5E:C1:55, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 1 12:12:00 hostapd: eth6: STA ec:fa:bc:5e:c1:55 IEEE 802.11: disassociated
Feb 1 12:12:00 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind EC:FA:BC:5E:C1:55, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 1 12:12:00 hostapd: eth6: STA ec:fa:bc:5e:c1:55 IEEE 802.11: disassociated

I am not sure if the dropped packets are causing the dissconnect or the dissconnect is causing the dropped packets?

 

[drinkingbird]

Ok, then Ill just monitor the buffer to see if it changes with an increase in workload.

As for the QoS, Custom Script and other stuff? None of that is enabled or used.
When ever I have factory reset the router the only settings I configure are the VPN Client, adding devices to the DHCP Manual Assignment list, changing the Wifi Channels to less congested ones and setting the IP Address Range.

This is the log when a device tries to reconnect and fails:


I am not sure if the dropped packets are causing the dissconnect or the dissconnect is causing the dropped packets?

Looks like one drop logged against your PPP (WAN) interface. Is your MTU set to 1492? Usually that is right for PPP but sometimes it needs even smaller.

That shouldn't cause your wireless clients to disconnect though. The router is seeing the client leave, that makes me think possible interference. Does it happen to both 2.4 and 5ghz clients? If it is a problem mainly on one or the other then need to look at sources of interference on each. 2.4 would be microwave, baby monitor, cordless phone (plus obviously neighboring networks). 5 would be mostly neighboring networks unless you're using a channel in the DFS space in which case it could be radar interfering.

How are you determining "less congested". Simply looking at neighboring wifi won't tell you how congested the channel is or how much interference there is. Try setting it to auto and see what channel it picks.

 

[KebabFan]

The WAN MTU is set to 1492. I'll research that number to set what my ISP says it should be. I thought that dropped packet might be related to the Firewall blocking an external request.

There is a microwave and cordless phone nearby, which have been there before the issues began occurring, but regardless Ill look into the amount of interference.

So to determine the least congested channel, I pull out a Wifi Analyser app, walk around the house and pick the clearest channel. Because it seems that all the neighbours wifi signals are set to "Auto" so I figured locking down a channel will produce more reliable wifi.

BTW, Thank you for quick responses

 

[drinkingbird]

So to determine the least congested channel, I pull out a Wifi Analyser app, walk around the house and pick the clearest channel. Because it seems that all the neighbours wifi signals are set to "Auto" so I figured locking down a channel will produce more reliable wifi.

Wifi analyzer apps that run on your phone or laptop will not show you what you need to see typically, if all they show is neighboring networks/channels and not full RF analysis. There are some out there that can show you more details on total utilization and interference, but they usually are paid apps and often need special hardware. A channel with 10 neighbors on it will be better than one with a high power military radar that shows 0 other networks. You need something that can do spectrum analysis to see all of the RF in the frequency range. The asus (well really the Broadcom chipset) has some basic ability to do that, which is why often what it picks for a channel will be better than what you pick.

I looked closer at that PPP drop and it was only 52 bytes so probably nothing. Wouldn't cause your wifi to disconnect anyway.