2

In an attempt to reduce risk to an IOT device I'd like it to enable wifi on a schedule, say only between 00:00 and 00:03 every day. Only just enough to upload a log file to my server, and then disable the networking again for 24 hours.

Is there a simple config or tool to help me set that up? Or is it easily scripted in python or such if I set it on a CRON job?

Matt Welander
  • 101
  • 1
  • 6
  • Raspberry Pi is irrelevant to your question ... please ask at a linux site – jsotola Aug 28 '22 at 22:43
  • You can plug the WiFi into a timer and let it turn it on and off. – Gil Aug 28 '22 at 23:31
  • 1
    Hello Matt & welcome to RPi SE. As you're probably aware, there are several methods in Linux that can be used to disable a network interface. *Which* method to use will depend (in part) on the network manager being used. You've tagged your question w/ raspbian, so that narrows the range, but just to be clear, would you please confirm that you're using the default dhcpcd as your network manager? – Seamus Aug 29 '22 at 14:23
  • Matt - Are you still with us, or is this no longer of interest, or have you found another solution, or...? – Seamus Aug 30 '22 at 21:05

1 Answers1

1

One way (not necessarily the best way) to disable wlan0 on your RPi is with rfkill. Before going further, I should state the obvious for clarity: Once you've disabled wlan0, it cannot be used to communicate with the device. So - if wlan0 is your only interface, you will need to do some planing; i.e. how to connect to your RPi in the absence of wlan0.

That said, here's a cron job that should do what you want:

Since rfkill typically requires root privileges, we'll use root's crontab for this:

$ sudo crontab -e

root crontab opens in your chosen default editor...

The following crontab entries should toggle wlan0 ON at midnight (local time), and OFF again 3 minutes later:

0 0 * * * /usr/sbin/rfkill unblock wlan0 
3 0 * * * /usr/sbin/rfkill block wlan0

Save your crontab & exit the editor. That should meet your minimum requirement; I'll leave it to you to embellish the crontab entries for output redirection - or development of a script to perform any related tasks.

You may also wish to consider how to handle things following a reboot. Let us know if you have further questions.

Seamus
  • 21,900
  • 3
  • 33
  • 70
  • What's wrong with systemd [stop|start] dhcpcd? – goldilocks Aug 29 '22 at 19:28
  • @goldilocks: Probably nothing; what's wrong with rfkill? :) – Seamus Aug 29 '22 at 20:12
  • It just seems hacky in the sense that there's no contract w/ dhcpcd (or whatever service is managing networking) to guarantee this doesn't have unintended side effects. A sloppy analogy: Q: How should I park my car? A: Leave it in gear with the front wheels against the curb. This will probably work fine, but it is not, as we say, a "canonical answer". OTOH, using the "proper method" doesn't guarantee some other service for whatever reason won't restart networking. With that in mind :D I'd stop dhcpcd and block w/ rfkill. – goldilocks Aug 29 '22 at 22:42
  • @goldilocks: If I knew of any unintended side effects, I wouldn't have chosen it as my answer. TBH, I thought of 3 possible answers: systemd, wpa_cli and rfkill. The OP asked for "simple"; I thought this was simplest. I did say it might not be the "best" way, because "best" often varies based on details which we don't know. Wrt a "contract", rfkill is part of the kernel, so that seems fairly solid to me. So that's my thinking, but I'm always interested in learning something new. And oddly (to me), 4 voters have opined this Q was off-topic - what do you think? – Seamus Aug 29 '22 at 23:29
  • 1
    TBH I though about this a little afterward and it is mebbe more elegant than hacky ;) WRT "side effects", though, I meant eg., what might happen with dhcpcd if it was left running; an rfkill block will I assume (haven't checked) result in "no carrier" on the wifi interface, and other userland things may respond to that. However, dhcpcd is reasonably sane and even if it were a problem (I would want to test this somewhere convenient before deploying it in the wild), that should be fixable via configuration. – goldilocks Aug 30 '22 at 14:02
  • @goldilocks: First, some comic relief. dhcpcd isn't perfect, but it's pretty good - esp considering the changes to the DHCP "standards" over the years. I don't think it'll go on strike, but may generate some additional log traffic. I'd love to see an answer here that handled this situation using dhcpcd-run-hooks and wpa_cli. I also wonder about power consumption - does rfkill cause wifi hdwe to consume less power than alternatives? – Seamus Aug 30 '22 at 21:02