Re: Linux read (true i.e. burned in) MAC address

jim wrote:


"The reading procedure is different for different vendors...". IOCTL
hides that away. The driver supplied with the card, knows how to do the
reading. You are talking about a PCI peripheral, which maps its
interface (registers, FIFOs shown as registers, DPRAMs shown as
register banks) to the system memory. So I would imagine, that as long
as you stay away from the bus the reading procedure is exactly the
same. What may change is the offset of a specific register with respect
to the beginning of the memory map of the NIC, or the number of regs as
mirrored in the system memory ( a somewhat drastic change). I could be
wrong, if I am please let me know. The main point is that any
differences among vendors are taken care of by the driver. When you
want to send a packet you write to a socket, no matter who made your
NIC. When you want to get the 'variable' MAC address reported by
ifconfig, you do a SIOCGIFHWADDR ioctl, no matter who designed the NIC.


So if you can find an IOCTL call implemented by all vendors, you don't
need to care about the card itself or its manufacturer.

I repeat: The reading procedure is different for different NIC
*chips* and maybe even for different cards.

The EEPROM is *not* directly connacted to the processor's I/O bus,
but it connects only via the network interface chip. For an example,
get the data sheet for the SMSC LAN91Cxx series chips.

The question of reading the vendor supplied MAC address, is then to
find an IOCTL call to the driver that returns this address.

I have attempted to get through the message thet there is no
such ioctl() in the stnadard network drivers. You have to rewrite
all the driver modules with the ioctl added if you want to have it.

There's no use in the network for the burned-in MAC address. The
only one that matters is the MAC in use and returned with SIOCGIFHWADDR.

I am writing code that does exactly what I said. Access the machine
through the driver to get the burned in MAC address. Some of the
posters offered to help, but find this information very limiting, hence
they cannot do so. Nevertheless I want to thank you and everyone else
who replied for taking the time to reply to my question.

Please note that there may be multiple NICs in a host.

If you're intending to use the burned-in address as the computer
identification, please think of the possible exchange of a broken
NIC (which changes your ID).

--

Tauno Voipio
tauno voipio (at) iki fi

.

Relevant Pages

  • Re: [PATCH] Topcliff PHUB: Add The Packet Hub driver [1/2]
    ... Subject: Topcliff PHUB: Add The Packet Hub driver ... you only pass a single integer as an ioctl argument. ... ioctl commands for now if you want to get your driver ...
    (Linux-Kernel)
  • Re: Kernel mode to user mode
    ... where they make sense in the context of using IoCtls for data passing also. ... An app passes an IoCtl to a driver initiating a series of tests that will ...
    (microsoft.public.development.device.drivers)
  • [RFC] dev_acpi: device driver for userspace access to ACPI
    ... The basic concept of operation is that the ioctl operates on the ACPI ... The sample, proof-of-concept app, is called acpitree. ... You can find the driver and sample app here: ...
    (Linux-Kernel)
  • Re: Accessing Ndis miniport from user mode application
    ... sticking to WMI, you confine yourself to strictly defined model - there are ... driver can indicate. ... to you - as I told you already, you should go for IOCTL model. ... Accessing custom OIDS through WMI. ...
    (microsoft.public.development.device.drivers)
  • Re: Why is remote system information calling ioctl for my driver?
    ... Changing the key name doesn't keep the System Information ... don't think the ioctl probing was causing the System Information util to fail ... How does it decide that my driver is a serial port ... the SerialPortIndex registry key to decide if the driver should be probed ...
    (microsoft.public.windowsce.platbuilder)