Folks, I'm running SUSE Pro 9.3 on an Intel server board with two NICs built in (a GigE and a 10/100). I've since added a Netgear GigE as a 3d NIC. I'm trying to set this box up as a Samba server for a 2-subnet LAN that will have a mix of XP and SUSE machines. eth0 is supposed to face the Net (on ....1.2); the other two NICs are supposed to connect only to eth0 for access to the Net and to each other. The problem I'm having (or maybe not; I'm an extreme newbie with networking) is that every time I boot up the SUSE server, the NICs come out assigned differently: 1 boot: eth0 on 192.168.3.1 Intel GigE NIC eth1 on ...2.2 Intel 10/100 eth2 on ...3.1 Netgear 2 boot: eth0 on ...3.1 Intel 10/100 eth1 on ...1.2 Netgear eth2 on ...2.2 Intel GigE 3 boot: eth0 on ...1.2 Netgear eth1 on ...3.1 Intel GigE eth2 on ...2.2 Intel 10/100 and so on. Both IP address assignments to the NICs and which NIC is on a given ethx change, apparently at random. It would seem that cabling my subnets cannot be done if the NIC assignments keep changing on every boot up. How can I force the system to keep the NICs on a stable assignment--and one of my choosing? The above changes come whether I change the NIC assignments via YaST or do nothing at all before a reboot. Thanks for your help. Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
Eric Hines wrote:
Folks,
I'm running SUSE Pro 9.3 on an Intel server board with two NICs built in (a GigE and a 10/100). I've since added a Netgear GigE as a 3d NIC. I'm trying to set this box up as a Samba server for a 2-subnet LAN that will have a mix of XP and SUSE machines. eth0 is supposed to face the Net (on ....1.2); the other two NICs are supposed to connect only to eth0 for access to the Net and to each other.
The problem I'm having (or maybe not; I'm an extreme newbie with networking) is that every time I boot up the SUSE server, the NICs come out assigned differently:
1 boot: eth0 on 192.168.3.1 Intel GigE NIC eth1 on ...2.2 Intel 10/100 eth2 on ...3.1 Netgear
2 boot: eth0 on ...3.1 Intel 10/100 eth1 on ...1.2 Netgear eth2 on ...2.2 Intel GigE
3 boot: eth0 on ...1.2 Netgear eth1 on ...3.1 Intel GigE eth2 on ...2.2 Intel 10/100
and so on. Both IP address assignments to the NICs and which NIC is on a given ethx change, apparently at random.
It would seem that cabling my subnets cannot be done if the NIC assignments keep changing on every boot up.
How can I force the system to keep the NICs on a stable assignment--and one of my choosing? The above changes come whether I change the NIC assignments via YaST or do nothing at all before a reboot.
Take a look at /etc/sysconfig/network/. In there, you'll find the full name for your NICs. For example, on this desktop system, I've got ifcfg-eth-id-00:05:5d:f6:04:ce, which is the config file for my ethernet port. My firewall, which has 3 NICs has 3 such files, each one containing the MAC address of the respective NIC. Find the files for each NIC and make your changes there, or use Yast, which also uses them.
At 12/24/05 18:53, James Knott wrote:
Eric Hines wrote:
Folks,
I'm running SUSE Pro 9.3 on an Intel server board with two NICs built in (a GigE and a 10/100). I've since added a Netgear GigE as a 3d NIC. I'm trying to set this box up as a Samba server for a 2-subnet LAN that will have a mix of XP and SUSE machines. eth0 is supposed to face the Net (on ....1.2); the other two NICs are supposed to connect only to eth0 for access to the Net and to each other.
The problem I'm having (or maybe not; I'm an extreme newbie with networking) is that every time I boot up the SUSE server, the NICs come out assigned differently:
1 boot: eth0 on 192.168.3.1 Intel GigE NIC eth1 on ...2.2 Intel 10/100 eth2 on ...3.1 Netgear
2 boot: eth0 on ...3.1 Intel 10/100 eth1 on ...1.2 Netgear eth2 on ...2.2 Intel GigE
3 boot: eth0 on ...1.2 Netgear eth1 on ...3.1 Intel GigE eth2 on ...2.2 Intel 10/100
and so on. Both IP address assignments to the NICs and which NIC is on a given ethx change, apparently at random.
It would seem that cabling my subnets cannot be done if the NIC assignments keep changing on every boot up.
How can I force the system to keep the NICs on a stable assignment--and one of my choosing? The above changes come whether I change the NIC assignments via YaST or do nothing at all before a reboot.
Take a look at /etc/sysconfig/network/. In there, you'll find the full name for your NICs. For example, on this desktop system, I've got ifcfg-eth-id-00:05:5d:f6:04:ce, which is the config file for my ethernet port. My firewall, which has 3 NICs has 3 such files, each one containing the MAC address of the respective NIC. Find the files for each NIC and make your changes there, or use Yast, which also uses them. Thanks for your quick response.
Each of the files in /etc/sysconfig/network has the lines STARTMODE='auto' (or is this the hostname to send; that's the only AUTO I see under YaST?) and USERCONTROL='no' (and user control is unchecked in YaST--what would it mean if I gave user control?). Are these what I change? Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup). Thanks, and Merry Christmas. Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote:
Eric Hines wrote:
Folks,
I'm running SUSE Pro 9.3 on an Intel server board with two NICs built in (a GigE and a 10/100). I've since added a Netgear GigE as a 3d NIC. I'm trying to set this box up as a Samba server for a 2-subnet LAN that will have a mix of XP and SUSE machines. eth0 is supposed to face the Net (on ....1.2); the other two NICs are supposed to connect only to eth0 for access to the Net and to each other.
The problem I'm having (or maybe not; I'm an extreme newbie with networking) is that every time I boot up the SUSE server, the NICs come out assigned differently:
1 boot: eth0 on 192.168.3.1 Intel GigE NIC eth1 on ...2.2 Intel 10/100 eth2 on ...3.1 Netgear
2 boot: eth0 on ...3.1 Intel 10/100 eth1 on ...1.2 Netgear eth2 on ...2.2 Intel GigE
3 boot: eth0 on ...1.2 Netgear eth1 on ...3.1 Intel GigE eth2 on ...2.2 Intel 10/100
and so on. Both IP address assignments to the NICs and which NIC is on a given ethx change, apparently at random.
It would seem that cabling my subnets cannot be done if the NIC assignments keep changing on every boot up.
How can I force the system to keep the NICs on a stable assignment--and one of my choosing? The above changes come whether I change the NIC assignments via YaST or do nothing at all before a reboot.
Take a look at /etc/sysconfig/network/. In there, you'll find the full name for your NICs. For example, on this desktop system, I've got ifcfg-eth-id-00:05:5d:f6:04:ce, which is the config file for my ethernet port. My firewall, which has 3 NICs has 3 such files, each one containing the MAC address of the respective NIC. Find the files for each NIC and make your changes there, or use Yast, which also uses them. Thanks for your quick response.
Each of the files in /etc/sysconfig/network has the lines STARTMODE='auto' (or is this the hostname to send; that's the only AUTO I see under YaST?) and USERCONTROL='no' (and user control is unchecked in YaST--what would it mean if I gave user control?). Are these what I change?
Normally, you'd use auto, when you want the NICs to be up all the time. You'd use user, when you want users to be able to start & stop NICs. However, that's described in Yast and I don't think it applies to your original question about the settings moving around. If you use the ifcfg files, then there's no way to get the NICs mixed up, as they're tied to the MAC address.
Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup).
I'm not sure what you're getting at here. If you use the ifcfg files, you'll always configure the correct NIC. If you need to refer to the NICs in a script, you use the full name.
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote:
Eric Hines wrote: <snip>
Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup).
I'm not sure what you're getting at here. If you use the ifcfg files, you'll always configure the correct NIC. If you need to refer to the NICs in a script, you use the full name.
<snip>
One of the problems I have--and I'll try editing the files directly, to guarantee that I'm configuring the correct NIC with the correct information--is that it doesn't seem to make any difference how I configure each NIC--or whether I configure them at all--on one boot up, eth0, say, will have NIC1, with IP address 2, attached to it, and on a subsequent bootup, eth0 will have NIC2, with IP address 3, attached to it, even though I have done nothing at--just boot up, run ifconfig -a to see what's where, then shut down. Similarly, there's no pairing between NIC and IP address--these change on their own, also: NIC3 with IP address 1 on one bootup will have, on the next bootup, IP address 3 attached. Also, even editing the files directly, I could see no way to pin a NIC to a specific eth. How do I do that? Thanks Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
Eric Hines wrote:
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote:
Eric Hines wrote: <snip>
Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup).
I'm not sure what you're getting at here. If you use the ifcfg files, you'll always configure the correct NIC. If you need to refer to the NICs in a script, you use the full name.
<snip>
One of the problems I have--and I'll try editing the files directly, to guarantee that I'm configuring the correct NIC with the correct information--is that it doesn't seem to make any difference how I configure each NIC--or whether I configure them at all--on one boot up, eth0, say, will have NIC1, with IP address 2, attached to it, and on a subsequent bootup, eth0 will have NIC2, with IP address 3, attached to it, even though I have done nothing at--just boot up, run ifconfig -a to see what's where, then shut down. Similarly, there's no pairing between NIC and IP address--these change on their own, also: NIC3 with IP address 1 on one bootup will have, on the next bootup, IP address 3 attached.
Also, even editing the files directly, I could see no way to pin a NIC to a specific eth. How do I do that?
Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
On Sun, 25 Dec 2005 15:59:12 -0500, you wrote:
Eric Hines wrote:
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote:
Eric Hines wrote: <snip>
Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup).
I'm not sure what you're getting at here. If you use the ifcfg files, you'll always configure the correct NIC. If you need to refer to the NICs in a script, you use the full name.
<snip>
One of the problems I have--and I'll try editing the files directly, to guarantee that I'm configuring the correct NIC with the correct information--is that it doesn't seem to make any difference how I configure each NIC--or whether I configure them at all--on one boot up, eth0, say, will have NIC1, with IP address 2, attached to it, and on a subsequent bootup, eth0 will have NIC2, with IP address 3, attached to it, even though I have done nothing at--just boot up, run ifconfig -a to see what's where, then shut down. Similarly, there's no pairing between NIC and IP address--these change on their own, also: NIC3 with IP address 1 on one bootup will have, on the next bootup, IP address 3 attached.
Also, even editing the files directly, I could see no way to pin a NIC to a specific eth. How do I do that?
Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
James, I think you're assuming that the OP understands as much about this as you do. I went thru the same learning/aggravation cycle when I installed SuSE 9.3 on my firewall system. Eric, What you're encountering is a raceway condition that's set up during boot. What happens is that a whole bunch of initialization tasks are started in a batch, and whatever NIC is initialized first is named eth0, second is eth1, etc. There are actually several ways to work around what may be the dumbest design decision in operating system history since 640K. The one that I use is explained here: http://www.catherders.com/tikiwiki-1.9.1/tiki-read_article.php?articleId=36 The one that James is trying to explain is more elegant but requires you to understand the contents of /etc/sysconfig/network/. In a nutshell, find the file named ifcfg-eth-id-mac address of the particular nic. Edit the contents to assign the ipaddress you want to the particular NIC with that MAC address. Repeat for the rest of your NICs. Mike- -- Mornings: Evolution in action. Only the grumpy will survive. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments.
Michael W Cocke wrote:
On Sun, 25 Dec 2005 15:59:12 -0500, you wrote:
Eric Hines wrote:
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote:
Eric Hines wrote: <snip> Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup). I'm not sure what you're getting at here. If you use the ifcfg files, you'll always configure the correct NIC. If you need to refer to the NICs in a script, you use the full name.
<snip> One of the problems I have--and I'll try editing the files directly, to guarantee that I'm configuring the correct NIC with the correct information--is that it doesn't seem to make any difference how I configure each NIC--or whether I configure them at all--on one boot up, eth0, say, will have NIC1, with IP address 2, attached to it, and on a subsequent bootup, eth0 will have NIC2, with IP address 3, attached to it, even though I have done nothing at--just boot up, run ifconfig -a to see what's where, then shut down. Similarly, there's no pairing between NIC and IP address--these change on their own, also: NIC3 with IP address 1 on one bootup will have, on the next bootup, IP address 3 attached.
Also, even editing the files directly, I could see no way to pin a NIC to a specific eth. How do I do that? Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
James, I think you're assuming that the OP understands as much about this as you do. I went thru the same learning/aggravation cycle when I installed SuSE 9.3 on my firewall system.
Eric, What you're encountering is a raceway condition that's set up during boot. What happens is that a whole bunch of initialization tasks are started in a batch, and whatever NIC is initialized first is named eth0, second is eth1, etc.
There are actually several ways to work around what may be the dumbest design decision in operating system history since 640K.
The one that I use is explained here: http://www.catherders.com/tikiwiki-1.9.1/tiki-read_article.php?articleId=36
The one that James is trying to explain is more elegant but requires you to understand the contents of /etc/sysconfig/network/. In a nutshell, find the file named ifcfg-eth-id-mac address of the particular nic. Edit the contents to assign the ipaddress you want to the particular NIC with that MAC address. Repeat for the rest of your NICs.
Interesting. However, that author is also making the same mistake that you have to deal with eth0 etc. For example, he uses it in a default route statement. What's wrong with specifying a default route network and then letting the IP stack figure out which NIC to use? Is there any reason why a configuration has to specify a particular NIC, instead of a network address?
At 12/25/05 16:24, James Knott wrote:
Michael W Cocke wrote:
On Sun, 25 Dec 2005 15:59:12 -0500, you wrote:
Eric Hines wrote:
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote: > Eric Hines wrote: <snip> Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
James, I think you're assuming that the OP understands as much about this as you do. I went thru the same learning/aggravation cycle when I installed SuSE 9.3 on my firewall system.
Eric, What you're encountering is a raceway condition that's set up during boot. What happens is that a whole bunch of initialization tasks are started in a batch, and whatever NIC is initialized first is named eth0, second is eth1, etc.
There are actually several ways to work around what may be the dumbest design decision in operating system history since 640K.
The one that I use is explained here: http://www.catherders.com/tikiwiki-1.9.1/tiki-read_article.php?articleId=36
The one that James is trying to explain is more elegant but requires you to understand the contents of /etc/sysconfig/network/. In a nutshell, find the file named ifcfg-eth-id-mac address of the particular nic. Edit the contents to assign the ipaddress you want to the particular NIC with that MAC address. Repeat for the rest of your NICs.
Interesting. However, that author is also making the same mistake that you have to deal with eth0 etc. For example, he uses it in a default route statement. What's wrong with specifying a default route network and then letting the IP stack figure out which NIC to use? Is there any reason why a configuration has to specify a particular NIC, instead of a network address?
I think I have an understanding of what's going on (and it was me that was missing something), and I now have a stable set up. What Mike is describing is consistent with the ifstatus man page saying that ethx is no longer bound to a NIC, since the advent of removable NICs (e.g., via USB). James is saying the same thing when he says don't worry about which eth is which, just get the NICs and IP addresses right. I followed James' suggestion and edited the ifcfg-eth-id-<MAC Address> files, and I've had a stable (under my clearer understanding of the meaning of "stable") set up since. There was one of two things going on with the latter: either YaST was messing up when I used it to edit the files, and I straightened that out when I edited the files directly, or I was collecting bad data and there were no wandering NIC/IP address problems all along. Unfortunately, I have to lean toward the latter. At any rate, thanks for taking the time to set me in the right direction. And Merry Christmas. Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
Eric Hines wrote:
I think I have an understanding of what's going on (and it was me that was missing something), and I now have a stable set up. What Mike is describing is consistent with the ifstatus man page saying that ethx is no longer bound to a NIC, since the advent of removable NICs (e.g., via USB). James is saying the same thing when he says don't worry about which eth is which, just get the NICs and IP addresses right. I followed James' suggestion and edited the ifcfg-eth-id-<MAC Address> files, and I've had a stable (under my clearer understanding of the meaning of "stable") set up since. There was one of two things going on with the latter: either YaST was messing up when I used it to edit the files, and I straightened that out when I edited the files directly, or I was collecting bad data and there were no wandering NIC/IP address problems all along. Unfortunately, I have to lean toward the latter.
At any rate, thanks for taking the time to set me in the right direction.
Did you also notice that while ifconfig supports only eth0 etc., ifstatus can work with either form? Yast also uses the ethid-<MAC address> version, instead of ethx. BTW, you don't have to copy your messages to everyone. We all read the same list and get all the same messages.
At 12/25/05 17:48, James Knott wrote:
Eric Hines wrote:
I think I have an understanding of what's going on (and it was me that was missing something), and I now have a stable set up. What Mike is describing is consistent with the ifstatus man page saying that ethx is no longer bound to a NIC, since the advent of removable NICs (e.g., via USB). James is saying the same thing when he says don't worry about which eth is which, just get the NICs and IP addresses right. I followed James' suggestion and edited the ifcfg-eth-id-<MAC Address> files, and I've had a stable (under my clearer understanding of the meaning of "stable") set up since. There was one of two things going on with the latter: either YaST was messing up when I used it to edit the files, and I straightened that out when I edited the files directly, or I was collecting bad data and there were no wandering NIC/IP address problems all along. Unfortunately, I have to lean toward the latter.
At any rate, thanks for taking the time to set me in the right direction.
Did you also notice that while ifconfig supports only eth0 etc., ifstatus can work with either form? Yast also uses the ethid-<MAC address> version, instead of ethx.
Yes. That sort of thing is slowly sinking in on me.
BTW, you don't have to copy your messages to everyone. We all read the same list and get all the same messages.
Yeah. Sorry. Banging Reply-All to make sure it got to the list, and then not editing the To filed.... There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
I hope someone here can at least point me in the right direction :) I am a middle school science teacher and run an after school robotics club. Each year we participate in a contest called Botball and the theme this year is searching for water on the moon using robots. As an advanced project I decided we should build our own semi-autonomus tele-operated rover capable of finding water ice in a soil sample. We are basing the robot around a mini-itx board with 512MB of RAM and a wireless NIC with a Phidget 8/8/8 interface kit for sensor interfacing ( http://www.phidgets.com/index.php?module=pncommerce&func=itemview&IID=85 ) and a Roboteq motor controller for motor control (http://www.roboteq.com/). We also have a Logitech Quickcam 4000 Pro for vision. The plan is to write a server that will stream out the sensor and video information from the robot to a client. There will be two clients, one on the robot that connects and interprets the information for semi-autonomus control and another remote client. You will be able to connect to the server via the remote client and view all the sensor and video information in real time and drive the rover around, looking for water. Eventually the OS on the robot will go onto a small bootable compact flash card. I have most of the details worked out except the streaming video part. Ive never done anything with streaming video - ever. What would be best would be a tutorial on how to setup a streaming server and how to program a simple client to connect to and view the stream either using Qt/KDE or GTK/Gnome. Any help? David Culp
David, On Sunday 25 December 2005 16:22, dwculp wrote:
I hope someone here can at least point me in the right direction :)
I am a middle school science teacher and run an after school robotics club. Each year we participate in a contest called Botball and the theme this year is searching for water on the moon using robots. As an advanced project I decided we should build our own semi-autonomus tele-operated rover capable of finding water ice in a soil sample. ...
The plan is to write a server that will stream out the sensor and video information from the robot to a client. There will be two clients, one on the robot that connects and interprets the information for semi-autonomus control and another remote client. ...
I have most of the details worked out except the streaming video part. Ive never done anything with streaming video - ever. What would be best would be a tutorial on how to setup a streaming server and how to program a simple client to connect to and view the stream either using Qt/KDE or GTK/Gnome.
Very cool. I'm not really up on Linux video, but a simple Web search for "Linux Video" turns up a lot of seemingly relevant pages. I'm really writing to ask you two things: 1) Please start a Web site to keep us posted on your progress with this project. I'm sure there are many people who would like to replicate, probably with variations, the project you're doing as well as simply watch your progress and find out what you've learned from doing it. 2) Don't use your mail client's "reply" function to start new topics. It breaks the topic threading in the mail clients of people using thread-capable mail clients such as Evolution, those from the Mozilla foundation or KMail. (But not, notably, Outlook, Outlook Express or Eudora.)
Any help?
The only other thing to say is that the Packman RPM repository (see http://www.opensuse.org/YaST_package_repository / http://www.opensuse.org/YaST_package_repository#Packman for access details) is usually the best and most comprehensive source for up-to-date media software for SuSE Linux.
David Culp
Randall Schulz
On Sun, 2005-12-25 at 17:27 -0800, Randall R Schulz wrote:
David,
On Sunday 25 December 2005 16:22, dwculp wrote:
I hope someone here can at least point me in the right direction :)
I am a middle school science teacher and run an after school robotics club. Each year we participate in a contest called Botball and the theme this year is searching for water on the moon using robots. As an advanced project I decided we should build our own semi-autonomus tele-operated rover capable of finding water ice in a soil sample. ...
The plan is to write a server that will stream out the sensor and video information from the robot to a client. There will be two clients, one on the robot that connects and interprets the information for semi-autonomus control and another remote client. ...
I have most of the details worked out except the streaming video part. Ive never done anything with streaming video - ever. What would be best would be a tutorial on how to setup a streaming server and how to program a simple client to connect to and view the stream either using Qt/KDE or GTK/Gnome.
Very cool.
I'm not really up on Linux video, but a simple Web search for "Linux Video" turns up a lot of seemingly relevant pages.
I'm really writing to ask you two things:
1) Please start a Web site to keep us posted on your progress with this project. I'm sure there are many people who would like to replicate, probably with variations, the project you're doing as well as simply watch your progress and find out what you've learned from doing it.
We should have a website up and operational just after the start of the year. Right now we have the motherboard and other componets mounted on a 16 inch round frame from Zagros robotics (https://www.zagrosrobotics.com/Index.asp). We have SuSE 10.0 installed on the 40 gig HD and the phidgets and camera operational. We are on hold right now until I get the money to buy the Roboteq controller, this project is funded in a large part by me. Eventually we will build a cutom aluminium frame for the bot. Phase 1 is just getting the parts mounted and OS installed. The first generation of the robot will be very simple. The actual client will run on the robot itself and you will simply remote desktop into it via VNC and start the video and control app and drive it around, that makes it stupidly simple. Eventually it will stream everything out to a remote client and the OS on the bot will be an X-less Linux installation on a small bootable compact flash card.
2) Don't use your mail client's "reply" function to start new topics. It breaks the topic threading in the mail clients of people using thread-capable mail clients such as Evolution, those from the Mozilla foundation or KMail. (But not, notably, Outlook, Outlook Express or Eudora.)
Opps......I'm sorry :(
Any help?
The only other thing to say is that the Packman RPM repository (see http://www.opensuse.org/YaST_package_repository / http://www.opensuse.org/YaST_package_repository#Packman for access details) is usually the best and most comprehensive source for up-to-date media software for SuSE Linux.
David Culp
Randall Schulz
On Sun, 25 Dec 2005 17:24:40 -0500, you wrote:
Michael W Cocke wrote:
On Sun, 25 Dec 2005 15:59:12 -0500, you wrote:
Eric Hines wrote:
At 12/25/05 07:51, James Knott wrote:
Eric Hines wrote:
At 12/24/05 18:53, James Knott wrote: > Eric Hines wrote: <snip> Alternatively, how do I use YaST to do this? I've been in YaST|Network Devices|Network Card|<NIC>|Edit and edited the IP address for each. I can't find any place to pin a NIC to a particular ethx, though. And both the addresses and the ethx change on each boot--e.g., eth0 will have on NIC (by MAC address) and one IP address after one bootup, and after another bootup it'll have a different NIC and a different IP address (and both will be completely different--it won't simply be a NIC/IP address pairing from another ethx on the earlier bootup). I'm not sure what you're getting at here. If you use the ifcfg files, you'll always configure the correct NIC. If you need to refer to the NICs in a script, you use the full name.
<snip> One of the problems I have--and I'll try editing the files directly, to guarantee that I'm configuring the correct NIC with the correct information--is that it doesn't seem to make any difference how I configure each NIC--or whether I configure them at all--on one boot up, eth0, say, will have NIC1, with IP address 2, attached to it, and on a subsequent bootup, eth0 will have NIC2, with IP address 3, attached to it, even though I have done nothing at--just boot up, run ifconfig -a to see what's where, then shut down. Similarly, there's no pairing between NIC and IP address--these change on their own, also: NIC3 with IP address 1 on one bootup will have, on the next bootup, IP address 3 attached.
Also, even editing the files directly, I could see no way to pin a NIC to a specific eth. How do I do that? Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
James, I think you're assuming that the OP understands as much about this as you do. I went thru the same learning/aggravation cycle when I installed SuSE 9.3 on my firewall system.
Eric, What you're encountering is a raceway condition that's set up during boot. What happens is that a whole bunch of initialization tasks are started in a batch, and whatever NIC is initialized first is named eth0, second is eth1, etc.
There are actually several ways to work around what may be the dumbest design decision in operating system history since 640K.
The one that I use is explained here: http://www.catherders.com/tikiwiki-1.9.1/tiki-read_article.php?articleId=36
The one that James is trying to explain is more elegant but requires you to understand the contents of /etc/sysconfig/network/. In a nutshell, find the file named ifcfg-eth-id-mac address of the particular nic. Edit the contents to assign the ipaddress you want to the particular NIC with that MAC address. Repeat for the rest of your NICs.
Interesting. However, that author is also making the same mistake that you have to deal with eth0 etc. For example, he uses it in a default route statement. What's wrong with specifying a default route network and then letting the IP stack figure out which NIC to use? Is there any reason why a configuration has to specify a particular NIC, instead of a network address?
Well, in my own particular case (my firewall system) I don't want to leave ANYTHING to chance, since a NIC misassignment will leave my intranet hanging out in the breeze... I could probably get a default route config such as you describe to work, but it seems to me to be more complex than it needs to be. Mike- -- Mornings: Evolution in action. Only the grumpy will survive. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments.
Michael W Cocke wrote:
On Sun, 25 Dec 2005 17:24:40 -0500, you wrote:
Interesting. However, that author is also making the same mistake that you have to deal with eth0 etc. For example, he uses it in a default route statement. What's wrong with specifying a default route network and then letting the IP stack figure out which NIC to use? Is there any reason why a configuration has to specify a particular NIC, instead of a network address?
Well, in my own particular case (my firewall system) I don't want to leave ANYTHING to chance, since a NIC misassignment will leave my intranet hanging out in the breeze... I could probably get a default route config such as you describe to work, but it seems to me to be more complex than it needs to be.
As I mentioned in another note, SUSE fireall supports NICs specified in the form of eth-id-00:05:5d:fe:fc:e4. Note that this contains the NIC MAC address. It's pretty hard to get confused by specifying the exact piece of hardware. About the only time this might cause some difficulty, is when you replace the NIC. At that point, you'll have to change the MAC address specified. If you absolutely must use ethx, you can always add a few lines to your scripts to grep & cut the output of ifconfig and use the results to do what you want.
At 12/25/05 18:14, you wrote:
Michael W Cocke wrote:
On Sun, 25 Dec 2005 17:24:40 -0500, you wrote:
Well, in my own particular case (my firewall system) I don't want to leave ANYTHING to chance, since a NIC misassignment will leave my intranet hanging out in the breeze... I could probably get a default route config such as you describe to work, but it seems to me to be more complex than it needs to be.
As I mentioned in another note, SUSE fireall supports NICs specified in the form of eth-id-00:05:5d:fe:fc:e4. Note that this contains the NIC MAC address. It's pretty hard to get confused by specifying the exact piece of hardware. About the only time this might cause some difficulty, is when you replace the NIC. At that point, you'll have to change the MAC address specified.
I can see typos, with attendant security holes occurring this way, though. On my server's motherboard are two NIC chips built in--and their MAC addresses differ only in the last character of the last character pair. There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
On Sun, 25 Dec 2005 18:21:08 -0600, you wrote:
At 12/25/05 18:14, you wrote:
Michael W Cocke wrote:
On Sun, 25 Dec 2005 17:24:40 -0500, you wrote:
Well, in my own particular case (my firewall system) I don't want to leave ANYTHING to chance, since a NIC misassignment will leave my intranet hanging out in the breeze... I could probably get a default route config such as you describe to work, but it seems to me to be more complex than it needs to be.
As I mentioned in another note, SUSE fireall supports NICs specified in the form of eth-id-00:05:5d:fe:fc:e4. Note that this contains the NIC MAC address. It's pretty hard to get confused by specifying the exact piece of hardware. About the only time this might cause some difficulty, is when you replace the NIC. At that point, you'll have to change the MAC address specified.
I can see typos, with attendant security holes occurring this way, though. On my server's motherboard are two NIC chips built in--and their MAC addresses differ only in the last character of the last character pair.
I had the same thought as Eric, in addition to the fact that I don't use the SuSE firewall - I use shorewall, which is significantly more complex to configure (It's also significantly more flexible, so don't suggest that I change). Mike- -- Mornings: Evolution in action. Only the grumpy will survive. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments.
Michael W Cocke wrote:
On Sun, 25 Dec 2005 18:21:08 -0600, you wrote:
At 12/25/05 18:14, you wrote:
As I mentioned in another note, SUSE fireall supports NICs specified in the form of eth-id-00:05:5d:fe:fc:e4. Note that this contains the NIC MAC address. It's pretty hard to get confused by specifying the exact piece of hardware. About the only time this might cause some difficulty, is when you replace the NIC. At that point, you'll have to change the MAC address specified. I can see typos, with attendant security holes occurring this way, though. On my server's motherboard are two NIC chips built in--and their MAC addresses differ only in the last character of the last character pair.
I had the same thought as Eric, in addition to the fact that I don't use the SuSE firewall - I use shorewall, which is significantly more complex to configure (It's also significantly more flexible, so don't suggest that I change).
Do know for a fact, that it won't support NIC designations such as eth-id-00:05:5d:fe:fc:e4? Changing NICs in a firewall should be a fairly rare event. Changing NICs in a server shouldn't cause a problem. Face it. The old ethx method is obsolete, so you'd better get used to the new way.
On Sun, 25 Dec 2005 19:38:35 -0500, you wrote:
Michael W Cocke wrote:
On Sun, 25 Dec 2005 18:21:08 -0600, you wrote:
At 12/25/05 18:14, you wrote:
As I mentioned in another note, SUSE fireall supports NICs specified in the form of eth-id-00:05:5d:fe:fc:e4. Note that this contains the NIC MAC address. It's pretty hard to get confused by specifying the exact piece of hardware. About the only time this might cause some difficulty, is when you replace the NIC. At that point, you'll have to change the MAC address specified. I can see typos, with attendant security holes occurring this way, though. On my server's motherboard are two NIC chips built in--and their MAC addresses differ only in the last character of the last character pair.
I had the same thought as Eric, in addition to the fact that I don't use the SuSE firewall - I use shorewall, which is significantly more complex to configure (It's also significantly more flexible, so don't suggest that I change).
Do know for a fact, that it won't support NIC designations such as eth-id-00:05:5d:fe:fc:e4? Changing NICs in a firewall should be a fairly rare event. Changing NICs in a server shouldn't cause a problem. Face it. The old ethx method is obsolete, so you'd better get used to the new way.
Why do people always say things like this? I don't give a hang if you don't like how I configure my NICs and I don't see why you should care. It works, end of discussion. If and when I get to a point where I feel the need to change how I do things just to make you happy, I'll let you know. Mike- -- Mornings: Evolution in action. Only the grumpy will survive. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces, try non-HTML, non-encoded, non-attachments.
Michael W Cocke wrote:
Why do people always say things like this? I don't give a hang if you don't like how I configure my NICs and I don't see why you should care. It works, end of discussion. If and when I get to a point where I feel the need to change how I do things just to make you happy, I'll let you know.
Perhaps people say such things, because they realize the way things are going and trying to retain old methods is futile. If you're having problems working with the old way, as some people are, perhaps it's because they're stuck in the past and unwilling to learn something new. Many years ago, I used to work with a guy who resisted change, because "we've always done it this way", ignoring the fact that the systems we worked with had changed considerably and the "old way" was no longer appropriate. As an example, many years ago, when I was a computer technician, I used to repair and overhaul disk pack drives, with a capacity of about 200 MB. Back in those days, it paid to have techs doing that sort of work, because a new drive cost about as much as a house! Nowadays, if a drive fails, we just toss it, because it's not worth the time it would take to repair it. Things change and if you're not willing to change with them, then you'll be stuck in the past. Now as someone else mentioned, one of the reasons for this situation was the introduction of USB & PCMCIA NICs, which could be inserted or removed at any time. What's your solution to this problem, besides complaining? At least, I provided some useful info, to resolve Eric's problem.
At 12/25/05 19:24, James Knott wrote:
Michael W Cocke wrote:
Why do people always say things like this? I don't give a hang if you don't like how I configure my NICs and I don't see why you should care. It works, end of discussion. If and when I get to a point where I feel the need to change how I do things just to make you happy, I'll let you know.
Perhaps people say such things, because they realize the way things are going and trying to retain old methods is futile. If you're having problems working with the old way, as some people are, perhaps it's because they're stuck in the past and unwilling to learn something new.
It's true that there comes a time when it's necessary--or at least more efficient--to update. But updating just because there's something new available isn't always appropriate. Two extreme examples: MS is trying to force "just because" updates with their new licensing procedure for their OS and their office suite. You "must" buy the upgrade every few (three?) years because they won't support the newly created legacy versions beyond those three years. Updating here benefits only the vendor, not the user. Along those lines, I work for a defense contractor, and we were using Office97 as recently as 2003--the bells and whistles in the newer versions just weren't useful to us, especially at the upgrade cost/license. We build simulators; "officing" just isn't that complex for us. Even so, when someone in our front office decided we needed to join the 20th century and upgrade to Office2000, it took us another year to do so because one of our major customers also used Office97, and they felt less of a need to upgrade their suite than we did. In the present example, the question of bouncing ethx only bothered one of us--the newbie with his newbie ignorance. That wasn't a problem for the others in this discussion. It's expensive to upgrade, even in an open source environment. If the added goodies in the newer thing aren't central to what one is doing, then it's a waste of money to upgrade. One man's must-have is another's bell and whistle. And being able to recognize the difference, and to recognize when one has become the other, puts a premium not on being stuck in the past and unwilling to learn, but on just the opposite. Then the decision to upgrade, or not, is informed rather than blindly automatic. Eric Hines There is no nonsense so errant that it cannot be made the creed of the vast majority by adequate governmental action. --Bertrand Russell
Eric Hines wrote:
At 12/25/05 19:24, James Knott wrote:
It's true that there comes a time when it's necessary--or at least more efficient--to update. But updating just because there's something new available isn't always appropriate. Two extreme examples: MS is trying to force "just because" updates with their new licensing procedure for their OS and their office suite. You "must" buy the upgrade every few (three?) years because they won't support the newly created legacy versions beyond those three years. Updating here benefits only the vendor, not the user. Along those lines, I work for a defense contractor, and we were using Office97 as recently as 2003--the bells and whistles in the newer versions just weren't useful to us, especially at the upgrade cost/license. We build simulators; "officing" just isn't that complex for us. Even so, when someone in our front office decided we needed to join the 20th century and upgrade to Office2000, it took us another year to do so because one of our major customers also used Office97, and they felt less of a need to upgrade their suite than we did.
In the present example, the question of bouncing ethx only bothered one of us--the newbie with his newbie ignorance. That wasn't a problem for the others in this discussion. It's expensive to upgrade, even in an open source environment. If the added goodies in the newer thing aren't central to what one is doing, then it's a waste of money to upgrade. One man's must-have is another's bell and whistle. And being able to recognize the difference, and to recognize when one has become the other, puts a premium not on being stuck in the past and unwilling to learn, but on just the opposite. Then the decision to upgrade, or not, is informed rather than blindly automatic.
As for updating MS Office, it's obvious who's benifit that's for. Most people would have been happy with Word 6 etc. However in this case, the change was made for technical reasons and actually eliminates some problems that occured the old way. For example in your case, with 3 NICs, there was no way for you to know, when you built your system, whether a NIC was going to be eth0 or eth2 etc. You simply built it and then found out where they were. Even having it consistent, wouldn't have changed that. Now, you can decide, even before you plug in the NICs, which one will be used for what connection. It doesn't matter what order it's plugged in or what type of physical connection it has. As long as you know the MAC, you can specify how it'll be used.
Eric Hines wrote:
At 12/25/05 18:14, you wrote:
As I mentioned in another note, SUSE fireall supports NICs specified in the form of eth-id-00:05:5d:fe:fc:e4. Note that this contains the NIC MAC address. It's pretty hard to get confused by specifying the exact piece of hardware. About the only time this might cause some difficulty, is when you replace the NIC. At that point, you'll have to change the MAC address specified.
I can see typos, with attendant security holes occurring this way, though. On my server's motherboard are two NIC chips built in--and their MAC addresses differ only in the last character of the last character pair.
Well, that's what cut 'n paste is for. Also, Yast finds the info automagically.
On Sun, 2005-12-25 at 15:59 -0500, James Knott wrote:
Eric Hines wrote: <snip> Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
Unless setting up the firewall with those names. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Ken Schneider wrote:
On Sun, 2005-12-25 at 15:59 -0500, James Knott wrote:
Eric Hines wrote: <snip> Either I'm missing something or you're missing something. Those files are tied directly to a NIC, with the corresponding MAC address. They don't work with any other. Now eth0, eth1 etc., may wander around, but why is that an issue? Servers talk to IP addresses, not NICs. It's up to the IP stack to figure out which NIC to talk to. You shouldn't have any need to worry about whether a NIC is eth0 or not.
Unless setting up the firewall with those names.
Again, no need. The SUSE firewall supports using the AMC IDs for NICs. For example, In my fireall, my NICs are listed as eth-id-00:05:5d:fe:fc:e4, eth-id-00:80:c6:f0:6a:5c and eth-id-00:c0:4f:a1:8f:94. There is no reason to specify eth0, eth1 etc. The only exceptions are my VPN which is tun0 and dial in port ppp0 which have no MAC addresses.
participants (6)
-
dwculp -
Eric Hines -
James Knott -
Ken Schneider -
Michael W Cocke -
Randall R Schulz