allow tcpdump to start recording from a specific non-existent interface when it becomes available

[floorjoist]

Currently, if one wishes to start recording on network interfaces that appear after capturing has started, one uses the following command:

tcpdump -i any -s 0 -w host 10.1.1.1

A feature request would be to start tcpdump with a specified interface to capture on - in this case, one that does not exist yet - and it will wait until the interface becomes available, at which time it would start capturing.

[guyharris]

The bulk of this should probably be done in libpcap, to 1) hide the platform dependency of the "wait for an interface to become available" mechanism and 2) allow other programs to do this as well.

Note that the underlying capture mechanism might not support a "start capturing as soon as an interface with a given name appears" feature, which means there will probably be a period between the interface becoming available and the capture starting in which packets won't be captured.

There's also the question of whether you can predict the name the interface will have once it appears.

[floorjoist]

In our particular instance, we're ok since we're the we're the only consumers of a given driver, and we can predict the interface name every time (it always comes back as the same).

Adding to my original suggestion would be an option to pause logging when the interface disappears and wait for the interface to reappear and start logging again, rather than writing out and quitting once the interface is no longer available. We have a TUN0 interface that is created and torn down many, many times during the course of testing.

Should I post this request in the libpcap bug tracker/feature request instead?

[guyharris]

That still doesn't address the

Note that the underlying capture mechanism might not support a "start capturing as soon as an interface with a given name appears" feature, which means there will probably be a period between the interface becoming available and the capture starting in which packets won't be captured.

issue. If that issue isn't a problem, you might want to just have a program that waits for the interface to appear and then starts tcpdump, as you run the risk of missing the initial packets no matter what.

[mcr]

I think that a loop in tcpdump that tries to open the device, sleeping between attempts would suffice.
Finding out when the interface appears is work for libnl (on Linux), or the routing socket on BSD machines. I don't know if libpcap should abstract that, but we already link libnl on Linux, I think.
But, as Guy says, the initial packets likely get lost as there is a race involved.
On Linux at least, one can make a /dev/net/tun interface persistant (and even change the uid that can open it). I don't recall if that causes the associated netdev persistant as well, or just the "master" side.

[mcr]

It's also really hard to capture initial packets (like DAD, PADT...) as the interface is down. A kernel patch to permit captures to occur when the interface is down would be nice.

[AGI-chandler]

Hi I came across this issue as I'd like to do something similar.  I think it could be accomplished with systemd.  I have the basic pieces in place but the full automation is not yet there.  It's not terribly critical for us right now, so thought I would share what I came up with so far at least, maybe one of you are able to figure out the rest...

First, as root, I just created a new Service Unit, e.g. /etc/systemd/system/tcpdump-vpn0-DNS-queries.service with the following content:

[Unit]
Description=vpn0 DNS Queries Logger
PartOf=sys-devices-virtual-net-vpn0.device

[Service]
Type=simple
ExecStart=tcpdump -K dst port 53 -i vpn0
StandardOutput=append:/var/log/tcpdump-vpn0-port53.log

[Install]
WantedBy=network-online.target

Then run systemctl daemon-reload.   The idea is that, when interface vpn0 is activated and created (by NetworkManager in this case), then the service will start tcpdump.  sys-devices-virtual-net-vpn0.device is the corresponding Systemd Device that gets created when the interface comes up.  It's listed in systemctl list-units after being activated.

Unfortunately the service doesn't get started when this happens, I'm not sure if different units need to be defined in PartOf= or WantedBy=.  Requires= and After= are other options that might need to be defined as well.  Also, since I activate the vpn0 interface from my regular user account through Gnome, maybe there is some disconnect between that and needing escalated privileges to start the tcpdump service?

I can start the service manually with root/sudo, but there are further irregularities with the log file/standard output.  It seems when the service is started then I can see the initial output from tcpdump in the log file, i.e.:

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vpn0, link-type RAW (Raw IP), snapshot length 262144 bytes

However, no further output is logged until I manually restart the service, then all the output that has been building up from tcpdump is dumped into the log file all at once... weird.  Anyway that's about it, there seem to be some others out there with more compilcated "systemd tcpdump" service units too so that might be worth exploring.  Best of luck!