Description of problem: tcptrack -i <interface> never shows any connections. Also: # tcptrack -i eth2 port 80 pcap_compile: syntax error It sucks up a lot of cpu doing it as well. Strace shows: [pid 1607] select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) [pid 1607] rt_sigaction(SIGTSTP, {0x679f440, [], SA_RESTART}, NULL, 8) = 0 [pid 1607] select(1, [0], NULL, NULL, {0, 100}) = 0 (Timeout) [pid 1607] rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTART}, {0x679f440, [], SA_RESTART}, 8) = 0 [pid 1607] select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) [pid 1607] select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) [pid 1607] rt_sigaction(SIGTSTP, {0x679f440, [], SA_RESTART}, NULL, 8) = 0 [pid 1607] select(1, [0], NULL, NULL, {0, 100}^C <unfinished ...> so not a very good event loop it seems. Version-Release number of selected component (if applicable): tcptrack-1.3.0-3.fc12.i686
The same problem appears on tcptrack.x86_64 tcptrack v1.3.0
Same issue here. I'm going to test a few other machines to see if there is a pattern. I'm running a fully updated Fedora 13 build x86_64. Thanks, ep
# tcptrack -i eth2 port 80 pcap_compile: syntax error That part is just the shell, quote the string tcptrack -i eth2 "port 80" But as for the tool actually doing anything, I don't see any traffic at all, selinux off/on iptables off/on strace shows a lot of select's failing, nothing much else I can make out of it...
Same issue also. tcptrack example: tcptrack -r 2 -i eth1 The output header and footer banners appear but with no tcp session info. On am on Fedora13 Kernel: 2.6.34.7-56.fc13.x86_64
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I built tcptrack 1.4.0, and that appears to work, although the event loop still sucks and it consumes at least 50% of my cpu when running. Kairo - are you still alive?
tcptrack-1.4.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/tcptrack-1.4.0-1.fc14
tcptrack-1.4.0-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/tcptrack-1.4.0-1.fc13
tcptrack-1.4.0-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update tcptrack'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/tcptrack-1.4.0-1.fc14
tcptrack-1.4.0-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
tcptrack-1.4.0-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.