Using any network interface whatsoever
From mailing list archives: I wrote some add-on bits for /etc/rc.network in 4.x that compares the link addresses of attached network interfaces to a list of link addresses, then sets ifconfig_ifN* variables accordingly before rc.network does anything. It provides a means of wiring IP addresses to physical ports in a way that gets around the problem of probe order. If there's interest, I'll get to work on an rcNG version. I would be interested in seeing this. I build custom machines for a company I work for, and one of our requirements is the ability to number the network ports. End users configure our software based on which port they use, so we need steady numbering of the ports, even when one customer machine might have different cards and number of cards. We basically want the order to be: 0-N motherboard ports N+1 - M card ports It sounds like your script might work, given the apparent absence of geographic mapping in most current systems. Thanks for any help. -- Where some they sell their dreams for small desires. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sun, Apr 09, 2006 at 06:48:25PM -0600, M. Warner Losh wrote: I though thtis was already supported. We export bus/slot/function information devd, which can be used to configure the device. If I've read the specs or code incorrectly please do let me know -- my reading here is based on the PCI code as I understand it to be. As I understand things, the bus/slot/function numbers in pci(9), the *slot* number isn't guaranteed to have any meaning in geographic reality; it's purely what the PCI logic thinks the bus topology looks like and hence what the device numbers are. See BUGS in pci(9). It won't tell you that a given card is in a given slot with any degree of certainty or consistency across the range of backplanes available from multiple vendors -- although people may like to give PICMG a try as I hear such boards are consistent about such things. In the old Microsoft-specified $PIR tables there was a column which allowed you to map the bus/device/function tuple we use to a physical slot number, but this only ran 1-6. With multiple PCI buses and slot types, as well as multifunction devices, this information quickly became unusable and unreliable, although src/tools/tools/pirtool will happily display this information. ACPI as you no doubt know does away with the $PIR tables, although many BIOS still export them to allow legacy DOS programs which use PCI to work. There is an extension to ACPI which adds geographical slot addressing to the device tree but I haven't seen any systems which support it. Regards, BMS P.S. I have some notes somewhere about the ACPI geog stuff but can't remember if I posted them or filed them elsewhere -- check the XORP mailing lists, I think we bashed this out there around 14 months ago. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : On Sun, Apr 09, 2006 at 06:48:25PM -0600, M. Warner Losh wrote: : I though thtis was already supported. We export bus/slot/function : information devd, which can be used to configure the device. : : If I've read the specs or code incorrectly please do let me know -- : my reading here is based on the PCI code as I understand it to be. : : As I understand things, the bus/slot/function numbers in pci(9), the : *slot* number isn't guaranteed to have any meaning in geographic reality; : it's purely what the PCI logic thinks the bus topology looks like and : hence what the device numbers are. See BUGS in pci(9). The device number is fixed for a given mother board slot. It will never change unless you change the mother board. However, for stacking topologies the slot is the position in the stack. : It won't tell you that a given card is in a given slot with any degree : of certainty or consistency across the range of backplanes available : from multiple vendors -- although people may like to give PICMG a try : as I hear such boards are consistent about such things. Correct. : In the old Microsoft-specified $PIR tables there was a column which : allowed you to map the bus/device/function tuple we use to a physical : slot number, but this only ran 1-6. With multiple PCI buses and slot : types, as well as multifunction devices, this information quickly became : unusable and unreliable, although src/tools/tools/pirtool will happily : display this information. Correct. : ACPI as you no doubt know does away with the $PIR tables, although many : BIOS still export them to allow legacy DOS programs which use PCI to work. : There is an extension to ACPI which adds geographical slot addressing : to the device tree but I haven't seen any systems which support it. OK. Physical slot information. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
I think at this point it's been pretty well established that: - Device naming and unit numbering is not stable enough to avoid breakage across hardware changes. - There is a need for generic and/or descriptive interface naming independent of driver- and probe-order-based naming. - There are static bits of information available about each device in the system that can be used to locate a specific device that would be sufficient to allow assignment of a network configuration to a physical device, not it's attached name. If I were to write an rc.d script to use descriptive network interface names and wire configs to static hardware identification, would there be support for such a feature? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Apr 10, 2006, at 2:23 PM, Darren Pilgrim wrote: I think at this point it's been pretty well established that: - Device naming and unit numbering is not stable enough to avoid breakage across hardware changes. - There is a need for generic and/or descriptive interface naming independent of driver- and probe-order-based naming. - There are static bits of information available about each device in the system that can be used to locate a specific device that would be sufficient to allow assignment of a network configuration to a physical device, not it's attached name. If I were to write an rc.d script to use descriptive network interface names and wire configs to static hardware identification, would there be support for such a feature? Being mostly a lurker on this list I don't know that my vote would count for much, but yes I'd support such a feature. Thank you also for outlining the issues for this thread in a simple manner. -- Joseph Scott [EMAIL PROTECTED] http://joseph.randomnetworks.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer wrote: In [EMAIL PROTECTED], Daniel Rock [EMAIL PROTECTED] typed: So I doubt that the overwriting of an Ingres database really happened in Solaris, like some other poster described - unless the administrator fiddled with /etc/path_to_inst by hand (you are free to shoot in your own foot). That happened very early in the life of Solaris, in the early 90s. Persistent numbering was added to Solaris in response to this incident (there were probably others as well). This was on a relatively large server, with something like 4 SCSI buses. A drive was added to a previously unused bus, making it appear between two drives that were already in the system. This gave all the drives further on in the probe sequence a device number one higher than they had previously had. It sounds for me as if you (Mike Meyer) are asking for something like 'acpidump -d' or 'pciconf -l -v' output, but translated into a filesystem abstraction -- ie a tree of directories corresponding to different busses containing device files ordered according to the bus slot they are plugged into. This would be something that you can use either in place of the traditional /dev or as an adjunct to it. I believe Solaris has a /devices tree which does essentially this. In practice however on the systems we deploy we know that the principal network interfaces are the ones on-board the motherboard, and we know that em0 or bge0 is the one closest to the PSU. Similarly for other devices -- disk device numbers can be deduced from the physical slot they are in. Sure it's just a convention, and it helps that the equipment supplier we use is very consistent about such things, and that in general we don't go around plugging USB disk devices into server systems that frequently. But on the whole it works. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Using any network interface whatsoever
Mike, Tell me about it, I know exactly what you mean! On Sat, Apr 08, 2006 at 06:53:11PM -0400, Mike Meyer wrote: My question about labels for ethernet devices wasn't meant to be rhetorical. Ethernet device names on Unix are pretty much worthless. They tell you basically nothing about which device you've got. On FreeBSD, different card types have different names, which is better than nothing - but that's about all it's better than. We need something akin to labels for ethernet devices. The LAN it's plugged into is the equivalent of the data on the disk - but there's no equivalent for the label. What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. I investigated this problem when doing research on XORP. The behaviour you describe is a functional requirement for a router chassis. What it really comes down to is that one needs a PCI variant which supports what's known as 'geographical addressing', and for FreeBSD's device / ifnet framework to support naming cards according to the geographic i.e. physical address. If you look at the very bottom of the man page pci(9) you'll see I've left a footnote about this. Unfortunately the only systems which tend to implement this feature at the moment are CompactPCI based chassis systems. Although there is support for geographical addressing in a recent ACPI spec but as far as I know it may only really have made its way into blade systems. Hope this helps. Regards, BMS P.S. If etiquette were taken more seriously then society as a whole might function better -- I think of it as part of the 'operating system' of the human spirit! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sat, Apr 08, 2006 at 05:42:13PM -0600, Scott Long wrote: Ceri Davies wrote: On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri I'll say again, how does having em0, em1, em2, and em3 help me know what is going on with each of those interfaces? Well it doesn't, but there is no way for the OS vendor to determine what you're doing. You're more than able to rename them to dmz0, world0 or whatever in order to reflect their real usage if you like. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpxxaANSPXAI.pgp Description: PGP signature
Re: Using any network interface whatsoever
eth0 works well for the degenerate case where there's a network card in the system, and nothing else. It works less well for systmes where there are more than one card, and where the hardware changes a lot for all the reasons discussed in this thread. It is too generic. Of course, when you have N copies of the same card on FreeBSD, it is as degenerate as ethN is. You can use devd right now to tie the device instance to a configuration using bus topology. That information is available to the devd script that's forked. However, experiments in doing that work only so long as chaning one card doesn't change the hardware topology of the other cards. For single-banger NICs, it won't. However, when you have multi-port NIC cards that are a bunch of individual chips behind a PCI bridge, the PCI bus numbers that they live on change as you insert/remove these multi-port NIC cards, so hardware topology fails you. Then you might think of tying the MAC address to an IP address/configuration. This works well in the above scenario since you can now remove cards that change topology. However, when you replace a defective card with another, you need to reconfigure because the MAC address changes. I've actually run into all of these problems on a machine we have at work that acts as a gateway to about 10-20 private networks. It has had between 2-4 dual cards and 2-4 quad cards, in various mix and match flavors over the years. We've replaced dual fxp cards with quad de cards that were replaced with quad dc cards, etc. Pairs of dual cards were replaced with a quad card at times. We've run a single fxp card in place of a failed quad fxp card for a few days too. The mobo has been replaced a few times as well, which also changes bus topology, as well as introduces new built-in NIC cards. The only solution that works for us has been to carefully desk check the results of each hardware change after the system has been rebooted. After the desk check, a ping of systems ensures that nothing has fallen through the cracks (usually). If there's a way that we can manage this chaotic system better, I'd love to hear about it. Warner P.S. There's conflicting netequite about what I should do with a long thread. some folks say quote the whole thing, others say quote tiny bits. I've decided to offend both camps by quoting nothing :-). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: [Tying names to MAC addresses.] That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. If you tie the name to the MAC address, you always have to change that part of the config. If you tie the name to the current name, then you only have to change it if you change drivers. Within the currently available capabilities, we get the network interface equivalent of disk volume labels. Not quite. With volume labels, I can arrange to keep a replicated drive with the same volume label, and can plug it in if the old drive fails without changing a single line of system configuration. Using the MAC address as the key requires that you reconfigure the name mapping (unless you have cards that let you change the MAC address, though I have no idea if those exist for any platform that FreeBSD runs on). [ Proposed use of PCI addresses instead of MAC addresses. ] The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. Right, it doesn't scale to ISA or USB devices. The prior probably isn't a big deal these days, but I imagine compatibility with USB devices is fairly important. From what Warner Losh posted (thanks for some hard data, Warner), the PCI address isn't fixed, though you're less likely to run into it moving. And Bruce Simpson (thanks Bruce) tells us that the solution I want - names based on slot addresses - is only available on some hardware, at least for now. There's no reason we can't extend your basic solution to handle configuration by either driver/number or MAC address, allowing the user to pick the properties they want for their names. Of course, this doesn't help the OP's problem of wanting to be able to address the sole interface in a system without knowing it's name in advance. Maybe a feature to provide a default name for an interface if one isn't found in the config file would do that. BTW, I'd like to point out that sound cards have the same problem, only they all get the same driver name. Worse yet, the numbering can change between reboots (at least, it could on 4.x). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sun, 2006-Apr-09 09:58:19 -0600, M. Warner Losh wrote: I've actually run into all of these problems on a machine we have at work that acts as a gateway to about 10-20 private networks. It has had between 2-4 dual cards and 2-4 quad cards, in various mix and match flavors over the years. We have several machines (for redundancy) that act as gateways into over 40 private networks. When there were only 4 networks, we used multiple NICs but decided this approach wasn't expandable and we now use VLAN trunks and break out the different networks within the switches. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Using any network interface whatsoever
From: Mike Meyer In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Youre' saying that instead of /dev/da0, we should have /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0 That's a ridiculous extreme. All I advocated was that we be able to easily identify the devices connected to the system, *not* that we be able identify every device in the world. Sun solved disk device naming back in the 80s. I think this is a problem consisting of multiple parts: 1. Identify physical devices and be able to access them. 2. Identify some stable logical names by device type, that stay fixed when the configuration changes. 3. Be able to find the mapping easily between these two. 4. Be able to change that mapping. USB is probably the subsystem that has a particular need in this kind of stuff. So, since we have devfs nowadays, why don't we just have multiple names (dev files) for the same device? For example, the same device can be named by driver aha0b0t0d0 and by logical type disk0. The 3rd part can be solved by using symlinks in devfs: i.e. disk0 would be a symlink to aha0b0t0d0, and you can do ls and find out what is linked to what. The 4th part can be solved by allowing the sysadmin to create symlinks in devfs. The network driver subsystem would obviously have to be changed to consult devfs for the device names. The next interesting question is how to keep these links persistent between boots. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. It wouldn't be too difficult to extend the configuration to allow entries like this: Interface0_addr=MAC 01:23:45:67:89:ab Interface1_addr=PCI 0:1:2 # pci0, device 1, function 2 Interface2_addr=USB 0:1:2 # usb0, addr 1, port 2 Add some bits to grok dmesg or pciconf/usbdevs or maybe even trigger from devd and there you go. I should mention that the second and third options could be broken by the addition or removal of a card with a PCI bridge or USB root hub on it. Of course, this doesn't help the OP's problem of wanting to be able to address the sole interface in a system without knowing it's name in advance. Maybe a feature to provide a default name for an interface if one isn't found in the config file would do that. # ifconfig `ifconfig -l link` name GenericName ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Using any network interface whatsoever (solution?)
From: Mike Meyer In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. If you tie the name to the MAC address, you always Nope, there is more than one goal. Sometimes you want to tie the device name to the slot, so that you can change the cards seamlessly. Sometimes you want to tie the device name to the card, so that you can move the card around between the slots (this is especially true for USB where you can change the topology very easily). I think the better solution is to let the administrator decide which particular way of tying the names he wants to use for a particular card. (And maybe make some reasonable guess by default, maybe depending on the device type). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : What it really comes down to is that one needs a PCI variant which supports : what's known as 'geographical addressing', and for FreeBSD's device / ifnet : framework to support naming cards according to the geographic i.e. physical : address. I though thtis was already supported. We export bus/slot/function information devd, which can be used to configure the device. : Unfortunately the only systems which tend to implement this feature at : the moment are CompactPCI based chassis systems. Although there is support : for geographical addressing in a recent ACPI spec but as far as I know : it may only really have made its way into blade systems. How is this different than bus/slot/function? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : Of course, this doesn't help the OP's problem of wanting to be able to : address the sole interface in a system without knowing it's name in : advance. Maybe a feature to provide a default name for an interface if : one isn't found in the config file would do that. ifconfig_DEFAULT already handles that. If you have only one interface, it will use the default, no matter which interface you install. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : Mike Meyer wrote: : In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: : You could test two different drivers on the same hardware and you wouldn't : have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: : : Yup, and this is an advantage. On the other hand, if you tie the : device name to the slot number (the real goal), you can swap different : hardware into that slot without having to modify any configuration : information at all. : : It wouldn't be too difficult to extend the configuration to allow entries : like this: : : Interface0_addr=MAC 01:23:45:67:89:ab : Interface1_addr=PCI 0:1:2 # pci0, device 1, function 2 : Interface2_addr=USB 0:1:2 # usb0, addr 1, port 2 : : Add some bits to grok dmesg or pciconf/usbdevs or maybe even trigger from : devd and there you go. : : I should mention that the second and third options could be broken by the : addition or removal of a card with a PCI bridge or USB root hub on it. The device subsystem already exports a bus-dependent plug and play position. No need to make it specific to USB/PCI/whatever. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
M. Warner Losh wrote: The device subsystem already exports a bus-dependent plug and play position. No need to make it specific to USB/PCI/whatever. Where is this information found? I can't find anything obvious that wouldn't change if you inserted a bus in the middle of the probe order. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In message: [EMAIL PROTECTED]
Darren Pilgrim [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: The device subsystem already exports a bus-dependent plug and play
: position. No need to make it specific to USB/PCI/whatever.
:
: Where is this information found? I can't find anything obvious that
: wouldn't change if you inserted a bus in the middle of the probe order.
I was replying to the position stuff that was proposed as a way to
find something. I was saying that you don't need to invent special
locators, since all busses are required to provide them.
For example:
% devinfo -v | grep fxp0
fxp0 pnpinfo vendor=0x8086 device=0x103d subvendor=0x104d
subdevice=0x8140 class=0x02 at slot=8 function=0 handle=\_SB_.PCI0.PCIB.LANC
You'd write the devd rule like:
attach 10 {
match slot 8;
match function 0;
action configure-network $device-name;
};
This is technically independent of the bus, since the bus isn't
exported (it should be). I'm told that some machines have multiple
pci domains, so bus number isn't unique. devinfo(8) should provide a
way to get this information as well, but it currently makes that kinda
hard (you could parse out the parent device name).
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Ceri Davies wrote: On Fri, Apr 07, 2006 at 03:57:42PM -0700, Brooks Davis wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: I'm trying to configure a bootable image to be used in various situations and on various (mostly unknown) hardware. For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT Superb, thank you! If you have non-Ethernet-like interfaces compiled in, you will probably want create empty ifconfig_if variables for them since DHCP won't work very well there. :) Good point, thanks again :) Ceri Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Because Unix has always made the hardware details available to administrators. Times have changed so that users now need to do things that used to be restricted to administrators. This historical behavior is a *good* thing. If all devices of type foo are just named foo and assigned numbers by the system, then I have no control over the names. If I don't care which is which, this isn't a problem. If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. Real world examples of this type of breakage include a FreeBSD 4.x system with SCSI disks that failed to boot when a USB mass storage device was plugged into it, and a Solaris system that started swapping on it's Ingres raw database partition after a disk was added. If a system is meant for desktop use where you typically have at most one of anything, then hiding the names from the users is a good thing. In a server environment, where you may have multiple instances of several different device types, then being able to easily tell which is which is a good thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer wrote: In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Because Unix has always made the hardware details available to administrators. Times have changed so that users now need to do things that used to be restricted to administrators. This historical behavior is a *good* thing. If all devices of type foo are just named foo and assigned numbers by the system, then I have no control over the names. If I don't care which is which, this isn't a problem. If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. Real world examples of this type of breakage include a FreeBSD 4.x system with SCSI disks that failed to boot when a USB mass storage device was plugged into it, and a Solaris system that started swapping on it's Ingres raw database partition after a disk was added. If a system is meant for desktop use where you typically have at most one of anything, then hiding the names from the users is a good thing. In a server environment, where you may have multiple instances of several different device types, then being able to easily tell which is which is a good thing. mike You're argument here doesn't really make sense. Youre' saying that instead of /dev/da0, we should have /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0, and instead of em0, it should be em0-192.168.254.199-24-192.168.254.1-192.168.254.255, right? That way all the information is present and there is no chance of mixing up devices. I'm not saying that we should get rid of the device information. I'm fully happy making it available to top layer applications. Administrators definitely need the information to make good decisions. But the information isn't always needed, and it does make simple management tasks harder. It also adds complexity that can lead to problems. Why when I add a RAID driver do I also need to hack up sysinstall so that it'll recognise the RAID devices? This is 2006, not 1976! The computer should be helping us in administration tasks, not hiding behind inconsistent and obscure names. Now, for your specific case of SCSI, it is possible to wire down device assignments by the administrator. It's been documented how to do this in man pages and kernel config files, most recently by me personally, for years. The flaw is that it still requires specific operator intervention to make work. That's where things like volume labels come in. Does a sysadmin care about the low-level device name for a drive on a Windows or Mac system? Does he even know without taking a deep look inside the system? Does not knowing it make it any less possible to easily and reliable manage and control the hardware? It's all done through human-readable labels that are easy to work with. The low level information is still available when needed, but it's not the primary means of control. I think that's fine; it strikes the balance between control and ease of use that I'm looking for. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Please trim the text you are repling to. You're argument here doesn't really make sense. Only because you're carrying it to ridiculous extremes and misinterpreting it. Youre' saying that instead of /dev/da0, we should have /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0 That's a ridiculous extreme. All I advocated was that we be able to easily identify the devices connected to the system, *not* that we be able identify every device in the world. Sun solved disk device naming back in the 80s. and instead of em0, it should be em0-192.168.254.199-24-192.168.254.1-192.168.254.255, right? This is a misinterpretation, because you're including system configuration information (the network it's attached to) in the device description. I'm not aware of a good solution to this problem for ethernet devices. I'm not saying that we should get rid of the device information. I'm fully happy making it available to top layer applications. Administrators definitely need the information to make good decisions. But the information isn't always needed, and it does make simple management tasks harder. I think I said that. It also adds complexity that can lead to problems. Why when I add a RAID driver do I also need to hack up sysinstall so that it'll recognise the RAID devices? Missing features in sysinstall would seem to be irrelevant. The computer should be helping us in administration tasks, not hiding behind inconsistent and obscure names. All names are obscure when you don't know what they mean. And once you know what they mean, they aren't obscure any more. Which doesn't mean the computer can't help us deal with things. The current BSD device naming and management schemes date back to at least v6. Updating them to deal with modern conditions, as opposed to those that were prevelant in the 70s, is certainly a reasonable thing to suggest. But the Linux solution of smashing all the devices of the same basic type into one flat undistinguished namespace is *not* an improvement. Now, for your specific case of SCSI, it is possible to wire down device assignments by the administrator. It's been documented how to do this in man pages and kernel config files, most recently by me personally, for years. I know. I figured all this out and documented it when it happened to me years ago (I did say it was a 4.x system). It's still a suprise when adding new hardware breaks the configuration of old hardware on a system as reliable as Unix usually is. I expect that from Windows, but not Unix. The flaw is that it still requires specific operator intervention to make work. That's the flaw, all right. The *problem* is that the system was trying to be user-friendly in ill-considered ways. Again, this is the kind of problem I expect to run into with Windows, not Unix. That's where things like volume labels come in. Does a sysadmin care about the low-level device name for a drive on a Windows or Mac system? Does he even know without taking a deep look inside the system? Does not knowing it make it any less possible to easily and reliable manage and control the hardware? On the Mac, the answers are yes, yes and not applicable. On Windows XP, the answers are yes, no, and yes. It's all done through human-readable labels that are easy to work with. No, it isn't. *Most* of it is, and probably everything that the casual user runs into. But we're talking about sysadmins, who have to deal with issues like unformatted drives and file systems that don't necessarily have labels. Oddly enough, on the Mac you tend to get things that look like your ridiculous disk name when dealing with these (i.e. 93.2 GB ST9100823A). The low level information is still available when needed, but it's not the primary means of control. I think that's fine; it strikes the balance between control and ease of use that I'm looking for. Volume labels would certainly solve a lot of issues - even some of the ones I brought up. In particular, if they became the standard way of dealing with devices, then we could unravel some of the more user-friendly-but-expert-hostile designs already in place. But where do you put the label on an ethernet interface? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer wrote: If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. I wrote some add-on bits for /etc/rc.network in 4.x that compares the link addresses of attached network interfaces to a list of link addresses, then sets ifconfig_ifN* variables accordingly before rc.network does anything. It provides a means of wiring IP addresses to physical ports in a way that gets around the problem of probe order. If there's interest, I'll get to work on an rcNG version. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer wrote: In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Please trim the text you are repling to. Please, I'm tired of arbitrary email etiquette. But where do you put the label on an ethernet interface? mike It sounds like your message is, don't be like Linux. Fine, what do you want instead? How does having 2 em devices in my system, named em0 and em1, tell me by name which one is connected to which LAN? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
...lazy...
Not all problems can be fixed by somebody else. Work a little for a
change.
If you wish to name your interfaces switch to Windows.
ifconfig -a | awk '/^[a-z0-9^]*:/ {i=$1} /inet / {ip=$2;net=$4;}
/status/ {print i ip - net - $2}'
em0: 10.0.1.1 - 0xff00 - active
em1: 69.x.x.x - 0xfff8 - active
em2: 64.x.x.x - 0xfff8 - active
em3: 192.168.3.1 - 0xff00 - active
em4: 206.x.x.x - 0xfff0 - active
Scott Long wrote:
Mike Meyer wrote:
In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed:
Please trim the text you are repling to.
Please, I'm tired of arbitrary email etiquette.
But where do you put the label on an ethernet interface?
mike
It sounds like your message is, don't be like Linux. Fine, what do
you want instead? How does having 2 em devices in my system, named em0
and em1, tell me by name which one is connected to which LAN?
Scott
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
[EMAIL PROTECTED]
--
Alain Hebert[EMAIL PROTECTED]
PubNIX Inc.
P.O. Box 175 Beaconsfield, Quebec H9W 5T7
tel 514-990-5911 http://www.pubnix.netfax 514-990-9443
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sat, 08 Apr 2006, Mike Meyer wrote: In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. Because Unix has always made the hardware details available to administrators. Times have changed so that users now need to do things that used to be restricted to administrators. This historical behavior is a *good* thing. If all devices of type foo are just named foo and assigned numbers by the system, then I have no control over the names. If I don't care which is which, this isn't a problem. If I do care - for instance, I want to distinguish between the ethernet interface that's on the internet and the one that's on my LAN, or I want root to be on the disk with the root file system on it - then this is a PITA, because every time I add hardware to the system, or re-arrange the cards in the cage, or similar things, I risk breaking the system configuration. If the device names are completely determined by the hardware settings, then this doesn't happen. That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, except that it means you have the option of looking up what on earth xl actually means to get a vague description of what type of hardware it is, rather than checking the dmesg for xlX or ethX. -- David Taylor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Please trim the text you are repling to. Please, I'm tired of arbitrary email etiquette. If you think etiquette is arbitrary, you're sadly mistaken. But where do you put the label on an ethernet interface? It sounds like your message is, don't be like Linux. No, the message is don't use solutions we know have serious problems. Having devices names that change when you don't make any changes to the device can cause serious problems. Linux does that for lots of things. FreeBSD does it for some things. Fine, what do you want instead? How does having 2 em devices in my system, named em0 and em1, tell me by name which one is connected to which LAN? It doesn't, any more than having disk0 and disk1 instead of ad0 and da0 tell you which disk has the root file system on it. It's not clear that that particular problem can be solved at the device name layer. It's not clear it should be. For disks, the device name should uniquely identify the drive in the system. Nothing short of changing the drives bus address should change that. Volume labels identify the data on the drive, which is what the user cares about. Letting the users work with what they care about should be the goal. My question about labels for ethernet devices wasn't meant to be rhetorical. Ethernet device names on Unix are pretty much worthless. They tell you basically nothing about which device you've got. On FreeBSD, different card types have different names, which is better than nothing - but that's about all it's better than. We need something akin to labels for ethernet devices. The LAN it's plugged into is the equivalent of the data on the disk - but there's no equivalent for the label. What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In [EMAIL PROTECTED], David Taylor [EMAIL PROTECTED] typed: That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, You're right - but at least you have the option of using different types of cards to get different names. I agree that this sucks, but it's better than nothing. I tried to find out how to tell the difference between ethernet interfaces on Linux. Seems that the 2.6 kernel can assign different names to the ethernet devices at each reboot. Um, yeah. Solutions for this problem all seem to involve assigning an arbitrary name based on the MAC address. This has two problems: 1) you have to have a mapping somewhere of mac addresses to cards so you know where to plug in the wan port vs. the lan port. 2) if you replace a dead card with an identical card, your configuration breaks. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpaF0iZFohHl.pgp Description: PGP signature
Re: Using any network interface whatsoever
Ceri Davies wrote: On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri I'll say again, how does having em0, em1, em2, and em3 help me know what is going on with each of those interfaces? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], David Taylor [EMAIL PROTECTED] typed: That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, You're right - but at least you have the option of using different types of cards to get different names. I agree that this sucks, but it's better than nothing. This is a script to rename interfaces based on the MAC address: #!/bin/csh set mac_list = /etc/MACaddr_list foreach ifn ( `ifconfig -l link` ) set ifn_mac = `ifconfig $ifn link | grep ether | cut -d ' ' -f 2` set ifn_name = `grep $ifn_mac $mac_list | cut -d ' ' -f 2` ifconfig $ifn name $ifn_name end Where /etc/MACaddr_list contains entries of the format: 00:00:00:00:00:00 NameLengthMax15 If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN=inet a.b.c.d/24 That's far better than trying to remember what's on em0. This is an off-the-top-of-my-head, 2-minute solution, largely untested due to present lack of a victim machine. pf doesn't seem to have any issue, but I haven't tested /etc/rc.d/netif, dhclient, wpa_supplicant, interface cloning and other things people do to their network interfaces. An rc-friendly version would probably make use of something like: ifconfig_UsefulName_linkaddr=00:00:00:00:00:00 in /etc/rc.conf rather than a seperate file, but this is just a proof of concept. Comments please! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
Mike Meyer [EMAIL PROTECTED] wrote: What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. Is information about the slot even available on a PC? For something like this: : [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 : vendor = 'Intel Corporation' : device = '82547EI Gigabit Ethernet Controller' : class= network : subclass = ethernet would you consider eth-6-7-0 to be an improvement over em0? It has the advantage of not changing if another card is added to the system, but it's not very informative. For a system that has only its two on-board NICs, em0 and em1 are very obvious--at least it's clear which one corresponds to the label eth 0 on the chassis. pgp4Fog3jMEng.pgp Description: PGP signature
Re: Using any network interface whatsoever
Scott Long schrieb: Ceri Davies wrote: On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. How do you know which manual page to read for driver specifics if they are all named eth0, eth1, ... With the current naming scheme you know when to read the man page for em(4), fxp(4), nve(4), ... I'll say again, how does having em0, em1, em2, and em3 help me know what is going on with each of those interfaces? FreeBSD doesn't support persistent instance numbering, unlike Solaris. If you unplug device em0 in FreeBSD the remaining interfaces get renamed em0, em1, em2 - which is a bad thing. If you unplug e1000g0 in Solaris the remaining interfaces will still be named e1000g1, e1000g2, e1000g3. So I doubt that the overwriting of an Ingres database really happened in Solaris, like some other poster described - unless the administrator fiddled with /etc/path_to_inst by hand (you are free to shoot in your own foot). Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In [EMAIL PROTECTED], Daniel Rock [EMAIL PROTECTED] typed: So I doubt that the overwriting of an Ingres database really happened in Solaris, like some other poster described - unless the administrator fiddled with /etc/path_to_inst by hand (you are free to shoot in your own foot). That happened very early in the life of Solaris, in the early 90s. Persistent numbering was added to Solaris in response to this incident (there were probably others as well). This was on a relatively large server, with something like 4 SCSI buses. A drive was added to a previously unused bus, making it appear between two drives that were already in the system. This gave all the drives further on in the probe sequence a device number one higher than they had previously had. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], David Taylor [EMAIL PROTECTED] typed: That doesn't quite work, though. Unless you require everyone wanting to distinguish between LAN and WAN interfaces uses different types of hardware for each card, they'll still end up with xl0 and xl1 (or whatever), which is in no way better than eth0 and eth1, You're right - but at least you have the option of using different types of cards to get different names. I agree that this sucks, but it's better than nothing. This is a script to rename interfaces based on the MAC address: Very nice. If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN=inet a.b.c.d/24 That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? Comments please! This is certainly a move in the right direction. However, MAC addresses are of about the same order of obscurity as device probe order numbers. It might be more usefull to do something like: ifn_list=/etc/NETIF_list for ifn in $(ifconfig -l link) do ifn_addr=$(pciconf -l | grep ^$ifn | sed -e 's/[EMAIL PROTECTED]@//' -e 's/: .*//') ifn_name=$(grep $ifn_addr $ifn_list | cut -d ' ' -f 2$) ifconfig $ifn name $ifn_name done This way, the name would be tied to the slot on the backplane that the device is plugged into. If you changed the card in that slot, it'd still get the same name, even if it was a different card type. That seems like desirable behavior to me, but I can also see cases where the name should follow the card if it moves to a different slot, which is what your version does. The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: If you add something to /etc/rc.d so that a sh-ified version of this script runs after all interfaces have attached but before any numbering or cloning takes place you can have lines like this in /etc/rc.conf: ifconfig_PublicLAN=inet a.b.c.d/24 That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? The network interface name the user sees becomes tied directly to the physical device by way of a unique, configuration-independent identifier. The probe order and driver name become transparent to the network configuration. You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: /etc/rc.d/netif stop PublicLAN kldunload olddriver kldload newdriver /etc/rc.d/netif start PublicLAN Within the currently available capabilities, we get the network interface equivalent of disk volume labels. [ Proposed use of PCI addresses instead of MAC addresses. ] The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. Right, it doesn't scale to ISA or USB devices. The prior probably isn't a big deal these days, but I imagine compatibility with USB devices is fairly important. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Using any network interface whatsoever
I'm trying to configure a bootable image to be used in various situations and on various (mostly unknown) hardware. For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: I'm trying to configure a bootable image to be used in various situations and on various (mostly unknown) hardware. For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT If you have non-Ethernet-like interfaces compiled in, you will probably want create empty ifconfig_if variables for them since DHCP won't work very well there. :) -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0vch5GVjmd.pgp Description: PGP signature
Re: Using any network interface whatsoever
On Fri, Apr 07, 2006 at 03:57:42PM -0700, Brooks Davis wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: I'm trying to configure a bootable image to be used in various situations and on various (mostly unknown) hardware. For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT Superb, thank you! If you have non-Ethernet-like interfaces compiled in, you will probably want create empty ifconfig_if variables for them since DHCP won't work very well there. :) Good point, thanks again :) Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpwXDII5LVgC.pgp Description: PGP signature
