The problem is that my slug is unslung, running busybox for most basic *nix tools and busybox’s touch command doesn’t support the -t option, so I can’t set the modification time on the file to properly queue it.  My half-assed workaround is a shell script (because I couldn’t get the System() command to run the whole string, try as I might) that nohups a background shell process that sleeps for the difference in seconds between now and the wakeup time, then creates the call file.  Not great for far-future scheduling or for large numbers of calls and it won’t survive a reboot, but it’s a start.

My Asterisk diaplan macro passes the target time/date string as the first argument, the target channel as the second, and the ${UNIQUEID} as the third.  One further wrinkle:  busybox 1.3.1, which was what came with the unslung firmware I used, doesn’t have nohup, so it won’t work; busybox 1.10.3 is what ipkg installed into /opt/ and has nohup, but the date command in 1.10.3 didn’t seem to support –date (at all, or maybe just not properly), so nohup is a reference to the 1.10.3 busybox in /opt/bin while /bin/date is a reference to the original 1.3.1 busybox.  Stupid, but it works.

(Oh, and as I told the last person I saw wearing a t-shirt that said “If it’s stupid, but it works, then it isn’t stupid,” there’s definitely such a thing as works-but-stupid–this script hackery is such a thing.  The better solution, space permitting, is probably just to install the coreutils package so as to have proper non-busybox touch and date)

On the other hand, ssh is a very robust protocol and somehow ssh sessions seem to readily survive disconnect/reconnect cycles. Making use of this, it is possible to get a workable, if slow, connection to a passworded-and-sleeping Mac.  On one connection to the firewall machine, run a loop of the wake-on-LAN command so that the magic packets that make the Mac wake are being sent every second or so.  Use another connection to ssh into the Mac and do whatever you need to do.  It helps to plan out what you need to do so that you can get the commands in fast, but even during the cycle where the Mac goes back to sleep and gets reawakened by the wake-on-LAN loop, you can type commands; they just won’t appear (not even echoed) until ssh recovers the connection.

While this is an annoying way to use a machine and it’s probably not good for the hardware to cycle in and out of sleep repeatedly in such a short time span, it does give a way to get at a passworded and sleeping Mac remotely.