Menu
▾
▴
devil-linux-develop
|
From: Andrzej O. <an...@ma...> - 2011-11-18 14:17:48
Attachments:
iptraf-tun-65534.diff.bz2
|
Dear Heiko, iptraf is a handy tool on routers, but does not show traffic on tun interfaces used by OpenVPN. A few months ago I found the cause, I made a patch and sent to the maintainers in Debian. I do not know whether this patch applied, but I'm using it for over half a year in the D-L on my production routers with success, so I think You can add it safely to the mainstream. Regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2011-11-18 15:32:39
|
Andrzej, I added the patch to CVS, thanks for submitting it. Heiko Quoting Andrzej Odyniec <an...@ma...>: > Dear Heiko, > > iptraf is a handy tool on routers, but does not show traffic on tun > interfaces used by OpenVPN. A few months ago I found the cause, I > made a patch and sent to the maintainers in Debian. I do not know > whether this patch applied, but I'm using it for over half a year in > the D-L on my production routers with success, so I think You can > add it safely to the mainstream. > > Regards > > -- > Andrzej Odyniec -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-03-05 14:30:18
Attachments:
iptraf-interfaces-sorting_diff.bz2
|
Heiko, Linux kernel (now 3.2.6) shows network interfaces in file /proc/net/dev not sorted, so far, but in some strange, random order. Network interfaces and tunnel pseudointerfaces are mixed. Meanwhile IPtraf builds an interface menu as well as the list of interfaces to the general statistics based on this file. If the router has a several interfaces, finding the appropriate becomes very difficult. I wrote the following patch to solve this problem, because I have on my central router several OpenVPN tunnels to office branches. So after building a list of interfaces, this list is also sorted lexicographically by name. In addition, in file /var/iptraf/iface.desc we can assign aliases and sorting keys for interfaces, in this way easily managing list. File is described in intro to patch. Regards Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-03-05 14:53:44
|
Andrzej, I upgraded the kernel in CVS to 3.2.9 over the weekend. Could you verify that this problem still exists in the newer version? If yes, then I don't see an issue with adding the patch. Heiko Quoting Andrzej Odyniec <an...@ma...>: > Heiko, > > Linux kernel (now 3.2.6) shows network interfaces in file > /proc/net/dev not sorted, so far, but in some strange, random order. > Network interfaces and tunnel pseudointerfaces are mixed. Meanwhile > IPtraf builds an interface menu as well as the list of interfaces to > the general statistics based on this file. If the router has a > several interfaces, finding the appropriate becomes very difficult. > > I wrote the following patch to solve this problem, because I have on > my central router several OpenVPN tunnels to office branches. So > after building a list of interfaces, this list is also sorted > lexicographically by name. > > In addition, in file /var/iptraf/iface.desc we can assign aliases > and sorting keys for interfaces, in this way easily managing list. > File is described in intro to patch. > > Regards > > Andrzej Odyniec -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-03-05 16:46:44
|
Heiko Zuerker wrote: > I upgraded the kernel in CVS to 3.2.9 over the weekend. Could you > verify that this problem still exists in the newer version? > If yes, then I don't see an issue with adding the patch. Heiko, I will check this problem. Maybe unsorted list of interfaces in /proc/net/dev is by error, not by design. Or maybe not. I will test my patch in both 32-bit and 64-bit compilation, because, as for now I only tested it on 32-bit compilation on my router. Iptraf code is old and raw, so there can be surprises with completly succesfull patching. As you now, there is try of reneval of iptraf, named iptraf-ng, but without serious changes. I was not sure, what I should patch: iptraf or iptraf-ng? So my changes was very delicate, possible to adopting on iptraf-ng too. So this patch is as for now, rather for testing, not for final application. But iptraf is still a very handy tool, so is worth adopting to current kernels. Regards Andrzej Odyniec |
|
From: Andrzej O. <an...@ma...> - 2012-03-06 14:46:56
Attachments:
iptraf-ltrim-for-64bit_diff.bz2
|
Heiko, I wrote: > I will check this problem. Maybe unsorted list of interfaces in /proc/net/dev > is by error, not by design. Or maybe not. For this I need some days, because many interfaces I have only on one, central router. To test, I need free night. So be patient. > I will test my patch in both 32-bit and 64-bit compilation, because, as for > now I only tested it on 32-bit compilation on my router. > > Iptraf code is old and raw, so there can be surprises with completly > succesfull patching. So... as for now, I prophesied. Testing my patch (still looks to be a valid) I found bug in iptraf, which manifests itself in the 64-bit compilation. In trimming interface name read from /proc/net/dev is used strcpy in improper manner to overlaping strings. Here is patch correcting this error. This patch is independent from previous patch, sorting interfaces. Best regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 14:53:56
|
Quoting Andrzej Odyniec <an...@ma...>: > Heiko, > > I wrote: >> I will check this problem. Maybe unsorted list of interfaces in >> /proc/net/dev is by error, not by design. Or maybe not. > > For this I need some days, because many interfaces I have only on > one, central router. To test, I need free night. So be patient. Okay. >> I will test my patch in both 32-bit and 64-bit compilation, >> because, as for now I only tested it on 32-bit compilation on my >> router. >> >> Iptraf code is old and raw, so there can be surprises with >> completly succesfull patching. > > So... as for now, I prophesied. Testing my patch (still looks to be > a valid) I found bug in iptraf, which manifests itself in the 64-bit > compilation. In trimming interface name read from /proc/net/dev is > used strcpy in improper manner to overlaping strings. Here is patch > correcting this error. This patch is independent from previous > patch, sorting interfaces. Any issues with this patch being present in the 32 bit version? -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-03-06 17:23:08
|
Heiko Zuerker wrote:
> Any issues with this patch being present in the 32 bit version?
Generally strcpy() function should not to be used in this manner as in ltrim()
in ifaces.c of iptraf package, because standard specification of strcpy says:
> char * strcpy ( char * destination, const char * source );
>
> Copies the C string pointed by source into the array
> pointed by destination, including the terminating null character.
>
> To avoid overflows, the size of the array pointed by destination
> shall be long enough to contain the same C string as source
> (including the terminating null character),
> and should not overlap in memory with source.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But effects depends on implementation of strcpy (maybe of glibc version).
Quite simple task of copying string in our glibc is now the following:
> /* Copy SRC to DEST. */
> char *
> strcpy (dest, src)
> char *dest;
> const char *src;
> {
> reg_char c;
> char *__unbounded s = (char *__unbounded) CHECK_BOUNDS_LOW (src);
> const ptrdiff_t off = CHECK_BOUNDS_LOW (dest) - s - 1;
> size_t n;
>
> do
> {
> c = *s++;
> s[off] = c;
> }
> while (c != '\0');
>
> n = s - src;
> (void) CHECK_BOUNDS_HIGH (src + n);
> (void) CHECK_BOUNDS_HIGH (dest + n);
>
> return dest;
> }
so is not simple (but maybe fast) and I'm not sure, what is doing for above
program our compiler and it's code generator. How long is reg_char type, how
is copied to memory etc.? For this knowledge, there is need to read many
sources. But if I will even analyse generated code, this can change with new
version of glibc or compiler. All, because standard says: "destination string
should not overlap in memory with source" and this does not depends on 32/64 bits.
I find this problem testing my sorting patch, when string | eth0| grabbed
from /proc/net/dev after ltrim became |e0h0| and this interface name is in
interface list in iptraf. As for now 32-bit compiled strcpy is not doing this
strange things. At least in my tests. But the 64-bit strcpy does so.
Interface list in iptraf is used to construct menu of interfaces and for
general statistics, but each interface on list is checked for operativity and
removed from list, if is not operative, so affected interface "e0h0" is
removed as non-operative. When we select general statistics, network packets
are catched and increments counter on this list, but if interface pointed by
packet is not found on this list (i.e. because name was broken), interface is
added to list from packet at list end. So this error is near invisible. But as
effect, starting interface menu can be without affected interface name.
Ofcourse there can be many other side effects.
But in ltrim() we not need to shift this string. Is sufficient to return
address pointing to start of interface name in original string.
I think: it is better to apply always this patch, as side effects of this bug
are unpredictable.
Regards
--
Andrzej Odyniec
|
|
From: Andrzej O. <an...@ma...> - 2012-03-06 19:14:46
|
Heiko, I wrote: > For this I need some days, because many interfaces I have only on one, > central router. To test, I need free night. So be patient. Fortunately, today I has possibility to change software on a newly compiled. And as I can see, all the processes go correctly, routing and BGP also, but the mess in the interface has not changed and probably will not change. Look yourself: > root@Gibraltar:~ # uname -a > Linux Gibraltar 3.2.9-grsec #1 SMP Tue Mar 6 05:32:21 CET 2012 i686 GNU/Linux > root@Gibraltar:~ # cat /proc/net/dev > Inter-| Receive | Transmit > face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed > eth3: 10701200 13641 0 0 0 0 0 0 5722494 18283 0 0 0 0 0 0 > tap0: 73358 590 0 0 0 0 0 0 960615 804 0 0 0 0 0 0 > ifb0: 15583424 29796 0 1 0 0 0 0 15583354 29795 0 0 0 0 0 0 > tun12: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun7: 1404 14 0 0 0 0 0 0 1407 12 0 0 0 0 0 0 > lo: 57903 683 0 0 0 0 0 0 57903 683 0 0 0 0 0 0 > eth2: 15777556 30017 0 0 0 0 0 0 4850630 22943 71 0 0 229 71 0 > tun11: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > eth1: 9430144 26153 0 0 0 0 0 0 4481901 23709 0 0 0 0 0 0 > tun10: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun1: 39392 368 0 0 0 0 0 0 396915 465 0 0 0 0 0 0 > tun5: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > eth0: 3507489 11278 0 2 0 0 0 71 8123938 11235 0 0 0 0 0 0 > tun9: 203 3 0 0 0 0 0 0 219 3 0 0 0 0 0 0 > eth4: 69124 169 0 0 0 0 0 168 250 3 0 0 0 0 0 0 > tap1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > ifb1: 10495061 12867 0 1 0 0 0 0 10494991 12866 0 0 0 0 0 0 > tun13: 4362 26 0 0 0 0 0 0 2902 21 0 0 0 0 0 0 > tun4: 2808 35 0 0 0 0 0 0 3138 28 0 0 0 0 0 0 > tun8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 So my patch, sorting this list is very useful to me, look: > root@Gibraltar:~ # iptraf -g > IPTraf > ┌ Iface ───────────────── Total ──────── IP ────── NonIP ────── BadIP ───── Activity ─────────────┐ > │ eth0 (LAN) 7546 7369 177 0 856.40 kbits/sec │ > │ eth1 (DMZ) 16240 16224 16 0 450.80 kbits/sec │ > │ eth2 (CDP) 19799 19787 12 0 1100.00 kbits/sec │ > │ eth3 (NASK) 7485 7484 1 0 162.20 kbits/sec │ > │ eth4 (WiFi) 120 120 0 0 6.60 kbits/sec │ > │ tap0 (OVPNudp) 158 124 34 0 3.60 kbits/sec │ > │ tap1 (OVPNtcp) 0 0 0 0 0.00 kbits/sec │ > │ tun1 (Chroscickiego) 219 219 0 0 2.00 kbits/sec │ > │ tun2 (Bialystok) 0 0 0 0 0.00 kbits/sec │ > │ tun3 (Bydgoszcz) 0 0 0 0 0.00 kbits/sec │ > │ tun4 (Czestochowa) 69 69 0 0 0.00 kbits/sec │ > │ tun5 (Gdansk) 0 0 0 0 0.00 kbits/sec │ > │ tun6 (Kalisz) 0 0 0 0 0.00 kbits/sec │ > │ tun7 (Katowice) 4 4 0 0 0.00 kbits/sec │ > │ tun8 (Krakow) 0 0 0 0 0.00 kbits/sec │ > │ tun9 (Lodz) 0 0 0 0 0.00 kbits/sec │ > │ tun10 (Poznan) 0 0 0 0 0.00 kbits/sec │ > │ tun11 (Szczecin) 0 0 0 0 0.00 kbits/sec │ > │ tun12 (Wroclaw) 0 0 0 0 0.00 kbits/sec │ > │ tun13 (Zamosc) 31 31 0 0 0.00 kbits/sec │ > │ tun15 (Slupsk) 0 0 0 0 0.00 kbits/sec │ > │ lo 258 258 0 0 2.00 kbits/sec │ > │ │ > │ │ > └ Elapsed time: 0:01 ──────────────── Total, IP, NonIP, and BadIP are packet counts ────────────┘ > Up/Down/PgUp/PgDn-scroll window X-exit > ┌ Select Interface ────┐──────────────┐ > │ All interfaces │ │ > │ eth0 │statistics │ > │ eth1 │ statistics │ > │ eth2 │owns... │ > │ eth3 │r │ > │ eth4 │──────────────│ > │ tap0 │ │ > │ tap1 │──────────────│ > │ tun1 │ │ > │ tun2 │──────────────│ > │ tun3 │ │ > │ tun4 │──────────────┘ > └──────────────────────┘ Best regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 19:52:18
|
Andrzej, both of your patches have been added. Thanks for the contribution. -- Regards Heiko Zuerker http://www.devil-linux.org |
