Hi,

I have an RPI that has three wlan interfaces wlan0, wlan1 & wlan2. Each interface is set to a different channel.

When running on a single interface i us eteh following cmmand

What i woudl liek to do is run teh same command on all three interfaces.

I have read that i can use "-i any" but i get an error saying

I presume its referring to eth0 and lo interfaces.

I have also tried

/usr/sbin/tcpdump -l -I -n -e -tt -i wlan0 type mgt subtype probe-req & /usr/sbin/tcpdump -l -I -n -e -tt -i wlan1 type mgt subtype probe-req & /usr/sbin/tcpdump -l -I -n -e -tt -i wlan2 type mgt subtype probe-req

But it pretty much kills the RPI and i get undervoltage errors plus no packets are captures on any interfaces.

Is there a way around this, can the command be run in three seperate sessions using different interfaces in each? It's also worth mentioing that i run this command via a python file which is triggered by a custome service i wrote. All works fine with a single interface, i just want to add more.

undervoltage means you must replace your power supply.

Just like the button to mark as solved, if only there was one to say what does this have to do with my question!

Hmmm, you specificially mention when you try your RPI is killed due to undervoltage, and you ask if there is a way around it. He offers you solution for under-voltage error, apperantly it's a hardware problem. So your response doesn't make a lot of sense.

Your absolutly right, its doesnt make any sense if you only post part of a sentance...

.. which bit of that reffers back to teh undervoltage...

Moving on... and back to teh original question please.... can the command be run in three seperate sessions using different interfaces in each?

I quoted the part where you mentioned undervoltage already when you tried something. Look closely, it's there. It was your error report when you mentioned trying something, you get that error, and it kills your RPI. I quoted that part specifically because you acted confused.

Try with new power supply, do you still get that error? Does it still kill your RPI? Cuz obviously you can't do anything useful with dead RPI, so first things first.

If that is run on one command line as it appears in the way it is posted then there is a problem with the & between the commands (backgrounding the first 2) but never noting the end of each command with a ; .

The comment about replacing the power supply is very germane to the issue since AFAIK a Pi only has one wifi interface by default and adding 2 more is additional hardware + additional power draw especially when they are constantly active as they would be when running tcpdump. The power supply is only capable of ~3 amps (~15 watts) if using the default power supply. The Pi itself told you it was under powered when you got the undervoltage errors.

Fix the power issue first since it can never be stable if it does not have adequate voltage/power to run properly.

As for your original question:
if you want those to run at the same time with only one terminal interface then change them to something like
My system does not have 'type mgt', although it does have a type indicated by -T and none match mgt. It also does not have a subtype designation.

By directing the output of the command to a file you then can look at the file content to see what was captured and once in the background the command will run without filling up your screen. Three separate processes trying to use the screen at the same time will be a problem.

AFAICT, the OP wants them to be run in background. And ampersand (&) not only puts the command to background, it functions as a command delimiter as well: just as the semicolon (;) does. Another question is how useful it would be to run three tcpdump instances at once. Honestly, I don't know. That said, for that command line I'd rather use parallel as a shortcut:
or

@OP. Perhaps, kismet / kismet_drone would fare better than tcpdump in this situation?

Yes, if you replace your PSU. That's all. Your command did not work because of a HW problem and any other command will/may fail the same way.

You could use {} in bash or a for loop. But that might be to much delay between commands...