[Top][All Lists]

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

Re: SIOCGIFHWADDR support for pfinet

From: Thomas Schwinge
Subject: Re: SIOCGIFHWADDR support for pfinet
Date: Sat, 13 Oct 2007 20:33:05 +0200
User-agent: Mutt/1.5.11


As people started working on DHCP support again...

On Wed, Feb 09, 2005 at 04:15:24PM +0100, Marcus Brinkmann wrote:
> At Tue, 03 Aug 2004 16:03:11 +0200,
> Marco Gerards wrote:
> > On debian-hurd someone noticed SIOCGIFHWADDR does not exist for
> > GNU/Hurd.  I have included the required patches for the Hurd and glibc
> > with this email.  Or can someone suggest a better way to read the
> > hardware address?
> It seems basically ok to me.  However, I think that two small changes
> could/should be made.
> 1. Only copy dev->addr_len bytes into the user buffer.  It's best to
>    give out less information than more.


> 2. Independent of that, do we need to check if there even is a
>    hardware address?  For example, what is the dev_addr of the
>    loopback interface?  How does Linux ifconfig detect that the
>    loopback interface doesn't have a valid MAC?  Do we initialize it
>    correctly in loopback.c and does your code deal with it in a
>    compatible way?

tschwinge@clubber:~ $ ./a.out eth0
The hardware address of eth0 is 00:03:47:6e:3f:5c.
tschwinge@clubber:~ $ ./a.out eth1
./a.out: ioctl failed: No such device
tschwinge@clubber:~ $ ./a.out lo
The hardware address of lo is 00:00:00:00:00:00.

Should be fine like this?

> I didn't do much to try to answer the second question, although the
> answer should be readily available by looking at Linux and net-tools
> source code.  Once we have determined that unconditionally copying the
> dev_addr field is ok, or did an appropriate check, it can go in (with
> the addr_len change mentioned above).

I checked it in with those minor changes, and also put the implementation
at a more suitable location inside the source code file.

The corresponding glibc patch has already been applied.

Michael: After updating, you can then remove the patch from the Debian


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]