| Summary: | tcpdump doesn't work on interface "any". | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Calum <caluml> |
| Component: | Current packages | Assignee: | Gentoo Netmon project <netmon> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Patch: Fix the handling of the "any" device in libpcap-1.0.0, including making it reject attempts to open it in monitor mode.
libpcap-1.0.0-r3.ebuild with patch my "emerge --info" |
||
|
Description
Calum
2006-02-10 09:14:48 UTC
Calum: Do you mean, that tcpdump works on x86 and does not work on amd64? Please, give emerge --info and show USE flags, you compiled tcpdump with. BTW. I can not reproduce bug on amd64 with my useflags (-ipv6 ssl) and tcpdump-0.9.3 and libpcap-0.9.3. Yes, I mean that it works as expected on an x86 box, but not on my AMD64 box. The flags compiled with: net-libs/libpcap +ipv6 net-analyzer/tcpdump +ipv6 +ssl Portage 2.0.51.22-r3 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-vs2.1.0-pre5-gentoo x86_64) ================================================================= System uname: 2.6.13-vs2.1.0-pre5-gentoo x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 acl aim alsa apache2 aper avi berkdb browserplugin bzlib cdparanoia crypt dga directfb divx4linux dlloader dv dvd dvdr dvdread encode faac faad ffmpeg fla flash gd-external gdbm gif gmp gphoto2 gtk2 hardened ieee1394 imlib ipv6 jabber jack java jpeg kde live lzo mad maildir matroska memlimit mozilla mozsvg mp3 mpeg mpeg4 mplayer msn network nls nodrm ntlm ogg oggvorbis opengl oscar pcre perl php pic pie png postgres quotas readline real rrdtool rtc samba sdl session sftplogging ssl svg tga theora tiff truetype truetype-fonts underscores v4l v4l2 voodoo3 vorbis xanim xfs xml2 xmms xv xvid xvmc yahoo yv12 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY I'll try recompiling tcpdump with -ipv6 and test # tcpdump -npi any not tcp port 23422 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel Nope, didn't make any difference with tcpdump -ipv6. My x86 libpcap and tcpdump are the same version, and have the same USE flags. 1. But what happens if you disable any filtering. Just select all traffic. Like this: `tcpdump -ni any` or just `tcpdump -n`. Can you see any traffic? And please. Show us all output do not redirect it to /dev/null. Few packets is enough. 2. Try to install any libpcap dependent utility. Fex iftop. Does it see any traffic? 3. May be you should try to reinstall all libs tcpdump depends on. Try to emerge -1a dev-libs/openssl net-libs/libpcap net-analyzer/tcpdump And more. Try to find out what net devices do you have in your system (ifconfig :) And try to set explicitly interface that has some traffic. BTW. You can check existance of traffic with `watch -d 'ifconfig eth0'`. Yes, tcpdump sees traffic without filters. # tcpdump -npi any tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 bytes 13:12:25.786571 IP 217.x.x.x.1022 > 82.x.x.x.60643: . 1764425161:1764426539(1378) ack 2669982064 win 2728 <nop,nop,timestamp 2531757159 451505> Lots and lots snipped. 314 packets captured 314 packets received by filter 0 packets dropped by kernel # tcpdump -npi any not tcp port 999 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 bytes ...wait a long time - yes there is traffic... 0 packets captured 0 packets received by filter 0 packets dropped by kernel Updated openssl yesterday: to dev-libs/openssl-0.9.7i tcpdump is net-analyzer/tcpdump-3.9.3 net-libs/libpcap-0.8.3-r1 Aaah. It's a problem with the "any" interface. If I run: tcpdump -npi eth0 not tcp port 999 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes ... I get lots of packets... 105 packets captured 105 packets received by filter 0 packets dropped by kernel Is this intentional? It's different behaviour to x86. Well. So problem is not filters but with interface "any". I can not reproduce your bug on amd64 system. So I'm not sure that this is amd64 specific. But I just noticed that you have hardened in your USE flags. I'm not sure but this may affect too. Have you hardened in you use flags on x86 system? And what is output of tcpdump -D? # tcpdump -D 1.eth0 2.tap1 3.tap2 4.eth2 5.any (Pseudo-device that captures on all interfaces) 6.lo The emerge --info from the x86 box: # emerge --info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.12-vs2.0-gentoo-r1 i686) ================================================================= System uname: 2.6.12-vs2.0-gentoo-r1 i686 VIA Nehemiah Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5-r2 [2.3.5 (#1, Oct 5 2005, 17:17:29)] dev-lang/python: 2.3.5-r2 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.2-r5 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 aac acpi alsa apm audiofile avi berkdb bzip2 cdparanoia crypt curl directfb divx4linux dv dvd eds emboss encode expat flac gd-external gif gstreamer gtk2 idn ipv6 jpeg kde lcms libg++ libwww lzo mhash mmx mmx2 mng mp3 mpeg ncurses network nls ogg oggvorbis perl png postgres readline sse sse2 ssl svga truetype truetype-fonts type1-fonts udev v4l v4l2 vorbis xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY So no, no hardened flags in the x86 box it looks like. As I say though, it used to work fine. Oh, I'm away until Tuesday/Wednesday now, so I won't be able to try anything. Calum. I've tryed and I can not reproduce your problem on amd64 hardened server. If you do not have enough time to debug problem on your own I suggest to reemerge whole system with --emptytree flag. May be this solves the issue... If you want to debug. You may insert prints in libpcap starting from pcap_open_live() and try to find out, what happens there. :) Well, I'd love to help! I can't reemerge my system though.. :( What about stracing the process ? I'd love to work this out. I re-compiled it without ipv6 support ( :( which I need ) and it now works. # tcpdump -npi any not port 1234 >/dev/null tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 bytes 134 packets captured 134 packets received by filter 0 packets dropped by kernel Can we find out why ipv6 support seems to break this? Hm. Seems that something broken in your build environment. In comment #3 you told that if you disable ipv6 flag nothing changes... But I'll try to test this on my box with ipv6 enabled. Well, you're right, it does say that. Perhaps it's just coincidence. Shall I recompile with IPv6 support and try again? i have a similar problem but on x86 platform: I do have a ipv6 uplink via a v6 in v4 tunnel I tried a tcpdump -i sit1 Using any kind of filter I see nothing using no filters I see packets. So there seems to be something broken with interfaces that are not physical and v6... emerge --info: Gentoo Base System version 1.6.14 Portage 2.0.54 (default-linux/x86/no-nptl/2.4, gcc-3.4.5, glibc-2.3.5-r2, 2.4.31 -gentoo-r1 i686) ================================================================= System uname: 2.4.31-gentoo-r1 i686 Pentium III (Coppermine) distcc 2.18.3 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled ] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.19-r1, 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/ distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 acl alsa apm arts avi berkdb bitmap-fonts bzip2 crypt cups eds emboss e ncode expat foomaticdb fortran gd gdbm gif gpm gstreamer gtk2 imlib ipv6 jpeg kd e ldap libg++ libwww mad mbox mikmod mmx motif mp3 mpeg ncurses nls ogg old-cryp t opengl oss pam pcre pdflib perl png postgres python qt quicktime readline sdl slang spell sse ssl tcpd truetype truetype-fonts type1-fonts vorbis xml xml2 xmm s xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY Or perhaps the filter changed too. Doesn't not tcp port 1234 translate into "not tcp" _and_ "port 1234", meaning no traffic will ever match? In the working example it was simply "not port 1234" right? Meaning that you actually want (in C syntax) something like !(tcp && port 1234), which using de-morgan becomes !tcp || !port 1234, or in pcap syntax: not tcp or not port 1234. Please test with 3.9.5 again, I just bumped it . Created attachment 223097 [details, diff]
Patch: Fix the handling of the "any" device in libpcap-1.0.0, including making it reject attempts to open it in monitor mode.
Created attachment 223099 [details]
libpcap-1.0.0-r3.ebuild with patch
Created attachment 223101 [details]
my "emerge --info"
Comment on attachment 223101 [details] my "emerge --info" I had a similar problem on AMD64 platform. And I had these in the output: diamond ~ # tcpdump -i any icmp tcpdump: SIOCGIFHWADDR: No such device diamond ~ # tcpdump -D 1.ppp0 2.eth1 3.eth2 4.lo I found the patch on http://packages.debian.org/sid/libpcap0.8-dev It's in http://ftp.de.debian.org/debian/pool/main/libp/libpcap/libpcap_1.0.0-6.debian.tar.gz package and it's called "20-fix-any-intf.diff". After I used the patch (see attachment) this problem was solved: diamond ~ # tcpdump -i any icmp and dst host diamond.mlzone tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes diamond ~ # tcpdump -D 1.ppp0 2.eth1 3.eth2 4.any (Pseudo-device that captures on all interfaces) 5.lo See also ebuild for net-libs/libpcap-1.0.0-r3 in attachment. Special thx to <guy> (author of that patch). |
