MC3190 DNS delay?

// Expert user has replied.
J Jun-Hua Liu 2 years 11 months ago
3 11 0

This issue is endangering a case of 2000 units of MC3190 and the customer is eager to get our response ASAP, so besides opening a case and waiting for support, I'd like to hear your advice.

Sometimes MC3190 response very slowly while MC3090 running the same application work smoothly. Both Cisco AP and our AP5131 lead to the same result. The customer’s IT said that the cause of that problem is the delay of DNS on MC3190. We captured some packets as attached for your analysis. The first scanning occurred at around 00:00:06. It led to a snappy response. The second one occurred at around 00:05:00, which encountered a delay of about 5 seconds before it got the response from the host. MC3190 was not moving during that test and it never suspended. Fusion version is the latest one, 3.00.2.0.022

 

All the MC3190 encountered the same problem from time to time on that site. Our partner has checked the wireless coverage and found the signal strength of that whole area is good. The test of pinging the gateway is also ok.

After MC3190 had been idle for about 3-5 minutes, pinging the domain name of their host also caused a delay of 5 seconds, while pinging IP address never suffered any serious delay.

 

MC3090 with the same application and in the same environment is free of this problem! Fusion is 2.5.2.0.071R.

 

Wireless infrastructure: cisco-1242ag and 5508. Our AP5131 also tested with the same result.

Thank you! Junhua

Please register or login to post a reply

11 Replies

J Jun-Hua Liu

Finally it is resolved!!! Disabling IPv6 stack on the OS side resolves that issue. [HKEY_LOCAL_MACHINE\Comm\AFD] "Stacks"=hex(7):\       74,63,70,73,74,6b,00,69,72,64,61,73,74,6b,00,62,74,64,00,00 Thank you! Junhua

J Jun-Hua Liu

Appreciate your warmly help!

Latest updates:

1)      We tried turning on CAM mode, and changing the registry items advised by Chris and Marcus, but neither worked.

2)      Our partner developed a program running on the background of on MC3190 to ping the MC3190 itself every 10 seconds. It resolved that issue!!! Clever idea, but of course it is not a nice one. The customer is still waiting for a formal response and solution from us.

 

Thank you!

Junhua

J Juan-Antonio Martinez

So, WM's DNS cache strikes again! I saw it before, in another scenario, but it looks the same to me... DNS cache is supposed to prevent DNS actual requests. However, if entries do not last long enough... cache becomes useless. JFYI, the problem I had was that if a given FQDN was solved by DNS via WAN, it was NOT refreshed when the current interface was Wifi, so if actual IP address was different depending on the interface, issues raised like mushrooms! If this was first solved by wifi, if was not refreshed/updated either when moving to WAN. So, DNS cache tables are not updated when changing the current interface. Be aware of this!!!

C Christopher Sather

I think the impact of this new default is actually pretty harmful to most all of our traditional data installations.  I have had to use it at every site to get the performance back to normal. I think this is a topic that needs more discussion.

R Richard Linsley-Hood

I am very puzzled by the url that is being dns-ed. '021-06.wms-v3.yihaodian.com' and its sub-variants. What was being used on the terminal during this test as yihaodian.com is a Chinese domain? A similar dns pattern shows up at 294. with exactly the same 5 sec delay on dns failure response. Perhaps this odd url is somehow to blame?

R Richard Linsley-Hood

In particular why is anything asking to dns '021-06.wms-v3.yihaodian.com.yihaodian.com' which seems very odd behavior. This is what appears to trigger the 5 second wait. This looks similar to xxx.com and www.xxx.com lookups which can be standard behavior but with some very odd fields as input.

M Mark Mann

That's interesting comment on Team software as a possible reason why we have this new WMM settings which now impact the majority of our data applications we do on our device.  Wondering if using the new Registry setting for data now impacts the device if using TEAM. Mark

M Marcus Kurath

Thats an interesting discussion. Of course, we only hear about the sites with problems.I suspect that it has no impact on the majority of our customers, and that in the future it will optimize the behavior of voice, which otherwise might be poroblematic. 

C Christopher Sather

Not sure if this will fix it, but its worth a try.  The registry for the current Fusion releases has some settings to optimize wmm.  This slows down traditional data applications.  [HKEY_LOCAL_MACHINE\Comm\JEDI10_1\Parms] "APSDConfiguration"=dword:0 "CCXParams"=dword:00000005 This is the original post where this was listed: http://devcentral.motorola.com/view/28151/view.aspx The reg key fixed this issue: http://devcentral.motorola.com/view/28738/view.aspx

M Marcus Kurath

Since we have started putting TEAM express on all MPA 2 products, I suspect that we have modified fusion to support QOS for voice prioritization. It might be worth investigating the attached doc and see if it applies to th 3190Z

R Richard Linsley-Hood

As a workaround, do you know that you can set up the eqivalent of a 'hosts' file in the registry to avoid the need for dns completely? HKEY_LOCAL_MACHINE\Comm\Tcpip\Hosts

CONTACT
Can’t find what you’re looking for?