1. henryw48's Avatar
    Not surprising that there may be more than one solution, depending on what apps were loaded on the device and what kind of device it is. Glad your wife found the problem on her device, Devils Advocate1.

    I suspect it might be a load and device capability problem (i.e. the straw that breaks the camel's back). Even with an app that has been on the device for a long time, the apps change with new features added, as was my case.
    01-07-2017 12:21 AM
  2. Huku's Avatar
    Hi Everyone,

    it's been already 4 days since 03.Jan.2017 and the mdnsd problem is gone!

    How did this happen?

    Well, as I wrote earlier I uninstalled Ping&DNS app and since then there is absolutely no problem, altghough I've been using my phone heavily (navigation, reading, watching videos, etc.).

    Meanwhile I stopped the auto-update of all other apps so I am sure nothing else has changed. The only apps that "slipped through" and updated on the same day (3.Jan) are (1) MyKi Watch (2) Peak. I am 99% sure they have nothing to do with mdsnd problem because they updated on the same day but before I remove Ping&DNS.

    @henryw48: The 4.4.2 is very good observation! I am using the same version of the OS on my Galaxy S5 phone (although I can update it, but don't want to) and that is almost for sure the reason that you reproduce the problem on your phone but not your tablet.

    And one more thing - a big thank you to all of you for all the efforts and time invested in solving this issue. Hopefully this thread will help other people also.
    01-07-2017 01:22 AM
  3. anon(10132667)'s Avatar
    Were you able to get rid of MDNSD? If so, how?
    01-10-2017 12:14 PM
  4. Devils Advocate1's Avatar
    mdnsd came back today. Still not using Weatherbug so something else is triggering it too.

    Will keep you updated.
    01-10-2017 02:39 PM
  5. henryw48's Avatar
    @bwg0719: On my device and also on Huku's device, the problem was being triggered by the updating of the installed Ping & DNS app. It had gotten updated in December 2016 and again in January 2017. As soon as we removed that app, the problem went away. Before those updates, Ping & DNS did not cause a problem. It appears that Ping & DNS had recently added a new feature to the app to monitor traffic on the network interfaces. That either presented extra load on the network interfaces or somehow interfered with the running of the system daemon program /system/bin/mdbsd, causing it to fall behind and lose packets and sockets and eventually enter a looping state draining the battery. Both Huku and I were running different devices but happened to be running the same version of the Android OS. I also have a tablet, which is newer and faster and running a later version of the Android OS. It did not have the problem even though I had also installed Ping & DNS on it.
    01-11-2017 04:45 AM
  6. vice86's Avatar
    Note 3 user here. Been up for a little over 5 hours now and i just saw my phone screen turn on, look at it and its low battery warning. in about 5.5 hours my battery has drained from 100% to 15%!!! Looked up battery usage and there was "mdnsd". Never seen this before show up on my battery list. I did notice the other day I saw the Nearby Devices show up on battery but I had the option off so not sure why it even showed up.

    Looking at my recent in stalls, a sneaker app called GOAT was my last install. Deleting now to see if that for some reason makes a difference.
    01-12-2017 10:11 AM
  7. henryw48's Avatar
    @vice86: By "recent installs", did you mean "Recently updated"? You need to look at all apps that were "Recently updated" as possible culprits, especially ones that might cause significant amounts of network traffic.

    "Nearby Devices" is not something I'm familiar with, but is definitely something to look at. One of the functions of "mdnsd" is to look for nearby devices by implementing the bonjour nearby device discovery protocol. One of its functions is to find nearby internet connected printers and other IoT devices without you having to know their Internet Protocol (IP) address. It is also used to do domain name resolutiion (translate an address such has "forums.androidcentral.com" to an IP address that the software can use).

    Look at all the apps that were recently updated by looking at Google Play's description of the app, including the "READ MORE" section, and the "Permission details" at the bottom of the bottom of the app description.
    01-12-2017 10:24 AM
  8. CarolaVw's Avatar
    I've got also the mdnsd problem.
    I've got a samsung galaxy S3 mini.
    What is happening on my phone is that when I start the Facebook app, my phone is restarting automatically. So I think that there is possably a link with the mdnsd and the facebook app.

    Sorry for my bad English, I'm a Duth girl.
    01-12-2017 04:54 PM
  9. henryw48's Avatar
    @CarolsVw: How did you determine it is the mdnsd problem? Did you see the mdnsd come up in your battery app display? The reason I ask is because this problem doesn't seem to be behaving the same way as the problem we've been working on in this thread.

    It almost sounds like you may have too many apps running at once and are running out of resources.

    I had taken the Facebook app off my Samsung S3 a long time ago and only used the web based access to Facebook. I don't remember exactly why, but I think I had some problem with it.
    01-13-2017 02:08 AM
  10. CarolaVw's Avatar
    @henryw48 I determined the problem by looking at the battery app display. There it came up as a high usage of the battery. And I was reading this treat, and I recognized a lot of what my phone is doing.
    The mdnsd is decreasing after charging my phone. And sometimes my phone wouldn't charge up to 100%. So I need to turn my phone completely off to recharge.
    A friend of my is a IT-boy. He suggests me to remove my SD card. So I did this evening. My phone is already a lot faster and I will keep an eye on the battery usage to see if the problem appears again or not.
    01-13-2017 04:11 PM
  11. henryw48's Avatar
    @CarolsVw: It certainly sounds like you may have a version of the problem. Once the mdnsd comes up as a high user on the battery display, the only way out is to restart. Since you said that the device is restarting by itself anyway, It would stop that. However, the battery display will not reset until you have fully charged the device and then disconnected the charger.

    Some people seeing this problem had tried taking out the SD card. Don't think it was effective if removing the problem. However, it may work for you, so it's worth a try anyway.

    Glad you have an IT friend helping you out. They might have some insight into the problem.
    01-13-2017 05:23 PM
  12. Devils Advocate1's Avatar
    I've got also the mdnsd problem.
    I've got a samsung galaxy S3 mini.
    What is happening on my phone is that when I start the Facebook app, my phone is restarting automatically. So I think that there is possably a link with the mdnsd and the facebook app.

    Sorry for my bad English, I'm a Duth girl.
    Got rid of mdnsd problem for a couple days by removing weather apps but now it's back and Facebook is not running correctly and mdnsd is back again. So I agree whatever the problem is that Facebook may be a culprit too. Interesting problem for sure.
    01-14-2017 12:13 AM
  13. wireshark007's Avatar
    I'm having the same problem on my S3. "mdnsd" is top battery drain by far. Also noticed that WIFI was never sleeping on my phone (even with screen off). With WIFI and mobile data off, the problem goes away (till WIFI is re-enabled). Did some packet sniffing on the WIFI network, and noticed that there are a few different formats of mdnsd packets emanating from my phone. There is a certain packet that is send in bursts every few seconds that seems to correlate with the problem - it looks like this: "1195 1459.768041 MDNS 316 Standard query response 0x0000 PTR, cache flush Android.local PTR, cache flush Android.local A, cache flush AAAA, cache flush <address> NSEC, cache flush NSEC, cache flush 8.D.C.A.1.F.E.F.F.F.A.8.0.3.A. NSEC, cache flush Android.local OPT".

    After reboot, these packets do not occur. As soon as I launch Facebook app (and no other app does this) the MDNS messages start, and continue even after shutting down Facebook (directly and in the application/task manager) until I reboot the phone (the messages temporarily stop when I turn off phones WIFI).

    I subsequently deleted my Facebook application cache - this resulted in my phone rebooting each time I try to start the Facebook app.

    I subsequently uninstalled Facebook entirely. This appears to have solved the problem.

    I subsequently reinstalled Facebook, the MDNS problem and associated packet stream was back.

    So I'm pretty sure Facebook is triggering the problem, even if the problem is in the MDNS service.
    01-15-2017 03:28 PM
  14. henryw48's Avatar
    @wireshark007: Good detective work and explanation. Yes. There appears to be several ways of causing the failure. Still don't fully understand the mechanism of the failure, but your analysis reaffirms one of scenarios that I thought was happening.

    As I understand it, mdnsd is an Android daemon process that provides DNS services as well as the local device discovery service for the local network (bonjour or multicast zero-config networking). The purpose is to translate a qualified name into an appropriate IP address for the service or device. I THINK the bonjour or multicast zero-config networking works by responding with a mapping dump when it sees a query for a local service or local device it knows about. Hence it can generate a lot of local network traffic. I SUSPECT that when there are too many responses from various other devices, a local mdnsd gets overloaded with too much traffic coming in all at once, the system starts dropping response packets and running out of buffers. When certain other processes such as the new Ping & DNS, or Facebook are running, it contributes to the packet loss and utilization of the network buffers aggravating the situation. When the local system finally gets to the point where there are no buffers left, it goes into a loop trying to write responses. At this point, the loop causes the full utilization of one of the CPUs and the draining of the battery. As I say above, this is my GUESS as to what is happening. This appears to be prevalent on certain releases of the Android OS and/or running on older/slower hardware.
    01-15-2017 11:27 PM
  15. timinaust's Avatar
    Hi, I too have the problem with mdnsd and the flat battery - on a Samsung Note 2 on Android KitKat 4.4.2 which has been going flat several times a day. Just thought I would offer some thoughts from my investigation. Sorry for the very very long and probably rambling technical post.

    mdnsd (aka Bonjour on Apple, Zeroconf etc) has two bugs that Google fixed between Android 4 and Android 5 (according to Android Open Software Project).

    The main bug was titled 'Fix mDNS socket leak during network configuration changes' and this was fixed in March 2014 by a clever person at Google, however the fix doesn't appear until devices with Android 5 Lollipop. This bug could 'eventually lead to failure of the mDNS daemon when its file-descriptor table fills up with orphans.' - which is exactly what appears to be happening on my phone as the number of network sockets attached to the mdnsd service builds to about 580 (on my phone it adds about 28 orphans with each network config change - and network config changes reliably include anything WiFi, Mobile Data and Charging state). Soon after reaching the magic 580, the mdnsd service goes into a high CPU utilisation (100% of one CPU core), presumably as it fails to acquire additional sockets. As it does this, the power management decides the phone is really busy, increasing the speed of, and power to, the CPU cores, the battery consumption goes way up and the back of the phone gets hot. The only fix is a reboot.

    However this is not the only problem - after all, the bug has been there since Android 4.4.2 was released, so something changed in November/December that is triggering the bug a in a big way. So what was that? Given that any application that wants to use mdnsd is required to install with CHANGE_WIFI_MULTICAST_STATE permission, a look with Permission Explorer (from Play Store) shows a limited set of applications that have that permission on my phone. They these basically fall into 4 groups - Nearby Devices/WiFi Direct, a bunch of Printing services, some Samsung stuff and Google Play services (which includes all the google services like backup, the sync services, gmail, maps etc etc etc and which is totally different to Google Play Store). (and a couple that I uninstalled while testing).

    A look at the network traffic to see what is being queried with using this multicast DNS shows a separate query for general _Android_ devices (probably from Nearby Devices and/or WiFi Direct bypassing mdnsd), plus one regular consolidated query (which is what mdnsd is designed for) looking for things like printing (_IPP_), file sharing (_SMB_, _FTP_ etc) and a range of other standard sharing type services which could come from any of these apps that have the right permission. Given Nearby Devices and WiFi Direct are part of the Android 4.4.2 build, and my printing services haven't been updated, this leaves the Samsung stuff and Google Play Services. As people are reporting the same issues on non-Samsung devices - to me this (probably) points to something in the vast array of stuff lumped under Google Play Services. Google released V10 (up from V9) of play services in late October 2016 which would have rolled out probably in November or early December.

    For me there are a number of possible 'official' remedies ... update to Android 5 or above - which I can't on my Note 2, but others may be able to (Check you don't have automatic update disabled on your phone); persuade Google to investigate whether something they did in Play Services V10 is triggering this 'old' bug on this 'old' version of Android and then fix Play Services - or buy a new handset. None of these seem particularly likely outcomes.

    So I have been looking at alternative strategies. At the moment, I have rooted the phone and am running a script that restarts the mdnsd service every 30 minutes (#setprop ctl.restart mdnsd). This clears out the orphan network sockets caused by the bug which will hopefully stop the mdnsd service from getting into trouble and flattening the battery. Given how mdnsd works, this shouldn't cause application problems as long as it doesn't get restarted too often. If the script proves to work for a few days, I will investigate how to automatically start the script on boot from within android (you can't restart mdnsd from within a normal app). If regularly restarting the service doesn't work, and it turns out the orphan sockets are just becoming invisible, I will investigate whether replacing the mdnsd executable with one from a similar Android 5 phone fixes the problem, or whether I can use Android Open Source to re-build the executable after applying the patch changes.

    I will report next if/when I get to a final solution - but I fear the solution won't sound like good news if you are not very technically minded - unless you finally want to justify a new phone.
    RikR likes this.
    01-16-2017 07:05 AM
  16. henryw48's Avatar
    @timinaust: thanks very much for your very detailed description of your in depth investigation of the problem. It was very informative and confirmed some of my suspicions. Will be waiting for further updates from you or others who have taken further steps to resolve the problem. It appears that I will either have to root my phone or get a new one. Verizon/Samsung hasn't sent any more updates out for my phone for years, forcing the issue. The other alternative is what I'm doing right now; not running any of the apps that trigger this problem.
    01-16-2017 07:48 AM
  17. henryw48's Avatar
    @timinaust: One additional note. I have found that restarting the device before the number of UDP and UDP6 sockets reaches over 500 does work. I just look at a netstat output or count the number of lines in /proc/net/udp and /proc/net/udp6. All the offending sockets are on port 5353 (0x14E9).
    01-16-2017 10:33 AM
  18. CarolaVw's Avatar
    Until today my mdnsd did not appear in the battery.
    I used all my apps exept facebook.
    Today I deinstalled the app and did a reinstallation of de facebook-app.
    And now the problem is back.
    So I really think that there is a link between the mdnsd and Facebook.
    So I will replace my sd-card, because I have not enough memory for taking pictures.
    And I will not using the facebook-app.
    Then I will see what is going to happen.
    01-16-2017 01:14 PM
  19. henryw48's Avatar
    @CarolaVw: sounds like a good plan. From what others have posted Facebook app is one of the apps that causes trouble. The sd-card doesn't cause the problem.
    01-16-2017 02:32 PM
  20. timinaust's Avatar
    Yes - restarting the device will restart the service and clear the problem. It is however a bit more invasive and manual than what I am hoping to achieve. It would mean I would have to remember keep checking. I have a script that loops every 5 seconds and is doing netstat | grep -c 5353 and that tells me the current count, but unless I remember to go check every 30 minutes it has a tendency to drain the battery while I am out shopping.

    Interesting that others seem to be having problems with facebook app. I don't use the facebook but looking at the permissions on play store, it doesn't have permission to access the mdnsd service, so it would not directly trigger the bug I found directly. It does however have rights to change both wifi (CHANGE_WIFI_STATE) and mobile data (CHANGE_NETWORK_STATE) - which it could be doing and hence causing the problem indirectly by making network configuration changes that mdnsd, (which something else has already used) is reacting to - many other apps have that permission too. I guess this means that the problem could be made worse by a combination of 3 or more apps, all interacting.
    01-16-2017 05:26 PM
  21. marymaz1's Avatar
    I've read these articles and posts and replies.. I've not had any luck figuring out this issue. I'm ready to throw the phone out the window!
    01-16-2017 05:41 PM
  22. oleksiy1978's Avatar
    If you want to minimize chances of mdnsd looping, turn off storing your location history in Google and Facebook. I used to get mdnsd restart almost right away after I restart the phone with Google Locations on. When I turned it off I went on for almost a day without mdnsd until I started FB. Now trying FB without location history too.
    01-17-2017 02:04 PM
  23. henryw48's Avatar
    @oleksiy1978: Interesting. Wonder if it was the storing of the locations or the determining the location that was causing that. Determining Location in HIgh Accuracy mode, in addition to using GPS, also uses the WiFi and mobile networks to get the location. This would put additional traffic on the network or, more specifically, on the device having to receive the additional traffic and process it.
    01-17-2017 02:19 PM
  24. oleksiy1978's Avatar
    Yes high accuracy is on. First I will try turning locations back on in Google and FB to confirm that it brings back the mdnsd loop for me. And then I will switch to GPS only for locations, to test if it is in fact accessing wifi and cell networks that is causing the loop to form.
    01-18-2017 03:31 AM
  25. timinaust's Avatar
    An update on what I have achieved ...

    Having rooted the phone, I found that regularly (every 30 minutes) restarting the mdnsd service reset the count of sockets it used and kept them at a fairly small number. However after a day, the maximum number it would go to went to about 50, and then wouldn't go beyond 3. Every restart of the service, it would release then re-open 3 sockets and never acquire any more. The implication therefore is that the sockets are being released by mdnsd but not freeing the resources in the underlying networking. The good thing was however, that with mdnsd now limited to 3 sockets, the CPU load problem, and hence the battery problem never reappeared, so it looked like a combination of out-of-resources in both mdnsd and in the underlying networking that caused the CPU problem on my phone at least. While this seems to solve the battery problem, I am not sure if mdnsd will continue work as expected as it is will still be trying to acquire sockets it can't get - hence the proper fix would have to be restarting the phone. So I went to the next step.

    I extracted a copy of the mdnsd executable file from an Android lollipop (5.0) phone, courtesy of Google's Android Studio and their pre-built Android emulators, making sure it was for the same 32bit ARM type of CPU. The file was twice the size of one on my phone, but that was because it has been build using static libraries (libraries included in the executable rather than linked to shared libraries as the Kitkat executable was). The advantage of using static libraries is that it makes it less of a risk that something changed in the underlying Lollipop libraries. I copied the mdnsd executable onto Android Studio's 32bit ARM Kitkat build - and it appeared to run, start, stop etc without any problem. I have now replaced the one on my real Note 2 and it seems to be working as normal - the number of sockets is back to one per 5353 port for IPV4 and one for IPV6 and it never goes up - which is exactly the behaviour I would expect to see. The broadcasts are appearing on the network as before, so it looks like it is working properly at last.

    I am now monitoring and will see how it goes after a few days, but I expect removing the underlying bug in the Kitkat mdnsd by putting in a proper build will fix the battery problem for me once and for all and make sure printing and all the other things mdns is used for keep working. Unless that is Samsung issues a firmware upgrade from 4.4.2 to 4.4.4 - which is very very unlikely - when I would have to re-replace the file. If Samsung upgrade Note 2 firmware to V5 Lollipop (also very very unlikely) or V6 Marshmallow (you have to dream don't you) - then the problem will be fixed anyway.

    While this solution does require rooting the phone to swap the file, so it is not for the faint hearted, it can be un-rooted again straight after, which I will do for safety reasons once I know it is working.
    RikR likes this.
    01-18-2017 05:45 AM
108 12345

Similar Threads

  1. How to reinstall Lollipop 5.1 on infected phone
    By AC Question in forum Ask a Question
    Replies: 6
    Last Post: 02-05-2017, 09:10 AM
  2. Bluetooth stopped working on Google maps
    By srfoot in forum Samsung Galaxy S5
    Replies: 2
    Last Post: 12-23-2016, 08:33 PM
  3. Replies: 2
    Last Post: 12-22-2016, 04:54 AM
  4. Can i use my galaxy j7 with your service
    By AC Question in forum Ask a Question
    Replies: 1
    Last Post: 12-21-2016, 05:46 PM
  5. Replies: 0
    Last Post: 12-21-2016, 05:38 PM