How does "alias ethX drivername" in modules.conf work?
I'm trying to figure out how "alias ethX" works in /etc/modules.conf
Is it some "magic" in depmod / modprobe? And how is the network interface identifier then passed into the module when it loads?
A nice whitepaper or doc or a few pointers or handholding would be apprecated.
Signature · 2 lines
Mark Atwood | I'm wearing black only until I find something darker. [email protected] | http://www.pobox.com/~mra
On Fri, Aug 03, 2001 at 02:29:58PM -0700, Mark Atwood wrote:
Is it some "magic" in depmod / modprobe? And how is the network interface identifier then passed into the module when it loads?
A nice whitepaper or doc or a few pointers or handholding would be apprecated.
the kernel calls modprobe asking for the network device 'eth0', modprobe uses the configuration file to map this to a module
--cw
Quoted 2 lines · Chris Wedgwood
the kernel calls modprobe asking for the network device 'eth0', modprobe uses the configuration file to map this to a module
so, what happens when you have two eth cards that use the same module? in the isa land, the order you pass the io=0x300,0x240 would determine which order the eth?'s go to...how about in the pci world?
-tduffy
Hi Thomas.
Quoted 7 lines
Quoted 2 lines
the kernel calls modprobe asking for the network device 'eth0', modprobe uses the configuration file to map this to a module
so, what happens when you have two eth cards that use the same module? in the isa land, the order you pass the io=0x300,0x240 would determine which order the eth?'s go to...how about in the pci world?
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulip
Best wishes from Riley.
Quoted 14 lines · Riley Williams
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulip
Quoted 1 line
Best wishes from Riley.
ok, well this makes sense for the ISA cards. I have card A in my hand, I set the jumpers on it to an io port 0x340, stick it in slot X on my computer, plug the wire into it from network 1, then I mentally can map all the stuff together, so I know how to setup the network in Linux
eth0 == io 0x340 == card A == slot X in my computer == network 1
but, how can you tell the difference between eth3 and eth4 -- and specify which *physical* card gets assigned to which virtual eth? name...ie, how do I know which pci slot is which eth? besides reading the motherboard documentation and maybe learning which direction and how the pci bus is ordered...which can differ between motherboard manufacturers and BIOS's, etc, etc.
and how do I change it if I don't like the default order (based off of pci scan order). what if I want card B, a pci card stuck in PCI slot Y to be eth4?
hope this is clearer...
thanks,
-tduffy
Hi Thomas.
Quoted 20 lines
Quoted 4 lines
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulipok, well this makes sense for the ISA cards. I have card A in my hand, I set the jumpers on it to an io port
0x340, stick it in slot X on my computer, plug the wire into it from network 1, then I mentally can map all the stuff together, so I know how to setup the network in Linux
Quoted 5 lines
eth0 == io
0x340== card A == slot X in my computer == network 1but, how can you tell the difference between eth3 and eth4 -- and specify which *physical* card gets assigned to which virtual eth? name...ie, how do I know which pci slot is which eth?
That depends on the driver used to map those cards. Here's what I know so far, mainly from experimentation:
1. The ne2k-pci driver assigns cards in ascending ethernet address on this machine.
2. On the same machine, when I had three tulip cards installed, the tulip driver assigned them in descending ethernet address.
3. Both of the above results are independant of the order the cards are plugged into the PCI bus.
As a result, there is no simple answer to your question, and the answer above probably depends to a large extent on factors other than the card itself.
However, if the cards are controlled by different drivers, you can influence the order they are detected in by your choice of entries in modules.conf - in the example above, the ISA cards are always eth0, eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the tulip card is always eth5, simply because that's what the said file says.
Quoted 3 lines
besides reading the motherboard documentation and maybe learning which direction and how the pci bus is ordered...which can differ between motherboard manufacturers and BIOS's, etc, etc.
Remember that every ethernet card has an ethernet address assigned to it, this being the "HWaddr" reported by ifconfig and (in theory at least) these are all unique. All you need to do is to determine the ethernet address of each of the cards in your system, then see which interface has that ethernet address assigned to it, and you've found the match...
Quoted 3 lines
and how do I change it if I don't like the default order (based off of pci scan order). what if I want card B, a pci card stuck in PCI slot Y to be eth4?
You could always add "options eth? io=0x????" lines for the PCI ports, and hope the addresses you've specified don't get changed, but I'll not guarantee this works as I've never tried it.
Probably of more use is to set the IP address for a particular interface dependant on the ethernet address of the card supplying it. The enclosed bash script should achieve that - it's basically the ifconfig command with the port name replaced by its ethernet address, but it only works for "eth?" ports. I've tried it on my system, and it does the job it's designed to, but YMMV...
Quoted 1 line
I hope this is clearer...
I hope this helps...
Best wishes from Riley.
#!/bin/bash
###############################################################################
#
# This script provides a version of the ifconfig command that expects to
# see the ethernet address associated with a particular port, and performs # the stated actions on whichever ethernet interface has the specified # ethernet address. All actions associated with the `ifconfig` command are # supported, and the only change in syntax is that the port name of "eth?" # is replaced by the associated ethernet address. # # If no ethernet interface is found with the specified ethernet address, # this script uses a return value of 1, otherwise it uses a return value # of 0. # ###############################################################################
function assign() {
local HW="$1" OK=Y
declare -i N=0
shift 1
while [ $OK = Y ]; do
if ! port eth$N ; then
if ifconfig eth$N up 2> /dev/null ; then
if [ "`hwaddr eth$N`" != "${HW}" ]; then
ifconfig eth$N down
else
ifconfig eth$N "$@"
OK=$?
fi
else
OK=0
fi
fi
N=$N+1
done
return $OK
}function hwaddr() {
ifconfig "$1" | grep "^$1" | tr ' ' '\n' | grep '[0-9A-F]:[0-9A-F]'
}function port() {
ifconfig | grep ^eth | fgrep "$1" > /dev/null
}
if [ $# -gt 0 ]; then
if assign "$@" ; then
echo No ethernet interface with address "$1" found. >&2 exit 1
else
exit 0
fi
else
ifconfig
exit 0
fi
Quoted 15 lines
Quoted 4 lines
Quoted 3 lines
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Quoted 9 lines
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulip
Quoted 3 lines
However, if the cards are controlled by different drivers, you can influence the order they are detected in by your choice of entries in modules.conf - in the example above, the ISA cards are always eth0,
^^^^^^
Quoted 3 lines
eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the tulip card is always eth5, simply because that's what the said file says.
Not always. You are wrong here, I'm afraid:
Lets assume that eth0-eth3 are not initialized at boot time and your init scripts attempt to initialize eth4 ...
To avoid such problems one probably should add a lot of pre-install parameters in modules.conf.
Andrzej
Hi Andrzej.
First, what's with the crazy addresses for Linux-Kernel mailing list and the various correspondants?
Quoted 19 lines
Quoted 14 lines
Quoted 4 lines
Quoted 3 lines
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Quoted 9 lines
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulipQuoted 3 lines
However, if the cards are controlled by different drivers, you can influence the order they are detected in by your choice of entries in modules.conf - in the example above, the ISA cards are always eth0,
^^^^^^
Quoted 8 lines
Quoted 3 lines
eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the tulip card is always eth5, simply because that's what the said file says.
Not always. You are wrong here, I'm afraid:
Lets assume that eth0-eth3 are not initialized at boot time and your init scripts attempt to initialize eth4 ...
Then I get an entry for eth4 in the ifconfig output, with NO entries for eth0 through eth3, exactly as expected.
Note that the ifconfig command refers to the interfaces by name, and it's the settings in modules.conf that decide what type of interface that name refers to. That mapping can't be changed by any interface configuration or initialisation command, and the names used are those as given.
Quoted 2 lines
To avoid such problems one probably should add a lot of pre-install parameters in modules.conf.
What problems?
Best wishes from Riley.
"Riley Williams wrote:"
Quoted 18 lines
Quoted 17 lines
Quoted 17 lines
Quoted 9 lines
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulipHowever, if the cards are controlled by different drivers, you can influence the order they are detected in by your choice of entries in modules.conf - in the example above, the ISA cards are always eth0,
eth1 and eth2, the NE2k-pci cards are always eth3 and eth4, and the tulip card is always eth5, simply because that's what the said file says.
Quoted 7 lines
Quoted 4 lines
Not always. You are wrong here, I'm afraid:
Lets assume that eth0-eth3 are not initialized at boot time and your init scripts attempt to initialize eth4 ...
Then I get an entry for eth4 in the
ifconfigoutput, with NO entries foreth0througheth3, exactly as expected.
Did you ever try ? I think no. I've got the problem a few times while (re)configuring multi-ethernet machines.
ne2k-pci is the first module loaded then and it finds two interfaces. As there is no interfaces registered at the moment, they are named eth0 and eth1 (sic!)
The interface names from modules.conf mean nothing here, they are ignored.
I see tho ways to get the proper intyerface names:
1. Force loading all modules in the appropriate sequence (ne before ne2k-pci) either manually or via pre-install command
2. Renaming interfaces after they are initialized (yes, interface names can be changed, but it is ugly)
Quoted 5 lines
Note that the
ifconfigcommand refers to the interfaces by name, and it's the settings in modules.conf that decide what type of interface that name refers to. That mapping can't be changed by any interface configuration or initialisation command, and the names used are those as given.
ifconfig does not assign interface names. The kernel driver (module) does. And the driver has no option passed (even I thing it is impossiblke to pass any) to define new interface naming scheme.
Quoted 4 lines
Quoted 2 lines
To avoid such problems one probably should add a lot of pre-install parameters in modules.conf.
What problems?
Described above.
Andrzej
Signature · 4 lines
======================================================================= Andrzej M. Krzysztofowicz [email protected] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk
Hi Andre.
Quoted 16 lines
Quoted 15 lines
Quoted 15 lines
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulipQuoted 4 lines
However, if the cards are controlled by different drivers, you can influence the order they are detected in by your choice of entries in modules.conf - in the example above, the ISA cards are always eth0, eth1 and eth2, the NE2k-pci cards are always
^^^^^^
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
eth3 and eth4, and the tulip card is always eth5, simply because that's what the said file says.
Not always. You are wrong here, I'm afraid:
Lets assume that eth0-eth3 are not initialized at boot time and your init scripts attempt to initialize eth4 ...
I gather that I misunderstood what you were saying above, so let me clarify what I now understand by your comments:
1. You are assuming a broken set of init scripts. Specifically, they load the individual modules manually by the name of the module, rather than stating that you wish to initialise a particular interface and letting kmod sort out the correct module.
If this is your assumption, then you've created an artificial situation that by its very nature is broken and unreliable.
2. Alternatively, you are saying that in your setup, the module referred to by the alias eth0 line in modules.conf was not compiled as part of the kernel.
If this is your claim, then you have created a deliberately broken setup.
3. Alternatively, you are saying that in your setup, the module referred to by the alias eth0 line in modules.conf is the wrong module for that particular interface.
If this is your claim, then you have again produced a broken setup.
4. Alternatively, in your setup, there are interfaces controlled by the same driver that are separated by interfaces controlled by one or more other drivers.
If this is your claim, then you will get the scenario that you describe, but this is simply because they are separated, and is corrected by renumbering them so that all interfaces that are controlled by the same driver are contiguously numbered for all drivers.
As I see things, if you're referring to a situation covered by any of the situations above, then my only interest is in advising you how to correct the situation to get rid of the broken setup.
Quoted 4 lines
Quoted 2 lines
Then I get an entry for eth4 in the
ifconfigoutput, with NO entries foreth0througheth3, exactly as expected.Did you ever try ?
Not with any of the broken scenarios described above, no.
Quoted 4 lines
I think no. I've got the problem a few times while (re)configuring multi-ethernet machines.
ne2k-pci is the first module loaded...
If it is, then the setup falls into one of the scenarios above. The CORRECT scenario (the only non-broken one) has ifconfig trying to initialise the interfaces in the sequence eth0 - eth1 - ... - ethN with kmod loading the appropriate driver for each one based on the contents of the modules.conf file. ANY other scenario is broken by design.
Quoted 5 lines
...and it finds two interfaces. As there is no interfaces registered at the moment, they are named eth0 and eth1 (sic!)
The interface names from modules.conf mean nothing here, they are ignored.
Then the init scripts are broken as stated above.
Quoted 7 lines
I see tho ways to get the proper interface names:
1. Force loading all modules in the appropriate sequence (ne before ne2k-pci) either manually or via pre-install command
2. Renaming interfaces after they are initialized (yes, interface names can be changed, but it is ugly)
The first is not only the correct one, but also what just about every system other than yours does by default.
Quoted 10 lines
Quoted 5 lines
Note that the
ifconfigcommand refers to the interfaces by name, and it's the settings in modules.conf that decide what type of interface that name refers to. That mapping can't be changed by any interface configuration or initialisation command, and the names used are those as given.ifconfig does not assign interface names. The kernel driver (module) does. And the driver has no option passed (even I thing it is impossiblke to pass any) to define new interface naming scheme.
Here's what is supposed to happen:
1. ifconfig tries to initialise interface eth0.
2. The kernel sees that interface eth0 doesn't exist as a module so asks the kmod driver to load it.
3. The kmod driver refers to the modules.conf file to determine the true name for the eth0 interface. On my system, it sees the line alias eth0 ne telling it that eth0 is controlled by the module ne.
4. The kmod driver checks whether the ne driver is loaded, and loads it if not.
5. The kmod driver advises the kernel that the eth0 module has beel loaded at whatever address the ne driver was loaded at.
6. The kernel then uses that module to refer to the eth0 driver.
Note that the kernel assigns interface names BASED ON WHAT IFCONFIG DOES. If ifconfig tries to initialise eth1 before eth0 then the kernel will get out of step with everything else, and correctly so. That's a bug in the init scripts, not in the kernel.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
To avoid such problems one probably should add a lot of pre-install parameters in modules.conf.
What problems?
Described above.
What KERNEL problems then? I don't see any yet.
Best wishes from Riley.
Quoted 4 lines · Riley Williams
Quoted 2 lines
Described above.
What KERNEL problems then? I don't see any yet.
I smell the stench of finger pointing. It's a pity that it stinks jsut as bad in the open source world as it is I am "privileged" when closed source shops, or (even worse) telco/network folks start playing "blameball".
Userspace init scripts point the finger at kernel, saying "there is no good and no well documented mapping method". Kernel points its finger at userspace, saying "this is the way we do it" and "we cant guarantee a perfect 100% mapping solution, so we're not even going to try for 90%" and "futz with your drivers and modules.conf and init scripts till you get something that works".
Fingers back and forth, fingers pointing all around
and those of us with lots of different interfaces, and those of us with several hot-plug interfaces
What happens to us?
We get the finger.
Signature · 2 lines
Mark Atwood | I'm wearing black only until I find something darker. [email protected] | http://www.pobox.com/~mra
Hi Mark.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Described above.
What KERNEL problems then? I don't see any yet.
I smell the stench of finger pointing. It's a pity that it stinks jsut as bad in the open source world as it is I am "privileged" when closed source shops, or (even worse) telco/network folks start playing "blameball".
I'm trying not to point any fingers anywhere, but I have to admit that I'm finding it VERY difficult in this case. The basic problem that I have is that the "way it's done" that I referred to in my posts so far is the way that RedHat, Caldera, Debian, Mandrake, SUSE and Eridani Linux all do it by default (I can't comment on SlackWare as I've never been able to get it to install myself and don't know anybody who runs it).
Quoted 7 lines
Userspace init scripts point the finger at kernel, saying "there is no good and no well documented mapping method". Kernel points its finger at userspace, saying "this is the way we do it" and "we cant guarantee a perfect 100% mapping solution, so we're not even going to try for 90%" and "futz with your drivers and modules.conf and init scripts till you get something that works".
I've certainly never stood in the position you call "Kernel" in that description. Here's the situation as I see it, put in those sort of terms, characters being InitScripts and Kernel respectively:
1. InitScripts points at Kernel saying "there is no good and no well documented mapping method".
2. Kernel replies "There is a good mapping method, which is to always map the ports starting with the lowest numbered one."
3. InitScripts then tells Kernel "But I don't want to map the ports in ascending numerical order!"
So far, I've only seen the above scenario occur, and I have to admit to having very little sympathy with it. However, I'm always open to persuasion that the above is not the situation that is occurring.
Quoted 8 lines
Fingers back and forth, fingers pointing all around
and those of us with lots of different interfaces, and those of us with several hot-plug interfaces
What happens to us?
We get the finger.
Not from me, you don't.
Let's deal with the various scenarios that I can see:
1. Just one interface, either static or hotplug.
By definition, there can be no problem here as the interface will always be eth0 when present, and missing when not.
2. Multiple identical static interfaces.
At the moment, you are required to initialise the interfaces in ascending order of their name in the modules.conf file.
I've dealt with this situation on several occasions, and never found this to be a problem in any way.
3. Multiple different static interfaces.
At the moment, you are required to group these by the driver that controls them, simply because each driver will automatically map all interfaces that it supports when it is loaded. Likewise, you are required to initialise interfaces in ascending order of their name in the modules.conf file.
I've dealt with this situation on several occasions, and never found this to be a problem in any way.
4. Multiple hotplug interfaces.
I have to admit to never having dealt with hotplug interfaces, but I understand some aspects of the interface are still being ironed out by the kernel developers. As a result, I would not be at all surprised to hear that problems still exist.
5. Multiple static and hotplug interfaces.
At the moment, you are required to group these by whether the interface is static or hotplug, configuring all static interfaces before any of the hotplug ones. This therefore reduces to being either case (2) or (3) followed by case (4), and should be dealt with accordingly.
As a result, the ONLY time I can see any problem occurring is when there are multiple hotplug interfaces to deal with (case (4) above), and this is acknowledged to be a case where some of the issues have not yet been fully ironed out.
Can you agree with this analysis, or have I overlooked something?
Best wishes from Riley.
Why not have a provision like the following:
1. For a given driver, assign ethX in [ascending|descending] (pick one) order based on MAC addr. At least this is a predictable order; it should never change for a given driver.
2. If it's modular, you could make it even more flexible with options:
alias eth0 eepro100
alias eth1 ne2k-pci
alias eth2 eepro100
options eepro100 "bind_mac_order=eth0,eth2 bind_mac_list=00D0B760C299,00D0B760C3DC"
3. if it's modular and insmod'ed with no options, default to a combo of the current behavior and #1, above.
Of course, you'd have to rely on the module maintainers to follow the convention.
Also, I can see a potential dependency manifested in a scenario like this:
1. add eth0, eth1, eth2 as above
2. un-hot-plug eth0. now hotplug another interface, not used by the previous driver
3. eepro100 driver is still bound to eth0
4. should the new device get eth3? or eth0?
5. Is this a textbook problem outside of PCMCIA?
Dumb? Klutzy? thoughts?
Thanks,
Josh
Hi Josh.
Quoted 5 lines
Why not have a provision like the following:
1. For a given driver, assign ethX in [ascending|descending] (pick one) order based on MAC addr. At least this is a predictable order; it should never change for a given driver.
Alan Cox will correct me if I'm wrong, but memory says that he pointed out a while back some problem with this idea. I've cc'd this to him for comments.
Quoted 7 lines
2. If it's modular, you could make it even more flexible with options:
alias eth0 eepro100
alias eth1 ne2k-pci
alias eth2 eepro100
options eepro100 "bind_mac_order=eth0,eth2 \
bind_mac_list=00D0B760C299,00D0B760C3DC"
I would suspect that all that would be needed here would be for each driver to only detect one interface each time it's called, so you would get something like the following instead:
alias eth0 eepro100
options eth0 mac=00:D0:B7:60:C2:99
alias eth1 ne2k-pci
alias eth2 eepro100
options eth2 mac=00:D0:B7:60:C3:DC
Incidentally, this follows the current modules.conf syntax rules, and (in this particular case) would be likely to be much simpler than your proposed change. Specifying the options on the interface rather than the driver is the ONLY way to specify different parameters for different interfaces in a flexible manner.
Quoted 5 lines
3. If it's modular and insmod'ed with no options, default to a combo of the current behavior and #1, above.
Of course, you'd have to rely on the module maintainers to follow the convention.
With the revised scenario, they already follow the convention because that is the current convention.
Quoted 2 lines
Also, I can see a potential dependency manifested in a scenario like this:
Your scenario has already been considered.
Quoted 2 lines
1. add eth0, eth1, eth2 as above
2. un-hot-plug eth0.
Two points here:
1. The fact that you can un-hot-plug eth0 states that you can also un-hot-plug eth1 and eth2. Any interfaces that can't be hot-plugged are currently required to be set up before any of the hot-pluggable ones.
2. The hotplug interface signals to the driver that this has happenned, so the driver de-registers eth0 by doing the equivalent of ifconfig eth0 down ; rmmod eth0 internally.
We continue...
Quoted 2 lines
3. now hotplug another interface, not used by the previous driver
4. eepro100 driver is still bound to eth0
No it isn't - see comments above.
Quoted 1 line
5. should the new device get eth3? or eth0?
As eth0 was auto-deregistered at point (2), it's actually irrelevant which it gets.
Quoted 1 line
6. Is this a textbook problem outside of PCMCIA?
It's one that has already been dealt with as part of the PCMCIA specification, and is thus already supported by the Linux PCMCIA interface.
I understand we can blame/credit Microsoft with the fact that this scenario was considered as part of the PCMCIA specification.
Quoted 1 line
Dumb? Klutzy? thoughts?
Neither dumb nor a problem.
Best wishes from Riley.
Quoted 9 lines
Quoted 5 lines
Why not have a provision like the following:
1. For a given driver, assign ethX in [ascending|descending] (pick one) order based on MAC addr. At least this is a predictable order; it should never change for a given driver.
Alan Cox will correct me if I'm wrong, but memory says that he pointed out a while back some problem with this idea. I've cc'd this to him for comments.
Correct. MAC addresses are defined per machine not per card. That they tend to be per card is on a PC isnt always true elsewhere. For example many sparc boxes have one mac per machine.
Its still a valuable way of naming devices.
Quoted 10 lines · Riley Williams
I've certainly never stood in the position you call "Kernel" in that description. Here's the situation as I see it, put in those sort of terms, characters being InitScripts and Kernel respectively:
1. InitScripts points at Kernel saying "there is no good and no well documented mapping method".
2. Kernel replies "There is a good mapping method, which is to always map the ports starting with the lowest numbered one."
Well, there is that present mapping method, but I hesitate to call it "good".
Plus, we are unable to satisfactorily define "lowest numbered one".
If I build a system with several identical (other than MAC) FooCorp PCI ethernics, they will number up in order of ascending MAC address.
I take the same system, replace the FooCorp cards with BarInc NICs, they will number up in reverse MAC address.
Replace them instead with Baz Systems NICs, and I get them in bus scan order (at which point I'm dependent on the firmware version of my PCI bridge too!).
And if I elect to use Frob Networking NICs, I instead get them in the *random* order that their oncard processors won the race to power up.
Gods and demons help me if I try putting several of all four brands in one box, or the firmware on my NICs or in my PCI bridges changes!
Quoted 3 lines
3. InitScripts then tells Kernel "But I don't want to map the ports in ascending numerical order!"
The phrase "ascending numerical order" becomes, depending on if you have a complex (lots of different kinds of interfaces) or dynamic (ferex, with PCMCIA, CompactPCI, USB, and Firewire ethernet interfaces), either useless or undefined.
Signature · 2 lines
Mark Atwood | I'm wearing black only until I find something darker. [email protected] | http://www.pobox.com/~mra
Hi Mark.
Quoted 8 lines
Quoted 8 lines
I've certainly never stood in the position you call "Kernel" in that description. Here's the situation as I see it, put in those sort of terms, characters being InitScripts and Kernel respectively:
1. InitScripts points at Kernel saying "there is no good and no well documented mapping method".
Quoted 8 lines
Quoted 2 lines
2. Kernel replies "There is a good mapping method, which is to always map the ports starting with the lowest numbered one."
Well, there is that present mapping method, but I hesitate to call it "good".
Plus, we are unable to satisfactorily define "lowest numbered one".
Why? When is eth0 higher numbered than eth1 for example?
Quoted 11 lines
If I build a system with several identical (other than MAC) FooCorp PCI ethernics, they will number up in order of ascending MAC address.
I take the same system, replace the FooCorp cards with BarInc NICs, they will number up in reverse MAC address.
Replace them instead with Baz Systems NICs, and I get them in bus scan order (at which point I'm dependent on the firmware version of my PCI bridge too!).
Quoted 7 lines
And if I elect to use Frob Networking NICs, I instead get them in the *random* order that their oncard processors won the race to power up.
Gods and demons help me if I try putting several of all four brands in one box, or the firmware on my NICs or in my PCI bridges changes!
I dealt with this problem in a previous email, but will repeat it for your benefit. The ONLY provisos I will use are the following two:
1. All ethernet interfaces in your machine have distinct MAC's.
2. If the firmware in your NIC's changes, the MAC's do not.
Providing both of these are met, the enclosed BASH SHELL SCRIPT implements the ifconfig command with the port name replaced by its MAC address.
With this change, it doesn't actually matter what port name a particular interface is given, because ALL of the other network config tools refer to the interface by its assigned IP address, not its port name. As a result, if its port name changes between boots, the routing automatically changes with it.
Quoted 7 lines
Quoted 2 lines
3. InitScripts then tells Kernel "But I don't want to map the ports in ascending numerical order!"
The phrase "ascending numerical order" becomes, depending on if you have a complex (lots of different kinds of interfaces) or dynamic (ferex, with PCMCIA, CompactPCI, USB, and Firewire ethernet interfaces), either useless or undefined.
I disagree: The phrase "ascending numerical order" has a FIXED meaning, namely that eth0 comes before eth1 which comes before eth2.
You appear to have assumed that I was referring to ascending MAC address, and such an assumption makes nonsense of most of what I said, but if you use the meaning I used, you'll see it makes perfect sense throughout.
Best wishes from Riley.
#!/bin/bash
###############################################################################
#
# This script provides a version of the ifconfig command that expects to
# see the ethernet address associated with a particular port, and performs # the stated actions on whichever ethernet interface has the specified # ethernet address. All actions associated with the `ifconfig` command are # supported, and the only change in syntax is that the port name of "eth?" # is replaced by the associated ethernet address. # # If no ethernet interface is found with the specified ethernet address, # this script uses a return value of 1, otherwise it uses a return value # of 0. # ###############################################################################
function assign() {
local HW="$1" OK=Y
declare -i N=0
shift 1
while [ $OK = Y ]; do
if ! port eth$N ; then
if ifconfig eth$N up 2> /dev/null ; then
if [ "`hwaddr eth$N`" != "${HW}" ]; then
ifconfig eth$N down
else
ifconfig eth$N "$@"
OK=$?
fi
else
OK=0
fi
fi
N=$N+1
done
return $OK
}function hwaddr() {
ifconfig "$1" | grep "^$1" | tr ' ' '\n' | grep '[0-9A-F]:[0-9A-F]'
}function port() {
ifconfig | grep ^eth | fgrep "$1" > /dev/null
}
if [ $# -gt 0 ]; then
if assign "$@" ; then
echo No ethernet interface with address "$1" found. >&2 exit 1
else
exit 0
fi
else
ifconfig
exit 0
fi
"Riley Williams wrote:"
Quoted 22 lines
Quoted 11 lines
If I build a system with several identical (other than MAC) FooCorp PCI ethernics, they will number up in order of ascending MAC address.
I take the same system, replace the FooCorp cards with BarInc NICs, they will number up in reverse MAC address.
Replace them instead with Baz Systems NICs, and I get them in bus scan order (at which point I'm dependent on the firmware version of my PCI bridge too!).
Quoted 7 lines
And if I elect to use Frob Networking NICs, I instead get them in the *random* order that their oncard processors won the race to power up.
Gods and demons help me if I try putting several of all four brands in one box, or the firmware on my NICs or in my PCI bridges changes!
I dealt with this problem in a previous email, but will repeat it for your benefit. The ONLY provisos I will use are the following two:
Quoted 7 lines
1. All ethernet interfaces in your machine have distinct MAC's.
2. If the firmware in your NIC's changes, the MAC's do not.
Providing both of these are met, the enclosed BASH SHELL SCRIPT implements the
ifconfigcommand with the port name replaced by its MAC address.
1. NFS-root needs to have RARP/NFS servers on eth0.
How can you deal with it if you have two boards supported by a single driver and, unfortunately, the one you need is detected as eth1 ? Assume that you cannot switch them as they use different media type...
Quoted 5 lines
With this change, it doesn't actually matter what port name a particular interface is given, because ALL of the other network config tools refer to the interface by its assigned IP address, not its port name. As a result, if its port name changes between boots, the routing automatically changes with it.
2. ipfwadm / ipchains / iptables may use interface names,
3. dhcpd may need interface names to be provided,
4. you may want to pass an interface name argument to tcpdump...
In 2.2+ you can deal with 2.-4. changing interface names using ip from iproute2. But I doubt whether ifconfig based scripts would work properly then. And problem 1. is still valid ...
Signature · 4 lines
======================================================================= Andrzej M. Krzysztofowicz [email protected] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk
Quoted 4 lines · Andrzej Krzysztofowicz
1. NFS-root needs to have RARP/NFS servers on eth0.
How can you deal with it if you have two boards supported by a single driver and, unfortunately, the one you need is detected as eth1 ? Assume that you cannot switch them as they use different media type...
Hmm. Then my system that does DHCP/NFS root with 2.4.7 and comes up on eth2 is doesn't work? Hmm it looks like it works to me.
Eric
Quoted 10 lines
Quoted 4 lines · Andrzej Krzysztofowicz
1. NFS-root needs to have RARP/NFS servers on eth0.
How can you deal with it if you have two boards supported by a single driver and, unfortunately, the one you need is detected as eth1 ? Assume that you cannot switch them as they use different media type...Hmm. Then my system that does DHCP/NFS root with 2.4.7 and comes up on eth2 is doesn't work? Hmm it looks like it works to me.
Then the documentation I've read must be outdated. Sorry.
Signature · 4 lines
======================================================================= Andrzej M. Krzysztofowicz [email protected] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk
Hi Eric.
Quoted 9 lines
Quoted 6 lines
1. NFS-root needs to have RARP/NFS servers on eth0.
How can you deal with it if you have two boards supported by a single driver and, unfortunately, the one you need is detected as eth1 ? Assume that you cannot switch them as they use different media type...
Hmm. Then my system that does DHCP/NFS root with 2.4.7 and comes up on eth2 is doesn't work? Hmm it looks like it works to me.
I have no personal experience of NFS-Root but the documentation I've seen all implied that it did the RARP broadcast in parallel on all configured NIC's and used the one that replied from there on. I'm glad to hear that my reading of the documentation was correct.
Best wishes from Riley.
Hi Andrzej.
Quoted 25 lines
Quoted 25 lines
Quoted 11 lines
If I build a system with several identical (other than MAC) FooCorp PCI ethernics, they will number up in order of ascending MAC address.
I take the same system, replace the FooCorp cards with BarInc NICs, they will number up in reverse MAC address.
Replace them instead with Baz Systems NICs, and I get them in bus scan order (at which point I'm dependent on the firmware version of my PCI bridge too!).
Quoted 7 lines
And if I elect to use Frob Networking NICs, I instead get them in the *random* order that their oncard processors won the race to power up.
Gods and demons help me if I try putting several of all four brands in one box, or the firmware on my NICs or in my PCI bridges changes!
I dealt with this problem in a previous email, but will repeat it for your benefit. The ONLY provisos I will use are the following two:
1. All ethernet interfaces in your machine have distinct MAC's.
Quoted 7 lines
Quoted 5 lines
2. If the firmware in your NIC's changes, the MAC's do not.
Providing both of these are met, the enclosed BASH SHELL SCRIPT implements the
ifconfigcommand with the port name replaced by its MAC address.1. NFS-root needs to have RARP/NFS servers on eth0.
I have to admit that I've never actually used NFS root, although I have read documents on it. I also have to say that my understanding was that it broadcast RARP packets on ALL configured network ports, and used the lowest numbered one for the rest of the boot process. If this isn't the case, then the documentation needs to be changed to reflect what it actually does - or, better still, the behaviour needs to be changed to match the documentation, as the documented behaviour would kill this problem completely.
Quoted 4 lines
How can you deal with it if you have two boards supported by a single driver and, unfortunately, the one you need is detected as eth1 ? Assume that you cannot switch them as they use different media type...
Assuming your claim is correct, then the behaviour needs to be changed to comform to the documeted behaviour, so this should be reported as a bug - IMHO, that is.
Quoted 7 lines
Quoted 5 lines
With this change, it doesn't actually matter what port name a particular interface is given, because ALL of the other network config tools refer to the interface by its assigned IP address, not its port name. As a result, if its port name changes between boots, the routing automatically changes with it.
2. ipfwadm / ipchains / iptables may use interface names,
I've yet to use iptables, so can't comment on that. With both ipfwadm and ipchains, the ONLY ports I've ever had reason to explicitly name have always been either ppp+ to refer to the PPP link across the modem, or sl0 to refer to the AX.25 link to my ham radio stuff. As a result, I've never actually experienced a situation that would be affected by this.
However, it's not hard to write code to translate. How about hw2eth which is a BASH script to convert from a stated MAC address to the port that MAC is mapped to:
Q> ifconfig | grep ^eth | fgrep "HWaddr $1" | cut -d ' ' -f 1
How about ip2eth which is a BASH script to convert from the local IP address of the port the interface in question maps to to its port name:
Q> ifconfig | grep -B1 "inet addr:$1" | grep ^eth | cut -d ' ' -f 1
The other option, route2eth (a program to convert a particular remote IP address to the port name of the interface we would use to connect to it) involves analysing the output of route -n so would be rather better suited to a C (or other) compiled program. However, even this shouldn't be that hard for a competent programmer to produce.
Quoted 1 line
3. dhcpd may need interface names to be provided,
I have to admit that I've never used dhcpd, so am somewhat disadvantaged here. However, I would imagine that the scripts above would provide the necessary translations.
Quoted 1 line
4. you may want to pass an interface name argument to tcpdump.
Whenever I use tcpdump on a system with multiple NIC's, I always have to use ifconfig to remember which interface attaches to which network, and then use the interface determined from that. I would assume that others would tend to do the same, and in this case, this problem case vanishes.
Even if this wasn't the case, the scripts above should help to minimise the problems.
Quoted 3 lines
In 2.2+ you can deal with 2.-4. changing interface names using ip from iproute2. But I doubt whether ifconfig based scripts would work properly then.
You shouldn't need to fudge the issue like that anyway, and if you do, then the various tools need to be redesigned to provide simple ways round the problem.
Quoted 1 line
And problem 1. is still valid ...
So is the solution above.
Best wishes from Riley.
Quoted 7 lines · Riley Williams
At the moment, you are required to group these by whether the interface is static or hotplug, configuring all static interfaces before any of the hotplug ones. This therefore reduces to being either case (2) or (3) followed by case (4), and should be dealt with accordingly.
Quoted 6 lines
As a result, the ONLY time I can see any problem occurring is when there are multiple hotplug interfaces to deal with (case (4) above), and this is acknowledged to be a case where some of the issues have not yet been fully ironed out.
Can you agree with this analysis, or have I overlooked something?
That is, yes indeed, pretty much the proper analysis, and my situtation. My case can be summarized as one static interface, followed by two (and if we can get the firewire stuff working, soon potentially to be more) dynamic interfaces.
Signature · 2 lines
Mark Atwood | I'm wearing black only until I find something darker. [email protected] | http://www.pobox.com/~mra
Hi Mark.
Quoted 11 lines
Quoted 11 lines
At the moment, you are required to group these by whether the
interface is static or hotplug, configuring all static interfaces before any of the hotplug ones. This therefore reduces to being either case (2) or (3) followed by case (4), and should be dealt with accordingly.As a result, the ONLY time I can see any problem occurring is when there are multiple hotplug interfaces to deal with (case (4) above), and this is acknowledged to be a case where some of the issues have not yet been fully ironed out.
Quoted 6 lines
Quoted 1 line
Can you agree with this analysis, or have I overlooked something?
That is, yes indeed, pretty much the proper analysis, and my situtation. My case can be summarized as one static interface, followed by two (and if we can get the firewire stuff working, soon potentially to be more) dynamic interfaces.
As long as the static interface is configured as eth0 before any of the dynamic interfaces are looked at, it will remain fixed, and gets taken out of the equation as a result.
As I understand it, the PCMCIA interface does the equivalent of...
ifconfig eth1 down ; rmmod eth1
...when the interface on eth1 is unplugged, so the unplugging shouldn't be a problem. However, I've no idea what it does on plugging in a new interface, other than that is somehow signals the fact to the kernel.
I can't comment on firewall as I know zilch about it, sorry.
Best wishes from Riley.
(apologies for splitting my reply into multiple pieces, but each part
covers different territory).
Quoted 8 lines · Riley Williams
2. Multiple identical static interfaces.
At the moment, you are required to initialise the interfaces in ascending order of their name in the modules.conf file.
I've dealt with this situation on several occasions, and never found this to be a problem in any way.
Have you ever assembled a distribution that's going to be imaged into several thousands to several tens of thousands of hardware boxes, with evolving-into-the-future changes in hardware version and changes in component suppliers?
If Linux really wants to break into the appliance market, this is going to be a bigger and bigger issue.
Signature · 2 lines
Mark Atwood | I'm wearing black only until I find something darker. [email protected] | http://www.pobox.com/~mra
Hi Mark.
Quoted 8 lines
(apologies for splitting my reply into multiple pieces, but each part covers different territory).
Quoted 5 lines
2. Multiple identical static interfaces.
At the moment, you are required to initialise the interfaces in ascending order of their name in the modules.conf file.
Quoted 7 lines
Quoted 2 lines
I've dealt with this situation on several occasions, and never found this to be a problem in any way.
Have you ever assembled a distribution that's going to be imaged into several thousands to several tens of thousands of hardware boxes, with evolving-into-the-future changes in hardware version and changes in component suppliers?
I haven't personally, no, but RedHat, Caldera, SUSE, Debian and Eridani all have, and (curiously enough) they all use the same basic solution, although implemented in different ways. This is also the solution implemented by the ifmap script I attached to my previous email.
Quoted 2 lines
If Linux really wants to break into the appliance market, this is going to be a bigger and bigger issue.
Agreed, but then, it appears to be an issue that has largely been solved. The only part that may still need attention (I'm not up to date on it, so can't say for sure) is the hotplug stuff.
Best wishes from Riley.
"Riley Williams wrote:"
Quoted 3 lines
1. InitScripts points at Kernel ...
2. Kernel replies ...
3. InitScripts then tells Kernel ...
I believe this discussion leads to constructive conlusions. Even if that are 2.5+ conclusions.
Quoted 3 lines
So far, I've only seen the above scenario occur, and I have to admit to having very little sympathy with it. However, I'm always open to persuasion that the above is not the situation that is occurring.
[...]
Quoted 3 lines
Let's deal with the various scenarios that I can see:
1. Just one interface, either static or hotplug.
Nothing interesting.
Quoted 1 line
2. Multiple identical static interfaces.
Nothing interesting.
Quoted 1 line
3. Multiple different static interfaces.
I see some subcases here:
3a. All interfaces are initialized
3b. Not all interfaces are initialized
[ "interface physicaly exist" != "interface is connected/configured"
3c. Interfaces supported by single driver are identical
3d. Interfaces supported by single driver are significantly different
I thing one met some common problems with the hotplug case here in the above subcases.
Quoted 7 lines
At the moment, you are required to group these by the driver that controls them, simply because each driver will automatically map all interfaces that it supports when it is loaded. Likewise, you are required to initialise interfaces in ascending order of their name in the modules.conf file.
4. Multiple hotplug interfaces.
I thing this case and 3. case should be solved both: for the modular drivers case and for the built-in drivers case.
Quoted 5 lines
I have to admit to never having dealt with hotplug interfaces, but I understand some aspects of the interface are still being ironed out by the kernel developers. As a result, I would not be at all surprised to hear that problems still exist.
Quoted 7 lines
5. Multiple static and hotplug interfaces.
At the moment, you are required to group these by whether the interface is static or hotplug, configuring all static interfaces before any of the hotplug ones. This therefore reduces to being either case (2) or (3) followed by case (4), and should be dealt with accordingly.
Consider complex situation: you have two drivers, each of them supporting static and built in and hotplug interfaces.
Yes, this is a theoretical problem, but solving it would probably also solve all (or almost all) of the above cases.
I like the idea of assigning names by MAC addresses. It IMO should solve all problems as:
- if more then one interface has the same MAC address, they are probably identical, and you can switch them in hardware (cabling). Or am I wrong here?
- If you want to change the MAC address you do it *AFTER* the interface is initialized (driver is loaded, interface name is assigned). Or am I also wrong here?
This seem to be a good idea if there's also support for "ether=" like global kernel parameter working for build-in drivers.
Quoted 6 lines
As a result, the ONLY time I can see any problem occurring is when there are multiple hotplug interfaces to deal with (case (4) above), and this is acknowledged to be a case where some of the issues have not yet been fully ironed out.
Can you agree with this analysis, or have I overlooked something?
Andrzej
Signature · 4 lines
======================================================================= Andrzej M. Krzysztofowicz [email protected] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk
Hi again Andrzej.
Quoted 6 lines
Quoted 3 lines
1. InitScripts points at Kernel ...
2. Kernel replies ...
3. InitScripts then tells Kernel ...I believe this discussion leads to constructive conlusions. Even if that are 2.5+ conclusions.
So do I.
Quoted 7 lines
Quoted 7 lines
So far, I've only seen the above scenario occur, and I have to admit to having very little sympathy with it. However, I'm always open to persuasion that the above is not the situation that is occurring.
Let's deal with the various scenarios that I can see:
Quoted 7 lines
Quoted 1 line
1. Just one interface, either static or hotplug.
Nothing interesting.
Quoted 1 line
2. Multiple identical static interfaces.
Nothing interesting.
Agreed.
Quoted 5 lines
Quoted 1 line
3. Multiple different static interfaces.
I see some subcases here:
3a. All interfaces are initialized
This is the assumption used by all of the standard distributions (with the possible exception of Slackware, but I'd be surprised if they differ here).
Quoted 2 lines
3b. Not all interfaces are initialized
"interface physicaly exist" != "interface is connected/configured"
This is definitely a problem case, as it leads to all sorts of race scenarios. Even Microsoft don't support this case with their operating systems.
Quoted 3 lines
3c. Interfaces supported by single driver are identical
3d. Interfaces supported by single driver are significantly different
With static interfaces, the difference between these two subcases is in theory irrelevant.
Quoted 2 lines
I thing one met some common problems with the hotplug case here in the above subcases.
Can I point out that this section specifically refers to STATIC (ie, non-hotplug) interfaces. This comment is therefore irrelevant here.
Quoted 10 lines
Quoted 7 lines
At the moment, you are required to group these by the driver that controls them, simply because each driver will automatically map all interfaces that it supports when it is loaded. Likewise, you are required to initialise interfaces in ascending order of their name in the modules.conf file.
4. Multiple hotplug interfaces.
I thing this case and 3. case should be solved both: for the modular drivers case and for the built-in drivers case.
Case (3) is already solved. Case (4) is the only one that needs solving, and that's still under development with various other problems to be solved as well.
Quoted 13 lines
Quoted 5 lines
I have to admit to never having dealt with hotplug interfaces, but I understand some aspects of the interface are still being ironed out by the kernel developers. As a result, I would not be at all surprised to hear that problems still exist.
Quoted 7 lines
5. Multiple static and hotplug interfaces.
At the moment, you are required to group these by whether the interface is static or hotplug, configuring all static interfaces before any of the hotplug ones. This therefore reduces to being either case (2) or (3) followed by case (4), and should be dealt with accordingly.
Quoted 4 lines
Consider complex situation: you have two drivers, each of them supporting static and built in and hotplug interfaces. Yes, this is a theoretical problem, but solving it would probably also solve all (or almost all) of the above cases.
All drivers already support both static (which is built-in) and hotplug interfaces, so that gains us nothing. All that changes in the hotplug case is that the hotplug bus controller signals the kernel to say either...
1. "The device that was in my slot N has been unplugged", in which case the kernel unmaps the driver for that device, or
2. "A new device has been plugged into my slot N", in which case the kernel works out what sort of device it is, then waits for some sort of configuration information.
As a result, most of the problems I've seen mentioned just can't occur.
Quoted 6 lines
I like the idea of assigning names by MAC addresses. It IMO should solve all problems as:
- if more then one interface has the same MAC address, they are probably identical, and you can switch them in hardware (cabling). Or am I wrong here?
According to Alan Cox, it's only the ix86 architecture where the MAC is per interface; on all other architectures, it's one MAC per system that is shared by all the ethernet interfaces. As a result, there is no guarantee that they are identical, or even similar.
Quoted 3 lines
- If you want to change the MAC address you do it *AFTER* the interface is initialized (driver is loaded, interface name is assigned). Or am I also wrong here?
I have no idea, and would not assume either way.
Quoted 2 lines
This seem to be a good idea if there's also support for "ether=" like global kernel parameter working for build-in drivers.
I have to agree that this may be a good idea for the ix86 architecture, but not for other architectures because of that limitation. However, this may be something that has to be solved on a per-architecture basis.
Quoted 6 lines
Quoted 6 lines
As a result, the ONLY time I can see any problem occurring is when there are multiple hotplug interfaces to deal with (case (4) above), and this is acknowledged to be a case where some of the issues have not yet been fully ironed out.
Can you agree with this analysis, or have I overlooked something?
Best wishes from Riley.
One point to remind people of here. You can runtime rename interfaces. Almost all the needed kernel infrastructure is there already.
Alan
Riley Williams <[email protected]> said:
[...]
Quoted 4 lines
According to Alan Cox, it's only the ix86 architecture where the MAC is per interface; on all other architectures, it's one MAC per system that is shared by all the ethernet interfaces. As a result, there is no guarantee that they are identical, or even similar.
On Sun all NICs of a machine by default share the same MAC (and you can change them individually at will, BTW). Other machines I've come across aren't this way. But there are several NICs around (even seen them on PCs, don't remember which ones, sorry) where you can change the MAC at will, and the change sticks IIRC.
If you look at how Ethernet works, it is clear that the MAC has to be unique on its network segment only, making it globally unique is simple, but way overkill.
Quoted 6 lines · Mark Atwood
Userspace init scripts point the finger at kernel, saying "there is no good and no well documented mapping method". Kernel points its finger at userspace, saying "this is the way we do it" and "we cant guarantee a perfect 100% mapping solution, so we're not even going to try for 90%" and "futz with your drivers and modules.conf and init scripts till you get something that works".
I'm working on one a possible solution, the Device Registry (www.tjansen.de/devreg). It solves this problem by assigning device ids to physical devices. This allows you to identify a physical device, even after you changed tge port.
Device ids can be used in two ways:
1. user space apps can use the device id to find the device's node in /dev
2. a user-space daemon can use the device ids to create stable symlinks to the /dev nodes (this is not possible to ethernet ids though)
bye...
Quoted 9 lines · Tim Jansen
Quoted 6 lines · Mark Atwood
Userspace init scripts point the finger at kernel, saying "there is no good and no well documented mapping method". Kernel points its finger at userspace, saying "this is the way we do it" and "we cant guarantee a perfect 100% mapping solution, so we're not even going to try for 90%" and "futz with your drivers and modules.conf and init scripts till you get something that works".
Quoted 4 lines
I'm working on one a possible solution, the Device Registry (www.tjansen.de/devreg). It solves this problem by assigning device ids to physical devices. This allows you to identify a physical device, even after you changed tge port.
Sounds interestingly like the solaris solution to the problem, /etc/path_to_inst.
Thanks,
Josh
Quoted 4 lines · Riley Williams
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulip
You have six drivers loaded, when you only need three (i.e. io=0x340,0x320,0x2c0 for ne options etc. etc). So you end up wasting some memory, and a worse icache behaviour as well. (the latter is probably a non-issue if you are happy with ISA)
Paul.
Hi Paul.
Quoted 14 lines
Quoted 4 lines
One of my systems has SIX ethernet cards, these being three ISA and two PCI NE2000 clones and a DEC Tulip. Here's the relevant section of modules.conf on the system in question:
Quoted 9 lines
Q> alias eth0 ne
Q> options eth0 io=0x340
Q> alias eth1 ne
Q> options eth1 io=0x320
Q> alias eth2 ne
Q> options eth2 io=0x2c0
Q> alias eth3 ne2k-pci
Q> alias eth4 ne2k-pci
Q> alias eth5 tulip
Quoted 3 lines
You have six drivers loaded, when you only need three (i.e. io=0x340,0x320,0x2c0 for ne options etc. etc). So you end up wasting some memory, and a worse icache behaviour as well.
Are you sure of this? My understanding (both from reading the code and from what others I respect have said) is that it is impossible to load any given module more than once, so the above will result in one copy each of the ne, ne2k-pci and tulip drivers being loaded.
Quoted 1 line
(the latter is probably a non-issue if you are happy with ISA)
It's not so much a case of being "happy with ISA" as of needing six interfaces on the same box, and it only has the three PCI slots...
Best wishes from Riley.
Quoted 9 lines · Riley Williams
Quoted 4 lines
You have six drivers loaded, when you only need three (i.e. io=0x340,0x320,0x2c0 for ne options etc. etc). So you end up wasting some memory, and a worse icache behaviour as well.
Are you sure of this? My understanding (both from reading the code and from what others I respect have said) is that it is impossible to load any given module more than once, so the above will result in one copy each of the ne, ne2k-pci and tulip drivers being loaded.
Here is an example of what I was talking about:
# insmod wd -o wd0 io=0x280 irq=10 # insmod wd -o wd1 io=0x680 irq=3 # insmod wd -o wd2 io=0xa80 irq=4 # insmod wd -o wd3 io=0xe80 irq=9 # cat /proc/modules wd3 2 0 wd2 2 0 wd1 2 0 wd0 2 0 8390 2 [wd3 wd2 wd1 wd0] 0 # rmmod wd3 wd2 wd1 wd0 # # insmod wd io=0x280,0x680,0xa80,0xe80 irq=10,3,4,9 # cat /proc/modules wd 2 0 8390 2 [wd] 0 #
The 1st way (4 copies of the driver present) will work, but is not as efficient as the 2nd way (one copy present).
[Don't look too hard at the I/O addresses or you will realize there was only one card in this particular machine anyway...]
Paul.
How to tell how much to expect from a fd
In reply to Chris WedgwoodDoes there exist a fcntl or some other way to tell how much data is "ready to be read" from a fd?
I'm doing this thing where I make the fd non-blocking, select on it, and then read on it into a buffer that I am pregrowing with realloc.
When the high water mark is up to the top of the buffer, I realloc the buffer to make it bigger. At present, I'm just adding a constant value to the buffer size each time I need to do this, but if there was a way to easily tell how much was "ready to be read" from the fd.
It's not necessary to be exact. If more becomes available between the time I do this wanted magic and do the read, read's 3rd parameter will keep me safe, and if it's too low, like if a dup of the fd already snarfed the data, also no big deal, I'm non-blocking and check the return value.
So, is this "nice to have" available?
Signature · 2 lines
Mark Atwood | Well done is better than well said. [email protected] | http://www.pobox.com/~mra
Re: How to tell how much to expect from a fd
Quoted 2 lines · Mark Atwood
Does there exist a fcntl or some other way to tell how much data is "ready to be read" from a fd?
int val;ioctl(fd, FIONREAD, &val);
See tcp(7).
Eric
Re: How to tell how much to expect from a fd
In reply to Mark AtwoodQuoted 12 lines · Mark Atwood
Does there exist a fcntl or some other way to tell how much data is "ready to be read" from a fd?
I'm doing this thing where I make the fd non-blocking, select on it, and then read on it into a buffer that I am pregrowing with realloc.
When the high water mark is up to the top of the buffer, I realloc the buffer to make it bigger. At present, I'm just adding a constant value to the buffer size each time I need to do this, but if there was a way to easily tell how much was "ready to be read" from the fd.
Quoted 7 lines
It's not necessary to be exact. If more becomes available between the time I do this wanted magic and do the read, read's 3rd parameter will keep me safe, and if it's too low, like if a dup of the fd already snarfed the data, also no big deal, I'm non-blocking and check the return value.
So, is this "nice to have" available?
It is possible that you are the one-in-a-million case that really needs
this, but the vast majority of the time people ask for this, they don't really want it.
Consider two very important points:
First, by the time you get this information, it's obsolete. If more data
becomes available in-between when you make this call and when you attempt to read, you'll take a double penalty. You'll need an extra 'read' later to get the rest and your next poll/select will break out immediately (which can be very expensive if you're dealing with a large number of fds).
Second, this would double the number of system calls you need to read the
data from the socket. There's almost no conceivable scenario in which it's worth the cost of doing this when you can either keep a buffer that's a bit too large around or copy it into a right-sized buffer and you can choose which option after you know how many bytes you got.
DS
On Fri, Aug 03, 2001 at 06:32:18PM -0700, Thomas Duffy wrote:
so, what happens when you have two eth cards that use the same module? in the isa land, the order you pass the io=0x300,0x240 would determine which order the eth?'s go to...how about in the pci world?
when the pci module loads, it find all devices and registers them
--cw
It's pretty simple. If you have no special options to pass to the module:
alias eth0 modulename
(example for 3C905B-TX: alias eth0 3c90x)
Quoted 8 lines · Mark Atwood
I'm trying to figure out how "alias ethX" works in
/etc/modules.confIs it some "magic" in depmod / modprobe? And how is the network interface identifier then passed into the module when it loads?
A nice whitepaper or doc or a few pointers or handholding would be apprecated.
It's a little simpler now.
Under 2.2 and 2.4, I have gotten away with doing the following (assuming the module does not require a port address or irq):
alias eth0 modulename
alias eth1 modulename
This assumes the kernel sees both cards (look in your kernel ring log, typically /var/log/dmesg). If the entries are both there for eth0 and eth1 and irq and port addresses are correct, you're ready to go. I have had no problems with DLink DE220s for example (NE2000 clones).
If it does not see the 2nd card (eth1), then go for something like "ether=0,0,eth1" in at the boot prompt (use the append option for LILO to make it permanent if you're using LILO). If that does not work, then provide "ether=11,0x300,eth1" (example of IRQ11, IO address 300 hex). The man page on bootparam will explain a little further.
The above was sometimes necessary for ISA, but the PCI world should require less intervention.
Quoted 18 lines · Thomas Duffy
Quoted 3 lines · Chris Wedgwood
the kernel calls modprobe asking for the network device 'eth0', modprobe uses the configuration file to map this to a module
so, what happens when you have two eth cards that use the same module? in the isa land, the order you pass the io=0x300,0x240 would determine which order the eth?'s go to...how about in the pci world?
(quoted diff) +0
-2-tduffy -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It's pretty simple. If you have no special options to pass to the module:
alias eth0 modulename
(example for 3C905B-TX: alias eth0 3c90x)
Quoted 8 lines · Mark Atwood
I'm trying to figure out how "alias ethX" works in
/etc/modules.confIs it some "magic" in depmod / modprobe? And how is the network interface identifier then passed into the module when it loads?
A nice whitepaper or doc or a few pointers or handholding would be apprecated.
How to hack a network driver to use a specific ethX (was Re: How does "alias ethX drivername" in modules.conf work?)
In reply to Mark AtwoodQuoted 10 lines · Tim Jansen
Quoted 3 lines · Mark Atwood
I'm trying to figure out how "alias ethX" works in
/etc/modules.confIs it some "magic" in depmod / modprobe? And how is the network interface identifier then passed into the module when it loads?If some user-space app accesses ethX the kernel calls "
/sbin/modprobeethX". The alias in/etc/modules.confjust gives ethX the name of the real module. The interface identifier isn't passed to the module, you have to initialize your interfaces in the right order (or set it using an option for modprobe, but I don't whether any drivers support setting the interface identifier).
Are their any examples of drivers that can set the interface identifier?
If it possible that a driver may do so, does that mean that the kernel can handle interface identifiers being set "out of order"?
My problem stems the following situation:
eth0 is an "ordinary" PCI hme ethernet device. That works just fine.
eth1 is a weird device that is still under hardware development,
and, depending on the phase of the moon and the favor of the Gods, sometimes comes up and sometimes doesnt
there is a line in /etc/modules that looks like
alias eth1 weirddevice
eth2 is to be a hot plugged PCMCIA ethernet device
In the cases when "weirddevice" properly comes up, I can
see it's driver in lsmod,
see it's interface in ifconfig as eth1,
and then when I plug in the PCMCIA card
it gets eth2, and works fine
In the cases when "weirddevice" doesnt come up, I can
still see it's driver in lsmod
but it's marked "(unused)"
dont see it in ifconfig
and then when I plug in the PCMCIA card
it gets eth1,
i can see the module driver in lsmod
i can see the interface in eth1
BUT
it doesnt work, and the cardmgr error log says that cardmgr keeps trying to reset the card to make it work
I suspect that the cardmgr is loading the correct card driver module, but then some sort of argument is happening under the hood, as the card driver knows that it registered eth1, but the modules.conf has the "alias eth1 weirddevice" line.
I'm feeling that the easiest way to make my headache go away is be able to somehow insist to each network driver "YOU go in eth1, no matter what, and YOU go in eth2, no matter if their is a eth1 or not".
I cannot do this by MAC address, because I have a small herd of these boxes, with different MACs for each interface in each box, and, if my employers dreams come true, there will soon enough be hundreds and then thousands of these boxes.
If it's not too terribly hard to modify a network driver to go to an interface specified as a module option, I can probably hack that into the module drivers (I do have the source to them, thank gods.)
Signature · 2 lines
Mark Atwood | I'm wearing black only until I find something darker. [email protected] | http://www.pobox.com/~mra