Re: [PATCH 2.6] dev.c: clear SIOCGIFHWADDR buffer if !dev->addr_len
Matt Domsch <Matt_Domsch <at> dell.com>
2004-11-01 04:44:33 GMT
On Sat, Oct 30, 2004 at 03:10:19PM -0400, jamal wrote:
> fix the net-snmp code. The addr_len is dependent on the device type.
> 6 is good for ethernet but may not equate for others.
I wish it were that simple. The problem, in my mind, is that the
SIOCGIFHWADDR ioctl does not behave in 2.6 kernels as it has behaved
in previous kernels, and applications have no way to know this. This
will lead to unexpected behaviour in many applications that (wrongly)
assume that the first 6 or more bytes of sa_data after ioctl() contain
valid data, unless told otherwise by a failure return value.
I took the liberty of unpacking all the sources to Fedora Core 3
development tree as of yesterday. Of those I looked into the source
for, nearly all the packages that call SIOCGIFHWADDR make an
assumption on the number of bytes returned and the validity of such,
nearly none clear the request structure before calling it (so when
ioctl() returns 0 the app believes the data is correct).
anaconda-10.1.0.0/isys/getmacaddr.c: if (ioctl(sock, SIOCGIFHWADDR, &ifr) < 0)
BROKEN: clears ifr before ioctl, copies first 6 bytes of ifr.ifr_hwaddr.sa_data
busybox-1.00.rc1/networking/udhcp/socket.c: if (ioctl(fd, SIOCGIFHWADDR, &ifr) == 0) {
BROKEN: oesn't clear ifr before ioctl, copies first 6 bytes of
ifr.ifr_hraddr.sa_data
busybox-1.00.rc1/networking/nameif.c: if (ioctl(ctl_sk, SIOCGIFHWADDR, &ifr))
BROKEN: doesn't clear ifr before ioctl, compares first ETH_ALEN bytes of
ifr.ifr_hraddr.sa_data
busybox-1.00.rc1/networking/libiproute/iptunnel.c: if (ioctl(fd, SIOCGIFHWADDR, &ifr)) {
(Continue reading)
RSS Feed