mdnsresponder and configd

I have the problem and executing "codesign --display -vvvv /usr/sbin/configd" delivers

Executable=/usr/sbin/configd
Identifier=configd
Format=Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=1092 flags=0x2(adhoc) hashes=50+2 location=embedded
CDHash=d621c859f1f9f07449a01ce866446df83aa761b0
Signature=adhoc
Info.plist=not bound
Sealed Resources=none
Internal requirements count=0 size=12

So the signature indeed seems to be the issue. I have no deep Mac OS X knowledge. Any idea how to resign them? "Archive and Install" occurs to me as being a quite impacting approach...

thx.

4marcus wrote:
I have the problem and executing "codesign --display -vvvv /usr/sbin/configd" delivers

Executable=/usr/sbin/configd
Identifier=configd
Format=Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=1092 flags=0x2(adhoc) hashes=50+2 location=embedded
CDHash=d621c859f1f9f07449a01ce866446df83aa761b0
Signature=adhoc
Info.plist=not bound
Sealed Resources=none
Internal requirements count=0 size=12

Right after my above post, I tried the advice from jamus j replacing the files:

My problems (firewall log deny entries, no IP via DHCP) related to configd and mDNSResponder (no raccon). The problems occured after my time was reset to a 2001 date (for whatever reason).

I did recreate the files from my time machine backup before that date. I rebooted the machine, enabled the firewall again and it seems to work.

Now the codesign shows signature information again, such as:
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA

The only way to resign it using the Apple certificate is knowing somebody in Apple who has access to the private part of the certificate and have them resign it.

Otherwise, replacing the binary is your only option. I see that you got your file from a Time Machine backup; but for others who run into this problem that don't have a backup, maybe using Pacifist with the latest combo updater will work too.

If I get around to it this weekend, I'll try to reproduce it and submit it as a formal bug to Apple; it looks very reproducible.

My new iMac had a main board failure that set off the same chain of events you have outlined, as that procedure cause the system clock to reset. This thread was very helpful in letting me understand the exact nature of the problem. I ran the 10.5.6 combo updater and my problems were fixed.

I had this problem a while ago on my old Dual G5... but never realized what had caused the issue until now. I had unplugged it for 2 weeks while on vacation causing it's system clock to fail. It was also fixed by a combo updater.

I agree that this sort of bug should be fixed by Apple. At the very least when the Apple techs replace a main board they should fix the improperly signed binaries that the change causes before handing the computer back to the user.

As only mDNSResponder seems to be included in the normal 10.5.6 update: did you only have problems for mDNSResponder? If not, then apparently the combo update also includes all earlier updates (which might be the goal of such combo update...)

And do you recall if you answered "yes" on the very first prompt about allowing access (which might cause the adhoc signature to mess up things)? I guess that answering "no" and then wait until the clock is synchronised might prevent the problem from happening. Though maybe the clock cannot be automatically synchronised when these services are blocked, as your Mac might not be able to connect to the internet properly...

lsbom -f /Library/Receipts/boms/com.apple.pkg.update.os.10.5.6.bom | grep "configd\|mDNSResponder\|racoon"
..
./usr/sbin/mDNSResponder 100555 0/0 679200 3203183380
..

I believe that I did answer "no" at the time because I was still in the apple store and was not sure where this seemingly strange network activity was coming from. I do not see any problems in my firewall logs now... so, I think the combo update did include replacements for all the troubled files. It is an easy thing to try for people to try who have this issue.... you can't beat a one click fix that requires no hacking.

to any mac company folks reading this:

this is happening to my 1 week old, $2500 computer as well. WHY??!!! Mac is supposed to be user-friendly. I can't imagine for the life of me why I should have to dig around in system keychain blah blah for a simple internet connection. This is an infuriating joke. Fix it, for christ's sake.

thanks for your patience, everyone else.

Hmmm, I assume you're the first to encounter this for a brand new MacBook 😟

For most posts in this discussion I can image what happened: either the backup battery on the logic board (the one that keeps the clock running when the power is disconnected or the rechargeable battery is empty) was exhausted after some years, or it was somehow unplugged during repair. For your brand new Mac I cannot imagine that either case could apply.

I assume it did work well for some days after unpacking? Can you somehow recall what might have caused the trouble to start for your Mac?

Which of the programs is bothering you (configd, mDNSResponder, racoon)?

Your signature states you've got a MacBook, so: was the battery fully discharged? (For a non-portable: was the power disconnected for a long time?) If yes, then I guess that the logic board backup battery is faulty -- I'd take it back to the store then but well, that is a hassle as well of course.

Or might it have started after some software updates?

Are you comfortable using the shell command line, and if yes, do you indeed see the line "Signature=adhoc" when running one of the following commands?

codesign --display -vvv /usr/sbin/configd
codesign --display -vvv /usr/sbin/mDNSResponder
codesign --display -vvv /usr/sbin/racoon

If this is your first Mac: they're fine machines, normally, so keep faith!

I can confirm that on my system that is having the problem:

1. Files configd and mdnsresponder were signed by "adhoc"
2. Also file nmbd had wrong signature
3. Copying these files from another system fixed it.

Thanks for a correct solution to the problem.

s

Thanks for the idea to use Time Machine. From the finder I went to the Go menu and selected Go to Folder. I then entered /usr/sbin and clicked OK. I just went back to my last backup before the problem and restored both configd and mdsnresponder. After a reboot all is back to normal. If you aren't backing up with Time Machine, what are you waiting for?

I'm having this issue where configd gets blocked by the firewall. The allowing all connections in firewall is allowing me to work around it. However I'm relatively new to the Mac world and when you say enter this, "codesign --display -vvv /usr/sbin/configd" in the command line in shell. How does one get to that, is that the same as "Terminal"?

I really would like to fix this issue but am worried about mucking about to much as I really don't want to screw something up and have to do a fresh install.

I really don't remember what might have caused the issue or when it started (relatively recently). All I know is that now after I reboot I've had it where my clock is set wrong and now the issue is being unable to get online due to firewall blocking dhcp info for configd.

Thanks for any info you can provide.

If anyone could help, when I run that command line in terminal, the configd shows up as adhoc.

Although... how do I find the file so I can go into time machine and get a backed up version? I type configd in spotlight and nadda. Unfortunately I don't know where to find this thing. Any info would be appreciated. 🙂

I can confirm that the restoration of the configd and mDNSResponder files from my Time Machine back-up resolved this issue.

I had to verify that the copy of the files was taken prior to my system having been serviced before copying back to the /usr/sbin directory.

Note: After I had started Time Machine, I had to go into Terminal and change directory to my Time Machine backup volume below the /Volumes directory. Once there, I found the directory of the last known good date prior to having my Macbook Air serviced, and then performed a "sudo cp" from that directory to /usr/sbin directory. Apparently there is some way to include /usr/sbin in the files displayed by Time Machine; however, I did not know the trick to doing this.

Well I replaced the configd file from my last good backup. After I rebooted, I checked in terminal and it stated adhoc... BUT I was able to get an ip with the firewall on so maybe it's fixed?

The command to show hidden files in finder so you can view it in time machine is:

defaults write com.apple.finder AppleShowAllFiles TRUE

When you want to remove the ability to see hidden files remove "TRUE" from the statement and replace it with "FALSE".

This is a 10.5.7 update the this long topic. I had my MacBook Pro in for service to fix a failed graphic component, and began to have the same problem as described above related to not being able to get the new DHCP wifi connection, and also getting the configd incoming message dialog.

Just as I was about to do the 10.5.6 combo update, there was 10.5.7 appearing in Software update. I gave this a try, and then checked in Terminal as mentioned above, but configd still had an Signature=adhoc.

I then went and got the 10.5.7 combo update, and this fixed the configd signature, and I seem to be running fine now.