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!

  @EuphoricHacker 

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 wrote

  @EuphoricHacker 

 

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!

  @EuphoricHacker 

  @EuphoricHacker 

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.)

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.

  @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.

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. 
 

  @mwhalen 

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.

  @EuphoricHacker 

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?