valgrind --leak-check=full netstat
(x86_64)

before:
  definitely lost: 1,536 bytes in 64 blocks
  indirectly lost: 479 bytes in 64 blocks
 ERROR SUMMARY: 1 errors from 1 contexts

after:
  definitely lost: 0 bytes in 0 blocks
  indirectly lost: 0 bytes in 0 blocks
 ERROR SUMMARY: 0 errors from 0 contexts

from scanf(3):
The a modifier is not available if the program is compiled with
gcc -std=c99 or gcc -D_ISOC99_SOURCE (unless _GNU_SOURCE
is also specified), in which case the a is interpreted
as a specifier for floating-point numbers (see above).

Since version 2.7, glibc also provides the m modifier for the
same purpose as the a modifier. The m modifier has the following
advantages:
* It may also be applied to %c conversion specifiers (e.g., %3mc).
* It avoids ambiguity with respect to the %a floating-point
  conversion specifier (and is unaffected by gcc -std=c99 etc.)
* It is specified in the upcoming revision of the POSIX.1 standard.

Tools have been inconsistently using exit codes when started with
--help/--version.
With this patch all tools use exit codes E_USAGE/E_VERSION defined
in net-support.h.

There's probably no rule what exit codes should programs use when
started with --help/--version, but when I'm checking programs on
my system most of them use 0 (SUCCESS) exit code.
Therefore I redefined E_USAGE/E_VERSION to EXIT_SUCCESS (0).

Ubuntu bug #992204

https://sourceforge.net/mailarchive/message.php?msg_id=28701120

The destination is not just the ipv4 address but the
ipv6 address notation for the ipv4 address.

This causes a build warning (since the string isn't const), and the
message lacks a new line.  Fix both in one go.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Patch by Dan Walsh.

With this patch mii-tool requires interface name
to be specified as argument.

Using mii-tool with e1000e driver results in:
SIOCGMIIREG on eth0 failed: Input/output error

Problem is in show_basic_mii() where the loop
    for (i = 0; i < ((verbose > 1) ? 32 : MII_BASIC_MAX); i++)
        mii_val[i] = mdio_read(sock, i);
checks all MII registers from 0x00 to 0x07 (or to 0x1F in verbose mode).
But there's no register with 0x07 value.

For more details see:
https://bugzilla.redhat.com/show_bug.cgi?id=491358#c1

Solution is to check only defined MII registers.

Also the "mii.h" is actually a duplicate of <linux/mii.h>.

We analyzed the net-tools-1.60 code with Coverity.
Coverity is commercial enterprise level tool for
static analysis (analysis based only on compiling
of sources, not based on running of binary) of the code.

This change should fix some possible problems like resource (memory,
file descriptors) leaks.

Follow respective parts of the scan log. The line
numbers could be quite different as we analyzed Red Hat's
heavily patched version of net-tools-1.60.

Error: RESOURCE_LEAK
ipmaddr.c:191: alloc_fn: Calling allocation function "malloc".
ipmaddr.c:191: var_assign: Assigning: "ma" =  storage returned from "malloc(sizeof (m) /*64*/)".
ipmaddr.c:203: overwrite_var: Overwriting "ma" in call "ma = malloc(sizeof (m) /*64*/)" leaks the storage that "ma" points to.

Error: RESOURCE_LEAK
iptunnel.c:473: alloc_fn: Calling allocation function "fopen".
iptunnel.c:473: var_assign: Assigning: "fp" =  storage returned from "fopen("/proc/net/dev", "r")".
iptunnel.c:488: leaked_storage: Variable "fp" going out of scope leaks the storage it points to.
iptunnel.c:524: leaked_storage: Variable "fp" going out of scope leaks the storage it points to.

Error: FORWARD_NULL
lib/inet.c:408: var_compare_op: Comparing "item" to null implies that "item" might be null.
lib/inet.c:410: var_deref_op: Dereferencing null variable "item".

Error: RESOURCE_LEAK
lib/masq_info.c:174: alloc_fn: Calling allocation function "malloc".
lib/masq_info.c:174: var_assign: Assigning: "mslist" =  storage returned from "malloc(1152UL)".
lib/masq_info.c:215: leaked_storage: Variable "mslist" going out of scope leaks the storage it points to.

Error: RESOURCE_LEAK
lib/netrom_gr.c:35: alloc_fn: Calling allocation function "fopen".
lib/netrom_gr.c:35: var_assign: Assigning: "f1" =  storage returned from "fopen("/proc/net/nr_nodes", "r")".
lib/netrom_gr.c:42: overwrite_var: Overwriting "f1" in call "f1 = fopen("/proc/net/nr_nodes", "r")" leaks the storage that "f1" points to.

Error: RESOURCE_LEAK
lib/netrom_gr.c:36: alloc_fn: Calling allocation function "fopen".
lib/netrom_gr.c:36: var_assign: Assigning: "f2" =  storage returned from "fopen("/proc/net/nr_neigh", "r")".
lib/netrom_gr.c:44: overwrite_var: Overwriting "f2" in call "f2 = fopen("/proc/net/nr_neigh", "r")" leaks the storage that "f2" points to

Error: FORWARD_NULL
lib/x25.c:101: var_compare_op: Comparing "p" to null implies that "p" might be null.
lib/x25.c:109: var_deref_op: Dereferencing null variable "p".

Error: RESOURCE_LEAK
nameif.c:166: alloc_fn: Calling allocation function "xmalloc".
nameif.c:166: var_assign: Assigning: "ch" =  storage returned from "xmalloc(sizeof (struct change) /*40*/)".
nameif.c:177: leaked_storage: Variable "ch" going out of scope leaks the storage it points to.

Error: NEGATIVE_RETURNS
netstat.c:463: negative_return_fn: Function "readlink(line, lname, 29UL)" returns a negative number.
netstat.c:463: var_assign: Assigning: signed variable "lnamelen" = "readlink".
netstat.c:464: negative_returns: Using variable "lnamelen" as an index to array "lname".

Error: RESOURCE_LEAK
netstat.c:894: alloc_fn: Calling allocation function "fopen".
netstat.c:894: var_assign: Assigning: "f" =  storage returned from "fopen("/proc/net/x25", "r")".
netstat.c:905: overwrite_var: Overwriting "f" in call "f = fopen("/proc/net/x25", "r")" leaks the storage that "f" points to.

Error: RESOURCE_LEAK
netstat.c:1916: alloc_fn: Calling allocation function "fopen".
netstat.c:1916: var_assign: Assigning: "f" =  storage returned from "fopen("/proc/net/ipx", "r")".
netstat.c:1934: leaked_storage: Variable "f" going out of scope leaks the storage it points to.
netstat.c:1947: leaked_storage: Variable "f" going out of scope leaks the storage it points to.
netstat.c:1957: leaked_storage: Variable "f" going out of scope leaks the storage it points to.

I'm not sure how to reproduce that, but the patch
is quite straightforward.

Steps to Reproduce:
1. arp -s 172.16.1.3 00:80:c8:04:05:06 -D eth0

(RHBZ #579854, Debian #561161)

original patch from Sami Farin

Steps to Reproduce:
/sbin/nameif eth1 00:00:10:10:11:11; echo $?

Actual Results:
interface 'eth1' not found
0

Expected Results:
interface 'eth1' not found
1

de.po: warning: Charset "iso8859-1" is not a portable encoding name.
                Message conversion to user's charset might not work.

http://www.gnu.org/licenses/gpl-2.0.html

On a system with a gigabit NIC attached to a 100mbit switch:
	# mii-tool -v eth0
	capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
	advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
	link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

Clearly the last two fields are swapped, and reading the code supports
this hypothesis.

URL: https://bugs.gentoo.org/393107
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511395Signed-off-by: Mike Frysinger <vapier@gentoo.org>