When attempting to build/use my own vanilla 2.4.7 kernel, i get errors when its trying to bring up the interfaces 'lo' and 'eth0'. The error it reports is 'protocol not supported' on both interfaces. The kernel is build with IPv4 support enabled and Unix Sockets. (No ipx, apletalk, etc). When manualy bringup up the interfaces (ifup lo, ifup eth0), both give the same failure message (protocol not supported, delaying $INT initialisation). However 'eth0' does show up in ifconfig, and is sending/recieving packets (judging by RX/TX fields), however 'using' the interface is imposible (tcp/udp/icmp). Also route shows no entries in the routing table. To verify that this was indeed a 'bug' i took a known-to-be-working-self-build-kernel from one of my other boxes (running rh 7.1), which used the same network card/scsi adapter.. When booting that working-kernel, i still got the same error when the interfaces are brought up. So a configuration error doesnt seem to be the case.. The bugzilla DB, nor the release-notes seem to mention any 'changes' to the way 'standard' network interfaces work.. When building a fresh kernel from the kernel-..-src.rpm, everything works fine. So it seems to be a reliance on a certain kernel patch (or config) that is 'not standard'
Created attachment 26613 [details] Configuration of my self-build-kernel
By doing a diff between your config and ours, this came up: -CONFIG_PACKET=y +CONFIG_PACKET=m the dhcp program needs that........ could you try loading the relevant module first and see if that helps ?
Tried it, and doesnt help. However (i for to mention, i know), i don't use DHCP, but static IP addresses And i also strongly presume 'lo' never will use nor touch dhcp? <grin>. ifcfg-eth0: DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.0.255 IPADDR=192.168.0.2 NETMASK=255.255.255.0 NETWORK=192.168.0.0 ONBOOT=yes ifcfg-lo: DEVICE=lo IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 # If you're having problems with gated making 127.0.0.0/8 a martian, # you can change this to something else (255.255.255.255, for example) BROADCAST=127.255.255.255 ONBOOT=yes NAME=loopback
ps, as mentioned in the the CONFIG_PACKET=m documentation, i also added alias net-pf-17 af_packet to /etc/modules.conf ... Also it works perfectly on all the other boxes i maintain (running various rh versions.. 6.1 / 6.2 / 7.0 / 7.1), so this is definatly 'new' behaviour as far as i can tell.
Would be possible to "strace -f" the ifup ? So that we can see what actually fails...
Created attachment 26635 [details] TAR file containing output from : dmesg / messages / ifconfig / lsmod / strace -f ifup & down of lo and eth0
Could you try removing the "if check_link_down" section from the ifup script? This seems to cause trouble for a lot of people.
We (Red Hat) really need to fix this defect before next release.
I removed the 'if check_link_down' section of the ifup script. This resulted in the -same- error while bringing up interface 'lo' (Module not found 'lo', delaying interface...), and NO errors while bringing up the interface 'eth0'. However eth0 was still unusable (did show up in ifconfig, wouldnt ifdown, network unreached on any attempt of making it do anything IP related, including pinging its own IP). (See my prev posted messages.tar for a lot of output & strace information, the errors seem the same still). Last, the 'dump' error (see messages.tar : messages) i get when upping 'lo' still seems extremely weird... neither lo nor eth0 use dhcp, and i presume 'lo' never should/would/will. So this error would indicate to me the if tools scripts are a bit 'wacko' ? Dont know if this presumption works though
What happens if you turn on CONFIG_RTNETLINK?
Enabled CONFIG_RTNETLINK in the kernel, also set the af_packet to y instead of m, yet getting the same results : gandalf ifup: Cannot send dump request: Connection refused gandalf modprobe: modprobe: Can't locate module net-pf-4 gandalf modprobe: modprobe: Can't locate module net-pf-5 gandalf ifup: Cannot send dump request: Connection refused gandalf ifup: Error adding address 192.168.0.2 for eth0. gandalf ifup: Cannot send dump request: Connection refused gandalf ifup: bind: Cannot assign requested address gandalf ifup: Cannot send dump request: Connection refused gandalf ifup: SIOCADDRT: Network is unreachable gandalf network: Bringing up interface eth0: succeeded The weird thing to me is still this error with the interfaces about net-pf-4 and net-pf-5. I wouldnt know which protocol that is.. Also the 'Cannot send dump request' puzles me... The 'bringing up ... eth0: succeeded' is due to removing 'if check_link_down' i presume? All this leaves me without 'lo' and a non functional 'eth0' and empty routes, etc.. (see messages.tar for more detailed outputs)
net-pf-4 & net-pf-5 are IPX and appletalk. They shouldn't be relevant. The only other thing I can see that *might* be relevant is CONFIG_FILTER. But I would think that CONFIG_NETLINK/CONFIG_RTNETLINK set you 'Y' should do it.
ok, i tried to build a plain vanilla 2.4.7 kernel using the config.athlon configuration from the RH 2.4.6 SRPMS. Using this kernel, the interfaces DO function! So Roswel seems to depend on a functionality/setting in the kernel, that previously was not mandatory, nor documented, not shared by any other linux platform (including previous RH's) :-) Next, i'll try enabling IPX/AppleTalk with 'my kernel config', and see if that makes anything of a difference. > The only other thing I can see that *might* be relevant is CONFIG_FILTER. The redhat's .config's also have CONFIG_FILTER enabled .. Also some of the other kernel's i tried (copied from other boxen) didnt have CONFIG_FILTER, so that shouldnt be the problem. Last I would presume that a standard plain and clean IPv4 setup in the kernel should be enough to get IPv4 networking? :)
Reassigning to kernel; I don't see how this is an initscripts problem.
> I don't see how this is an initscripts problem Actualy in my perspective it would have to be an initscript problem... ie: a initscipt dependancy to a kernel setting(s) that is 'non-standard'. As mentioned before, i get the same results with a know-to-be-working kernel copied from another box .. Also when taking the kernel config from the SRPMS RH kernel, applying that to a standard vanilla kernel does provide a working situation ... However 'just' having a standard IPv4 envirioment (with and/or without af_packet, ipx, appletalk, netfilter, unix_sockets) doesnt work ... So somewhere the if-scripts seem to depend on a kernel setting thats 'non standard'.. However, which setting, i have yet to discover :) Basicly it means that most ppl's own kernel configurations will fail to work, although they do on other linux distributions (including rh 6-.x>71). This doesnt seem like a desiriable situation :)
Look, if the kernel team is going to claim this is
bah, never mind my babbling.
I've just checked with a custom ext3 build here, and CONFIG_RTNETLINK is indeed required for a dhcp ifup in Roswell. It was not needed in 7.1.
CONFIG_RTNETLINK and CONFIG_NETLINK should be all that you need; if that doesn't work, I think your kernel install might be somehow fubar? This was caused by the switch to /sbin/ip; it requires NETLINK and RTNETLINK to function properly. It is impossible to make use of the kernel's full routing functionality without these two things enabled. These will probably become standard features in future kernels.