[Closed] Linux: running tcpdump on boot

(“stretch,” where do they get the names from?)

Toy Story characters! https://wiki.debian.org/DebianReleases#Codenames

Stick your tcpdump command at the end of /etc/rc.local and you're good to go.

Far as I can tell, rc.local is deprecated here?  The file says # By default this script does nothing and then starts wibbling on about execution bits.  (Is this referring to chmod?  The file is already executable...)

Does Raspbian have systemd running? You could create a custom systemd unit file.....

I'm not familiar with network monitoring to be any help... But maybe this:

https://frdmtoplay.com/counting-wireless-devices-on-a-raspberry-pi-with-tcpdump/

OK, i've not researched this in the slightest and i'm probably going to get laughed at buuuuut

Could you not just set up a cron job to run every 10 mins or something, check if your monitor is running and if not, start it.

Bonus is that you could add in some maintenance tasks to the start of the script (like emailing you or sftping you the batched up results already) then clear them down and if the tcpdump dies then you just have to wait till it kicks off again rather than user intervention.

Does Raspbian have systemd running?

There's a systemd folder in /etc so I guess yes?

You could create a custom systemd unit file…

You vastly overestimate my Linux knowledge!  I had to Google what systemd does.

I’m not familiar with network monitoring to be any help

I'm not too worried about that - I've got tcpdump working at a command line, it's the startup that's confusing me.  Cheers though.

Probably init.rc or similar script. That should give you a good Google hit. Rasbirian is Debian based so use Debian as your distribution search anchor.

[i]sirromj wrote:[/i]

Does Raspbian have systemd running? You could create a custom systemd unit file…..

The current versions do, because they have a recent Debian kernel. That is indeed the "correct" way to do it, and what I'm using for startup scripts. It's not all that difficult, here's a fairly easy to understand article

https://www.raspberrypi-spy.co.uk/2015/10/how-to-autorun-a-python-script-on-boot-using-systemd/ (it works just the same to run anything other than a python script).

I'm fairly sure rc.local has been deprecated for a while (as is init.rc now, systemd has replaced that).

Cougar part of your frustration may come from the fact that you're expecting to solve every problem by a google. Which is always going to cause frustration if you haven't got your head around the fundamentals.

Raspberry Pi have some overview docs about linux here:  https://www.raspberrypi.org/documentation/linux/

And then boot up scripts are covered here:  https://www.raspberrypi.org/documentation/linux/usage/systemd.md

You seem to think that linux is a monolithic single entity like Windows. It is not. It's wildly flexible with many variants and distros and components. Expecting to just google "how do I do this in linux" is like trying to find" how do I fix my carburettor" and getting a result that works for a specific car. So maybe steer clear of the forums and go looking for the documentation instead. Don;t be the Stackoverflow CNTRL-C, CNTRL-V man, be a mechanic instead.

[i]DavidB wrote:[/i]

You seem to think that linux is a monolithic single entity like Windows. It is not. It’s wildly flexible with many variants and distros and components.

I'm inclined to disagree with that - excluding the real esoteric there are only a few fundamental distros and the vast majority of those in use are based on either Redhat or Debian kernels. Doing something in Debian is much the same whether it's Raspbian on a RPi or Ubuntu on a server (or any one of other numerous variants). Sure there are some big fundamental differences between the Redhat and Debian forks, but in this case we're talking about systemd which has been in use on both of those for years and works much the same on either - any generic Linux documentation on running stuff on startup should explain how to use that and be applicable to Raspbian, Ubuntu, Fedora, Centos, RHEL etc.

edit: sorry, i'm posting about the wrong version let me check stretch and i'll update the post

edit2: my stretch system has the file and it works, however Google tells me other people don't have it. Easiest solution is the link aracer posted above.

Cougar part of your frustration may come from the fact that you’re expecting to solve every problem by a google.

I take your point and to an extent you're right.  I've been working on and off with it for a couple of years (as opposed to the vague dabbling I did for yonks prior to that) and the entire thing has been a steep learning curve for me.  But it's not really feasible to learn an entire system overnight, doubly so when by necessity I'm bouncing between distros and what works on one doesn't work on another.  I'm keen to do things the "right" way, and there's so much contradictory advice out there that it just bends my mind.  It took me ages just to even get tcpdump installed (I couldn't do it manually at all, ended up adding a Debian repository so apt-get would find it.  Is this the "right" way?  Whoever knows.)  Case in point, everything I read yesterday and all the different solutions I looked at, I don't recall systemd mentioned at all.

You seem to think that linux is a monolithic single entity like Windows. It is not. It’s wildly flexible with many variants and distros and components

No, I understand this, that's part of the problem!  Those links (and aracer's) are useful though, thanks.  I'll give that a go.

Come back C:\Program Files\Startup, all is forgiven.

as suggested cron would be the easiest way to run something at defined times ., it will also be portable knowledge for any unix flavour  , you can ask cron to run your tcpdump  by time , date, or both.

try not to get involved with systemd  - there are websites dedicated to hate for systemd

[i]Cougar wrote:[/i]

 It took me ages just to even get tcpdump installed (I couldn’t do it manually at all, ended up adding a Debian repository so apt-get would find it.  Is this the “right” way?  Whoever knows.)

ISTR your issue was versions and that the version available on RPi was older and didn't have the functionality you needed? I've had similar situations and ended up compiling from source (which is the fallback method which should enable anything to work, and also isn't that hard once you get used to the sequence of commands required).

Case in point, everything I read yesterday and all the different solutions I looked at, I don’t recall systemd mentioned at all.

The problem here may be "inertia". init.d and rc.local were around for such a long time that a lot of doc got generated on them - systemd might be a few years old now, but in Linux terms that's still kind of recent. It all works so, so much better IME though - I've done a lot of sysadmin type stuff on anything from proper Linux servers to RPi, and it's so much easier and neater now. I guess the thing is you do need to know what it is you're looking for and what's instantly obvious to somebody who's done Linux sysadmin isn't necessarily so to somebody who's just played with Ubuntu or a RPi.

[i]finishthat wrote:[/i]

as suggested cron would be the easiest way to run something at defined times ., it will also be portable knowledge for any unix flavour  , you can ask cron to run your tcpdump  by time , date, or both.

To be fair you can also use cron to run something at startup, but the only flavours of Linux systemd isn't portable to are old or esoteric ones.

try not to get involved with systemd  – there are websites dedicated to hate for systemd

Websites run by dinosaurs who don't like change I suspect. As mentioned above, people have spent decades doing stuff the old way and don't like having to do something different. Such hate also ignores the reality that with modern Linux distros all the system and built in stuff is controlled by systemd and it all works perfectly fine.

ISTR your issue was versions and that the version available on RPi was older and didn’t have the functionality you needed? I’ve had similar situations and ended up compiling from source (which is the fallback method which should enable anything to work, and also isn’t that hard once you get used to the sequence of commands required).

You're sort of remembering correctly but that was a different project, that was iperf on a USB pendrive running Lubuntu.  After much wailing and gnashing of teeth (and great help from STW) I worked out that the secret handshake was:

./configure
make
checkinstall

... to spit out a .deb file which was then nice and portable. Great.

The next time I had to install something from outside a repository (for another project), it used an app manager called Composer.  That was another learning curve whilst I tried to unpick exactly what files needed to be in what folders based on contradictory advice between the PHP app I was trying to install and Composer's own documentation.

Then this time around I first thought, I'll see if there's a binary available, and sure enough there is.  It failed to install with missing dependencies which also needed to be installed manually, and those dependencies had dependencies, and down the rabbit-hole we go.  So, "nay bother" I thought, "I'll compile it from source, I know how to do that now.  ./configure - "File not found."  #RageQuit

In the end I spotted that the download page named the Debian repository it was in, so I added that to sources.list and it Just Worked.  It'll probably break something else fairly hideously at some point, I should remove it really.

Websites run by dinosaurs who don’t like change I suspect.

I was just reading about this.  The argument appears to be that it's not in the "spirit" of Linux because they keep improving it.

Is it just a case of creating a shell script to execute tcpdump in /etc/init.d ?

Did you look at this link btw, just in case it wasn't clear from my post it does have some relevant stuff re systemd & tcpdump (perhaps?)

https://frdmtoplay.com/counting-wireless-devices-on-a-raspberry-pi-with-tcpdump/
/a>

Did you look at this link btw, just in case it wasn’t clear from my post it does have some relevant stuff re systemd & tcpdump (perhaps?)

That was a timely reminder, thank you.  I've set up the service and it wasn't working.  On that page they put the tcpdump command in a .sh script then calls the script from the unit.  Figured that's why mine wasn't working so I've done the same.  Still isn't working though, the service launches the script and the script fails (code=exited, status=203/EXEC).

(Of course, it'll presumably help if the script is bloody well executable...)

Getting there.  I'm assuming this is a classic schoolboy error, but it seems that even though it renders perfectly in nano, shell scrips don't like Windows newlines.  Script is now running, I just have a permissions issue as tcpdump requires root.

BOOM!  Working. The example on the RPi site had a line User=pi in the config.  Took that out and it works.

It's done something fruity with the folder structure on the USB pendrive, I guess that's a case adding a dependency in the unit to wait for the pendrive to be available.  But that's a job for after lunch.  Cheers all, I'll report back in a bit.

Cougar

Websites run by dinosaurs who don’t like change I suspect.

I was just reading about this. The argument appears to be that it’s not in the “spirit” of Linux because they keep improving it.

It's not in the spirit of Linux because it's (perceived to be) one amorphous blob which is gradually accumulating more and more of the system.

This is the opposite to the traditional UNIX philiosphy of 'do one thing, and do it well'.

Also, aside from the software itself, Len Poettering is in my opinion a bit of a **** and hasn't really done the project many favours.

Getting there.  I’m assuming this is a classic schoolboy error, but it seems that even though it renders perfectly in nano, shell scrips don’t like Windows newlines.

"dos2unix" will sort that 🙂

Guess you've solved it now but this is a decent overview

https://unix.stackexchange.com/questions/47695/how-to-write-startup-script-for-systemd

Cheers.

Next question:

I have a folder on the pendrive called TCPDUMP.  On a reboot, the folder is inaccessible (chmod 700) and a new folder is created called TCPDUMP1 with the contents of TCPDUMP and an owner of pi (755) rather than root. If I stop the service I can rm -rf TCPDUMP but cannot mv TCPDUMP1 ("device busy").  Removing and reinserting the pendrive renames the folder back to its original name.

What's going on here?

Hold it - it's not a folder, it's the volume name in /media/pi/ - presumably the systemd process is blocking the default mount name.

Seems there's a RequiresMountsFor= directive.  I'll give that a go.

EDIT: no dice.

pi@raspberrypi:/media/pi $ ls -l
total 37
drwxr-xr-x 4 root root 1024 Apr 10 13:59 SETTINGS
drwx------ 2 root root 4096 Apr 11 14:24 TCPDUMP
drwxr-xr-x 2 pi pi 32768 Jan 1 1970 TCPDUMP1
pi@raspberrypi:/media/pi $

Anyone have any ideas?  I mean, it works so it's not the end of the world, but I don't like messy.

What made the folders? What is mounting them (or attempting to)? Kill the service and remove both what happens?  Just wondering if there's more than one thing trying to mount it? UDEV for instance as well as ..... your script? And timestamp on 2nd is interesting.

And timestamp on 2nd is interesting.

And the file size.

I mean seriously, it’s like an I’m Considerably More Clever Than Yow contest.

That's how the term BOFH came about, I think.

timestamp on 2nd is interesting

RPi has no RTC (at least the old ones didn't)

So you'd need to depend on network access and ntp updating the time first?  Which might not be compatible with what the device is meant to do, from the OP? (I assumed it'd need hardcoded IP compatible with the network, then just spy, or no IP and just dump raw ether packets?)

Curiouser and curiouser.

I've tried various combinations of Requires= and After= with various combinations of references to the drive - media-pi-TCPDUMP / dev-sda1.device - as well as RequiresMountsFor=/media/pi/TCPDUMP and nothing seems to avoid it.

And it seems I'm not the first:  https://unix.stackexchange.com/questions/396519/systemd-service-to-run-a-script-when-a-usb-hdd-is-plugged-in

For the requires/wanted-by (or whatever you go with) have you tried media-pi-TCPDUMP.mount  ?

I don't know much about systemd, as I try to avoid it.

But if you want to run a script when a USB drive is inserted, you should be able to use udev.

Probably something as simple as creating a file /etc/udev/rules.d/99-usb-insert.rules with this in it:

SUBSYSTEM=="block", KERNEL=="sd[a-z][0-9]*", RUN+="/usr/local/myscript.sh"

(Change the pattern to match whatever it is you've got).

whist a systemd service would probably be my first choice you can use cron to  run your tcpdump script as suggested earlier using the @reboot option if your crond supports it like vixie cron etc.

edit: it does.. https://www.raspberrypi.org/documentation/linux/usage/cron.md

re the usb, perhaps your USB drivers are not loaded when the root file system is first mounted.

you are not using pmount are you? IIRC if you have a directory on the stick which is the same name as an existing mount point it will get appended with a one, check you don't have an actual directory at /media/pi/TCPDUMP if you are.

you should be able to mount the stick on boot via fstab but you could try usbmount ive had more success automounting with it in some cases and that should work from a boot if you run something like udevadm trigger --action=add /dev/sdd<x> before you run tcpdump

do you want to run tcpdump when the usb is automounted or will it always be in the device and just mount on boot if so, theres a specific chain of events that you'll need to get in order.

thought about running ntop as a service instead?

cheers

I've just thought.

It's not systemd causing the problem, is it.  It's the shell script trying to write to a location that doesn't exist yet.  I can check in there to wait for the mount to appear.  I'll have a look at it tomorrow.

FWIW, systemd, at least as packaged by Debian/Raspbian should support /etc/rc.local via a magic service (rc-local.service) that gets automatically enabled if /etc/rc.local exists and is executable.

The hack solution to what you're trying to do:

(while [ ! -d /media/pi/TCPDUMP ] ; do sleep 1; done ; tcpdump ... ) &

The brackets and ampersand mean will put it in the background so it doesn't prevent completion of the script which may or may not be what you want.

[i]Cougar wrote:[/i]

I’ve just thought.

It’s not systemd causing the problem, is it.  It’s the shell script trying to write to a location that doesn’t exist yet.  I can check in there to wait for the mount to appear.  I’ll have a look at it tomorrow.

Sorry I've not read all of that to understand exactly what problem you're having with USB, but it should be possible to set systemd to run a process after everything else is done to avoid that. If not then just make a shell script which checks for existence of the USB before running tcpdump, something like:

[code]while [ ! -d /media/pi/TCPDUMP ]
do
sleep 1
done<span style="font-size: 0.8rem;">[/code]</span>

(off the top of my head, so that may not be working code, and I'm not sure if that will force it to recheck whether the directory exists each time around the loop)

edit: FFS this stupid forum - it seems the only way to even make a code block is copy and paste from a proper editor, if you type it in here the spacing gets all ****ed up (and even then it adds extraneous tags - I CBA getting rid of them)

Cheers both.  Slight delay here as the Pi crashed on Friday and now won't boot so I'm having to rebuild it.

aracer, you can use backtick to start and end code blocks.

🤣 hadn't spotted that pdw posted exactly the same code as me! I didn't cheat, honest!

@pdw - I understand the line of code there but everything else may as well be in Klingon.  How does fg / bg apply to scripts running non-interactively as a 'service'?

I'm not entirely sure what the aim is with backgrounding that, but I reckon you understand better than you realise. If putting that straight into rc.local (as he suggests) then you might want to bg it so that other stuff there will also run and rc.local will complete. If running it as a systemd service, then I can't think of any reason you'd ever want to bg it - a service is effectively already in the background - unless you were also trying to do something else as part of your service.

Re doing it the right way with Linux.

The little bit that I've learnt from deploying a load of servers to deploy some open source business apps on is that there's not a right way. There's a wrong way, it doesn't quite work way, and a it works really well way. But no right way.

It doesn't, it's an alternative to wrapping it properly in systemd (if I've read that right), fine if you're an admin just trying to get the data asap.

I'd spend the time to get it working myself, just so it's easy to recreate or move, and behaves/is managed like the other system services

Might have lost the thread here, but I'd be inclined to get a nice big SD Card for the Pi, write active data to /var/tmp/something and work on another script to stop the service, cp or mv the data folder to the USB and restart collection on insert of the USB. You could take options on compressing the data too then if dump size is a problem.

Nailed it.

I took out the tcpdump command and put some debugging in so that I could follow the execution of the script (I just created text files on the desktop, I'm sure there's a more elegant way but it worked).  This showed me two things.

1) Nothing I put in the systemd unit made any difference to the execution of the script, it always ran even if the USB was unplugged.  There must be a way of doing this, but I don't know what it is.

2) The wait code above does work.  It'll sit there happily waiting until the USB is presented before continuing.

However, restoring the tcpdump command was still symptomatic, I'd end up with two mount points on a reboot.  So I figured maybe the mount point is visible for some value of, but not yet accessible, or some such.  After all, when you insert a USB key it takes a couple of seconds for the desktop to go "Do you want to open this drive?"

So, I stuck a 10s sleep command between the while loop and the tcpdump command.  Rebooted and, what do you know, it works perfectly!  10s is probably excessive, but I'd rather err on the side of caution and I couldn't care less about a few seconds' delay.

If running it as a systemd service, then I can’t think of any reason you’d ever want to bg it

I've sussed this too I think.  Using tcpdump at a command line hangs up the console until you ^C out of it.  Predictably, it also does the same to a shell script.  So if there were further commands I needed to run immediately after launching tcpdump I'd have to background it.

I'll write up a summary in a bit.  Thanks all for your help.

If running it as a systemd service, then I can’t think of any reason you’d ever want to bg it

My suggestion was to run it from rc.local.  If you don't background it, it'll prevent the completion of the rc.local script, both whilst it's waiting for the USB key to be mounted, and once tcpdump is running.  This will prevent any other commands further down rc.local from running, and will also probably cause systemd to sulk because it'll think that that start up process didn't complete properly.

If you're setting it up as a proper systemd service, then there are various different modes you can use, depending on whether the command forks (Type=forking i.e. creates its own process in the background and then exits), or stays running in the foreground (Type=simple).  When using systemd, the latter is generally preferable as systemd can then monitor the process and restart it if it dies.

As for the race condition of it creating the directory before mounting, you can do something like this:

while ! grep /media/pi/USBDISK /proc/mounts > /dev/null ; do sleep 1 ;  done ; tcpdump ...

[i]pdw wrote:[/i]

If running it as a systemd service, then I can’t think of any reason you’d ever want to bg it

My suggestion was to run it from rc.local.  If you don’t background it, it’ll prevent the completion of the rc.local script, both whilst it’s waiting for the USB key to be mounted, and once tcpdump is running.  This will prevent any other commands further down rc.local from running

Yeah, as I mentioned in the bit just above what you're quoting 😉 (I had to go back to check I'd written that, but I presume you're quoting Cougar quoting me rather than snipping my post then repeating the bit you'd snipped 🙂 )

Good advice on checking /proc/mounts - I often enough do a sleep as Cougar is to make something work, but even if you don't mind waiting it's always better to do it properly rather than risk it breaking at some point in the future when there's an unusually long delay.

As for the race condition of it creating the directory before mounting, you can do something like this:

while ! grep /media/pi/USBDISK /proc/mounts > /dev/null ; do sleep 1 ;  done ; tcpdump

Well blow me, that works.  Nice work there, thank you so much.