-
Notifications
You must be signed in to change notification settings - Fork 834
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Numeric adapter names can't be used for capture #522
Comments
The reason for the
In the list above only numbers 1 and 3 have a corresponding ifindex. That said, when a network interface name is a number, the existing convention does not work. As the comment in /*
* If the argument is a number, treat it as
* an index into the list of adapters, as
* printed by "tcpdump -D".
*
* This should be OK on UNIX systems, as interfaces
* shouldn't have names that begin with digits.
* It can be useful on Windows, where more than
* one interface can have the same name.
*/ In this case either the existing convention should be reviewed or the system in question should use a more traditional network interface naming pattern. |
How many network interfaces does it take to slow |
The number is not, and has never been intended to be, an ifindex. It is, and has always been intended to be, an ordinal number in the On systems where interfaces have short simple names, the number convention isn't all that useful; however, tcpdump also runs on systems where interfaces have ugly names with UUIDs in them, namely all NT flavors of Windows starting with Windows 2000. So, yes, tcpdump should try to open the name before it decides it's an ordinal number in the interface list. |
OK, that's a little over 4.7 seconds of CPU time - mostly spent fetching interface information from the kernel, given that almost all of that is system time. Most of that 2 minutes 10 seconds is presumably spent printing the list of interfaces, as 130 >> 4.7, so the fact that it takes minutes isn't the result of tcpdump or libpcap being slow, it's the result of the list being long, and therefore there's not much tcpdump can do about making it faster. |
The time printing the interfaces is not that long - you can try this even on a system with only 100 interfaces or so and the user time is much longer than the time spent printing the interfaces - the lag time between running the command and any output showing up is quite a while. Much of the time seems to be spent in some never ending sequence of socket operations that look a little odd (although this isn't my jam, so maybe this looks ok):
|
288 interfaces (not counting "any") seems to take ~10 seconds on a 24 core system:
2500 interfaces takes a few minutes. |
Some strace summary output for reference:
Something in there waits for some period of time that isn't charged to |
Could you confirm those are the latest master branch builds of tcpdump and libpcap and also tell the distribution and version of the OS? Thank you. |
They're definitely not:
The userland is Ubuntu 14.04.4 server LTS. |
Could you please check using the latest versions? |
I certainly can't change the libpcap version on production systems - I'll see what I can do about building some static binaries for testing. That being said, the code is the same now - as identified earlier in the thread. There's nothing that has changed that will change the fact that tcpdump can't capture on these interfaces without finding their "indices" according to tcpdump. I don't care how long it takes tcpdump to generate these index numbers - I care that I can't use the actual name. |
To build the latest binary you would need a git clone of libpcap and a git clone of tcpdump (next to each other such that tcpdump configure script can find libpcap in |
(If anybody feels up to working on this, please feel free to do, I am mainly collecting the details when I have a spare minute). |
…d only on failure look up numeric indexed device
Some UN*Xes apparently can have purely numeric interface names, so we can't unconditionally treat purely numeric interface names as interface indices. Do so only for "names" that don't correspond to interfaces. Fixes GitHub issue #522.
If N is a number, and is the name of an interface on the system, "-i N" will now attempt to open that interface, not the Nth interface in the list of interfaces. See GitHub issue #522.
…umber. Our current assumption that a numeric argument to -i must be an index interface is not valid on Linux; see the-tcpdump-group/tcpdump#522 Change-Id: Ieb6e17e6ceb23095a463336f0c88182373503aa6 Reviewed-on: https://code.wireshark.org/review/37369 Reviewed-by: Guy Harris <gharris@sonic.net>
At the time the bug was filed, libpcap tried to open all interfaces found by the call made to find interfaces, so that only interfaces that could be opened were added. That caused users to see no interfaces when they didn't have permission to capture, which caused them to ask on Wireshark Q&A/ask on Wireshark mailing lists/etc. "why isn't Wireshark seeing any interfaces?", which caused Wireshark developers to spend extra time figuring out that the problem was permissions (and, if they were running on a Debian derivative, telling them to run the installer command that gave Wireshark's dumpcap program the capability needed to capture). So I changed libpcap so that it used different mechanisms - if any - to determine whether an interface is supported by the capture mechanism (that test dates back to issues with the loopback device on Solaris 10 and earlier - it showed up as an interface but the DLPI capture mechanism didn't support it - and "don't show loopback interfaces" was clearly the wrong answer, as both the BSDs and Linux do support capturing on it). For Linux, that meant "no mechanism"; if it shows up as an interface, you should be able to bind it to a PF_PACKET socket. So current versions of libpcap should do much less work getting the interface list - and, in a quick test on an Ubuntu virtual machine with the tip of the master branch, they do; that change was made a while ago, so libpcap 1.9.x, at least, should skip that stuff. |
tcpdump should try to open the name before it decides it isn't there:
Also, adapter indices aren't
ifindex
numbers (this is clear-ish from the man page, but not from the error message), they're some version of a number that tcpdump makes on its own, which you can only get by runningtcpdump -D
, which takes literally minutes on systems with lots of interfaces:The text was updated successfully, but these errors were encountered: