netdev - Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080204130252.GA2537@mea-ext.zmailer.org>
Date:	Mon, 4 Feb 2008 15:02:52 +0200
From:	Matti Aarnio <matti.aarnio@...iler.org>
To:	linux-hams@...r.kernel.org
Cc:	netdev@...r.kernel.org
Subject: Re: What were the reasons of having mandatory IP address at AX.25
	interfaces ?

.. the original reason was apparently that _ifconfig_ blew up
when it saw protocols that it didn't understand on network
interfaces.  Possibly when there was no IP protocol on an
interface.

This happened on DECNET, and apparently on others too.

Thus the  SIOCGIFCONF  ioctl is not returning much else
than interfaces with IP addresses on them, and to get
_all_ interfaces, one must read thru  /proc/net/dev  file.

Some reason like that is possibly behind the reason why
SIOCGIFCONF does not find anything but PF_INET sockets
even when it is run on  PF_AX25 type socket..

The "fun" part is that  ifconfig  does look for all devices
in /proc/net/dev.   Perhaps we should just make all devices
findable with  SIOCGIFCONF regardless of what protocols
they may support ?   And if the  ifconfig  blows up, the
bug is in ifconfig tool, not kernel.

Alternatively one could iterate all network devices of
protocol family X being enabled when  ioctl() is called
on socket with PF_x  (like PF_AX25.)

Can anyone recall any real reason why this would not be
acceptable ?

/Matti Aarnio
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html