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 (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 (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 (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 (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]
