Contrary to the expectations of the code, IoUtils.closeQuietly()
does not unblock system calls. So mReceiveThread.halt() was not
actually stopping the receive thread.
This wasn't actually a problem, because after "stopping" the
receive thread, either the interface would go down (interrupting
the previous receive thread with ENETDOWN), or a packet would
arrive to both the old and new receive threads, stopping the
old one. But the lack of a "stopping receive thread" message at
the expected time was confusing.
While I'm at it, also add the string for CMD_TIMEOUT.
Bug: 19704592
Change-Id: I74732429118af780453028898148519b294fa9d3
be843e8394