Created attachment 482389 [details] Patch Description of problem: Network devices can have arbitrary names, and due to http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming, will have different names in Fedora 15. ifaces.c: char ifaces[][6] = { "lo", "eth", "sl", "ppp", "ippp", "plip", "fddi", "isdn", "dvb", "pvc", "hdlc", "ipsec", "sbni", "tr", "wvlan", "wlan", "sm2", "sm3", "pent", "lec", "brg", "tun", "tap", "cipcb", "tunl", "vlan", "hsi", "ctc", "ath", "bond" }; It matches against this to determine whether an interface is supported. Version-Release number of selected component (if applicable): iptraf-3.0.1 How reproducible: Visible by code inspection. The attached patch fixes this by always accepting device names. Seems like a better idea than trying to extend the whitelist.
Needs some further fixes; promisc.c:init_promisc_list() and packet.c:getlinktype() are similarly broken.
Enable unsupported devices are bad idea. It's always marked as Ethernet device. Which device what you want to be supported?
The point is that ethernet devices could be named anything: eth0, em2, pci3, fred, bob, etc... attempting to categorize them simply by device name will always have holes.
iptraf dont view intel interface https://bugzilla.redhat.com/show_bug.cgi?id=706317 when fix?
is there a way to determinate what devices is what? Not all devices are Ethernet, that why is there the list.
/sys/class/net/<name>/type These correspond to the types in include/linux/if_arp.h.
ok, that sounds lovely to my ears. During next week I'll write the patch and post it here for testing.
*** Bug 699178 has been marked as a duplicate of this bug. ***
FWIW, bumping the severity on this. With consistent device naming in F15, iptraf is essentially useless. It can only monitor the localhost interface.
I was just getting ready to file a new Bugzilla report on iptraf when I stumbled across this existing report. I will second Matthew's comment. I use iptraf extensively to troubleshoot network issues and with iptraf broken in F15, I am operating with 1.5 hands tied behind my back.
ok, I have a ready patch, but I haven't test iptraf well yet. I'll prepare scratch build and if you could test iptraf it'll be awesome.
Yes, happy to test. I have an F15 system set up as a firewall at a customer site with 2 live NICs and a third NIC not connected to anything. The NICs are named em1, p1p1, and p2p1. Thanks. Should I file a new bugzilla for the "Warning: unable to tag this process" error when iptraf starts up?
Damn, firstly try to remove all locks (iptraf -f). Secondly take a look if /var/lib/iptraf/ and /var/lock/ directories exists. From top of my head there were some changes due to systemd. (will look at it and I'll fix it in scratch build)
Looks like an easy workaround for the "unable to tag this process" problem: [root@hhhc-fw ~]# iptraf -f Unable to read directory /var/lock/iptraf No such file or directory Press Enter to continue. Warning: unable to tag this process Press Enter to continue. [root@hhhc-fw ~]# mkdir /var/lock/iptraf [root@hhhc-fw ~]# iptraf -f [root@hhhc-fw ~]# iptraf [root@hhhc-fw ~]# Aw nuts, I forgot to look and see if /var/lock already existed before I created /var/lock/iptraf by hand.
Any progress on this?
https://bugzilla.redhat.com/show_bug.cgi?id=734019 iptraf is created under /var/lock but in reboot iptraf directory is not present. Systemd?.
systemd or I can add a few lines to create this directory.
(In reply to comment #11) > FWIW, bumping the severity on this. With consistent device naming in F15, > iptraf is essentially useless. It can only monitor the localhost interface. Same problem here. My em1 interface is not usable, even if I specify it on command line "iptraf -i em1". :-(
*** Bug 706317 has been marked as a duplicate of this bug. ***
Same problem on a fresh installation of Fedora 16. :(
Same problem in F16 using preupgrade from F15, iptraf fail
Come on guys, surely this can't be difficult to fix. I suspect even a beginner could find a list of device strings, modify and recompile, but making an rpm isn't so trivial - at least for me!
Downloaded latest source from http://iptraf.seul.org/ and applied this patch. Good news is that it does not give no supported interface error. Bad news is that the TCP flow rate is not calculated (stays 0.00 kbits/s). IP Traffic Monitor on em1. Not sure if this same issue is present in the Fedora RPM - since it doesn't work at all. Nine months since patch provided, any guess on when this RPM is going to be fixed so that it works on Fedora?
As a workaround you can add the "-u" option to iptraf, which is essentially what Bill's patch does.
iptraf-ng-1.1.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/iptraf-ng-1.1.0-1.fc15
iptraf-ng-1.1.0-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/iptraf-ng-1.1.0-1.fc16
Package iptraf-ng-1.1.0-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing iptraf-ng-1.1.0-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0453/iptraf-ng-1.1.0-1.fc16 then log in and leave karma (feedback).
iptraf-ng-1.1.0-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/iptraf-ng-1.1.0-2.fc16
iptraf-ng-1.1.0-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/iptraf-ng-1.1.0-2.fc15
*** Bug 782020 has been marked as a duplicate of this bug. ***
iptraf-ng-1.1.0-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
iptraf-ng-1.1.0-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.