Switching eth0 with eth1

Hi all,

I have a Supermicro X7SLA-H motherboard with two onboard gigabit NIC's (Realtek 8169). Since the performance was on the low side and due to some (known) driver issues I added a Intel Pro 1000 GT (PCI-bus) en disabled the onboard LAN. However, I couldn't get WOL to work on the Intel ethernet card, while the onboard LAN works great. I still want to use my Intel card for network traffic, and the Realtek card just for the WOL feature. unRAID will load the driver for the RTL8169, assigning it to eth0, and the Intel second (eth1).

The way unRAID works it ignores the eth1 and will always use eth0 for network traffic. Is there some way I can change this assignment? Any help would be greatly appreciated!

In looking at this very briefly....

and I do mean briefly.

You might have to custom code something in rc.inet1.conf.

Then make sure the custom configurations are re-installed on reboot.

If you look at it, the code has

# /etc/rc.d/rc.inet1.conf
#
# This file contains the configuration settings for network interfaces.
# If USE_DHCP[interface] is set to "yes", this overrides any other settings.
# If you don't have an interface, leave the settings null ("").

# You can configure network interfaces other than eth0,eth1... by setting
# IFNAME[interface] to the interface's name. If IFNAME[interface] is unset
# or empty, it is assumed you're configuring eth<interface>.

# Several other parameters are available, the end of this file contains a
# comprehensive set of examples.

# =============================================================================

# Config information for eth0:
# tmm - Read settings from config file:
fromdos </boot/config/network.cfg >/var/tmp/network.cfg
source /var/tmp/network.cfg
DHCP_HOSTNAME[0]="`hostname`"

-- snip --
                                                  
#IPADDR[0]=""
#NETMASK[0]=""
#USE_DHCP[0]="yes"
#DHCP_KEEPRESOLV="no"
#DHCP_HOSTNAME[0]=""

# Config information for eth1:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""

# Config information for eth2:
IPADDR[2]=""
NETMASK[2]=""
USE_DHCP[2]=""
DHCP_HOSTNAME[2]=""

and in /boot/config/network.cfg

root@Atlas /etc/rc.d #more /boot/config/network.cfg
# Generated settings:
USE_DHCP=no
IPADDR=192.168.1.179
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
HWADDR=00:50:8D:9D:7B:AA
DHCP_KEEPRESOLV=no
DNS_SERVER1=192.168.1.253
DNS_SERVER2=
DNS_SERVER3=

 

 

In looking at this very briefly....

and I do mean briefly.

 

You might have to custom code something in rc.inet1.conf.

Then make sure the custom configurations are re-installed on reboot.

 

If you look at it, the code has

 

*** snip ***

 

and in /boot/config/network.cfg

 

*** snip ***

I don't know what part of the code was relevant to the issue, so I tried adding the HW_ADDRESS in network.cfg with the MAC address from the Intel NIC, but ended up with a spoofed MAC address on the Realtek adapter. What I found while searching was that I have to call

modprobe e1000

in

rc.inet1

to load the module for the Intel adapter first. But it seems this executable is called before I have the chance to overwrite it with my own custom made one.

I don't know what part of the code was relevant to the issue, so I tried adding the HW_ADDRESS in network.cfg with the MAC address from the Intel NIC, but ended up with a spoofed MAC address on the Realtek adapter. What I found while searching was that I have to call

 

modprobe e1000

 

in

rc.inet1

to load the module for the Intel adapter first. But it seems this executable is called before I have the chance to overwrite it with my own custom made one.

Hmmm... Maybe if you shutdown tcpip via /etc/rc.d/rc.inet2 stop  /etc/rc.d/rc.inet1 stop.

Then do rmmod on the ethernet modules.

then do insmod on the modules you want to load.

Then restart the inet scripts

/etc/rc.d/rc.inet1 start

/etc/rc.d/rc.inet2 start

 

 

In looking at this very briefly....

and I do mean briefly.

 

You might have to custom code something in rc.inet1.conf.

Then make sure the custom configurations are re-installed on reboot.

 

If you look at it, the code has

 

*** snip ***

 

and in /boot/config/network.cfg

 

*** snip ***

 

I don't know what part of the code was relevant to the issue, so I tried adding the HW_ADDRESS in network.cfg with the MAC address from the Intel NIC, but ended up with a spoofed MAC address on the Realtek adapter. What I found while searching was that I have to call

 

modprobe e1000

 

in

rc.inet1

to load the module for the Intel adapter first. But it seems this executable is called before I have the chance to overwrite it with my own custom made one.

The config/network.cfg file is "sourced" in the existing rc.inet script(s) as one of the very first things they do.

I'll bet if you edit it and add the

modprobe e1000

line to it, it will  execute before almost everything else in the network setup process.

Joe L.

It might be even easier than that....

 

The config/network.cfg file is "sourced" in the existing rc.inet script(s) as one of the very first things they do.

I'll bet if you edit it and add the

modprobe e1000

line to it, it will  execute before almost everything else in the network setup process.

 

Joe L.

I think I tried that already, but that didn't work. Figured it was just a settings file, not something that was actively executed. Maybe I'll give it another try.

Hmmm... Maybe if you shutdown tcpip via /etc/rc.d/rc.inet2 stop  /etc/rc.d/rc.inet1 stop.

Then do rmmod on the ethernet modules.

then do insmod on the modules you want to load.

Then restart the inet scripts

 

/etc/rc.d/rc.inet1 start

/etc/rc.d/rc.inet2 start

 

This seems like something that could work, but it'll add even more to the already long boot time. Then again, that's why sleep mode was invented in the first place, ey?

This seems like something that could work, but it'll add even more to the already long boot time. Then again, that's why sleep mode was invented in the first place, ey?

It should not take that long.

perhaps just putting the

rmmod

and

insmod in the config/network.cfg script would work.

Keep in mind, anytime you change the network configuration from emhttp you will have to re-edit this file.

This seems like something that could work, but it'll add even more to the already long boot time. Then again, that's why sleep mode was invented in the first place, ey?

 

It should not take that long.

perhaps just putting the

rmmod

and

insmod in the config/network.cfg script would work.

 

Keep in mind, anytime you change the network configuration from emhttp you will have to re-edit this file.

Yeah, the boot time isn't really a big issue. Should I use

modprobe

or

insmod

?

This seems like something that could work, but it'll add even more to the already long boot time. Then again, that's why sleep mode was invented in the first place, ey?

 

It should not take that long.

perhaps just putting the

rmmod

and

insmod in the config/network.cfg script would work.

 

Keep in mind, anytime you change the network configuration from emhttp you will have to re-edit this file.

Yeah, the boot time isn't really a big issue. Should I use

modprobe

or

insmod

?

The rc.inet script uses /sbin/modprobe ... I'd use it, although it probably does not matter.

I tried adding

modprobe e1000

to

network.cfg

and now eth0 is indeed the Intel adapter, only it does not get an IP address. Secondly, the Realtek adapter does not get the eth1 interface name, although the module is loaded as shown by

lsmod

.

If I add

/etc/rc.d/rc.inet2 stop
/etc/rc.d/rc.inet1 stop
rmmod e1000
rmmod r8169
modprobe e1000
modprobe r8169
/etc/rc.d/rc.inet1 start
/etc/rc.d/rc.inet2 start

to the GO script, I do get an IP address on eth0 (Intel), but the Realtek adapter is still not assigned to eth1. It seems to me that I don't really need the Realtek adapter to have DHCP and such, as long as it will wake the system. Is that even possible?

I do get an IP address on eth0 (Intel), but the Realtek adapter is still not assigned to eth1. It seems to me that I don't really need the Realtek adapter to have DHCP and such, as long as it will wake the system. Is that even possible?

The wake on lan is handled at the MAC level. Your eth1 should not need an address, however it should be recognized.

In order to assign it an address, you have to modify the rc.inet1 script and look for the [1] variables.

It could also be done manually with ifconfig.

ifconfig eth1 up

I do get an IP address on eth0 (Intel), but the Realtek adapter is still not assigned to eth1. It seems to me that I don't really need the Realtek adapter to have DHCP and such, as long as it will wake the system. Is that even possible?

The wake on lan is handled at the MAC level. Your eth1 should not need an address, however it should be recognized.

ifconfig eth1 up

Will this assign eth1 to the Realtek adapter, or just enable it? The problem is that if I enter

ethtool eth1

I get an error saying the interface cannot be found. Without any modifications to the network configuration,

ethtool eth0

will give me info on the Realtek adapter, and

ethtool eth1

about the Intel adapter.

I do get an IP address on eth0 (Intel), but the Realtek adapter is still not assigned to eth1. It seems to me that I don't really need the Realtek adapter to have DHCP and such, as long as it will wake the system. Is that even possible?

The wake on lan is handled at the MAC level. Your eth1 should not need an address, however it should be recognized.

ifconfig eth1 up

Will this assign eth1 to the Realtek adapter, or just enable it? The problem is that if I enter

ethtool eth1

I get an error saying the interface cannot be found. Without any modifications to the network configuration,

ethtool eth0

will give me info on the Realtek adapter, and

ethtool eth1

about the Intel adapter.

I don't have the complete answer to this.

eth# is assigned based on how the modules are loaded.

Look in your syslog to see that the module was loaded and if eth1 was assigned to the realtek adapter.