2 nic woes

I have a computer with a built-in realtek 8139 chipset, as well as a
Belkin USB wireless adapter.

Both of these work fine when they work, but....

On cold boot, the system doesn't see the Belkin so the realtek gets
initialized as eth0.

On warm boot, the system sees the Belkin first, so it gets initialized as
eth0.

This of course makes it impossible to network the machine - its whole
purpose is to run unattended, and every time it reboots I have to run over
there and manually see what the system has done with networking. It gets
turned on and off several times a day (it's a DVD player.)

I've tried setting the load order in modules.conf:

alias eth0 usbvnetr
alias eth1 8139too

I've also tried various settings in
/etc/sysconfig/network-scripts/ifup-ethX, fiddling with ONBOOT=yes/no,
still, no joy.

I'm running RH 8, with a stock 2.4.22 kernel. How do I get a fixed ethX
boot order?

-Dondo

On Fri, 05 Sep 2003 09:25:23 -0400, Captain Dondo wrote:
> I have a computer with a built-in realtek 8139 chipset, as well as a
> Belkin USB wireless adapter.
>
> Both of these work fine when they work, but....
>
> On cold boot, the system doesn't see the Belkin so the realtek gets
> initialized as eth0.
>
> On warm boot, the system sees the Belkin first, so it gets initialized as
> eth0.
>
> This of course makes it impossible to network the machine - its whole
> purpose is to run unattended, and every time it reboots I have to run over
> there and manually see what the system has done with networking.


Possible solution is test the connection and if fails, run same
commands you do to force the configuration you need. You could create
a script and call it from the init dir with normal start/stop links or
from rc.local.

Simple example:

ping -c 1 -w 2 ip_address_here

if [ $? -ne 0 ] ; then # cannot get gateway response
service network restart
fi

On Fri, 05 Sep 2003 14:29:13 +0000, Bit Twister wrote:

> On Fri, 05 Sep 2003 09:25:23 -0400, Captain Dondo wrote:
>> I have a computer with a built-in realtek 8139 chipset, as well as a
>> Belkin USB wireless adapter.
>>
>> Both of these work fine when they work, but....
>>
>> On cold boot, the system doesn't see the Belkin so the realtek gets
>> initialized as eth0.
>>
>> On warm boot, the system sees the Belkin first, so it gets initialized as
>> eth0.
>>
>> This of course makes it impossible to network the machine - its whole
>> purpose is to run unattended, and every time it reboots I have to run over
>> there and manually see what the system has done with networking.
>
>
> Possible solution is test the connection and if fails, run same
> commands you do to force the configuration you need. You could create
> a script and call it from the init dir with normal start/stop links or
> from rc.local.
>
> Simple example:
>
> ping -c 1 -w 2 ip_address_here
>
> if [ $? -ne 0 ] ; then # cannot get gateway response
> service network restart
> fi

I think you're on to someting.

I have to run a bunch of iwconfig commands to set up wireless; these are
hard-coded to eth0.

I could run iwconfig on eth0, if it fails, then run it on eth1.

I really don't care which if is initialized as eth0/1; they're both
assigned using DHCP; I just need to get wireless running every time....

-Dondo

On Fri, 05 Sep 2003 18:34:17 -0500, Mauriat wrote:

> I have the *exact* same problem with my linux based DVR with RH8.
> Anyways I have a tulip based on board NIC. So I added in modules.conf:
> 'pre-install usbvnetr /sbin/modprobe tulip'. Replace tulip with 8139too.
> So now what happens is regardless if the onboard NIC has a connection,
> the USB device always gets forced to eth1 (for me). If the NIC has a
> cable plugged in, it will automatically get eth0 before the USB.
> Whichever device has a connection gets the IP address for the box
> assigned to it. If both come online the 2nd device (USB) gets an IP
> address incremented by 1. The modprobe command doesn't gaurantee it will
> get an IP, it just prevents the USB from claiming eth0.
>
> Hope that helps. Using RH8, custom 2.4.20acpi.

Damn, that so slick and simple I wish I'd thought of it... :-)

BTW, how did you get acpi running? I assume you did from the name of your
kernel. I keep getting unresolved symbols if I try to load any acpi
modules:

[root@hermes2 Documentation]# /sbin/modprobe thermal
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_generate_event
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_os_free
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_get_device
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_set_register
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_root_dir
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_install_notify_handler
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_extract_package
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_evaluate_object
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_register_driver
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_fadt
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_get_register
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_evaluate_integer
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_unregister_driver
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_get_handle
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_remove_notify_handler
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: insmod /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o failed
/lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: insmod thermal
failed

-Dondo

Captain Dondo wrote:
> I have a computer with a built-in realtek 8139 chipset, as well as a
> Belkin USB wireless adapter.
>
> Both of these work fine when they work, but....
>
> On cold boot, the system doesn't see the Belkin so the realtek gets
> initialized as eth0.
>
> On warm boot, the system sees the Belkin first, so it gets initialized as
> eth0.
>
> This of course makes it impossible to network the machine - its whole
> purpose is to run unattended, and every time it reboots I have to run over
> there and manually see what the system has done with networking. It gets
> turned on and off several times a day (it's a DVD player.)
>
> I've tried setting the load order in modules.conf:
>
> alias eth0 usbvnetr
> alias eth1 8139too
>
> I've also tried various settings in
> /etc/sysconfig/network-scripts/ifup-ethX, fiddling with ONBOOT=yes/no,
> still, no joy.
>
> I'm running RH 8, with a stock 2.4.22 kernel. How do I get a fixed ethX
> boot order?
>
> -Dondo

I have the *exact* same problem with my linux based DVR with RH8.
Anyways I have a tulip based on board NIC. So I added in modules.conf:
'pre-install usbvnetr /sbin/modprobe tulip'. Replace tulip with 8139too.
So now what happens is regardless if the onboard NIC has a connection,
the USB device always gets forced to eth1 (for me). If the NIC has a
cable plugged in, it will automatically get eth0 before the USB.
Whichever device has a connection gets the IP address for the box
assigned to it. If both come online the 2nd device (USB) gets an IP
address incremented by 1. The modprobe command doesn't gaurantee it will
get an IP, it just prevents the USB from claiming eth0.

Hope that helps. Using RH8, custom 2.4.20acpi.

--

Mauriat
----------------------------
Remove 'NOSPAM' to email me.

Captain Dondo wrote:

> On Fri, 05 Sep 2003 18:34:17 -0500, Mauriat wrote:
>
>
>>I have the *exact* same problem with my linux based DVR with RH8.
>>Anyways I have a tulip based on board NIC. So I added in modules.conf:
>>'pre-install usbvnetr /sbin/modprobe tulip'. Replace tulip with 8139too.
>>So now what happens is regardless if the onboard NIC has a connection,
>>the USB device always gets forced to eth1 (for me). If the NIC has a
>>cable plugged in, it will automatically get eth0 before the USB.
>>Whichever device has a connection gets the IP address for the box
>>assigned to it. If both come online the 2nd device (USB) gets an IP
>>address incremented by 1. The modprobe command doesn't gaurantee it will
>>get an IP, it just prevents the USB from claiming eth0.
>>
>>Hope that helps. Using RH8, custom 2.4.20acpi.
>
>
> Damn, that so slick and simple I wish I'd thought of it... :-)
>
> BTW, how did you get acpi running? I assume you did from the name of your
> kernel. I keep getting unresolved symbols if I try to load any acpi
> modules:
>
> [root@hermes2 Documentation]# /sbin/modprobe thermal
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_generate_event
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_os_free
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_get_device
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_set_register
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_root_dir
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_install_notify_handler
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_extract_package
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_evaluate_object
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_register_driver
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_fadt
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_get_register
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_evaluate_integer
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_bus_unregister_driver
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_get_handle
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: unresolved symbol acpi_remove_notify_handler
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: insmod /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o failed
> /lib/modules/2.4.22clean/kernel/drivers/acpi/processor.o: insmod thermal
> failed
>
> -Dondo
>

Glad to help. I wasn't completely satisfied with this trick but it did
the job.

Well I have an old P3 system, so all I use ACPI is for the power button.
On my DVR it helps that people can automatically turn of the system by
pushing the power button. So I have not tested the other ACPI features
like thermal etc. I documented how I did sometime ago (in another
newsgroup post). Read it here:

http://www.mjmwired.net/resources/redhat8-acpi.html

--

Mauriat
----------------------------
Remove 'NOSPAM' to email me.