EAP660HD - packet drops impacting browsing (DNS)
Hi.
I'm running consumer-pro network at home and have local NAS. Sniffing the network shows at times DNS queries from my Mac never makes it to the NAS and thus, the browser experience often lag. Software is current.
The test happened on 5Ghz using a Macbook M1 - The wifi is on a band that doesn't have much interferences around.
Total : 14 clients
Unscheduled Automatic Power Save Delivery - Enable
OFDMA - Enable
Channel Width - auto
Tx Power - High
Remaining disable.
5Ghz stats look fine to me but the "Retried packets" graph has a constant noise of ~3300 +/- 300 retries w/ spikes at up to ~32k !
Any hep is appreciated.
Mode:
802.11a/n/ac/ax mixed
Channel Width: Auto
Channel: 36 / 5180MHz
Tx Power: 26
Rx Packets: 43048258
Rx Bytes: 17.23 GB
Rx Dropped Packets: 0
Rx Errors: 27
Tx Packets: 151696743
Tx Bytes: 159.03 GB
Tx Dropped Packets: 0
Tx Errors: 0
LAN shows 0 errors but .. no mention of possible packet drop?!
Uplink wire stats... no stats. Could there be drops or crc/checksum errors?!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
mwhalen wrote
First, your NAS is running DNS? Second, have you run a long ping test from the M1 to your NAS? What’s the response time?
Indeed the NAS is running the DNS service. The M1 is ~10' / ~3m away from the AP.
Running the following command works fine for ~1-20 queries, it hangs and starts to work again.
while host <hostname>; do sleep 0.1; done
No network errors / drops seen on the NAS interface.
This below is ~2k ping packets is with 0.1 second interval.
--- 192.168.1.66 ping statistics ---
2006 packets transmitted, 2006 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.722/6.908/115.151/6.457 ms
No packet lost but the max is high.
Thanx for helping out!
- Copy Link
- Report Inappropriate Content
it may be distasteful, but have to set a different DNS server manually on your Mac to rule out your NAS DNS service? Also, do you have a windows machine to rule out the Mac?
- Copy Link
- Report Inappropriate Content
mwhalen wrote
it may be distasteful, but have to set a different DNS server manually on your Mac to rule out your NAS DNS service? Also, do you have a windows machine to rule out the Mac?
@mwhalen I had done that test in the past as well - I just did it again, it's still happening.
Since we have 0 err/drop stats at the network level, at least not in the view on Omada controller.
Next step is to replace the dummy POE switch with a smarter one to get error stats .. it's also possible the current POE switch is causing this? I will proceed later after everyone is done with their day (WFH).
Stay tune!
- Copy Link
- Report Inappropriate Content
I suppose one thing to consider is that DNS lookups are not tcp, but udp. It's supposed to fall back to tcp, but may not be in your case... UDP never acknowledges connections from what I know. So that might be why things are just timing out for you.
So, that being the case, it may be more useful to use dig to run some test from the Mac.
In your case, you can open a Terminal and run, for example...
dig (at)8.8.8.8 google.com
Note: I can't use the @ symbol without making the editor think I'm reference someone on the forum. So, change the "(at)" to the @ symbol.
This is query Google's DNS server at 8.8.8.8 for Google's A record. You can use the same method to query your NAS's DNS server.
The other thing you can do is use netcat to check that port 53 over UDP (DNS) is open and responding:
nc -vnzu 8.8.8.8 53
Again, you can do this via the Terminal.
(note: If I were more knowledgeable, I could make this repeating. I don't know how to do that. But you can run it once, use the up arrow to recall the command from zsh history, then hit enter to run it again. Run it as many times as you want. Change 8.8.8.8 to your own NAS DNS server.)
- Copy Link
- Report Inappropriate Content
Turns out the issue appears to be the Mac M1. tcpdump shows the packet coming in on the interface but randomly there's a ~3-4 seconds daily before the client receives the packet. In this case for simple tests, the clients are "dig" & "host". I've also rebooted in safemode, didn't make a difference.
Same tests on another identical Mac M1 2020 doesn't show any such "lagging". This is true on WiFi and LAN.
Will make an appt at Apple to get this one replaced.
- Copy Link
- Report Inappropriate Content
@EuphoricHacker well you seem to have clued in on something but I'm a little lost on how you tested with dig and host.
You mentioned, for example, there's ~3-4 second delay before the client receives the packet. I assume this means the client is the Mac and the server is your NAS or whatever your DNS server is testing against. How did you determine that the client received the packet at all as opposed of retry that amounted to 3-4 seconds?
I guess I'm also confused as to why Apple would hand over a replacement Mac before doing a great deal of troubleshooting first?
I don't require explanation, of course. I'm just curious.
EuphoricHacker wrote
Turns out the issue appears to be the Mac M1. tcpdump shows the packet coming in on the interface but randomly there's a ~3-4 seconds daily before the client receives the packet. In this case for simple tests, the clients are "dig" & "host". I've also rebooted in safemode, didn't make a difference.
Same tests on another identical Mac M1 2020 doesn't show any such "lagging". This is true on WiFi and LAN.
Will make an appt at Apple to get this one replaced.
- Copy Link
- Report Inappropriate Content
mwhalen wrote
@EuphoricHacker well you seem to have clued in on something but I'm a little lost on how you tested with dig and host.
You mentioned, for example, there's ~3-4 second delay before the client receives the packet. I assume this means the client is the Mac and the server is your NAS or whatever your DNS server is testing against. How did you determine that the client received the packet at all as opposed of retry that amounted to 3-4 seconds?
tcpdump shows the p
I guess I'm also confused as to why Apple would hand over a replacement Mac before doing a great deal of troubleshooting first?
I don't require explanation, of course. I'm just curious.
I'm not sure what you don't get from this :
"tcpdump shows the packet coming in on the interface but randomly there's a ~3-4 seconds daily before the client receives the packet. In this case for simple tests, the clients are "dig" & "host". I've also rebooted in safemode, didn't make a difference."
It's easy to troubleshot a computer, at least for me it is... just as a fyi, I've setup an ISP alone back 1994. I've learned my ways around.
- Copy Link
- Report Inappropriate Content
oh wow I completely missed the part about tcpdump. Sorry about that. I saw the item about dig and host but not tcpdump. I apologize if I came off as
condescending. What do you think is wrong with the Mac?
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 895
Replies: 9
Voters 0
No one has voted for it yet.