Support capturing on multiple interfaces

[riccardomanfrin]

I would be good to be able to listen on two or more interfaces in promisquous mode, which, to my knowledge/understanding is not supported. There is unofficial documentation stating that multiple "-i" options do the job, but it appears as only the last interface is actually fetched.

[guyharris]

I would be good to be able to listen on two or more interfaces in promisquous mode, which, to my knowledge/understanding is not supported.

Listening on two or more interfaces isn't supported at all, except by capturing on the "any" device in Linux, and that device doesn't support promiscuous mode.

There is unofficial documentation stating that multiple "-i" options do the job

If we have documentation saying that, it needs to be fixed.

If somebody else has documentation saying that, they're mistaken and should stop saying that; perhaps they've confused tcpdump with Wireshark's dumpcap and/or TShark, which do support capturing on multiple interfaces.

dumpcap and TShark support writing pcapng files; tcpdump writes capture files using libpcap, which doesn't yet support writing pcapng files. You'd need pcapng to support the general case of capturing on multiple interfaces and saving to a file; we could, in principle, support tcpdump with multiple -i options and without -w, so that it prints packets, without pcapng support.

[riccardomanfrin]

Thanks for the fast reply. I'll give a try with tshark. If yoy need I can provide you with reference to misleading documentation from external source.

[guyharris]

If yoy need I can provide you with reference to misleading documentation from external source.

Yes, please. That needs to be fixed.

[infrastation]

@RiccardoManfrin, could you provide the link? Thank you.

[riccardomanfrin]

http://edoceo.com/cli/tcpdump

[riccardomanfrin]

It's my first output on G when searching for "tcpdump multiple interfaces"

[infrastation]

That page has got interesting comments. Apparently we cannot fix the Internet but I have left them a message.

Shall this issue remain open as a feature request?

[riccardomanfrin]

I guess so ;) As for the question, as a prospective user, I'd definitely make use of such feature, therefore I would answer yes.

Thanks, R

[raellic]

Could you bridge the connections and capture on that interface? I haven't done that with tcpdump but I've done it with Snort, and it seems to work great. In testing with tcpdump I've just used "&" to initiate multiple captures on different interfaces. Specifically, a tapped connection in which send and receive are on separate wires. Not ideal, but it seems to work. For better performance I've been looking at using taskset to assign particular instances of tcpdump to particular cores. If the timestamps are all accurate, you could combine the resulting capture files and get the same result as if you had multi-interface capable tcpdump.

[raellic]

I tried bridging with tcpdump today and it worked fine. Just tap the connection and bridge send and receive, and you get a capture file that shows everything.

[gvanem]

.. and you get a capture file that shows everything.

Not everything. AFAICS you'll get all packets intermingled with no information on which each interface each packet is from.

Depending on what you want to accomplish, writing to several .pcap files simultaneously and using tcpslice to extract the wanted details could be an alternative.

[riccardomanfrin]

Not everything. AFAICS you'll get all packets intermingled with no information on which each interface each packet is from.

Sadly.. I thought that since it works for any and single interfaces, supporting a specific set of them would be patch work, but I haven't read the code so I'm not in the position to make such guess

[raellic]

Not everything. AFAICS you'll get all packets intermingled with no information on which each interface each packet is from.

You're right, I don't get interface in the capture on a bridged connection. I'm running RHEL 6.8 with the latest versions of tcpdump and libpcap. Since I'm just capturing on a single tapped connection at the moment, this works for me, but if I were to capture on a bridge containing unrelated interfaces, I would definitely want to see which interface the packets were on. That would also be extremely useful for a tool like OmniPeek that supports multi-segment analysis. Instead of aggregating multiple capture files with OmniPeek, you could have one capture running on your router or an inline appliance and get all the traffic from multiple interfaces, with a perfect record of which packets came in on which interface.

[raellic]

Thanks, actually I edited my post to remove the Mac OS X section because I realized that I was capturing on "any" interface rather than on a bridged connection, so it wasn't relevant to my post. I was going to try bridging two interfaces and capturing on that, but Mac OS X doesn't apparently have the usual brctl program. I will figure it out and see what happens.

Sent from my iPhone

On Jun 27, 2016, at 7:02 AM, Gisle Vanem notifications@github.com wrote:

@raellic

Out of curiosity, I tried tcpdump on Mac OS X 10.11.5 on multiple interfaces and it does show which interface the packets came in on (see screenshots attached).

Answering via email and your nice screen-shots seems to have been dropped by Github somehow 😦 . You can probably edit your answer above here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gvanem]

Thanks, actually I edited my post to remove the Mac OS X section because ...

I noticed that too, but a bit too late. That's why I deleted my reply.

[guyharris]

but Mac OS X doesn't apparently have the usual brctl program

If "usual" means "common-on-Linux", then that's because OS X/Darwin isn't Linux (just as *BSD, Solaris, AIX, HP-UX, etc. aren't Linux).

[raellic]

As a start, I'm looking at identifying in the output which interface the packets came in on when capturing on a bridged connection. I'm new to this project; anyone know roughly where in the source this feature should go? Thanks.

[infrastation]

It may happen you are looking to finish this work.

[djbusby]

Hey, I'm the one who has the site with the bad information on -i ; I've finally fixed that page after '@infrastation' requested the update in 2015. Better late than never I guess

[infrastation]

Yes, better late than never. Thank you!

[leonerd]

@raellic:

As a start, I'm looking at identifying in the output which interface the packets came in on when capturing on a bridged connection. I'm new to this project; anyone know roughly where in the source this feature should go? Thanks.

My suggestion would be to implement the LINUX_SLL2 header type, which includes interface index information.

[infrastation]

Given the initial SLL2 implementation, what is the main reason to keep this feature request open? Is it because tcpdump -i any does not put any of the interfaces into promiscuous mode or is it because the user cannot specify exact few interfaces as opposed to all interfaces in the system? Please try to describe specific practical use cases to support your point.

[sbonds]

For my use cases, it would be great to specify a specific subset of interfaces and capture on that set. Information on which packets came from which interface is important for later decoding. I do not need promiscuous mode except in very rare cases.

[leonerd]

Presumably if the ifindex or ifname filter syntax were implemented (because SLL2 has the interface index known), then this would be a simple matter of

-i any -f "ifindex 2 or ifindex 5 or ..."

[infrastation]

That could be simpler than the one thread per interface parallel captures I had in my mind.

[fenner]

Interestingly, libpcap subtracts SLL2_HDR_LEN from constant loads on LINUX_SLL2 sockets, so you have to use ether[-4068:4]' to get it to installether[-4088:4]` in the kernel to access the ifIndex. Presumably "real" lipbcap code would avoid this detail, but putting it here if anyone else is experimenting.

[fenner]

I’ve also implemented the ifindex filter keyword at https://github.com/fenner/libpcap/tree/ifindex . Using this, tcpdump -y linux_sll2 -i any ifindex 2 or ifindex 4 or ifindex 6 works to capture on 3 interfaces simultaneously. I’ll submit a pull request for this after a little more testing.

I haven’t yet dealt with interface names, due to the conflict with the existing PF code. It’s reasonably straightforward to deal with, I think, but does have some subtle details like converting name to ifindex isn’t necessarily correct for save files generated In a different context.

[mcr]

fenner notifications@github.com wrote:

I’ve also implemented the ifindex filter keyword at https://github.com/fenner/libpcap/tree/ifindex . Using this, tcpdump -y linux_sll2 -i any ifindex 2 or ifindex 4 or ifindex 6 works to capture on 3 interfaces simultaneously. I’ll submit a pull request for this after a little more testing.

So this might allow one to capture on only an interface that is not yet up. It's often very difficult to capture the first few packets (DADs, PADTs, etc.)