6

I'm trying to find a way to block all internet access (and local network access) to a Raspberry Pi 2 for a limited time while an important task is running.

The problem is, my Pi is doing a video recording and starts producing errors when other users connect while a recording is in progress. So my failsafe idea is to watch the schedule for recordings and take the Pi into local-only mode while it's busy with that.

I'd monitor the schedule in Python, so a Python solution is preferred, but any scriptable commands will do.

A perfect solution would allow blocking local network access and remote access independently... I'm using the current Raspbian distribution.

Any tips on how to achieve that?

7
  • 4
    Wouldn't it be a lot easier to just renice the recording process so it gets all the CPU it needs?
    – MSalters
    Commented Sep 22, 2016 at 10:14
  • This is a rather "hacky" solution that seems to attempt to avoid another problem that could potentially cause other issues that have not yet been identified. As much as I hate to be that over-opinionated StackExchange jerk who insists that your question should not be answered because you're asking the wrong question, this does not seem like the best solution. It's like the joke about the patient who tells a doctor, "It hurts when I do this", and the doctor admonishes the patient not to "do that". The solution to having problems with incoming network connections during recording shouldn't just Commented Sep 22, 2016 at 11:37
  • You really don't want to do this. What if you try to run this over SSH?
    – Mast
    Commented Sep 22, 2016 at 14:36
  • Why not just block users from accessing the device for that time period. Dont take down ethernet.. what if it doesnt come back up
    – Piotr Kula
    Commented Sep 22, 2016 at 17:48
  • @ppumkin - if the device doesn't come back, unplug, plug back in... just like any headless raspberry that becomes unresponsive. .Reg other comments: The recording is done by a software (tvheadend) that behaves badly when too much load happens - changing the software behavior is out of my reach. The goal here of an undisturbed recording has priority over everything else, including SSH access, so dropping network while a recording runs to prevent accidental access to the pi by anyone is a solution...
    – 576i
    Commented Sep 23, 2016 at 8:41

4 Answers 4

7

There are a couple of options:

  1. Take the interface down:

    /sbin/ifconfig eth0 down
    /sbin/ifconfig wlan0 down
    

    and to bring it back up:

    /sbin/ifconfig eth0 up
    /sbin/ifconfig wlan0 up
    
  2. You could add a rule to your firewall using either UFW or iptables directly. UFW will block most incoming traffic by default.

    You will need to install UFW first:

    sudo apt-get install ufw
    

    then enable it:

    sudo ufw enable
    

    then to block a specific port:

    sudo ufw deny 53
    

    you can remove thepreceeding rule with this command:

    ufw delete deny 53
    

    you may also need to restart UFW after changing the rules:

    sudo service ufw restart
    

More information on using UFW can be found here

  1. If using Ethernet you could pull the cable, or if using an external WiFi dongle remove it.

The first is probably easier, but the second will allow you to allow/disallow traffic by IP address, port, protocol etc.

You don't mention what model Pi you are using, but a better long term solution may be to get a second Pi that you can dedicate to just the video, or a model 3B, which may provide better performance because of its upgraded processor - compared to other models.

1
  • Thanks for the answers. It's a pi2 running tvheadend, connected to a satellite usb card. It runs great with the one exception that you are not allowed to connect to it while a recording is running: On connect it serves a channel list and all EPG data to the connecting client and at that exact point the running recording is damaged. When a recording is not running, access is needed to set timers for future recordings and to download recordings. Just blocking the 2 ports tvheadend uses might be a good idea. Can you add the exact commands how to block a specific port and unblock it later?
    – 576i
    Commented Sep 22, 2016 at 7:50
4

Expanding on @MSalters comment, you should really try to play with priority and see if that solves the problem. You have two options here:

  • either you start your recording process with increased priority using nice -n-10 recording_command,
  • or you decrease the priority of the server process your users connect to. Assuming a web server, that would be renice +10 -u www-data.

Both commands should be run as root.

4
  • Giving a very CPU heavy task, such as video encoding, a niceness of less than zero might very well bring just about everything else on the system to a halt. So, if you do try using nice on your recording command, be prepared for the whole system to go unresponsive to every method of communication for the duration of the encoding.
    – Patrick M
    Commented Sep 22, 2016 at 18:05
  • 1
    @PatrickM, I don't think it's that drastic if you're not using real-time priorities. Also, if it's about encoding a live recording, it's not likely to use all available CPU.
    – ilkkachu
    Commented Sep 22, 2016 at 22:02
  • This might be a solution, if the recording process could be separated from the other disturbing processes. In my scenario that is not the case, therefore the question here is how to block all network access or at least some ports for a limited time...
    – 576i
    Commented Sep 23, 2016 at 8:53
  • @576i I don't quite understand what you mean by separated, starting a process with nice doesn't require you to manage it afterwards in any way, it simply gets higher priority which the scheduler takes into account. However, if you insist on disabling the network interface, I'm not going to convince you here. Commented Sep 23, 2016 at 9:11
1

You can give realtime priority to the video recording task using the chrt command, which will schedule this task whenever there is anything for it to do. The other tasks will only get CPU time while the recording task is waiting for the disk, or idle.

2
  • Which chrt parameters do you recommend? Commented Sep 22, 2016 at 13:10
  • If you just have one realtime process, the actual parameters don't matter -- realtime processes are scheduled before non-realtime. The strategy and priority settings are for resolving situations where two realtime processes are runnable. Commented Sep 22, 2016 at 18:03
-1

Have you ensured that your power supply is up to snuff?

https://www.raspberrypi.org/forums/viewtopic.php?f=26&t=42572

I had issues with intermittent connectivity that turned out to be power related.

1
  • Actually, this comment is not as stupid, as other people may think. The recording is done via USB using a USB satellite card onto a USB stick, so power could be an issue... Still blocking all network would save me from having to research that...
    – 576i
    Commented Sep 23, 2016 at 8:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.