Bug 1062511
| Summary: | tcpdump: WARNING: SIOCGIFADDR: nflog: No such device | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ian Kent <ikent> |
| Component: | libpcap | Assignee: | Michal Sekletar <msekleta> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jan Ščotka <jscotka> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | jiyin, jscotka, lmiksik, lnykryn, mwoehlke.floss |
| Target Milestone: | rc | Keywords: | TestBlocker |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 13:00:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ian Kent
2014-02-07 06:45:03 UTC
You didn't specify interface on which you would like to capture packets. In this case tcpdump will call pcap_lookupdev() function which returns first non-loopback device on the box. It looks like on your machine nflog pseudo-interface is first in the list (you can check by printing list of available interfaces using tcpdump -D). There is a filter provided, but for DLT_NFLOG we don't support BPF filtering. tcpdump shouldn't crash as it does now, but if we backport the patch it will not solve your problem. You'd have to patch your test anyway and provide interface name explicitly. (In reply to Michal Sekletar from comment #2) > > tcpdump shouldn't crash as it does now, but if we backport the patch it will > not solve your problem. You'd have to patch your test anyway and provide > interface name explicitly. That's sounds easy enough but it isn't. It's a multi-host test and the beaker machines can be on different subnets so you can't assume that because an interface is on the same network it is the server in question. AFAICS there is only one interface used on each machine and it would be reasonably straight forward to find it but there is no guarantee that will be the case in future. Perhaps the multiple interface argument above is lame since tcpdump wouldn't know which interface to use either, mmm .... This is a regression though since, with a single interface, this worked fine for years. What changed? Ian Our primary source of information about interfaces on the system is getifaddrs() function. Looking at the source code, it doesn't look like something relevant has changed. If the order is different from what it was then I think something has changed under the hood, either glibc or kernel. If there are any ordering guarantees for list of interfaces then this is the regression (not necessarily in libpcap). I will check on that with upstream maintainers. But I am not convinced yet that this is the case. According to discussion [1] ("The list of network adapters...") on tcpdump-workers mailing list it looks like there are no ordering guarantees and if you did rely on them I think you are just out of luck. Sorry.
I will just backport the patch so we don't segfault when trying to apply filter on interface with NFLOG datalink type.
[1] http://article.gmane.org/gmane.network.tcpdump.devel/5240
(In reply to Michal Sekletar from comment #5) > According to discussion [1] ("The list of network adapters...") on > tcpdump-workers mailing list it looks like there are no ordering guarantees > and if you did rely on them I think you are just out of luck. Sorry. > > I will just backport the patch so we don't segfault when trying to apply > filter on interface with NFLOG datalink type. We should be filtering on an ip address (and if not it shouldn't be too hard to do so) so a "-i any" might be sufficient, as long as tcpdump doesn't fail due to the nflog problem. Ian By all means, you can try -i any. Let me know if it works for you. And no, tcpdump should not fail when '-i any' is specified. (In reply to Michal Sekletar from comment #7) > By all means, you can try -i any. Let me know if it works for you. And no, > tcpdump should not fail when '-i any' is specified. All usages of tcpdump in my tests use a source or destination filter on addresses. Using the "-i any" worked in a manual test and did result in a couple of tests passing that previously failed due to this difficulty. So it looks like this approach works fine. I backported the patch [1]. Thanks for the report! Btw, I am glad to hear that -i any workaround works for you. [1] http://bulk-mail.corp.redhat.com/archives/cvs-commits-list/2014-February/msg07008.html This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. I'm seeing this also in Fedora 20. Can the change be made there also, or do I need to open a separate bug report? |