[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Issues found by inetutils-ifconfig.

Hello there!

[Please keep me on CC exchange.]

With the purpose of refining the abilities of inetutils-ifconfig 
for GNU/Hurd, I got hold of the image debian-hurd-2015024 two
days ago, where gnumach is of version 1.4+git20150409.

I am an upstream developer of GNU Inetutils, and as such I just
observed two issues in the collaboration of gnumach and glibc.
They are very technical, but important, and both deal with
network adapters and their representations.

  * The hardware type of an adaper is encoded in the member
    `ifr_hwaddr.sa_family' of `struct ifreq'. An ethernet
    adapter will correctly state ARPHRD_ETHER (= 1), while
    the loopback adapter `lo' will be in error with a value 4.
    The correct value is ARPHRD_LOOPBACK (= 772), which is
    in use by GNU/Linux. See the header <net/if_arp.h>.
    The value 4 is ARPHRD_PRONET, the PROnet token ring!

  * The ioctl calls for SIOCGIFDSTADDR of `lo' as well as of
    `/dev/eth1' are surprisingly successful, leading to the
    conclusion that both are tunnel devices:

       lo: -->
       /dev/eth1: -->

    This answer is counter-intuitive and differ from the
    response found in GNU/Linux: the ioctl should fail
    in general, certainly for `lo'.

It is my hope that somebody on this list might know enough
to investigate these issues and communicate explanations.
It is not clear to me, whether the problem lies in glibc
or i gnumach, so your knowledge is decisive.

In case nothing surfaces, I will in a day or two commit
to the development head of GNU Inetutils new code that
enables inetutils-ifconfig to parse a command line as
is the lagacy use of `ifconfig', while at the same time
include code that temporarily works around the two issues
expressed above.

Best regards,
  Mats Erik Andersson, on behalf of GNU Inetutils

Reply to: