No Wired Network connection on Slackware 13.1 new install [SOLVED]
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No Wired Network connection on Slackware 13.1 new install [SOLVED]
I am not new to Linux (Old Gentoo User) but new to Slackware. I have installed 13.1, the network card is found, the dhcp seems to work on bootup giving the correct address to eth0, but the address is not shown in the route, and there is no connection to the network.
Here is some info:
ifconfig -a
Aug 16 17:59:17 scorpio dhcpcd: eth0: leased 192.168.0.3 for 86400 seconds
Aug 16 17:59:17 scorpio kernel: e1000e 0000:04:00.0: eth0: changing MTU from 1500 to 576
Aug 16 17:59:17 scorpio dhcpcd: eth0: MTU set to 576
Aug 16 17:59:17 scorpio dhcpcd: eth0: carrier lost
Aug 16 17:59:17 scorpio dhcpcd: eth0: MTU restored to 1500
Aug 16 17:59:17 scorpio kernel: e1000e 0000:04:00.0: eth0: changing MTU from 576 to 1500
Aug 16 17:59:20 scorpio kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Aug 16 17:59:20 scorpio dhcpcd: eth0: carrier acquired
Aug 16 17:59:20 scorpio kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 16 17:59:20 scorpio dhcpcd: eth0: rebinding lease of 192.168.0.3
Aug 16 17:59:25 scorpio dhcpcd: eth0: acknowledged 192.168.0.3 from 192.168.0.1 `˙'
Aug 16 17:59:25 scorpio dhcpcd: eth0: checking for 192.168.0.3
Aug 16 17:59:30 scorpio dhcpcd: eth0: leased 192.168.0.3 for 86400 seconds
Aug 16 17:59:30 scorpio kernel: e1000e 0000:04:00.0: eth0: changing MTU from 1500 to 576
Aug 16 17:59:30 scorpio dhcpcd: eth0: MTU set to 576
Aug 16 17:59:30 scorpio dhcpcd: eth0: carrier lost
Aug 16 17:59:30 scorpio dhcpcd: eth0: MTU restored to 1500
Aug 16 17:59:30 scorpio kernel: e1000e 0000:04:00.0: eth0: changing MTU from 576 to 1500
Aug 16 17:59:33 scorpio kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Aug 16 17:59:33 scorpio dhcpcd: eth0: carrier acquired
Aug 16 17:59:33 scorpio kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 16 17:59:33 scorpio dhcpcd: eth0: rebinding lease of 192.168.0.3
I've no idea what the `˙' after the address is all about???
/etc/resolv.conf - nothing in there
I even installed the latest e1000e linux driver from Intel.
I have tried DHCP, Fixed IP adressing, and even dhclinet and installed wicd and used that! All failed!
I have looked at all of the Slackware manuals, and FAQs and Troubleshooting, as well as trawling the forums.
I have not added anything to Slack, just got it running on a fresh install.
I thought I should have a go with Slackware, and see how I got on, but you cannot do anything without a functioning network.
Any ideas?
Thanks
Well, did you turn on debug in /etc/rc.d/rc.inet1.conf?
DEBUG_ETH_UP="YES"
Yes I did.
Code:
Is there anything in /etc/dhcpc/ ?
Nothing there
Hmm. Had you done that prior to collecting the logs that you posted earlier?
Take a look at "man dhcpcd-run-hooks". You may want to set up your own /etc/dhcpcd.enter-hook script and dump out further debugging info for the TEST, NOCARRIER, INFORM, and CARRIER reasons. (That MTU change is weird.)
There might be some artifacts coming and going in various /var/run/dhcpcd subdirectories.
Hmm. Had you done that prior to collecting the logs that you posted earlier?
Yes I had set DEBUG_ETH_UP="YES" before logs
I have had a llook at the man pages you suggest, but quite honestly I have no idea how to use these hooks, can you suggest how I might use them?
I have tried setting /etc/resolv.conf manually, but that makes no difference.
I have even tried disabling the onboard lan and putting a different ethernet card in the machine, but the problem remains the same.
Thanks
After alot more fiddling about I found that on installing 32bit Slackware 12.2 the network functioned normally.
I reinstalled 13.1 and then came across this post so by clearing the entries in /etc/rc.d/rc.inet1.conf and running
dhclient eth0
the card was properly configured, and the network woke up!
I have added this line to /etc/rc.d/rc.local and all is well.
Thanks for the input.
The problem with putting that in rc.local, in general, is that network daemons have already been started because rc.local is run at the end of the boot process. Knowing that people may have complex networking setups for which rc.inet1 may fall short, and that dhcpcd does not always work with every router out there (this is one of those cases), I would like to propose the following change in rc.M to the Slackware team:
Code:
--- rc.M 2010-08-18 20:36:15.081228275 +0200
+++ rc.M.new 2010-08-18 20:41:34.525228484 +0200
@@ -86,6 +86,9 @@
if [ -x /etc/rc.d/rc.inet1 ]; then
. /etc/rc.d/rc.inet1
fi
+if [ -x /etc/rc.d/rc.inet1.local ]; then
+ /etc/rc.d/rc.inet1.local
+fi
# Look for additional USB/SCSI/IEEE1394/etc devices on multiple LUNs:
if [ -x /etc/rc.d/rc.scanluns ]; then
This way, if there is an executable file /etc/rc.d/rc.inet1.local, it's run after rc.inet1. With this hook, people could easily write their own procedure to bring the network hardware up when rc.inet1 is not enough. Two notes:
It's executed after rc.inet1 and not instead of rc.inet1. rc.inet1 brings up the lo interface, so it's better to let it do that work first or everyone would have to set up the lo interface if they write a rc.inet1.local script.
Second, it's not sourced but simply executed. This gives more flexibility and, even if they write it as a shell script in most cases, protects the rest of rc.M if the user wants to write a complex script that runs "exit" at some points.
With that addition, the OP would only need to create /etc/rc.d/rc.inet1.local with the following contents:
Code:
#!/bin/sh
/sbin/dhclient eth0
And he would have his network interface up and running using dhclient instead of dhcpcd, and before the network daemons start.
Me neither. I only know DHCP from the user level, but it's not the first and won't be the last time someone faces a problem with dhcpcd not working, and dhclient working, or vice-versa. I see that from time to time in the IRC channel too.
Edit: also, this applies to different versions of dhcpcd as well (dhcpcd A.B not working and dhcpcd C.D working).
Hmm. Had you done that prior to collecting the logs that you posted earlier?
Yes I had set DEBUG_ETH_UP="YES" before logs
I have had a llook at the man pages you suggest, but quite honestly I have no idea how to use these hooks, can you suggest how I might use them?
I have tried setting /etc/resolv.conf manually, but that makes no difference.
I have even tried disabling the onboard lan and putting a different ethernet card in the machine, but the problem remains the same.
Thanks
Well, the simplest thing would be to copy the 01-test script and change it a little bit...
Code:
#! /bin/bash
DUMPFILE=/tmp/dhcpc-dump.txt
case $reason in
TEST|NOCARRIER|INFORM|CARRIER|BOUND)
echo "The reason was $reason" >>${DUMPFILE}
set | grep "^\(interface\|metric\|pid\|reason\|skip_hooks\)=" | sort >>${DUMPFILE}
set | grep "^\(new_\|old_\)" | sort >>${DUMPFILE}
;;
*)
echo "Not dumping for reason $reason" >>${DUMPFILE}
;;
esac
The above code wrote the following for my system as it came up (via "/etc/rc.d/rc.inet1 restart"):
Code:
Not dumping for reason PREINIT
The reason was CARRIER
interface=eth0
pid=21493
reason=CARRIER
skip_hooks=lookup-hostname
The reason was BOUND
interface=eth0
pid=21493
reason=BOUND
skip_hooks=lookup-hostname
new_broadcast_address=172.16.0.255
new_dhcp_lease_time=3600
new_dhcp_message_type=5
new_dhcp_rebinding_time=3150
new_dhcp_renewal_time=1800
new_dhcp_server_identifier=172.16.0.1
new_domain_name=home.flacy
new_domain_name_servers=172.16.0.1
new_ip_address=172.16.0.2
new_network_number=172.16.0.0
new_ntp_servers=172.16.0.1
new_routers=172.16.0.1
new_subnet_cidr=24
new_subnet_mask=255.255.255.0
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
