Not sure if I've observed this just plain not work before, although calling
shutdown in an ssh session may often cause it to hang on your side. I'll hazard a guess and say the reason you have this problem with wifi but not ethernet is because of the bit of latency involved. TBH that's a dubious, unsatisfying guess, but I don't think we need a complete understanding.
The way I deal with shutdown via ssh is to send the command into the background and exit. My personal preference is actually
halt -p but I am not sure if that matters:
sudo halt -p & exit
& backgrounds a process, meaning the call returns immediately, before the command itself completes. Shutting down the system usually takes at least a few seconds before the final move, which is to tell the hardware to poweroff (I'm not sure how meaningful that is on the pi -- so the
-p may just be an irrelevant habit).
exit then refers to the ssh login, so that will then be immediately disconnected properly. The way the timing works out is that
halt on the other end won't have stopped
sshd yet, so no snags.
Using this method (
foo & exit) with most processes will probably end up with the process failing or dying mysteriously. It works with
shutdown) because these are actually commands to the init system. Not a complete explanation, but enough said here.
foo & bar is very different than
foo && bar. The latter means wait for
foo to finish executing and then only start
foo succeeded. That's not what you want to do.