LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Funky NIC configurations - MAXNICS setting in /etc/rc.d/rc.inet1too low. (http://www.linuxquestions.org/questions/slackware-14/funky-nic-configurations-maxnics-setting-in-etc-rc-d-rc-inet1too-low-672210/)

kfanyo 09-25-2008 12:40 AM

Funky NIC configurations - MAXNICS setting in /etc/rc.d/rc.inet1too low.
 
Hi,

I have three Linux boxes, one of which is our internet gateway that has 5 NICs in it. I use ultra cheap (a la eBay) PCI PNP NICs based on the Realtek 8139 chip for 10/100 connections and the Realtek 8169 chip for 10/100/1000 traffic. To make a really long, convoluted story short, I've found that the current NIC setup and configuration files in Slackware may be failing to find NICs that may be subsequently assumed to be bad and tossed or otherwise abused.

I was going to post a long narrative about I fell onto this but decided to more or less let the script code speak for itself.

There are four snippets here; two sets of rc.inet.conf snips and the output of 'ifconfig' after running '/etc/rc.d/rc.inet1' with an rc.inet.conf containing each of the rc.inet.conf snippets.

I have populated the stanzas with IP and netmask data so that rc.inet1 script can have something to work with. The IP addresses are completely bogus and are written to 1)be absurd, and 2)to help indicate which interface number a NIC may have been assigned...

Anyway, the "short" set is as follows (This is the 'standard' number of
stanzas you will find in rc.inet.conf after a new installation of Slackware):

/etc/rc.d/rc.inet.conf (Short)
Code:

# Config information for eth0:
IPADDR[0]="10.252.252.230"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]="no"
DHCP_HOSTNAME[0]=""

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

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

# Config information for eth3:
IPADDR[3]="10.252.252.233"
NETMASK[3]="255.255.255.0"
USE_DHCP[3]="no"
DHCP_HOSTNAME[3]=""

Output of ifconfig (after running 'rc.inet1 restart')
Code:

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3484784 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3484784 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:208995127 (199.3 MiB)  TX bytes:208995127 (199.3 MiB)

As you can see, there are no interfaces configured even though there are five NICs (Four in PCI slots and one integrated) in the machine.

Now, the "long" set is as follows:

/etc/rc.d/rc.inet.conf (Long)
Code:

# Config information for eth0:
IPADDR[0]="10.252.252.230"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]="no"
DHCP_HOSTNAME[0]=""

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

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

# Config information for eth3:
IPADDR[3]="10.252.252.233"
NETMASK[3]="255.255.255.0"
USE_DHCP[3]="no"
DHCP_HOSTNAME[3]=""

# Config information for eth4:
IPADDR[4]="10.252.252.234"
NETMASK[4]="255.255.255.0"
USE_DHCP[4]="no"
DHCP_HOSTNAME[4]=""

# Config information for eth5:
IPADDR[5]="10.252.252.235"
NETMASK[5]="255.255.255.0"
USE_DHCP[5]="no"
DHCP_HOSTNAME[5]=""

# Config information for eth6:
IPADDR[6]="10.252.252.236"
NETMASK[6]="255.255.255.0"
USE_DHCP[6]="no"
DHCP_HOSTNAME[6]=""

# Config information for eth7:
IPADDR[7]="10.252.252.237"
NETMASK[7]=""
USE_DHCP[7]="no"
DHCP_HOSTNAME[7]=""

# Config information for eth8:
IPADDR[8]="10.252.252.238"
NETMASK[8]="255.255.255.0"
USE_DHCP[8]="no"
DHCP_HOSTNAME[8]=""

# Config information for eth9:
IPADDR[9]="10.252.252.239"
NETMASK[9]="255.255.255.0"
USE_DHCP[9]="no"
DHCP_HOSTNAME[9]=""

# Config information for eth10:
IPADDR[10]="10.252.252.240"
NETMASK[10]="255.255.255.0"
USE_DHCP[10]="no"
DHCP_HOSTNAME[10]=""

# Config information for eth11:
IPADDR[11]="10.252.252.241"
NETMASK[11]="255.255.255.0"
USE_DHCP[11]="no"
DHCP_HOSTNAME[11]=""

# Config information for eth12:
IPADDR[12]="10.252.252.242"
NETMASK[12]="255.255.255.0"
USE_DHCP[12]="no"
DHCP_HOSTNAME[12]=""

# Config information for eth13:
IPADDR[13]="10.252.252.243"
NETMASK[13]="255.255.255.0"
USE_DHCP[13]="no"
DHCP_HOSTNAME[13]=""

# Config information for eth14:
IPADDR[14]="10.252.252.244"
NETMASK[14]="255.255.255.0"
USE_DHCP[14]="no"
DHCP_HOSTNAME[14]=""

# Config information for eth15:
IPADDR[15]="10.252.252.245"
NETMASK[15]="255.255.255.0"
USE_DHCP[15]="no"
DHCP_HOSTNAME[15]=""

Output of ifconfig (after running 'rc.inet1 restart')

Code:

eth4      Link encap:Ethernet  HWaddr 00:A0:0C:C8:A1:E2 
          inet addr:10.252.252.234  Bcast:10.252.252.255  Mask:255.255.255.0
          inet6 addr: fe80::2a0:cff:fec8:a1e2/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53786582 errors:10 dropped:322 overruns:9 frame:0
          TX packets:37516206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:534386965 (509.6 MiB)  TX bytes:3097172327 (2.8 GiB)
          Interrupt:11 Base address:0xd000

eth7      Link encap:Ethernet  HWaddr 00:07:95:CC:B2:24 
          inet addr:10.252.252.237  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0xd400

eth9      Link encap:Ethernet  HWaddr 00:B0:C0:03:60:87 
          inet addr:10.252.252.239  Bcast:10.252.252.255  Mask:255.255.255.0
          inet6 addr: fe80::2b0:c0ff:fe03:6087/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13816238 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20258231 errors:1 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000
          RX bytes:3601215805 (3.3 GiB)  TX bytes:3609230685 (3.3 GiB)
          Interrupt:11 Base address:0x2800

eth10    Link encap:Ethernet  HWaddr 00:B0:C0:03:50:8A 
          inet addr:10.252.252.240  Bcast:10.252.252.255  Mask:255.255.255.0
          inet6 addr: fe80::2b0:c0ff:fe03:508a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18524524 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25327976 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3577065765 (3.3 GiB)  TX bytes:4276777228 (3.9 GiB)
          Interrupt:5 Base address:0x4400

eth11    Link encap:Ethernet  HWaddr 00:1D:0F:22:EC:A2 
          inet addr:10.252.252.241  Bcast:10.252.252.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:fff:fe22:eca2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9956537 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19721248 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3789151779 (3.5 GiB)  TX bytes:4212299310 (3.9 GiB)
          Interrupt:11 Base address:0xee00

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3484784 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3484784 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:208995127 (199.3 MiB)  TX bytes:208995127 (199.3 MiB)

Now all NICs are configured and available but id's eth[123568] were not used. If you had just filled in the values for the stock rc.inet.conf file, none of the NICs would be found. However, if you had increased the number of stanzas in the config file to allow for five interfaces, you would have "found" one (eth4). If you remove the stanzas related to the eth#'s that weren't used, everything works fine.

The cards I get are so cheap that I am inclined to toss one without much thought if it doesn't configure on the first try. I'm afraid this is happening with other folks, too.

Anyway, if you have a NIC lying around that doesn't seem to work but should, save your working conf file, populate the working conf file with the info above, set MAXNICS in rc.inet1 to 16, restart rc.inet1 and see if ifconfig will be willing to talk about it then. I have another machine whose two interfaces configure to eth0 and eth13 (thirteen). If you remove the 'eth0' NIC the other remains at eth13 after rebooting. I have not the slightest idea why.

I wrote to Pat V. and the Slackware folks about this and got no reply. I first noticed all of this with Slack v10 or thereabouts. Googling 'Slackware MAXNICS' gets nothing relevant on the first few pages and this all tells me that I have either stumbled onto something that really deserves some attention or I am re-hashing an old issue that really doesn't.

That's it. Nothing broken, just some weirdness...Thanks for listening.

Regards,

Ken

onebuck 09-25-2008 05:32 AM

Hi,

You should look at the '/etc/udev/rules.d/70-persistent-net.rules'. If you don't change the network rules then the NIC assignment will be the same.

BTW, it would be nice if you place your code snippets in vbcode tags, use the # at the top of the reply window. You can still edit your post to place the data within tags.

kfanyo 09-25-2008 09:15 AM

Hi, Onebuck,

Thanks for the info about why such things occur. I can't recall with certainty when udev made its first appearance in Slackware (I want to say v11.0) but this NIC business has been a consideration for me since v10.

Anyway, the issue I have is that for a user who just wants to upgrade and get on with his/her WORK without having to delve into the innermost Slackware, udev and the stock rc.inet* files effectively make up a broken configuration. It looks like the ability of your system to use a particular NIC is to be determined--without intervention--by some esoteric processing of the NIC's MAC address. Oh, wow, THAT's cool...

I like to think I read the CHANGES and HINTS file and I don't recall anything that gently and respectfully suggests:

HEY!!!!! When using a system with multiple network interfaces with udev for the first time, You MUST be prepared to edit either '/etc/udev/rules.d/70-persistent-net.rules' or '/etc/rc.d/rc.inet.conf' to reflect or rectify the changes that udev WILL impose on your system. That is, either edit /etc/udev/rules.d/70-persistent-net.rules' to contain NIC info consistent with '/etc/rc.d/rc.inet.conf' or vica versa. If you don't take this step, it is quite possible that your network configuration WILL BREAK INTO TINY, CONFUSING, INFURIATING PIECES and you may put yourself at risk of not liking Patrick Volkerding anymore. And who wants THAT, SlackGeek?

A recent example is psmouse in Slackware 12.1. I recently upgraded to a wide LCD panel so I can rotate it (and the console) and see vast amounts of code on one screen. I upgrade to 12.1 to take advantage of whatever improvements may have been made to better enable/handle console and screen rotation. CHANGES and HINTS just mentions in passing that psmouse is not blacklisted anymore. Okay. whatever. And, on reboot, the mouse cursor is gone, gone, gone. I'm sure you can understand a feeling of being blindsided at this point.

Imagine bringing home a new car and then reading on page 32 (while you are looking for info about the new braking system) that the manufacturer has decided to change the dimmer function for the lights (for whatever IMPORTANT reason) so that high and low beams work in reverse from what they used to. It probably won't occur to you that this is significant until 19 other drivers have flashed you because you are blinding them with your high beams. Are you going to step up and adjust serenely to the new environment or are you going to find yourself subconsciously calculating the cost of returning the damned car like, RIGHT NOW.

People need to be told LOUD and CLEAR about the effects of changes that udev implies. Most are going to run across the 'notice' while looking earnestly at something else and get into (unnecessary, I think) trouble. A few words up front could save a LOT of people a LOT of time late at night when they're trying to fix a SYSTEM broken by the Latest and Greatest Slackware.

Oh, yeah, one more thing: the HUGE config file for compiling the kernel ain't. It's the GENERIC config file.

I yield the soapbox...

Regards,

Ken

--If I didn't like Slackware so much, it wouldn't annoy me so much...

T3slider 09-25-2008 11:42 AM

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
udev was upgraded - don't forget to move/merge all of the associated *.new
files into place or you will have problems. We are now using as much of
the upstream udev rules as possible (and efforts are underway to further
unify us with other distributions), so you'll notice a lot more udev rules
files in that directory. Be sure to heed the warnings about not editing
the included rules files, as they will be overwritten if/when the udev
package is upgraded.
If you have more than one network card and have been using the
75-network-devices.rules file, it is now called 70-persistent-net.rules
(and is generated from 75-persistent-net-generator.rules).
Rules for optical devices are now located in 70-persistent-cd.rules (and
are generated from 75-cd-aliases-generator.rules).
You will need to remove the old rules files (75-optical-devices.rules and
75-network-devices.rules) so that they don't conflict.

As stated above, Slackware's udev implementation will automatically create
rules files for your optical devices and network interfaces on first boot.
If you add/remove/replace any of this hardware, and/or you "clone" a system
to another hard drive for deployment, you will need to either remove these
two rules files (so that udev will regenerate them to reflect the new or
changed hardware) or edit them accordingly.

That is pretty clear to me that if you have multiple network cards (which you do), you should be looking at 70-persistent-net.rules and 75-network-devices.rules. This is stated right in CHANGES_AND_HINTS.TXT, which is considered mandatory reading. What more do you want?
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
The psmouse module is no longer blacklisted by default; instead, it is loaded
with the imps protocol per /etc/modprobe.d/psmouse -- if you need/want a
different protocol, edit that file. Note that options declarations have
no bearing on *if* a module is loaded - they only affect *how* it is loaded.
In other words, the module should now be loaded automatically (since it's no
longer blacklisted), and the options in /etc/modprobe.d/psmouse are the ones
applied when loading it.

The /etc/modprobe.d/blacklist file has been changed significantly; be sure to
move/merge the /etc/modprobe.d/blacklist.new file in its place. Also, you
must NOT leave a backup of the old blacklist file (such as blacklist.orig)
in /etc/modprobe.d/ -- ALL files in that directory are checked, so if a
module is blacklisted in *any* of them, it won't be loaded.

That is pretty clear as well. Maybe instead of complaining that things didn't work right away, you should read the documentation that comes with your Slackware installation. If after reading that THOROUGHLY and applying all of the hints it still doesn't work, then complain. I think you are complaining without any merit whatsoever here. Things didn't automatically work, so you got annoyed and blamed the distro/documentation when all of the instructions are clearly spelled out for you.
Quote:

Originally Posted by kfanyo
Oh, yeah, one more thing: the HUGE config file for compiling the kernel ain't. It's the GENERIC config file.

I'm afraid I don't understand this statement. Can you elaborate? I'm not at my computer right now so I can't check, but I'm almost 100% positive that the huge-smp config file in /boot reflects the huge-smp options and the generic-smp config file reflects the generic-smp options. A diff of the two files should show many differences. But again, I can't check. Regardless, if you want to generate a .config file from the current running kernel (ie boot either the huge-smp or generic-smp kernel), you can do so with the following command:
Code:

zcat /proc/config.gz > .config
I'm pretty sure that is the correct command, but since I'm not at my PC (and since I always use autocompletion in a terminal and don't have that exactly memorized), it *could* be slightly off.

keefaz 09-25-2008 12:13 PM

Yes it is the correct command :)
Really handy, I often use zcat /proc/config.gz | grep -i <something> to check if a feature is enabled or not in the kernel

onebuck 09-25-2008 06:03 PM

Hi,

A lot of people don't read the README.txt files that are provided to the end user. It would be nice if everyone would read them. That way a lot of the problems the user develop wouldn't waste everyone's time if the reference text had been read.

PV and team have given the Slackware community a lot of information that should be required reading before any install. EULA anyone? Just in jest so don't get your shorts in a kink. :)

cwwilson721 09-25-2008 09:28 PM

Quote:

Originally Posted by keefaz (Post 3291594)
Yes it is the correct command :)
Really handy, I often use zcat /proc/config.gz | grep -i <something> to check if a feature is enabled or not in the kernel

Jeez...Another thing that I've been trying to figure out...

THIS one goes near the top of my "Gotta Keep On A Post-It Note" list.

THANK YOU

kfanyo 09-26-2008 01:35 PM

Oh, my, my, my.

Evidently some folks have taken what I have been saying as simply a rant. I'll lower my voice so I can make the content of my message a little more clear.

'/etc/rc.d/rc.inet.conf' comes with 4 stock stanzas, presumably because so few, if any, users are going to have more than four NICs in their systems. These stanzas are numbered sequentially (0-3). They are unpopulated with IP/Netmask info. If the user supplies the info during the configuration segment of Slackware Setup, the first stanza (eth0, NOT eth13) will be populated with the supplied info.

'/etc/rc.d/rc.inet1' comes with a stock MAXNICS setting of 6. When 'rc.inet1' runs it must, as I understand things, find a stanza in '/etc/rc.d/rc.inet.conf' with a number corresponding to the 'eth<#>' interface ID being considered AND the stanza must have meaningful IP/Netmask info (or be set to use DHCP) for the NIC to be properly configured and made usable.

Enter udev. The file Onebuck pointed out to me says the 'eth<#>' associated with the interface is calculated using the MAC address as a base. In my own experience, this can range as high as eth13. I suspect it will max at 15 but--who really knows?--it could go to 31 or beyond.

Okay? Now, watch...

eth13. MAXNICS=6. Four unpopulated stanzas.

This is a broken system that will fail to configure a significant percentage of NICs (About 50% of my mine). Yet there is no accommodation in /etc/rc.d/rc.inet.conf and vanishingly little in /etc/rc.d/rc.inet1 for these udev shenanigans and apparently no need to spell all of this out to folks who never had a problem until 'udev' stepped in to make things so much easier and nicer.

'udev', as I understand it, is designed to make your computer more universally plug 'n' play running Linux. IMHO, it is achieving just the opposite. One of the main reasons I've used Slackware for so long is because it tries to stay on the simple side of things and the Slack folks seemed so accessible. 'udev' is not on the simple side of things and it is not, clearly, nearly as accessible.

I did a simple file count in /lib/udev, /dev/.udev, /etc/udev. 3036 files. This simplifies things? Come on. Call me pessimistic, but I consider every operating system file to also be a PPOF (Potential Point of Failure).

I am clearly underwhelmed by 'udev'.

That is not why I'm posting.

I am posting because the stock network configuration with 'udev' is broken and I fear that a lot of folks are going to find it easier to go elsewhere rather than fraggle a solution that they will likely decide they should not have been required to fraggle because it's so clear the solution could easily be a part of the setup/initialization routines. You know, increased number of stanzas in 'rc.inet.conf', the ability to populate a stanza out of sequence, increased MAXNICS setting. Or, modify '/etc/udev/rules.d/70-persistent-net.rules' as part of the setup routine so that the NICs are assigned consecutive interface numbers. You know, things like that.

RTFM'ing is not going to fix the issue I have been referring to all along, folks. The 'manual' assumes the rc.inet*/udev triad is not a priori broken for a significant percentage of NICs and it is.

If Slackware is satisfied with its place in the server/gateway world, OK. If not, this is an issue that deserves more attention than a paragraph or two in the occasional HINTS file.

Kernels: When I compiled the 2.6.24.5 (12.1) kernel using the 'huge-SMP' config file, the kernel image was half the size of the stock (pre-compiled) 'huge-SMP' kernel. All I did was turn screen rotation. Then, make; make modules; make modules_install; make install. The kernel failed. To be sure, I compiled it a second time and ditto. I compiled with the 'generic' config file and the kernel was of comparable size to the stock 'huge' kernel. For v12.0, The stock 'huge' kernel is just about twice the size of the stock 'generic' one. I think the config file names for v12.1 have been reversed. I'm still sifting through this one, though...

I yield the soapbox...

Regards,

Ken

onebuck 09-26-2008 03:20 PM

Hi,

In order to get to the 'eth13' you state then you some how had multiple recognitions for the udev to set a rule.

How did you break your kernel? What were the errors that you got from the kernel?

Alien Bob 09-26-2008 03:58 PM

I feel a bit sorry to say this, but Slackware is not for you. You are the first person who manages to add 13 (mostly defective) NICs to a Slackware box while failing to notice that every new card's interface name is incremented by one. The Internet is literally overflowing with helpful hints about how to cure that (beneficial!) udev behaviour by removing it's network configuration file "/etc/udev/rules.d/70-persistent-net.rules". Yet you failed to either look for - or find this information. Or decided to just ignore it and get mad at Slackware.
Slackware's network configuration is not broken.

As for kernel compilation - you do not make any sense at all with your story.
Check the output of
Code:

diff /kernels/hugesmp.s/config /source/k/config-generic-smp-2.6.24.7-smp
and note where the huge kernel has all these drivers compiled-in (CONFIG_......=y) versus the generic kernel with the drivers compiled as modules (CONFIG_......=m)?

Eric

kfanyo 09-27-2008 10:51 PM

Crikey...

Biostar M7NCG400, Athlon 2500+, 3G RAM, Bootable RAID1, Data on RAID5, Sound, Video, NICs.

A PC.

The first Slackware version I ever installed was 1.1.2. I patched the kernel to 1.1.23 and it stayed up for a year. I patched the kernel in Slack v3.1 once or twice. I've configured and built the kernel in a couple of versions to support IP Masq'ing. Built one to run Slackware on a laptop with Windows 2000. Otherwise, I've used pre-compiled kernels. Now, I just want to rotate the screen. If Pat, et al., had seen fit to click one more time in the Graphics Kernel Configuration area, I wouldn't be messing with this one. I've been doing this long enough to at least try to avoid fixing things that aren't broken.

I'm hoping that someone will (someday) get that I'm not talking about strange network interface configurations so much as an apparent lack of interest in the Slack folks to rise up and adjust the system to accommodate the new weirdness brought about by 'udev'.

Slackware is just right for me, all in all, and thank you very much. Over the last decade or so I've spent MUCH less time futzing with Slackware Linux than I have Winblows. I had an infatuation with Redhat around RH v5, but, thankfully, I got over it in a very short time.

This list isn't right for me. I'm not talking to hackers or even geeks. I'm talking to acolytes. Bye, y'all...

Crikey...


All times are GMT -5. The time now is 03:08 PM.