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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
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
> > 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 */
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 :)
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.
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
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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
From: Abraham vd Merwe <[email protected]>
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
Abraham vd Merwe <[email protected]> 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
On Tue, 6 Aug 2002, Randy.Dunlap wrote:
>
> Abraham vd Merwe <[email protected]> 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.
"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: [email protected]
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
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.
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
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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
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.
> 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.
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...)
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
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.
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.
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.
> 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
> 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.
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
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.
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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
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
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...
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.
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
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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
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
In article <[email protected]> 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
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.
[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.
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
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 [email protected]
MS Windows *is* user-friendly, but only for certain values of "user".