| Summary: | net-analyzer/iptraf - make iptraf see br and vmnet devices ( among others ) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rui Santos <rsantos> |
| Component: | Current packages | Assignee: | Peter Volkov (RETIRED) <pva> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | jer, netmon |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Thank you for report Rui! In case of iptraf this is the right place to report such bugs. But note, if upstream is active it's also worth to report all patches upstream. And next time, please, put patches as attachments. (you have to create bug first and then attach patch). Fixed in iptraf-3.0.0-r4.ebuild. Why did the following things happen?: 1) The patch went straight in, without consulting upstream. 2) The revision bump was needless, as probably a minority of users would use these devices && use iptraf to monitor them. 3) The bump went straight to stable so that everybody now gets an iptraf with an untested patch on their systems. I have reverted 3.0.0-r4 to ~arch for now. Stabilisation may follow in, say, 30 days? (In reply to comment #2) > Why did the following things happen?: > > 1) The patch went straight in, without consulting upstream. Taking into account that I do not see much activity in upstream I've decided not to spent much time trying to contact them. Can you confirm that they are more or less active? > 2) The revision bump was needless, as probably a minority of users would use > these devices && use iptraf to monitor them. Rev bump is always required when patch with does not affect compilation problem is applied. > 3) The bump went straight to stable so that everybody now gets an iptraf with > an untested patch on their systems. > I have reverted 3.0.0-r4 to ~arch for now. Sorry about that. My fault. I was more concentrated on how to cope with different one-two line patches and finding out what they do... Thank you for fix. > Stabilisation may follow in, say, 30 days? Sure. :) And in any case bug was fixed ;) (In reply to comment #1) > Thank you for report Rui! > > In case of iptraf this is the right place to report such bugs. But note, if > upstream is active it's also worth to report all patches upstream. And next > time, please, put patches as attachments. (you have to create bug first and > then attach patch). > > Fixed in iptraf-3.0.0-r4.ebuild. > What is that upstream "thing" ? I'm assuming is some kind of discussion mailinglist environment... Whatever it is, I did not find any reference to it on gentoo web sites. Can you please point me out to any "link" that I can read to find out how it is done? About the attched patch, from now on, I will do what you mentioned. Thanks. "Upstream" means whoever develops or developed a package or a program packaged by Gentoo. The HOMEPAGE variable in ebuilds commonly refers to the website of "upstream", usually the author or authors. Sending a patch upstream means contacting the original developers/maintainers of the package. The term seems to have been derived from "swimming upstream". By analogy, in the case of reporting bugs, you would be sending code (patches) the wrong way. Normally code would be coming down from authors to distributors to users, but patches go from users to distributors to authors. http://en.wikipedia.org/wiki/Upstream_(computer_science) has a short explanation (4th paragraph). Got it. Thanks for your time Jeroen. |
iptraf does not support br( bridge ) nor vmmnet( e.g. vmware ) devices. Reproducible: Always Steps to Reproduce: 1. Create a bridge 2. Run iptraf 3. br0 will not appear in the network lists Expected Results: They show appear and be able to do sniff them. Another distribution ( openSUSE ) has a patch iptraf that will allow these devices to be shown. I adapted that patch it would apply on the files at /var/tmp/portage/net-analyzer/iptraf-3.0.0-r3/work/iptraf-3.0.0/src Sorry to be this way but, I'm new to gentoo ( trying it to replace openSUSE ). Here is the patch: --- src/ifaces.c +++ src/ifaces.c @@ -32,14 +32,15 @@ #include "error.h" extern int accept_unsupported_interfaces; -#define NUM_SUPPORTED_IFACES 28 +#define NUM_SUPPORTED_IFACES 35 extern int daemonized; 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", "ath", "bnep" + "pent", "lec", "brg", "tun", "tap", "cipcb", "tunl", "vlan", "ath", "bnep", + "dsl", "modem", "ni", "br", "tap", "dummy", "vmnet" }; char *ltrim(char *buf) --- src/packet.c +++ src/packet.c @@ -128,8 +128,12 @@ result = LINK_INVALID; break; } - } else if (accept_unsupported_interfaces) + } + else if(strncmp(ifname, "ni", 2) ==0 || strncmp(ifname, "tap", 3) == 0 || strncmp(ifname, "dummy", 5) == 0 || strncmp(ifname, "br", 2) == 0 || strncmp(ifname, "vmnet", 5) == 0) result = LINK_ETHERNET; + + else if (accept_unsupported_interfaces) result = LINK_ETHERNET; + break; case ARPHRD_LOOPBACK: result = LINK_LOOPBACK; --- src/promisc.c +++ src/promisc.c @@ -87,6 +87,11 @@ (strncmp(buf, "tr", 2) == 0) || (strncmp(ptmp->params.ifname, "wvlan", 4) == 0) || (strncmp(ptmp->params.ifname, "lec", 3) == 0) || + strncmp(buf, "ni", 2) == 0 || + strncmp(buf, "tap", 3) == 0 || + strncmp(buf, "dummy", 5) == 0 || + strncmp(buf, "br", 2) == 0 || + strncmp(buf, "vmnet", 5) == 0 || (accept_unsupported_interfaces)) { strcpy(ifr.ifr_name, buf); I hope this is the correct place to make any sugestion...