ethtool documentation

ethtool documentation

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hi!

Is there a document describing the ethtool ioctl's which need to be
implemented in each ethernet driver?

-- 

Regards
 Abraham

Superstition, idolatry, and hypocrisy have ample wages, but truth goes
a-begging.
		-- Martin Luther

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: ethtool documentation

[Jeff Garzik]

Abraham vd Merwe wrote:
> Hi!
> 
> Is there a document describing the ethtool ioctl's which need to be
> implemented in each ethernet driver?


Unfortunately not.  There is a distinct lack of network driver docs at 
the moment...  The best documentation is looking at source code of 
drivers that implement the most ioctls.

	Jeff

Re: ethtool documentation

[Tim Hockin]

> > Is there a document describing the ethtool ioctl's which need to be
> > implemented in each ethernet driver?
> 
> 
> Unfortunately not.  There is a distinct lack of network driver docs at 
> the moment...  The best documentation is looking at source code of 
> drivers that implement the most ioctls.


I've got a draft of a quick overview doc.  I need to add docs for a few of
the newer commands, still, and I want to get into the structs for each call
in more detail, too.  I want to re-examine a few of recent additions,
before they become too ubiquitous - am I too late to pipe up for my own
aesthetics?

Tim




The ethtool API
08/05/2002

These are the valid parameters to the SIOCETHTOOL ioctl().  Network drivers
should support these as much as possible.

ETHTOOL_GSET
ETHTOOL_SSET

  Get/set NIC settings.  These commands expect a 'struct ethtool_cmd *'
  argument.  This struct includes fields for supported features (speed,
  duplex, transceiver), advertised features, speed, duplex, port,
  transceiver, and autonegotiation.  If the caller attempts to set an
  invalid value for any field, return -EINVAL.

ETHTOOL_GDRVINFO

  Get driver information.  This command expects a 'struct ethtool_drvinfo *'
  argument.  This struct includes the driver identifier as a string, the
  driver version as a string, bus information for the interface, and length
  information for other ETHTOOL_* commands.

ETHTOOL_GREGS

  Get a register dump from the NIC.  This command expects a 'struct
  ethtool_regs regs *' argument.  This struct has a driver-specific version
  field and a length field.  The length field indicates the length of the
  data field to be populated with register information.

ETHTOOL_GWOL
ETHTOOL_SWOL

  Get/set wake-on-lan options for the NIC.  These commands expect a 'struct
  ethtool_wolinfo *' argument.  This struct has fields for supprted and
  active WoL options, and the SecureOn password, if active.  If the caller
  attempts to set an invalid value, return -EINVAL.

ETHTOOL_GMSGLVL
ETHTOOL_SMSGLVL

  Get/set the driver message-level value for the NIC.  This command expects
  a 'struct ethtool_value *' argument.

ETHTOOL_NWAY_RST

  Force auto-negotiation to restart, if it is enabled.  If it is not
  enabled, return -EINVAL.

ETHTOOL_GLINK

  Read the current link status.  This command expects a 'struct
  ethtool_value *' argument.

ETHTOOL_GEEPROM
ETHTOOL_SEEPROM

  Get/set EEPROM data.  These commands expect a 'struct ethtool_eeprom *'
  argument.  This struct has a magic number, an offset and length pair, and a
  data field.  If the offset+length are longer than the maximum size, the
  extra is silently ignored.

ETHTOOL_GCOALESCE
ETHTOOL_SCOALESCE

  Get/set coalescing parameters.  These commands expect a 'struct
  ethtool_coalesce *' argument.  This struct has several fields for
  configuring coalescing - see ethtool.h for details.  If the caller
  attempts to set an invalid value, return -EINVAL.


ETHTOOL_GRINGPARAM
ETHTOOL_SRINGPARAM

  Get/set RX/TX ring parameters.  These commands expect a 'struct
  ethtool_ringparam *' aargument.  This struct has fields for several
  rx pending options, and tx pending. If the caller attempts to set an invalid
  value, return -EINVAL.

ETHTOOL_GPAUSEPARAM
ETHTOOL_SPAUSEPARAM

  Get/set the RX/TX pause parameters.  These commands expect a 'struct
  ethtool_pauseparam *' argument.  This struct has fields to enable
  autonegotiation of pause parameters and to force RX and TX pause control.

ETHTOOL_GRXCSUM
ETHTOOL_SRXCSUM

  Get/set the RX hardware checksum capability/flag.  These commands expect
  a 'struct ethtool_value *' argument.  If the caller attempts to enable RX
  hardware checksumming on an interface that does not support it, return
  -EINVAL.

ETHTOOL_GTXCSUM
ETHTOOL_STXCSUM

  Get/set the TX hardware checksum capability/flag.  These commands expect
  a 'struct ethtool_value *' argument.  If the caller attempts to enable TX
  hardware checksumming on an interface that does not support it, return
  -EINVAL.

ETHTOOL_GSG
ETHTOOL_SSG

  Get/set the scatter/gather capability/flag.  These commands expect a 'struct
  ethtool_value *' argument.  If the caller attempts to set an invalid value,
  return -EINVAL.

ETHTOOL_TEST
/* execute NIC self-test, priv. */

ETHTOOL_GSTRINGS
/* get specified string set */

ETHTOOL_PHYS_ID
/* identify the NIC */

ETHTOOL_GSTATS
/* get NIC-specific statistics */

Re: ethtool documentation

[Jeff Garzik]

Tim Hockin wrote:
>>>Is there a document describing the ethtool ioctl's which need to be
>>>implemented in each ethernet driver?
>>
>>
>>Unfortunately not.  There is a distinct lack of network driver docs at 
>>the moment...  The best documentation is looking at source code of 
>>drivers that implement the most ioctls.
> 
> 
> 
> I've got a draft of a quick overview doc.  I need to add docs for a few of
> the newer commands, still, and I want to get into the structs for each call
> in more detail, too.  I want to re-examine a few of recent additions,
> before they become too ubiquitous - am I too late to pipe up for my own
> aesthetics?


Sure, comments are always welcome.

And if you're bored, IMO putting the docs into Documentation/DocBook is 
preferred :)

Re: ethtool documentation

[Jonathan Lundell]

At 3:16 PM -0400 8/5/02, Jeff Garzik wrote:
>Tim Hockin wrote:
>>Is there a document describing the ethtool ioctl's which need to be
>>implemented in each ethernet driver?
>
>Unfortunately not.  There is a distinct lack of network driver docs 
>at the moment...  The best documentation is looking at source code 
>of drivers that implement the most ioctls.

Is there a driver with anything like what you'd consider a canonical 
(or at least exemplary) implementation of the ethtool ioctls?
-- 
/Jonathan Lundell.

Re: ethtool documentation

[Jeff Garzik]

Jonathan Lundell wrote:
> At 3:16 PM -0400 8/5/02, Jeff Garzik wrote:
> 
>> Tim Hockin wrote:
>>
>>> Is there a document describing the ethtool ioctl's which need to be
>>> implemented in each ethernet driver?
>>
>>
>> Unfortunately not.  There is a distinct lack of network driver docs at 
>> the moment...  The best documentation is looking at source code of 
>> drivers that implement the most ioctls.
> 
> 
> Is there a driver with anything like what you'd consider a canonical (or 
> at least exemplary) implementation of the ethtool ioctls?


tg3, 8139cp, and natsemi

Re: ethtool documentation

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

Hi Tim!

> These are the valid parameters to the SIOCETHTOOL ioctl().  Network drivers
> should support these as much as possible.
> 
> ETHTOOL_GSET
> ETHTOOL_SSET
> 
>   Get/set NIC settings.  These commands expect a 'struct ethtool_cmd *'
>   argument.  This struct includes fields for supported features (speed,
>   duplex, transceiver), advertised features, speed, duplex, port,
>   transceiver, and autonegotiation.  If the caller attempts to set an
>   invalid value for any field, return -EINVAL.

What is the difference between the supported and advertising fields?
What is MII? (as in the SUPPORTED_MII feature?).

If you can't control the # of ints before Tx/Rx, I take it you can just
set those fields to 0?

> ETHTOOL_GDRVINFO
> 
>   Get driver information.  This command expects a 'struct ethtool_drvinfo *'
>   argument.  This struct includes the driver identifier as a string, the
>   driver version as a string, bus information for the interface, and length
>   information for other ETHTOOL_* commands.

What do you set the bus_info field to if there is no bus? Where are all
these bus types defined? The header file isn't very clear about anything
other than pci bus types.

I take it you can just set fw_version to zero length string if it is unknown?

> ETHTOOL_GEEPROM
> ETHTOOL_SEEPROM
> 
>   Get/set EEPROM data.  These commands expect a 'struct ethtool_eeprom *'
>   argument.  This struct has a magic number, an offset and length pair, and a
>   data field.  If the offset+length are longer than the maximum size, the
>   extra is silently ignored.

Wouldn't it have been better to make this 'n character device which can be
read from / written to just like a normal file (/dev/nvram-like interface) -
that way applications can actually use unused eeprom space.

> ETHTOOL_GCOALESCE
> ETHTOOL_SCOALESCE
> 
>   Get/set coalescing parameters.  These commands expect a 'struct
>   ethtool_coalesce *' argument.  This struct has several fields for
>   configuring coalescing - see ethtool.h for details.  If the caller
>   attempts to set an invalid value, return -EINVAL.

Wtf is coalescing parameters? These commands aren't even defined in the
2.4.18 kernel headers. Is this 2.5.xx additions?

Same goes for the following commands:

> ETHTOOL_GRINGPARAM
> ETHTOOL_SRINGPARAM
> ETHTOOL_GPAUSEPARAM
> ETHTOOL_SPAUSEPARAM
> ETHTOOL_GRXCSUM
> ETHTOOL_SRXCSUM
> ETHTOOL_GTXCSUM
> ETHTOOL_STXCSUM
> ETHTOOL_GSG
> ETHTOOL_SSG
> ETHTOOL_TEST
> ETHTOOL_GSTRINGS
> ETHTOOL_PHYS_ID
> ETHTOOL_GSTATS

-- 

Regards
 Abraham

Lying is an indispensable part of making life tolerable.
		-- Bergan Evans

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: ethtool documentation

[David S. Miller]

   From: Abraham vd Merwe <abraham@2d3d.co.za>
   Date: Tue, 6 Aug 2002 12:17:51 +0200
   
   Wtf is coalescing parameters? These commands aren't even defined in the
   2.4.18 kernel headers. Is this 2.5.xx additions?
   
   Same goes for the following commands:

They are all in 2.4.19

Re: ethtool documentation

[Randy.Dunlap]

Abraham vd Merwe <abraham@2d3d.co.za> wrote:
| What is the difference between the supported and advertising fields?
| What is MII? (as in the SUPPORTED_MII feature?).

MII:  (is this a serious question ?):
[from a National Semi. ethernet repeater design Application Note]
The Medium Independent Interface, as specified in the IEEE 802.3u/D5.3
standard, is designed to support the PHY/MAC interface.

| > ETHTOOL_GEEPROM
| > ETHTOOL_SEEPROM
| >
| >   Get/set EEPROM data.  These commands expect a 'struct ethtool_eeprom
| >   *'
| >   argument.  This struct has a magic number, an offset and length
| >   pair, and a
| >   data field.  If the offset+length are longer than the maximum size,
| >   the extra is silently ignored.
|
| Wouldn't it have been better to make this 'n character device which can
| be read from / written to just like a normal file (/dev/nvram-like
| interface) -
| that way applications can actually use unused eeprom space.

I wouldn't care for this.  There's nothing 'normal' about this
EEPROM space, and apps generally won't know where there might be
some 'unused eeprom space'.

-- 
~Randy

Re: ethtool documentation

[Richard B. Johnson]

On Tue, 6 Aug 2002, Randy.Dunlap wrote:

> 
> Abraham vd Merwe <abraham@2d3d.co.za> wrote:
> | What is the difference between the supported and advertising fields?
> | What is MII? (as in the SUPPORTED_MII feature?).
> 
> MII:  (is this a serious question ?):
> [from a National Semi. ethernet repeater design Application Note]
> The Medium Independent Interface, as specified in the IEEE 802.3u/D5.3
> standard, is designed to support the PHY/MAC interface.
> 
> | > ETHTOOL_GEEPROM
> | > ETHTOOL_SEEPROM
> | >
> | >   Get/set EEPROM data.  These commands expect a 'struct ethtool_eeprom
> | >   *'
> | >   argument.  This struct has a magic number, an offset and length
> | >   pair, and a
> | >   data field.  If the offset+length are longer than the maximum size,
> | >   the extra is silently ignored.
> |
> | Wouldn't it have been better to make this 'n character device which can
> | be read from / written to just like a normal file (/dev/nvram-like
> | interface) -
> | that way applications can actually use unused eeprom space.
> 
> I wouldn't care for this.  There's nothing 'normal' about this
> EEPROM space, and apps generally won't know where there might be
> some 'unused eeprom space'.
> 
> -- 
> ~Randy


The EEPROM (SEEPROM) on these NICS is used to contain the startup
configuration bits and the IEEE Station Address. This must be a
unique number that is assigned so that there is no other such
number in (preferably) the world, and certainly in the LAN.
If you let a user write to this area, you will allow the user
to destroy the connectivity on a LAN.

If you provide an ioctl() to write new SEEPROM contents, it had
better be disabled in code that user's (any, including root)
can execute because, if caught, your company may lose it's IEEE
Station Addresses and never again be allowed to configure Ethernet
Controllers.

Because of this, there is no such thing as 'unused eeprom space' in
the Ethernet Controllers. Be careful about putting this weapon in
the hands of the 'public'. All you need is for one Linux Machine
on a LAN to end up with the same IEEE Station Address as another
on that LAN and connectivity to everything on that segment will
stop. You do this once at an important site and Linux will get a
very black eye.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: ethtool documentation

[Chris Friesen]

"Richard B. Johnson" wrote:

> Because of this, there is no such thing as 'unused eeprom space' in
> the Ethernet Controllers. Be careful about putting this weapon in
> the hands of the 'public'. All you need is for one Linux Machine
> on a LAN to end up with the same IEEE Station Address as another
> on that LAN and connectivity to everything on that segment will
> stop. You do this once at an important site and Linux will get a
> very black eye.

Can't we already tell cards (some of them anyway) what MAC address to use when
sending packets?  This doesn't overwrite the EEPROM, but it does last for that
session...

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: ethtool documentation

[Randy.Dunlap]

On Tue, 6 Aug 2002, Chris Friesen wrote:

| "Richard B. Johnson" wrote:
|
| > Because of this, there is no such thing as 'unused eeprom space' in
| > the Ethernet Controllers. Be careful about putting this weapon in
| > the hands of the 'public'. All you need is for one Linux Machine
| > on a LAN to end up with the same IEEE Station Address as another
| > on that LAN and connectivity to everything on that segment will
| > stop. You do this once at an important site and Linux will get a
| > very black eye.
|
| Can't we already tell cards (some of them anyway) what MAC address to use when
| sending packets?  This doesn't overwrite the EEPROM, but it does last for that
| session...

Sure, and that doesn't violate any IEEE Ethernet standards.
Locally Administered Addresses are allowed.
Just make sure that they don't conflict with other addresses.

-- 
~Randy

Re: ethtool documentation

[Richard B. Johnson]

On Tue, 6 Aug 2002, Chris Friesen wrote:

> "Richard B. Johnson" wrote:
> 
> > Because of this, there is no such thing as 'unused eeprom space' in
> > the Ethernet Controllers. Be careful about putting this weapon in
> > the hands of the 'public'. All you need is for one Linux Machine
> > on a LAN to end up with the same IEEE Station Address as another
> > on that LAN and connectivity to everything on that segment will
> > stop. You do this once at an important site and Linux will get a
> > very black eye.
> 
> Can't we already tell cards (some of them anyway) what MAC address to use when
> sending packets?  This doesn't overwrite the EEPROM, but it does last for that
> session...
> 
> Chris

Sure you can. And it was assumed that the MAC address provided by
the manufacturer would always be used by the software for the MAC
address on the wire. However, 'software engineers' have decided
that they don't have to follow the rules, so they provide hooks
so you can use a MAC address of anything.  They even call it
"Local Administration...", which decoded means; "Screw the
committee".

But....
If you ever sell a controller that contains an address that was
not allocated to the 'producer', somebody is going to get very
angry. This means, to me, that if you ever write a new MAC address
to that card/board, you had better throw it away when you are done.

It's easier to make sure that the MAC address doesn't get changed.
You still "screw the comittee" locally, but you don't modify the
hardware.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: ethtool documentation

[Randy.Dunlap]

On Tue, 6 Aug 2002, Richard B. Johnson wrote:

| On Tue, 6 Aug 2002, Chris Friesen wrote:
|
| > "Richard B. Johnson" wrote:
| >
| > > Because of this, there is no such thing as 'unused eeprom space' in
| > > the Ethernet Controllers. Be careful about putting this weapon in
| > > the hands of the 'public'. All you need is for one Linux Machine
| > > on a LAN to end up with the same IEEE Station Address as another
| > > on that LAN and connectivity to everything on that segment will
| > > stop. You do this once at an important site and Linux will get a
| > > very black eye.
| >
| > Can't we already tell cards (some of them anyway) what MAC address to use when
| > sending packets?  This doesn't overwrite the EEPROM, but it does last for that
| > session...
| >
| > Chris
|
| Sure you can. And it was assumed that the MAC address provided by
| the manufacturer would always be used by the software for the MAC
| address on the wire. However, 'software engineers' have decided

Assumed by whom?  IEEE allows locally administered addresses,
and most NIC mfrs that I know of support/allow them.

| that they don't have to follow the rules, so they provide hooks
| so you can use a MAC address of anything.  They even call it
| "Local Administration...", which decoded means; "Screw the
| committee".

<snippage>

-- 
~Randy

Re: ethtool documentation

[Ben Greear]

Randy.Dunlap wrote:
> On Tue, 6 Aug 2002, Richard B. Johnson wrote:
> 
> | On Tue, 6 Aug 2002, Chris Friesen wrote:
> |
> | > "Richard B. Johnson" wrote:
> | >
> | > > Because of this, there is no such thing as 'unused eeprom space' in
> | > > the Ethernet Controllers. Be careful about putting this weapon in
> | > > the hands of the 'public'. All you need is for one Linux Machine
> | > > on a LAN to end up with the same IEEE Station Address as another
> | > > on that LAN and connectivity to everything on that segment will
> | > > stop. You do this once at an important site and Linux will get a
> | > > very black eye.

Actually, any important site has some kind of failover in place, and they
could very well be using this feature to provide seamless MAC/IP takeover
in the case of a server outtage.

This feature also allows bridging to work, and anyone with root priviledges
can send any ethernet packet they want using a raw packet socket anyway.

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: ethtool documentation

[Tim Hockin]

> If you ever sell a controller that contains an address that was
> not allocated to the 'producer', somebody is going to get very
> angry. This means, to me, that if you ever write a new MAC address
> to that card/board, you had better throw it away when you are done.

As a developer of integrated systems, it is imperative the we be able to
re-program EEPROMs and MAC addresses.  Cobalt systems all have Cobalt as
the MFR section of the MAC address.  Sun Systems all have Sun.  (insert pokes
about whether Cobalt is Sun here...)

> It's easier to make sure that the MAC address doesn't get changed.
> You still "screw the comittee" locally, but you don't modify the
> hardware.

Other things get stored in the EEPROM - for example, Wake-on-Lan options.
Just to name one.

Re: ethtool documentation

[Richard B. Johnson]

On Tue, 6 Aug 2002, Tim Hockin wrote:

> > If you ever sell a controller that contains an address that was
> > not allocated to the 'producer', somebody is going to get very
> > angry. This means, to me, that if you ever write a new MAC address
> > to that card/board, you had better throw it away when you are done.
> 
> As a developer of integrated systems, it is imperative the we be able to
> re-program EEPROMs and MAC addresses.  Cobalt systems all have Cobalt as
> the MFR section of the MAC address.  Sun Systems all have Sun.  (insert pokes
> about whether Cobalt is Sun here...)
> 
> > It's easier to make sure that the MAC address doesn't get changed.
> > You still "screw the comittee" locally, but you don't modify the
> > hardware.
> 
> Other things get stored in the EEPROM - for example, Wake-on-Lan options.
> Just to name one.
> 
If you really are what you say you are, then you know that you
cannot use a MAC address that has not been assigned to your
company.

And, as a developer or "integrated systems", I do program MAC
addresses into AMD PCnet32 SEEPROMS and I do have a batch of
MAC addresses assigned to Analogic and I do known what I am
talking about.

The Linux pcnet32 driver does not have this capability so I
had to add that capability for our purposes. I would not
advise putting such a driver in the standard kernel.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: ethtool documentation

[Tim Hockin]

> If you really are what you say you are, then you know that you
> cannot use a MAC address that has not been assigned to your
> company.

Come on, of COURSE we don't ship MAC addresses that we don't own.  We
(Cobalt) have/had a whole 24 bit address space allocated - just like the
other manufacturers of networked systems.  Please give me a _little_
credit.

> The Linux pcnet32 driver does not have this capability so I
> had to add that capability for our purposes. I would not

So you're saying it is a useful feature, that you and I both use...

> advise putting such a driver in the standard kernel.

...but you don't think others should be able to.  Why?  Give me one good
reason that this capability should not be there for people to use.

Re: ethtool documentation

[Alan Cox]

On Tue, 2002-08-06 at 21:03, Richard B. Johnson wrote:
> Sure you can. And it was assumed that the MAC address provided by
> the manufacturer would always be used by the software for the MAC
> address on the wire. However, 'software engineers' have decided

Umm no

DECnet used dynamically assigned MAC addresses from the beginning and
Digital (now Compaq (now HP)) were one of the creators of the original
DIX ethernet standard

Thats why several boards allow you to have a pair of receiving MAC
addresses.

Re: ethtool documentation

[Randy.Dunlap]

On 6 Aug 2002, Alan Cox wrote:

| On Tue, 2002-08-06 at 21:03, Richard B. Johnson wrote:
| > Sure you can. And it was assumed that the MAC address provided by
| > the manufacturer would always be used by the software for the MAC
| > address on the wire. However, 'software engineers' have decided
|
| Umm no
|
| DECnet used dynamically assigned MAC addresses from the beginning and
| Digital (now Compaq (now HP)) were one of the creators of the original
| DIX ethernet standard
|
| Thats why several boards allow you to have a pair of receiving MAC
| addresses.

Do you mean several unicast MAC addresses, as opposed to
broadcast + several multicast + (one) unicast MAC address?
If so, I'm not familiar with that scenario.

-- 
~Randy

Re: ethtool documentation

[Alan Cox]

On Tue, 2002-08-06 at 21:42, Randy.Dunlap wrote:
> Do you mean several unicast MAC addresses, as opposed to
> broadcast + several multicast + (one) unicast MAC address?
> If so, I'm not familiar with that scenario.

Two unicast addresses, one for the sane world one for DECnet. The DEC
tulip supports this as one example

Re: ethtool documentation

[Mark H. Wood]

On 6 Aug 2002, Alan Cox wrote:
> On Tue, 2002-08-06 at 21:42, Randy.Dunlap wrote:
> > Do you mean several unicast MAC addresses, as opposed to
> > broadcast + several multicast + (one) unicast MAC address?
> > If so, I'm not familiar with that scenario.
>
> Two unicast addresses, one for the sane world one for DECnet. The DEC
> tulip supports this as one example

Yes indeedy.  This is what DECnet Phase IV has instead of ARP.  Rather
than broadcast a query and hope someone answers with the desired mapping,
Phase IV specifies a mapping formula so that the sender can simply
calculate a MAC address for any neighbor, given its upper-level address.
That's where those AA-00-04 addresses come from -- the lowest 16 bits are
the DECnet area and node number.  There are a number of well-known
multicast addresses (AB-00-04) too.

Notice something that nobody has brought up yet (unless it's in the 3000
messages I haven't caught up to yet, sorry):  LAA and UAA addresses can
always be distinguished, by a bit in the top end.  You can manufacture all
the LAAs you want and namespace collisions are your problem, but UAAs are
expected to be unique and unchanging.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".

Re: ethtool documentation

[Richard B. Johnson]

On 6 Aug 2002, Alan Cox wrote:

> On Tue, 2002-08-06 at 21:03, Richard B. Johnson wrote:
> > Sure you can. And it was assumed that the MAC address provided by
> > the manufacturer would always be used by the software for the MAC
> > address on the wire. However, 'software engineers' have decided
> 
> Umm no
> 
> DECnet used dynamically assigned MAC addresses from the beginning and
> Digital (now Compaq (now HP)) were one of the creators of the original
> DIX ethernet standard
> 
> Thats why several boards allow you to have a pair of receiving MAC
> addresses.
> 

That's not the MAC address. That's the multicast hash. They are
different. The MAC address says who you are. The multicast hash
says who you can receive (in addition to your MAC and the
all 1's broadcast). Of course there's also 'promisc' which turns
off receive filtering all together.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: ethtool documentation

[Alan Cox]

On Wed, 2002-08-07 at 02:57, Richard B. Johnson wrote:
> > DECnet used dynamically assigned MAC addresses from the beginning and
> > Digital (now Compaq (now HP)) were one of the creators of the original
> > DIX ethernet standard
> > 
> > Thats why several boards allow you to have a pair of receiving MAC
> > addresses.
> > 
> 
> That's not the MAC address. That's the multicast hash. They are
> different. The MAC address says who you are. The multicast hash

No thats a unicast address not a multicast hash entry. Go read the
Decnet protocol specifications

Re: ethtool documentation

[Ryan Anderson]

> The EEPROM (SEEPROM) on these NICS is used to contain the startup
> configuration bits and the IEEE Station Address. This must be a
> unique number that is assigned so that there is no other such
> number in (preferably) the world, and certainly in the LAN.
> If you let a user write to this area, you will allow the user
> to destroy the connectivity on a LAN.
> 
> If you provide an ioctl() to write new SEEPROM contents, it had
> better be disabled in code that user's (any, including root)
> can execute because, if caught, your company may lose it's IEEE
> Station Addresses and never again be allowed to configure Ethernet
> Controllers.

I think you overstate the seriousness here - it's not unheard of for
manufacturers to ship hardware with duplicate MAC addresses - a trivial
search on Google turns up Cisco as one offender:

http://www.cisco.com/warp/public/770/7.html

> 
> Because of this, there is no such thing as 'unused eeprom space' in
> the Ethernet Controllers. Be careful about putting this weapon in
> the hands of the 'public'. All you need is for one Linux Machine
> on a LAN to end up with the same IEEE Station Address as another
> on that LAN and connectivity to everything on that segment will
> stop. You do this once at an important site and Linux will get a
> very black eye.

Worse than GE?

http://www.gefanuc.com/support/plc/m030202.htm

Being able to permanently fix a screwed up card that duplicated another
card on my LAN would be nice, imo.

Of course, this assumes that IEEE Station Address == MAC address.


--
Ryan Anderson
  sometimes Pug Majere

Re: ethtool documentation

[Dax Kelson]

On Tue, 6 Aug 2002, Richard B. Johnson wrote:

> If you let a user write to this area, you will allow the user
> to destroy the connectivity on a LAN.
> 
> Because of this, there is no such thing as 'unused eeprom space' in
> the Ethernet Controllers. Be careful about putting this weapon in
> the hands of the 'public'. All you need is for one Linux Machine
> on a LAN to end up with the same IEEE Station Address as another
> on that LAN and connectivity to everything on that segment will
> stop. You do this once at an important site and Linux will get a
> very black eye.

Dick, this "weapon" has been the in the hands of admins and evil-doers for 
YEARS!

It is called /sbin/ifconfig

With this evil command nearly any NIC can masquerade as any one of
~281474976710656 possible IEEE Station Addresses. This weapon of
destruction has seen wide spread proliferation across most Unix varients.
Human sacrifice, dogs and cats living together, mass hysteria!

Err, no wait.

The sky is not falling, you protest too much.

Dax Kelson

Re: ethtool documentation

[Jonathan Lundell]

At 11:32 PM -0600 8/6/02, Dax Kelson wrote:
>The sky is not falling, you protest too much.

Ha! Just wait until the jack-booted IEEE enforcers kick down *your* 
door in the middle of the night to nab you for MAC-address trespass. 
THEN we'll see who' protesting too much.
-- 
/Jonathan Lundell.

Re: ethtool documentation

[Alan Cox]

On Wed, 2002-08-07 at 07:30, Jonathan Lundell wrote:
> At 11:32 PM -0600 8/6/02, Dax Kelson wrote:
> >The sky is not falling, you protest too much.
> 
> Ha! Just wait until the jack-booted IEEE enforcers kick down *your* 
> door in the middle of the night to nab you for MAC-address trespass. 
> THEN we'll see who' protesting too much.

Just don't use it to go around proprietary software license managers,
because if so the fbi might just do that...

Re: ethtool documentation

[Peter Samuelson]

  [Jonathan Lundell]
> > Ha! Just wait until the jack-booted IEEE enforcers kick down
> > *your* door in the middle of the night to nab you for MAC-address
> > trespass.

[AC]
> Just don't use it to go around proprietary software license
> managers, because if so the fbi might just do that...

Very useful ability, that.  Especially when the vendor tool reports
the wrong license number so the license you legally obtained doesn't
work.  Changing the software MAC address makes everything better.  The
one time I had to do this, it was fun to tell people "In order to do
my job today I had to break Federal law."  Alas I think everyone
assumed I was just being melodramatic.

Re: ethtool documentation

[Richard B. Johnson]

On Tue, 6 Aug 2002, Dax Kelson wrote:

> On Tue, 6 Aug 2002, Richard B. Johnson wrote:
> 
> > If you let a user write to this area, you will allow the user
> > to destroy the connectivity on a LAN.
> > 
> > Because of this, there is no such thing as 'unused eeprom space' in
> > the Ethernet Controllers. Be careful about putting this weapon in
> > the hands of the 'public'. All you need is for one Linux Machine
> > on a LAN to end up with the same IEEE Station Address as another
> > on that LAN and connectivity to everything on that segment will
> > stop. You do this once at an important site and Linux will get a
> > very black eye.
> 
> Dick, this "weapon" has been the in the hands of admins and evil-doers for 
> YEARS!
> 
> It is called /sbin/ifconfig
> 
> With this evil command nearly any NIC can masquerade as any one of
> ~281474976710656 possible IEEE Station Addresses. This weapon of
> destruction has seen wide spread proliferation across most Unix varients.
> Human sacrifice, dogs and cats living together, mass hysteria!
> 
> Err, no wait.
> 
> The sky is not falling, you protest too much.
> 
> Dax Kelson
> 

That capability is not permanent. If you let users write to the
SEEPROM, permanently changing the IEEE Station Address, you have
let users permanently break their network boards. I do protest
when this capability is in the kernel.

Anybody, who knows how can, write a driver that can destroy their
disk drives, their modems, their audio boards, their screen-cards,
their motherboards, ...the list goes on..., because EEPROMS are
being used now days. But, you don't put that capability in the
kernel as a default.

If you do, you get complaints from those who have had the misfortune of
being interrogated by lawyers.

Also, if you want to destroy Ethernet, mucking with the MAC address
is an easy way to do it.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: ethtool documentation

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

Hi Richard!

This whole argument is useless anyway. The ethtool API already allows
userland apps to change the eeprom, so you can already change the MAC
address (which I also believe is the way it should be, because that allows
manufacturers to program the MAC address without requiring additional
drivers).

People don't like to break their hardware for the fun of it. You don't see
people reprogramming their memory eeproms using the i2c code, but the
functionality is there. I think ripping out all kinds of functionality just
because there is a slight chance of some stupid person trashing his/her
hardware is unproductive and contrary to the spirit of open and free software.

> > > If you let a user write to this area, you will allow the user
> > > to destroy the connectivity on a LAN.
> > > 
> > > Because of this, there is no such thing as 'unused eeprom space' in
> > > the Ethernet Controllers. Be careful about putting this weapon in
> > > the hands of the 'public'. All you need is for one Linux Machine
> > > on a LAN to end up with the same IEEE Station Address as another
> > > on that LAN and connectivity to everything on that segment will
> > > stop. You do this once at an important site and Linux will get a
> > > very black eye.
> > 
> > Dick, this "weapon" has been the in the hands of admins and evil-doers for 
> > YEARS!
> > 
> > It is called /sbin/ifconfig
> > 
> > With this evil command nearly any NIC can masquerade as any one of
> > ~281474976710656 possible IEEE Station Addresses. This weapon of
> > destruction has seen wide spread proliferation across most Unix varients.
> > Human sacrifice, dogs and cats living together, mass hysteria!
> > 
> > Err, no wait.
> > 
> > The sky is not falling, you protest too much.
> > 
> > Dax Kelson
> > 
> 
> That capability is not permanent. If you let users write to the
> SEEPROM, permanently changing the IEEE Station Address, you have
> let users permanently break their network boards. I do protest
> when this capability is in the kernel.
> 
> Anybody, who knows how can, write a driver that can destroy their
> disk drives, their modems, their audio boards, their screen-cards,
> their motherboards, ...the list goes on..., because EEPROMS are
> being used now days. But, you don't put that capability in the
> kernel as a default.
> 
> If you do, you get complaints from those who have had the misfortune of
> being interrogated by lawyers.
> 
> Also, if you want to destroy Ethernet, mucking with the MAC address
> is an easy way to do it.

-- 

Regards
 Abraham

Luck can't last a lifetime, unless you die young.
		-- Russell Banks

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: ethtool documentation

[Bernd Eckenfels]

In article <Pine.LNX.3.95.1020807070841.28061A-100000@chaos.analogic.com> you wrote:
> That capability is not permanent. If you let users write to the
> SEEPROM, permanently changing the IEEE Station Address, you have
> let users permanently break their network boards. I do protest
> when this capability is in the kernel.

It does not break it permanently. You just need to write a sane address and
it will work again. 

Greetings
Bernd
y

Re: ethtool documentation

[erik]

On Wed, Aug 07, 2002 at 07:18:17AM -0400, Richard B. Johnson wrote:
> 
> That capability is not permanent. If you let users write to the
> SEEPROM, permanently changing the IEEE Station Address, you have
> let users permanently break their network boards. I do protest
> when this capability is in the kernel.

Don't forget the old sun workstations that keep MAC addresses in
nvram, where it's setable via the boot prom.  I had one with a bad
battery that I had to reset the MAC address on by hand if I unplugged
it for too long.

They DID implement a check to make sure the first few bits were
correct for the product, though.  I couldn't pick completely random
MACs (though C0FFEE fit nicely at the end).

Given a working nvram, this change was "permanent", and the only tools
needed came with the system.



Erik

-- 
Ask not what your computer can do for you.  Ask what you can do for
  your computer.

Re: ethtool documentation

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Hi Randy!

> | Wouldn't it have been better to make this 'n character device which can
> | be read from / written to just like a normal file (/dev/nvram-like
> | interface) -
> | that way applications can actually use unused eeprom space.
> 
> I wouldn't care for this.  There's nothing 'normal' about this
> EEPROM space, and apps generally won't know where there might be
> some 'unused eeprom space'.

That's not true. Sure, it may not be useful in your average setup, but there
are some cases where it might be useful, e.g. in embedded systems.

-- 

Regards
 Abraham

Faith is under the left nipple.
		-- Martin Luther

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: ethtool documentation

[Leif Sawyer]

Ben Greear responded to:
> "Richard B. Johnson" who wrote:
>> Because of this, there is no such thing as 'unused eeprom space'
>> in the Ethernet Controllers. Be careful about putting this weapon
>> in the hands of the 'public'. All you need is for one Linux Machine
>> on a LAN to end up with the same IEEE Station Address as another
>> on that LAN and connectivity to everything on that segment will
>> stop. You do this once at an important site and Linux will get a
>> very black eye.
> 
> Actually, any important site has some kind of failover in 
> place, and they could very well be using this feature to provide
> seamless MAC/IP takeover in the case of a server outtage.
> 
> This feature also allows bridging to work, and anyone with 
> root priviledges can send any ethernet packet they want using
> a raw packet socket anyway.

Absolutely.  Remember this is all about Freedoms.  Why try to take
away the ability to do something?  Especially when it already exists
and is very usefull.

I recently replaced a firewall "live"  by using mac-address spoofing.
Nobody noticed anything, except for a 30-sec 'hiccup' when traffic
"slowed down."

And really, Richard, If you want to take that argument, why would you
want anybody to change IP's?  Because if one Linux Machine on a LAN
ended up with the same IP of another machine on that LAN, then connectivity
to those two machines is flakey at best.  Or if it took over the IP of
the default GW, then all communication outside of the LAN will stop.
And this _never happens_ in real life?  Yet we still can change IP
addresses freely.  ( e.g., VLANs, Frame Relay DLCIs, ATM, AX.25, DecNet
nodes, etc...)

RE: ethtool documentation

[Richard B. Johnson]

On Tue, 6 Aug 2002, Leif Sawyer wrote:

> Ben Greear responded to:
> > "Richard B. Johnson" who wrote:
> >> Because of this, there is no such thing as 'unused eeprom space'
> >> in the Ethernet Controllers. Be careful about putting this weapon
> >> in the hands of the 'public'. All you need is for one Linux Machine
> >> on a LAN to end up with the same IEEE Station Address as another
> >> on that LAN and connectivity to everything on that segment will
> >> stop. You do this once at an important site and Linux will get a
> >> very black eye.
> > 
> > Actually, any important site has some kind of failover in 
> > place, and they could very well be using this feature to provide
> > seamless MAC/IP takeover in the case of a server outtage.
> > 
> > This feature also allows bridging to work, and anyone with 
> > root priviledges can send any ethernet packet they want using
> > a raw packet socket anyway.
> 
> Absolutely.  Remember this is all about Freedoms.  Why try to take
> away the ability to do something?  Especially when it already exists
> and is very usefull.
> 
> I recently replaced a firewall "live"  by using mac-address spoofing.
> Nobody noticed anything, except for a 30-sec 'hiccup' when traffic
> "slowed down."
> 
> And really, Richard, If you want to take that argument, why would you
> want anybody to change IP's?  Because if one Linux Machine on a LAN
> ended up with the same IP of another machine on that LAN, then connectivity
> to those two machines is flakey at best.  Or if it took over the IP of
> the default GW, then all communication outside of the LAN will stop.
> And this _never happens_ in real life?  Yet we still can change IP
> addresses freely.  ( e.g., VLANs, Frame Relay DLCIs, ATM, AX.25, DecNet
> nodes, etc...)
> 

This is not about 'freedom'. This is about modifying some hardware
to make it pretend that it's something that it is not. It's completely
unlike IP addresses or anything like that. It is supposed to uniquely
identify a piece of hardware. It's like the "frequency of a radio station"
where the IP address is like the "call sign".

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: ethtool documentation

[Jamie Lokier]

Richard B. Johnson wrote:
> This is not about 'freedom'. This is about modifying some hardware
> to make it pretend that it's something that it is not. It's completely
> unlike IP addresses or anything like that. It is supposed to uniquely
> identify a piece of hardware. It's like the "frequency of a radio station"
> where the IP address is like the "call sign".

That right, and it's very useful.  How else would I have the freedom to
connect different computers onto the cable modem at home when our router
dies? (The cable service only allows a single registered MAC address)

And how else would I have the freedom to replace the old ISA NIC at
work, and continue to run the MAC-locked licensed compiler?

If nobody restricted freedoms by keying to the MAC address, I'd never
want to change it.  But they do.  And if the NICs didn't allow for
reprogramming it, I'd guess that there would be a Linux flag to run the
cards in promiscuous mode to simulate a fake MAC address in software..

-- Jamie

RE: ethtool documentation

[Leif Sawyer]

Richard B. Johnson writes:
>
> Also, if you want to destroy Ethernet, mucking with the MAC address
> is an easy way to do it.

Yeah, I remember the time that I set all the prefixes in my lab for the
stations I had running WinX to BE:DE:AD, and Linux to FE:ED:B0,
and the station addresses from 1-24. 

That way a quick arp on the router would tell me which of my stations were
booted into Windows, and which were booted into Linux.

<sarcasm>
Gosh, that wasn't helpful at all to me, and sure b0rked up "Ethernet"
</sarcasm>

If you don't like it, don't use it.  Please don't try to take that
functionality away from the rest of the world, because we find it
useful.  And sometimes it's required.


Leif

Re: ethtool documentation

[Helge Hafting]

Alan Cox wrote: 
>Jonathan Lundell wrote:
>> Ha! Just wait until the jack-booted IEEE enforcers kick down *your* 
>> door in the middle of the night to nab you for MAC-address trespass. 
>> THEN we'll see who' protesting too much.
>
> Just don't use it to go around proprietary software license managers,
> because if so the fbi might just do that...

I wouldn't worry aboyt that.  A licence manager depending on
MAC addresses simply isn't doing its job.  
Moving a ethernet card from one computer to another is
perfectly legal if you own both of them.  So it is the
licence manager that is broken.  

I know no law that require IEEE conformant networks either.
If I want to run a net with crazy MAC addresses then I
can do so -  and deal with interoperability problems myself.

Piracy is still illegal of course, but nobody can force
me to keep a broken licence manager in working order. :-)

Helge Hafting