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: 127.0.0.1 --> 127.0.0.1
/dev/eth1: 192.168.56.177 --> 192.168.56.177
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: