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.
I recently switched over to current on my T500 notebook wich has
Code:
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5300
and noticed that with this version dhcpcd fails the to challenge the IP for my wlan0 .. ( for eth0 goes wonder )
Code:
info, wlan0: dhcpcd 3.2.3 starting
info, wlan0: hardware address = 00:21:6a:16:8a:02
info, wlan0: DUID = 00:01:00:01:11:f8:04:bd:00:22:68:0a:74:76
info, wlan0: broadcasting for a lease
debug, wlan0: sending DHCP_DISCOVER with xid 0x6a025829
debug, wlan0: waiting for 30 seconds
debug, wlan0: sending DHCP_DISCOVER with xid 0x6a025829
debug, wlan0: sending DHCP_DISCOVER with xid 0x6a025829
debug, wlan0: sending DHCP_DISCOVER with xid 0x6a025829
debug, wlan0: sending DHCP_DISCOVER with xid 0x6a025829
debug, wlan0: got a packet with xid 0x6a025829
debug, wlan0: no facility to parse DHCP code 23
info, wlan0: offered 192.168.115.5 from 192.168.115.1 `WatchGuard DHCP'
debug, wlan0: sending DHCP_REQUEST with xid 0x6a025829
debug, wlan0: waiting for 17 seconds
debug, wlan0: sending DHCP_REQUEST with xid 0x6a025829
debug, wlan0: sending DHCP_REQUEST with xid 0x6a025829
debug, wlan0: sending DHCP_REQUEST with xid 0x6a025829
debug, wlan0: sending DHCP_REQUEST with xid 0x6a025829
debug, wlan0: sending DHCP_REQUEST with xid 0x6a025829
info, wlan0: trying to use old lease in `/etc/dhcpc/dhcpcd-wlan0.info'
info, wlan0: probing for an IPV4LL address
debug, wlan0: sending ARP probe #1
debug, wlan0: sending ARP probe #2
debug, wlan0: sending ARP probe #3
debug, wlan0: sending ARP claim #1
debug, wlan0: sending ARP claim #2
info, wlan0: adding IP address 169.254.201.130/16
debug, wlan0: no dns information to write
debug, wlan0: writing /etc/dhcpc/dhcpcd-wlan0.info
debug, wlan0: forking to background
info, wlan0: exiting
switching back to 2.0.8 (12.2) fix it ..
Code:
Broadcasting DHCP_REQUEST for 192.168.115.4
broadcastAddr option is missing in DHCP server response. Assuming 192.168.115.255
dhcpIPaddrLeaseTime=86400 in DHCP server response.
DHCP_ACK received from WatchGuard DHCP (192.168.115.1)
Broadcasting ARPOP_REQUEST for 192.168.115.4
Broadcasting DHCP_REQUEST for 192.168.115.4
broadcastAddr option is missing in DHCP server response. Assuming 192.168.115.255
dhcpIPaddrLeaseTime=86400 in DHCP server response.
DHCP_ACK received from WatchGuard DHCP (192.168.115.1)
Broadcasting ARPOP_REQUEST for 192.168.115.4
do I need to modify something to make the new package work ? I did copy the rc.inet1.conf and wpa_supplicant.conf from my 12.2 installation but the script are unchanged from current ...
thank ya
Last edited by NetNightmare; 07-31-2009 at 03:32 AM.
The only option would indeed be to downgrade (or upgrade) your dhcpcd. I seriously doubt that the dhcpcd in Slackware will be upgraded to a 4.x or 5.x version. The risks are too high in case other problems show up, this close to a new Slackware release.
The only option would indeed be to downgrade (or upgrade) your dhcpcd. I seriously doubt that the dhcpcd in Slackware will be upgraded to a 4.x or 5.x version. The risks are too high in case other problems show up, this close to a new Slackware release.
Eric
So, Slack 13 will be shipped with a broken dhcpcd. That doesn't sound like a good idea.
Here's the situation: dhcpcd-3.x is indeed broken in some rare circumstances. This is not the first report we've seen of similar breakage, but the others were fixed by fixing the dhcp server. Granted, the client should be able to work around the server breakage, or even if this is a true dhcpcd issue (and it quite possible *is*), it only affects a few people based on the reports we've gotten.
Contrast that with: dhcpcd-5.x is completely a completely new and untested codebase with many incompatible command-line options and switches, and the package layout is completely different, and there's at least one potential bug (I say potential because I'm not sure) with it already -- and that's based on testing it with a grand total of TWO MACHINES at my house with a known good dhcp server.
Here's the situation: dhcpcd-3.x is indeed broken in some rare circumstances.
It wasn't made clear that this was an "exceptional" circumstance. It was just reported as an known bug.
Quote:
Originally Posted by rworkman
This is not the first report we've seen of similar breakage, but the others were fixed by fixing the dhcp server.
That might be a solution where you control the server as well, but where you have no control over the server, this is not really acceptable.
Quote:
Originally Posted by rworkman
Contrast that with: dhcpcd-5.x is completely a completely new and untested codebase with many incompatible command-line options and switches, and the package layout is completely different, and there's at least one potential bug (I say potential because I'm not sure) with it already -- and that's based on testing it with a grand total of TWO MACHINES at my house with a known good dhcp server.
Isn't there a version 4. How does that stack up.
Quote:
Originally Posted by rworkman
Again, what do you suggest?
Do further testing before releasing the product. DHCP is fundamental to most people's systems. Releasing a product that has a, possibly small, window of failure will not go down too well, especially with the number of alternative distributions available. One of Slack's strong points is how "bullet proof" it is.
So, Slack 13 will be shipped with a broken dhcpcd. That doesn't sound like a good idea.
That is taking a shortcut in reasoning. I know many more programs that have bugs, that will not have been fixed by the time the decision is made to release Slackware 13.0. It is a matter of triage: what do we have to do so that the largest percentage of people have the least amount of issues.
With the current 3.x release of dhcpcd we have had a few reports of problems. The previous 2.x had segfault issues on slackware64 and more than a few bug reports that were not architecture related. The 5.x release is, as rworkman indicated, rewritten mostly from scratch and will contain not-yet-discovered bugs.
The 4.x version may help solve the problem at hand, but still it will not be wise to add this to slackware-current at this time. There will just not be enough time to get it extensive testing. Even this 4.x version works differently from our 3.x.
It is a pity that the development of dhcpcd is currently being done in a seemingly random way, making incompatible changes in the way the commandline parameters work, and having multiple "stable" versions to choose from. We can do nothing about that. It hinders our upgrade path.
All in all: the version of dhcpcd we have in Slackware-current at the moment, works for all but a few people. In my opinion, it is the safest choice to stick with that version. However, it is not my opinion that matters; Pat Volkerding decides.
And as a final thought - if you are one of the few persons experiencing problems with dhcpcd 3.2.3, you can relatively easily grab the SlackBuild/package source for dhcpcd and update it to version 4 yourself. I have done so on one of my boxes where I experienced this, and for what it's worth it's been running trouble-free for a few months now.
That's one of the many great things with Slackware - if there's something you don't like, you can always relatively easily fix/change it yourself!
NOTE though that anyone doing this is on their own and should definitely not bother Pat or other members of the Slackware team about it :-)
That is taking a shortcut in reasoning. I know many more programs that have bugs, that will not have been fixed by the time the decision is made to release Slackware 13.0. It is a matter of triage: what do we have to do so that the largest percentage of people have the least amount of issues.
Sorry, that was a bad choice of words I used.
It's just that dhcpd is so pervasive, that even if a few people experience problems, it could have a negative effect on Slack's reputation.
Just asking as I lack experience in this. Is dhcpcd the best DHCP client currently available? I know there are others like dhclient and pump. Why does Slackware use dhcpcd instead of, say, dhclient, which the BSDs use?
Slackware ships dhclient too. Its part of the dhcp package.
But the init scripts use dhcpd. I don't know the exact reason that's preferred but my guess would be that's because the dhcpd package is only a client,
rather than both a server and a client.
I also had problems with dhcpcd. I have a Verizon MiFi and dhcpcd would refuse to take an address from it. I switched over to dhclient and it works fine.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
dhcpcd 3.2.3 in Salckware current x86
