Re: Issues found by inetutils-ifconfig.
Hey Mats :)
Quoting Mats Erik Andersson (2015-07-16 01:29:50)
> 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.
Thanks for looking into this.
> * 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!
That is surprising indeed. A superficial look revealed that it should
indeed be set to ARPHRD_LOOPBACK:
% grep ARPHRD_LOOPBACK
pfinet/linux-src/include/linux/if_arp.h:#define ARPHRD_LOOPBACK 772 /* Loopback device */
[...]
pfinet/loopback.c: dev->type = ARPHRD_LOOPBACK;
I'll look into this when I have some more time.
> * 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'.
Hmmm. Currently, the call returns the `ifa_address' field, which for
PTP is the peer address, but for normal interfaces is the interfaces
address itself. Do you want the call to fail for non-PTP interfaces?
Is the intended behaviour documented somewhere, or are we just
emulating an interface that Linux pulled out of the blue?
> 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.
Both problems are likely Hurd problems, rather than a glibc problem.
This is certainly not a GNU Mach problem.
> In case nothing surfaces, I will in a day or two commit to the
> development head of GNU Inetutils new code that [...] temporarily
> works around the two issues expressed above.
Please don't, let's fix this.
Cheers,
Justus
Reply to: