[SOLVED] slackware dhcpcd IP renewal: need to specify eth name to get IP
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
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.
slackware dhcpcd IP renewal: need to specify eth name to get IP
I just realized that since I reinstalled slackware on my laptop, the machine is not obtaining an IP from my router during the startup proccess like it used to do before.
Now I see something like:
Code:
dhcpcd: eth0: waiting for carrier
dhcpcd: eth0: timed out
dhcpcd: eth0: waiting 8 sec
and it fails. After I login in KDE, I need to manually renew (or acquire) an IP. Issuing the command
Code:
/etc/rc.d/rc.inet1 start
or
Code:
/etc/rc.d/rc.inet1 restart
will result in the same errors as above and no IP will be obtained.
TO successfully obtain an IP I need to issue one of the above commands with specifying the interface name such as:
Quote:
/etc/rc.d/rc.inet1 eth0 start
and an IP will be obtained.
I never had to do that before. This machine has a wifi card (wlan0) as well as the eth0 Broadcom gigabit adapter.
/etc/rc.d/rc.inet1.conf
Code:
# /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:
IPADDR[0]=""
NETMASK[0]=""
USE_DHCP[0]="yes"
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]=""
# Config information for eth3:
#IPADDR[3]=""
#NETMASK[3]=""
#USE_DHCP[3]=""
#DHCP_HOSTNAME[3]=""
# Default gateway IP address:
GATEWAY=""
# Change this to "yes" for debugging output to stdout. Unfortunately,
# /sbin/hotplug seems to disable stdout so you'll only see debugging output
# when rc.inet1 is called directly.
DEBUG_ETH_UP="no"
## Example config information for wlan0. Uncomment the lines you need and fill
## in your info. (You may not need all of these for your wireless network)
#IFNAME[4]="wlan0"
#IPADDR[4]=""
#NETMASK[4]=""
#USE_DHCP[4]="yes"
#DHCP_HOSTNAME[4]="icculus-wireless"
#DHCP_KEEPRESOLV[4]="yes"
#DHCP_KEEPNTP[4]="yes"
#DHCP_KEEPGW[4]="yes"
#DHCP_IPADDR[4]=""
#WLAN_ESSID[4]=BARRIER05
#WLAN_MODE[4]=Managed
##WLAN_RATE[4]="54M auto"
##WLAN_CHANNEL[4]="auto"
##WLAN_KEY[4]="D5AD1F04ACF048EC2D0B1C80C7"
##WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=96389dc66eaf7e6efd5b5523ae43c7925ff4df2f8b7099495192d44a774fda16"
#WLAN_WPA[4]="wpa_supplicant"
#WLAN_WPADRIVER[4]="ndiswrapper"
## Some examples of additional network parameters that you can use.
## Config information for wlan0:
#IFNAME[4]="wlan0" # Use a different interface name nstead of
# the default 'eth4'
#HWADDR[4]="00:01:23:45:67:89" # Overrule the card's hardware MAC address
#MTU[4]="" # The default MTU is 1500, but you might need
# 1360 when you use NAT'ed IPSec traffic.
#DHCP_KEEPRESOLV[4]="yes" # If you dont want /etc/resolv.conf overwritten
#DHCP_KEEPNTP[4]="yes" # If you don't want ntp.conf overwritten
#DHCP_KEEPGW[4]="yes" # If you don't want the DHCP server to change
# your default gateway
#DHCP_IPADDR[4]="" # Request a specific IP address from the DHCP
# server
#WLAN_ESSID[4]=DARKSTAR # Here, you can override _any_ parameter
# defined in rc.wireless.conf, by prepending
# 'WLAN_' to the parameter's name. Useful for
# those with multiple wireless interfaces.
#WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=thekey"
# Some drivers require a private ioctl to be
# set through the iwpriv command. If more than
# one is required, you can place them in the
# IWPRIV parameter (separated with the pipe (|)
# character, see the example).
What is wrong? eth0 is my main interface, I never use the wifi so no need to have it functional, but I dont want to completely disable it in case I go somewhere where wifi is the only way of connecting...
Markus, heres the output of ifconfig after the system booted, and just before I issue the renewal command...
Code:
root@dell:/home/lpallard# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:1d:09:48:97:c8
inet6 addr: fe80::21d:9ff:fe48:97c8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1463 (1.4 KiB) TX bytes:492 (492.0 B)
Interrupt:17
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:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)
wlan0 Link encap:Ethernet HWaddr 00:1f:3b:7b:ba:e5
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)
Then I issues the renew command to get an IP
Code:
root@dell:/home/lpallard# /etc/rc.d/rc.inet1 eth0 restart
Polling for DHCP server on interface eth0:
dhcpcd: version 5.2.2 starting
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: offered 192.168.0.106 from 192.168.0.100
dhcpcd: eth0: acknowledged 192.168.0.106 from 192.168.0.100
dhcpcd: eth0: checking for 192.168.0.106
dhcpcd: eth0: leased 192.168.0.106 for 28800 seconds
dhcpcd: forking to background
Markus, the dhcp server is a pfsense box that I built around 9 months ago and always worked perfectly. In fact, I have this problem since I reinstalled slackware from scratch 2 days ago... and it happens only on this laptop. My other machines are still getting IPs from the pfsense router wiithout a glitch
mh, I can't seem to find a failure in your configuration, but I have sometimes similar issues with Slackware.
Could you please post the output of lspci for the wired and wireless network-card of your laptop? .... and please look at the output of lspci with the -v option, it gives a more verbose output and at the end of each device-section it shows the module which is yet loaded for the device. Maybe it is of interest to look at these.
In the kernelsources there is another module available "bnx2", here an abstract of the helptext
Code:
Broadcom NetXtremeII support (BNX2)
CONFIG_BNX2:
This driver supports Broadcom NetXtremeII gigabit Ethernet cards.
To compile this driver as a module, choose M here: the module
will be called bnx2. This is recommended.
I'd recommend to unload the tg3 driver and try if the bnx2 driver works, if it does, I'd blacklist the tg3 driver, configure the bnx2 to be loaded at systemstart and try if DHCP then works properly at systemstart.
Markus
[EDIT] I'm running the 2.6.37 kernel yet and looked in it's sources[/EDIT]
Last edited by markush; 01-21-2011 at 05:38 PM.
Reason: typo
Markus, I tried unloading tg3 and loading bnx2 instead. When I issue the command /etc/rc.d/rc.inet1 restart, it quickly finishes and using ifconfig -a reveals that eth0 is simply non-existent:
So I believe bnx2 does not support my ehterner adapter. In fact the helpfile says NetXtremeII whereas my lspci says that I have NetXtreme (not II).... Do you think it has something to do?
Well, maybe, in first sight I thought the bnx2 module would be the adequate choice, but if it doesn't work the tg3 module probably is the best solution and your problem therefore has nothing to do with the driver. At least you have one possible reason for your problem excluded, namely the module.
Mmmm pretty interesting. I have the feeling that it has something to do with the new kernel I am using. I upgraded from 2.6.33.4 (huge kernel) to 2.6.37 from kernel.org...
Unless there is no new bugs or glitch in the kernel, there might be an option I forgot to activate or unset?
You should be able to run that on your pfSense firewall too.
You'll at least get an idea as to what your DHCP server and client are doing. You should see bidirectional traffic, which looking at the initial post you made, I'm inclined to believe your DHCP server isn't answering at all. I'm guessing you'll be seeing traffic going from the client but nothing coming back.
thank you for your post, this is an interesting suggestion. The reason for me to ask about the DHCP-server (post #4) was the same, but since lpallard didn't experience this issue with his old kernel and other Computers I thought that it must be an issue of the system on the laptop... Long story short, do you think that it can be an issue of both systems (laptop and DHCP-server) together?
I have similar issues with my netbook with Gentoo and my wireless network, haven't found a solution yet. The problem there was that it works with Slackware64 but not with Gentoo. I've also tried tcpdump on it, but maybe I'm not experienced enough to find the needle in the haystack. So I'm following this thread and hope I'll find some usefull informations for my system.
thank you for your post, this is an interesting suggestion. The reason for me to ask about the DHCP-server (post #4) was the same, but since lpallard didn't experience this issue with his old kernel and other Computers I thought that it must be an issue of the system on the laptop... Long story short, do you think that it can be an issue of both systems (laptop and DHCP-server) together?
I have similar issues with my netbook with Gentoo and my wireless network, haven't found a solution yet. The problem there was that it works with Slackware64 but not with Gentoo. I've also tried tcpdump on it, but maybe I'm not experienced enough to find the needle in the haystack. So I'm following this thread and hope I'll find some usefull informations for my system.
Markus
Hello Markus!
I really don't know what the problem is, and having a networking background, my approach is to start there.
I thought if we could see the traffic we might get a clue as to what the problem is. There could be a response from the server that might provide a clue, so it never hurts to take a look. tcpdump is an excellent tool to use to diagnose things, one I use often and consider one of the best there is.
Looking at the behavior that lpallard reported, I don't think we'll see a response from the server, but you never know until you look. I'm guessing there is a problem with the DHCP request that is sent out, which is why the server doesn't respond. Once we see that request, we'll have something that we can compare against a proper request and then run some searches to see if there is a fix out there. That tcpdump command might not even be detailed enough. Might have to dig into the packet deeper, but this is a good place to start.
It does seem strange that the interface doesn't get a DHCP lease initially, then when restarting it it works. The easiest way to capture the first DHCP requests at boot might be at the firewall/router or whatever is acting as a DHCP server if that is possible. I use a Vyatta firewall and an OpenWRT router that is positioned between the firewall and my lan, both of which have tcpdump installed. Makes things easier to diagnose if there is a problem, and lpallard mentioned he's using a pfSense firewall, which has packages for tcpdump available as I recall. I used a pfSense firewall for several months a few years ago and remember using tcpdump on it.
Hmmnn...I'm going to see if I can run a few searches now for issues on this. I know that the both of you have probably done this already, but sometimes it just takes a different set of eyes on the issue.
The problem is probably some sort of strange module/library incompatibility. Might have to run an strace session on the dhcp command. Haven't used that tool in quite a while.
Well, I have several times experienced the problem with Slackware, that the DHCP-request went (apparently) normal, and then after a valid IP-adress was offered (in my case 192.168.178.26 for example) my Slackware-laptop checked for an apipa adress (169.254..../16), and used this one. Then after manually running "dhcpcd wlan0" as root, the laptop got a valid adress via DHCP. As far as I remember I had this problem only with Slackware and the wireless network, but didn't search for a solution yet since it happened only a few times.
I agree that tcpdump is a very valuable tool, I have often used it on my Linux-netbook when I'm working within Windows-networks since they (M$) don't have such programs which are quickly installable on a Windows-computer.
So let's wait what lpallard has to say. Anyway thanks for your information, I find it very useful.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
