Bug 682348 - assumes network devices are named certain things
Summary: assumes network devices are named certain things
Alias: None
Product: Fedora
Classification: Fedora
Component: iptraf
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Nikola Pajkovsky
QA Contact: Fedora Extras Quality Assurance
: 699178 706317 782020 (view as bug list)
Depends On:
Blocks: 682334 682350
TreeView+ depends on / blocked
Reported: 2011-03-04 21:45 UTC by Bill Nottingham
Modified: 2014-03-17 03:26 UTC (History)
18 users (show)

Fixed In Version: iptraf-ng-1.1.0-2.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 682350 (view as bug list)
Last Closed: 2012-01-24 19:56:13 UTC
Type: ---

Attachments (Terms of Use)
Patch (473 bytes, patch)
2011-03-04 21:45 UTC, Bill Nottingham
no flags Details | Diff

Description Bill Nottingham 2011-03-04 21:45:48 UTC
Created attachment 482389 [details]

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.


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):


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.

Comment 1 Bill Nottingham 2011-03-04 21:53:12 UTC
Needs some further fixes; promisc.c:init_promisc_list() and packet.c:getlinktype() are similarly broken.

Comment 2 Nikola Pajkovsky 2011-03-07 08:50:23 UTC
Enable unsupported devices are bad idea. It's always marked as Ethernet device. Which device what you want to be supported?

Comment 3 Bill Nottingham 2011-03-07 17:25:49 UTC
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.

Comment 4 stufently 2011-05-25 15:46:37 UTC
iptraf dont view intel interface
when fix?

Comment 5 Nikola Pajkovsky 2011-05-26 09:10:21 UTC
is there a way to determinate what devices is what? Not all devices are Ethernet, that why is there the list.

Comment 6 Bill Nottingham 2011-05-26 18:57:29 UTC

These correspond to the types in include/linux/if_arp.h.

Comment 7 Nikola Pajkovsky 2011-05-27 09:10:57 UTC
ok, that sounds lovely to my ears. During next week I'll write the patch and post it here for testing.

Comment 10 Nikola Pajkovsky 2011-06-01 10:40:12 UTC
*** Bug 699178 has been marked as a duplicate of this bug. ***

Comment 11 Matthew Booth 2011-06-05 08:50:01 UTC
FWIW, bumping the severity on this. With consistent device naming in F15, iptraf is essentially useless. It can only monitor the localhost interface.

Comment 12 Greg Scott 2011-07-20 06:00:32 UTC
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.

Comment 13 Nikola Pajkovsky 2011-07-20 06:08:45 UTC
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.

Comment 14 Greg Scott 2011-07-20 06:21:08 UTC
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?

Comment 15 Nikola Pajkovsky 2011-07-20 06:40:14 UTC
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)

Comment 16 Greg Scott 2011-07-20 18:05:51 UTC
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.

Comment 17 Orion Poplawski 2011-09-13 21:48:52 UTC
Any progress on this?

Comment 18 xset1980 2011-09-15 10:15:15 UTC

iptraf is created under /var/lock but in reboot iptraf directory is not present.

Comment 19 Nikola Pajkovsky 2011-09-19 09:17:02 UTC
systemd or I can add a few lines to create this directory.

Comment 20 Jan ONDREJ 2011-10-10 11:30:50 UTC
(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". :-(

Comment 21 Rodrigo A B Freire 2011-10-13 16:59:03 UTC
*** Bug 706317 has been marked as a duplicate of this bug. ***

Comment 22 Thomas Müller 2011-11-12 17:31:37 UTC
Same problem on a fresh installation of Fedora 16. :(

Comment 23 xset1980 2011-11-28 10:15:27 UTC
Same problem in F16 using preupgrade from F15, iptraf fail

Comment 24 Andrew Haveland-Robinson 2011-11-28 23:50:59 UTC
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!

Comment 25 Lee Clemens 2011-12-16 00:34:08 UTC
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?

Comment 26 Orion Poplawski 2011-12-16 22:46:47 UTC
As a workaround you can add the "-u" option to iptraf, which is essentially what Bill's patch does.

Comment 27 Fedora Update System 2012-01-12 07:12:11 UTC
iptraf-ng-1.1.0-1.fc15 has been submitted as an update for Fedora 15.

Comment 28 Fedora Update System 2012-01-12 07:12:34 UTC
iptraf-ng-1.1.0-1.fc16 has been submitted as an update for Fedora 16.

Comment 29 Fedora Update System 2012-01-15 19:58:15 UTC
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:
then log in and leave karma (feedback).

Comment 30 Fedora Update System 2012-01-16 11:16:05 UTC
iptraf-ng-1.1.0-2.fc16 has been submitted as an update for Fedora 16.

Comment 31 Fedora Update System 2012-01-16 11:16:31 UTC
iptraf-ng-1.1.0-2.fc15 has been submitted as an update for Fedora 15.

Comment 32 Nikola Pajkovsky 2012-01-16 11:42:47 UTC
*** Bug 782020 has been marked as a duplicate of this bug. ***

Comment 33 Fedora Update System 2012-01-24 19:56:13 UTC
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.

Comment 34 Fedora Update System 2012-01-24 19:59:52 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.