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

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:

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: -->
>        /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'.

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.


Reply to: