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 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150716110107.20306.87...@thinkbox.jade-hamburg.de