Puppy 3.00BETA bug reports here

Please post any bugs you have found
Message
Author
tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#106 Post by tempestuous »

dhcpcd update.
rerwin reported a MAC-address misidentification issue with the new version of dhcpcd earlier in this thread, and also on the Developer Forum.
So I emailed the maintainer of the dhcpcd project, Roy Marples, about the problem. Roy's prompt reply was this:

"dhcpcd-3.1 uses client node identifiers, which is correct.

http://www.rfc-archive.org/getrfc.php?rfc=4361

To stop this either disable ENABLE_DUID in config.h or use -I '' on the dhcpcd command line.

Basically, the error is that the DHCP server assumes that the clientID field holds the MAC address.
This assumption is invalid for a few reasons

1) RFC 2131 states that the ClientID is optional
2) RFC 2131 also states that it could be a user defined string (type 0)
OR a MAC address (type 1)

RFC 4361 goes on to extent this by using type 255.

In other words, the DHCP server in question doesn't allow the RFC guidelines."

So the question is now whether we make a HOWTO post on the forum about this subject, and trust that affected users will see the information and be able to launch dhcpcd with the required parameters ... or I recompile dhcpcd with "ENABLE_DUID" disabled.
Any opinions?
Do we think that enough routers will have this problem to justify permanently disabling DUID?
Or is the DUID function, which is supposed to be technically correct, worth keeping?

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#107 Post by PaulBx1 »

Add another button to the network wizard under the "Auto DHCP" button, "Auto DHCP w/o DUID"? And use it to launch with the -I switch? Normally, users trying to get their network up will attempt one, then the other, without much in the way of support on the forum...

Could add a short explanatory note there also, or something as simple as "If Auto DHCP does not work, try Auto DHCP w/o DUID."

First let's make sure adding the switch on the command line does actually fix the problems rerwin and maybe others have seen...

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#108 Post by tempestuous »

PaulBx1 wrote:First let's make sure adding the switch on the command line does actually fix the problems rerwin and maybe others have seen...
Yes indeed. rerwin (and gliezl) the command is -

Code: Select all

dhcpcd -I '' eth0
That's hyphen, uppercase i, space, single inverted comma, single inverted comma.

And it might be necessary to kill dhcpcd first, if it's already running

Code: Select all

dhcpcd -k eth0
rm /etc/dhcpc/dhcpcd-eth0.*

User avatar
veronicathecow
Posts: 559
Joined: Sat 21 Oct 2006, 09:41

#109 Post by veronicathecow »

Hi Barry, am using the 3.00 beta and have backgrounded the network with the code from this thread

http://www.murga-linux.com/puppy/viewtopic.php?t=13130

and it is working fine.
It Knocked 21% off my boot time (from 43 down to 34 seconds excluding POST)
PClinux takes 55 seconds to boot.
I think we should be able to boot in half that speed with a bit of tweaking 8-)

User avatar
veronicathecow
Posts: 559
Joined: Sat 21 Oct 2006, 09:41

#110 Post by veronicathecow »

CUPS still not printing on my Canon iP4300 although it appears to recognise that it exists. No jobs appear in the Q.
Barry, unless it's light outside, go get some kip mate!

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

dhcpcd follow-up

#111 Post by rerwin »

Many, many thanks, tempestuous, for pursuing the "autodhcp" problem I reported. I have examined the documentation at the link you included and understand why the change was made and what it is intended to accomplish. I will review what I understand and opine (as a former corporate programmer on mission-critical ealtime satellite control systems).

This DHCP client supports the DHCPv4 specifications which have been updated to be compatible with the newer DHCPv6 specs. This impacts the "clientID" that is transmitted to "the network" (router, in my case). The controlling documents, RFC 2131 & RFC 2132 have been updated to delete some options in the composition of the clientID, specifically the use of the network interface MAC address alone; it can be combined with other data as a client ID, but in a format that does not begin with the MAC address.

In the real world, and acknowledged in the RFC documents, some networking equipment (e.g. D-Link DI-524) work only with the MAC address form of ClientID -- or at least their user interface expects them. The devices operate under firmware control; so updates to comply with the modified requirements depend on each manufacturer releasing a firmware upgrade -- very unlikely for older units.

All of the man pages I could find (up to 3.0.19) state that if a clientID is not specified (as in Puppy), the default is the MAC address. The 2.17/3.00 version, 3.1.0 (and probably earlier), changes the default that all software relies on, without notifying anyone (that I could find) of the impact of the change in default -- or that it has changed! This secretive revision of the rules was frowned upon in my programming environment, to put it mildly.

However, I see the desirablity of adapting to the new requirements. The benefit I see for Puppy users is that a PC or laptop that has both an NIC and a wireless card (or either built in) would be recognized on a network as the same computer and IP address; currently, each interface on that computer would have a separate IP address and appear as a separate computer. (Another issue the changes address is the fact that an IP address is associated with a NIC or wireless card that could be moved to another computer, instead of continuing to associate the IP address with the computer. This is important in sophisticated networks where the IP address is associated with other characteristics of the particular computer's place in the network configuration; changing out a NIC upsets this.)

In the recommendations for implementing "node-specific identification" of networked equipment, the burden appears to be placed on the client (Puppy, through dhcpcd) to ensure that only one "clientID" is issued by a computer-&-operating system (I think). If a PC has multiple network interfaces, it must use the same ID on all interfaces; this means additional logic either in Puppy or dhcpcd. The dhcpcd developer has not (AFAIK) announced what DHCPCD does about this or expects from the invoker. I suspect that Puppy will have to build a ClientID somehow and pass it as the "-I ..." option to dhcpcd; or it will have to read the ID that dhcpcd creates (but has not been described, or how to read it) and save and re-use it for all subsequent invocations.

With that as background, I feel that, for now, Puppy must ensure that nothing changes in what it uses to identify PCs. I have tested the recommendation to use "-I ''" and it appears to work; my test entailed inserting that parameter into the script net-setup.sh invocation of dhcpcd.

Although the new parameter restores the expected behavior, so would reverting to the old version (1.3.22) or the Slackware version (2.0.4) of dhcpcd. However, 3.1.0 seems to have other bugs that I reported in the beta2 thread. Both 2.0.4 and 3.1.0 give false positives for a not-completely-connected interface; but ifconfig shows different consequences of that -- 2.0.4 shows no eth0 link (good), while 3.1.0 results in an "active" link using IP address 169.254.184.245 (at least on my system) that causes the browser to (frustratingly) not find any web sites (bad). What is a newbie to do!

The conservative action for 3.00 final would be to revert to 1.3.22 and wait until next release to implement compliance with the ClientID requirements of 3.1.0, whatever they turn out to be, and/or to correct the false-positive problem. Are there any compelling reasons for jumping to 3.1.0 ahead of all mainstream Linux distributions?

FYI, I see that the developer web site may be http://dhcpcd.berlios.de/, but I could not get it to load.

Thanks, again, for initiating the dialog with the developer.

Richard

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

Re: dhcpcd follow-up

#112 Post by tempestuous »

rerwin wrote:The conservative action for 3.00 final would be to revert to 1.3.22
Potentially, that sounds OK ... but testing is required.

Forum member tony reported a freeze with the old version of dhcpcd and his Ralink wifi driver -
http://www.murga-linux.com/puppy/viewto ... 317#130317
... but the Ralink driver had problems at that stage, and has been updated since then.
dhcpcd may be innocent in this case.

And some other forum members have reported that their wifi configuration is successfully retained at each boot up with the new dhcpcd, whereas they lost it with the old one.

So I have posted the old dhcpcd version (1.3.22) here as a dotpet -
http://www.murga-linux.com/puppy/viewto ... 656#143656
It would be good if people could try this in Puppy 3.0 beta.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Contingency dhcpcd plan

#113 Post by rerwin »

Thanks, tempestuous, for considering my conservative approach and for recalling the old issues with 1.3.22.

If anyone continues to see problems with 1.3.22 and wireless, it would be interesting to know whether 2.0.4 corrects them. So, along with the dotpet you have provided, would you consider making one for 2.0.4? I extracted dhcpcd from the slackware dhcpcd-2.0.4 package, but a dotpet would make it easier for those with wireless issues to try it.

If this compromise version cures the wireless problems, we might use it, instead, even though it produces a false positive in the HomePlug situation; at least it handles it better than 3.1.0

EDIT: Afterthought: Since the meaning of "default" appears ambiguous for the "-I" option, it would probably be prudent to be explicit, in the net-setup wizard's invocation of dhcpcd, to insert the "-I ''" string into it. The result would be in line 897 in beta3:

Code: Select all

		if dhcpcd -d -I '' "$INTERFACE"
This would ensure that the eventual step-up to version 3.x.x would not impact the use of MAC addresses until code is added to provide the alternative of using the "node-specific" client ID as intended by the rule-makers -- to use the same ID for all network interfaces on the same computer.

EDIT: After a reality test -- do not add the option/parameter as I suggest above! I tried that with 2.17 with dhcpcd 1.3.22 in place of 3.1.0 and saw an unexpected misbehavior. Without the "I" option, my Equium is assigned ...103, which I told my router to use for the MAC address of the Equium.

But with "-I ''", the router assigned ...107, apparently because it thought the Equium was a different computer on my LAN, turned off but connected via a USB HomePlug device. The NIC is part of the device, so probably is always on; the router got confused. When I removed the "-I ''" option from net-setup.sh and reran the wizard, the Equium was recognized correctly and was assigned ...103.

Another reason to not make the change is that "-I ''" is not a documented
value for the I option. That may have been added for 3.1.0 -- in secret.

Richard
Last edited by rerwin on Mon 01 Oct 2007, 15:32, edited 2 times in total.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#114 Post by tempestuous »

rerwin, can you send me v2.0.4 by private message? You will need to gzip the file before attaching it to the message.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

dhcpcd

#115 Post by rerwin »

I have sent the requested dhcpcd 2.0.4 by PM.

In my previous post, I added a section suggesting that the "I" option be added to the net-setup.sh script, to specify the special meaning of it -- null means "use MAC address" instead of a string to be used as clientID. However, I just now tried that with 1.3.22 and saw a bizarre consequence. So, please ignore my suggestion and leave net-setup as is.

Richard

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#116 Post by tempestuous »

rerwin, dhcpcd-2.0.4 is now available here
http://www.murga-linux.com/puppy/viewto ... 293#144293

DonT
Posts: 12
Joined: Tue 21 Aug 2007, 02:01
Location: Panama City Beach, Florida

#117 Post by DonT »

I would like to possibly add something to this thread regarding dhcpcd, if I may.

I had posted a problem with browser redirection to a login page on an open wireless hotspot. Problem had started with Puppy 2.17.1

http://www.murga-linux.com/puppy/viewtopic.php?t=21023

After reading the excellent tempestuous and rerwin posts, I installed dhcpcd-1.3.22 pet into Puppy 2.17.1, 2.20alpha, and 3.00beta, and the browser would redirect to a login page.

However, dhcpcd 2.0.4 pet would not redirect the browser to a login page.

Would like to thank tempestuous and rerwin for their excellent work.

Hope this info helps a little.

DonT

Post Reply