arp(8) obtains the information it prints the old way from /proc/net/arp
which for incomplete ARP entries contains no HW address such as in the
following example:

IP address       HW type     Flags       HW address            Mask     Device
192.168.122.99   0x1         0x0         00:00:00:00:00:00     *        ens3
192.168.122.98   0x1         0x0         00:00:00:00:00:00     *        ens3
192.168.122.1    0x1         0x2         52:54:00:00:5d:5f     *        ens3
172.20.1.99      0x3         0x0              *        bpq0
10.0.0.2         0x1         0x0         00:00:00:00:00:00     *        ens7

This means the scanf call will incorrectly scan the * character for the
HW address, the device (bpq0 in above example) for the mask and nothing
for the device, that is the last scanf'ed device name or "-" if non has
been read before, will be used resulting in the following incorrect output
for 172.20.1.99:

Address                  HWtype  HWaddress           Flags Mask            Iface
[...]
172.20.1.99                      (incomplete)                              ens3

Fixed by calling scanf a 2nd time if we notice that the first time around
only 5 elements were read.

Arguably this is a kernel bug caused by the silly attempt of printing a
MAC address that consists of only blanks for incomplete ARP entries of
HW type 0x3 but it exists for so long that it virtually has become part of
the API so this just tries to live with it.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

The ROSE code is using %02x for conversion of the BCD encoded ROSE
address to ASCII resulting in

  # ifconfig rose0 hw rose 0123456789
  # ifconfig rose0
  rose0: flags=128<NOARP>  mtu 249
          rose 01234567ff  txqueuelen 1  (AMPR ROSE)
          RX packets 0  bytes 0 (0.0 B)
          RX errors 0  dropped 0  overruns 0  frame 0
          TX packets 0  bytes 0 (0.0 B)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This is due to the stdio %02x conversion doesn't as the code seems o
expect truncate the converted output to two rightmost digits as illustrated
by this little test case:

  #include <stdio.h>

  static char array[] = { 0x88 };

  int main(int argc, char *argv[])
  {
          printf("%02hx\n", array[0]);

          return 0;
  }

Fixed by replacing the use of %02x with %02hhx.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Axattach has been renamed to kissattach early in the history of the
ax25-utils package which itself has been superseeded by libax25,
ax25-tools and ax25-apps but stale referenes have remained.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Netstat is not handling properly ROSE kernel nodes and neighbour tables.
This patch add /proc/net/rose/nodes and /proc/net/rose/neigh display in
rose_gr.c.
Code is using the same style as NetRom and AX.25 hamradio options.

This code was written in 1999 and it is operational on my AX.25 Raspbian
Linux distro dor RapsBerry Pi for years.
Committed patch is against last net-tools-2.10-alpha snapshot on
sourceforge.

If people want to stuff in extra libs, they can use the standard $(LDLIBS).
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

While linux-4.8+ headers work, older ones are missing includes.
Dropping netinet/ip.h uncovered that mess, so add linux/ip.h.

URL: https://bugs.gentoo.org/599542Reported-by: Conrad Kostecki <ck@bl4ckb0x.de>

The only reason we include this header is to get the IP_DF define.
However, we already have a local #define fallback in case that isn't
already defined for us.

Including this header while also including linux/if_tunnel.h causes
problems with newer Linux headers (v4.8+):
cc -O2 -g -Wall -fno-strict-aliasing  -D_GNU_SOURCE \
	-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
	-I. -I/usr/local/src/net-tools/include -Ilib -c iptunnel.c
In file included from /usr/include/linux/if_tunnel.h:6:0,
                 from iptunnel.c:34:
/usr/include/linux/ip.h:85:8: error: redefinition of 'struct iphdr'
 struct iphdr {
        ^
In file included from iptunnel.c:29:0:
/usr/include/netinet/ip.h:44:8: note: originally defined here
 struct iphdr
        ^

Changing netinet/ip.h to linux/ip.h won't help because it doesn't
provide IP_DF or anything else we care about.  Simply drop the header
to avoid the build failure.
Reported-by: Randy MacLeod <randy.macleod@windriver.com>

Thanks to Eugen Feller.

Avoid using `ls` to get the file list as its behavior can be changed
by env vars.  Using shell globs instead should be much more stable.

Also check the exit value of the install command itself and abort if
we fail to install a man page.

The kernel will delete alias interfaces when you assign it an address
of 0.0.0.0.  i.e. These two commands will both destroy eth0:0:
  ifconfig eth0:0 0.0.0.0
  ifconfig eth0:0 del

Omit the implicit "up" behavior when this addr is given as the kernel
will always throw an error.  Distros/people have long gotten into the
habit of deleting addresses by assigning 0.0.0.0.

URL: https://bugs.gentoo.org/568446Reported-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>

The ifconfig tool has long had the ability to suppress implicit bring up
by adding an - suffix to the alias name.  Document this in the man page.

URL: https://bugs.gentoo.org/568446Reported-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>

We use scanf %64[...] to get local addresses, but then we store the result
into a char[64] buffer.  Since scanf always writes a terminating NUL, we
overflow the buffer by a single byte.  Use a buffer of 128 bytes to match
the style of other funcs in this file.
Reported-by: Maxim Ostapenko <m.ostapenko@partner.samsung.com>

This changes the hostname behavior to match other systems and its own
documentation.  Namely, that -s just parses the result of the active
gethostname() and does not attempt any network/DNS traffic.  Other
distros like Fedora/RedHat and Debian/Ubuntu have also changed their
behavior in this regard.

URL: https://bugzilla.redhat.com/319981
URL: https://bugzilla.redhat.com/531702
URL: https://bugs.debian.org/552482
URL: https://bugs.gentoo.org/515836

After the typo fixes, some of the translations were duplicated leading
to errors during message generation.

Not all sockaddr structs have the same alignment.  Instead, it depends
on the fields contained in it.  The way net-tools has written things
though, it accepts sockaddr* everywhere which has 16bit alignment, even
though it will cast it to other sockaddr types that have higher alignment.
For example, `route` can crash on alpha because it declares sockaddr on
the stack, but then casts it up to sockaddr_in6 (which has 32bits).

It's also bad storage wise as we might try to cast the sockaddr to a type
that is larger than sockaddr which means clobbering the stack.

Instead, lets rewrite all the APIs to take a sockaddr_storage.  This is
guaranteed to have both the maximum alignment and size requirements for
all other sockaddr types.  Now we can safely cast that pointer to any
other sockaddr type and not worry about it.  It also has the nice effect
of deleting a lot of casts in a lot of places when we only need the type
of family.

The vast majority of changes here are mechanical.  There are a few places
where we have to memcpy between a dedicated sockaddr_storage and a smaller
struct because we're using an external embedded type (like arpreq).

URL: https://bugs.gentoo.org/558436

Rather than use different sockaddr base types for storage, always
start with sockaddr_storage on the stack and set up pointers to
more limited versions to that.  This way we always get the correct
alignment and storage when we pass it down to lower layers.

This is really just a set up for a follow up change to convert the
codebase entirely to sockaddr_storage.  This is just a fairly self
contained change.

Signed-off-by: Jiri Popelka <jpopelka@redhat.com>

This way we can support any length line w/out hardcoded buffer limits.

Move the strlen calculation outside the loop to avoid recalculating it
every time.

In the output of netstat --ipx, the network and port numbers are byteswapped.
For instance:

Proto Recv-Q Send-Q Local Address              Foreign Address            State
IPX        0      0 000A6F83:2E40              04036F83:000000000001:5104 ESTAB

The local network number is actually 836F0A00, and the NetWare server reports
my socket number as 402E.  Similarly, the server's address is
836F0304:000000000001, and the standard NCP port is 0415.

URL: https://bugzilla.redhat.com/show_bug.cgi?id=46434Reported-by: Ben Harris <bjh21@cam.ac.uk>

The parsing logic doesn't handle IPv6 addresses.
Clean it all up.

Rather than do the sorting at runtime, run the tables through `sort`.
This lets us constify them and speed up runtime slightly.

Mark all the read-only strings in this file as const.

The vast majority of these aren't used outside of this file, so mark
them all static accordingly.

Some of the globs might expand into files that start with a dash, so
pass -- everywhere to keep problems from showing up.  Some call sites
don't actually need this, but better to be consistent.

There's no need to cast the char* to a struct in6_addr*, so delete
that logic.

Switch the hardcoded 80 limit to the INET6_ADDRSTRLEN constant.

Make sure the buffer we pass into inet_ntop is always NUL terminated.

This is only used in this file, so localize it.

This might end up violating alignment requirements, so memcpy the
variable through a short variable instead.  For most systems, this
will optimize into the same code anyways, and for the rest, we need
to do it this way to avoid unaligned accesses crashing.

URL: https://bugs.gentoo.org/558436

This avoids casting from a char* pointer to a struct in_addr* pointer
which have different alignment requirements, and moves away from the
deprecated inet_ntoa function.

URL: https://bugs.gentoo.org/558436