Debugging PCSecrets Synchronization

A reader of my Effective Debugging book commented that debugging is learned through experience. I think he’s partly right, so I’ll periodically describe here techniques and tools I use when debugging. A problem I faced today was the inability of the PC-based PCSecrets program to sync with the Secrets for Android counterpart. Here is how I troubleshot and solved the problem.

As the setup used to work in the past, I first reasoned that this was an intermittent failure due to a problem in one of the programs involved. Therefore I restarted the desktop and Android client programs as well as the Android sync service. This didn’t solve the problem.

My next assumption was that the Android part had been auto-updated and couldn’t work any more with its desktop counterpart. Reinstalling the desktop client didn’t help.

Time to go in depth by looking at the network communication. I launched Wireshask and added a filter to look only at packets associated with the mobile phone: host dds-samsung. This allowed me to see that the Android sync client’s UDP discovery packets were indeed arriving at the PC end.

Were the packets able to reach the PCSecrets program? I checked that by running the Sysinternals Procmon tool to look at how its underlying process (javaw) responded when it received the synchronization packets. The process didn’t do anything at all, which made me wonder whether it was listening for them.

I therefore run the netstat command and saw that the PC client program was indeed listening for all the relevant packets when it was expecting a sync.

$ netstat -an | grep -e 9100 -e 53165
  TCP    0.0.0.0:9100           0.0.0.0:0              LISTENING
  TCP    [::]:9100              [::]:0                 LISTENING
  UDP    0.0.0.0:53165          *:*
  UDP    [::]:53165             *:*

To rule out port conflicts I also verified that nobody was listening on those ports at other times.

Were the packets able to reach a user program? To test this I run netcat as a UDP server and saw that (after I responded to a Windows firewall prompt) it was indeed receiving the packets.

$ nc -ul 9100
DISCOVER_PCSECRETS_REQUESTDISCOVER_PCSECRETS_REQUEST

The firewall prompt made me think that this might be a firewall issue. So I disabled the Windows firewall, and, presto, the sync process started working again. I then examined at the firewall rules and saw that the particular Java executable was blacklisted, probably after a Java SDK update. I configured a suitable rule, enabled the firewall again, and tested that everything worked fine.

Problem solved!

Comments   Toot! Tweet Share