Wireshark and nftables

asked 2024-02-13 05:59:14 +0000

fsbof
3 ●3

updated 2024-02-15 08:28:30 +0000

Hi,

I have Wireshark installed on Linux and it works fine.

When starting Wireshark, it was starting very quickly (less the 2 seconds) until I setup nftables.

It then started to pause on 'Initializing external capture plugins' for about 20-25 seconds.

I have been trying to workout what it was stumbling over and have come up with the following;

With only a very simple input and output chain that have 'accept' as their default states, Wireshark starts quickly.
With either or both being set to 'drop', Wireshark pauses.
With both being set to 'accept' and the loopback, eth, wlan interfaces all being set to 'drop', Wireshark starts quickly.
With either or both being set to 'drop' and all the interfaces shown by Wireshark except for 'bluetooth-monitor' being set to 'accept', Wireshark pauses.
With either or both being set to 'accept' and all the interfaces shown by Wireshark except for 'bluetooth-monitor' being set to 'drop', Wireshark starts quickly.

I am unable to add 'bluetooth-monitor' as an interface to nftables even to test. The error reported by the syntax checker is the interface names exceeds 16 characters! I also tried adding 'pan1' to nftables which compiled ok but made no difference. I should note that there is no bluetooth interface on this host

Has anyone got any suggestions;

A. what may be causing Wireshark to start slower? (Resolved : Loopack interface was blocked - see comment by @johnthacker below - thanks)

B. what troubleshooting steps I could take next? (Resolved : Thanks @Jaap, @Guy-Harris and johnthacker for your suggestions)

C. fingers crossed - what a fix might be? ;-) (Resolved : See above)

Many Thanks

Kernel 6.1.75

Wireshark 4.0.12

edit retag flag offensive close merge delete

Comments

If you go into preferences, one the 'Capture' panel, there are two settings (Don't load interfaces at startup and Disable external capture interfaces). Does toggling these have an impact? What happening if you run dumpcap -D from the command line?

Jaap ( 2024-02-13 21:55:36 +0000 )edit

Hi @Jaap

Don't load interfaces at startup - doesn't seem to affect it, it is still slower.
Disable external capture interfaces - also doesn't seem to affect it, it is still slower.
dumpcap -D responds quickly with no delays and returns a list of all the interfaces except for the Extcap ones. So it includes the real interfaces, any, loopback, bluetooth-monitor, nflog and nfqueue.

Thank you for the pointer to dumpcap, I've used wireshark for years but never explored this option and it's perfect for something else I want to do.

fsbof ( 2024-02-13 23:56:40 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2024-02-14 01:55:47 +0000

johnthacker
171 ●32 ●5

Sounds like the issue fixed by this commit.

It is probably related to the androiddump extcap, which uses Bluetooth, trying to see if a Bluetooth device is connected.

An unfortunate problem that I noticed recently is that Disabling the external capture interfaces does not, unfortunately, prevent the external capture interfaces from being initialized and checking to see if they are valid. This is because when the extcap preferences get registered, it calls all the extcap interfaces to get loaded (so that each can register its preferences). But that's before the other preferences get read, including the preference that says not to load the extcaps.

So while "Disable external capture interfaces" is the right idea, there's a bug in Wireshark. You might be able to simply remove the anddroiddump extcap from /usr/lib64/wireshark/extcap/ or wherever it's installed.

edit flag offensive delete link

Comments

Hi @johnthacker, thanks for this suggestion - the fix was in here! First I tried moving the androiddump (and all the other extcap files) out of the folder temporarily but it didn't seem to have any effect. Then, based on the link you provided, I tried explicitly allowing ('accept') traffic in/out of 'lo' in both chains. This resolved the issue. It probably makes sense to allow this anyway when drop is the default policy. I am sure other services also rely on the loopback interface, so it would probably catch me out somewhere else. Many, thanks.

fsbof ( 2024-02-15 08:21:04 +0000 )edit

add a comment

answered 2024-02-14 20:47:54 +0000

Guy Harris
19890 ●3 ●659 ●207

I am unable to add 'bluetooth-monitor' as an interface to nftables even to test.

Not all of the entities on which you can capture correspond to "normal" interfaces on the operating system for the machine running Wireshark.

For one thing, libpcap - which is the library used by tcpdump, Wireshark, and other programs to do packet captures - supports additional capture devices that don't correspond to network interfaces that show up in the OS networking stack. For example, on Linux, there are:

devices to support capturing raw USB traffic on the machine's USB buses (this is different from capturing on USB network interfaces, which uses the standard network stack plumbing; it can capture USB traffic to all USB devices, including, for example, disks, keyboards, mice, etc.);
devices to support netfilter traffic;
devices to support Bluetooth traffic.

bluetooth-monitor is one of those devices; as it's not a regular network device, ifconfig, ip, and nftables don't know that it exists.

In addition, Wireshark has its own mechanism, the "external capture" or "extcap" mechanism, which allows writing programs (in a compiled or scripting language) to support capturing. Those are also unknown to the OS's networking stack.

what may be causing Wireshark to start slower?

The "external capture"/"extcap" devices can do so. See @Jaap's comment, and try doing what he suggests. If turning on "Disable external capture interfaces" makes Wireshark start faster, the problem is that one of the extcap programs is taking a while to start up.

edit flag offensive delete link

Comments

@Guy-Harris - Thank you for the explanation. The results to the things @Jaap suggested I look at are above. It doesn't appear to me to be related to an Extcap interface.

fsbof ( 2024-02-15 07:52:24 +0000 )edit

add a comment