Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 17 Apr 2014, 22:46
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Puppy 3.00BETA bug reports here
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 8 of 8 [117 Posts]   Goto page: Previous 1, 2, 3, ..., 6, 7, 8
Author Message
tempestuous

Joined: 10 Jun 2005
Posts: 5139
Location: Australia

PostPosted: Thu 27 Sep 2007, 06:34    Post subject:  

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?
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 27 Sep 2007, 09:46    Post subject:  

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...
Back to top
View user's profile Send private message 
tempestuous

Joined: 10 Jun 2005
Posts: 5139
Location: Australia

PostPosted: Thu 27 Sep 2007, 12:02    Post subject:  

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:
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:
dhcpcd -k eth0
rm /etc/dhcpc/dhcpcd-eth0.*
Back to top
View user's profile Send private message 
veronicathecow


Joined: 21 Oct 2006
Posts: 530

PostPosted: Thu 27 Sep 2007, 17:37    Post subject:  

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 Cool
Back to top
View user's profile Send private message 
veronicathecow


Joined: 21 Oct 2006
Posts: 530

PostPosted: Fri 28 Sep 2007, 09:05    Post subject:  

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!
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1463
Location: Maine, USA

PostPosted: Fri 28 Sep 2007, 18:04    Post subject: dhcpcd follow-up
Subject description: Opinion on resolution for 3.00
 

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
Back to top
View user's profile Send private message 
tempestuous

Joined: 10 Jun 2005
Posts: 5139
Location: Australia

PostPosted: Fri 28 Sep 2007, 22:23    Post subject: Re: dhcpcd follow-up
Subject description: Opinion on resolution for 3.00
 

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/viewtopic.php?p=130317#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/viewtopic.php?p=143656#143656
It would be good if people could try this in Puppy 3.0 beta.
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1463
Location: Maine, USA

PostPosted: Sat 29 Sep 2007, 08:57    Post subject: Contingency dhcpcd plan
Subject description: Consider 2.0.4 to resolve wireless issues
 

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:
      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, 11:32; edited 2 times in total
Back to top
View user's profile Send private message 
tempestuous

Joined: 10 Jun 2005
Posts: 5139
Location: Australia

PostPosted: Sun 30 Sep 2007, 00:01    Post subject:  

rerwin, can you send me v2.0.4 by private message? You will need to gzip the file before attaching it to the message.
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1463
Location: Maine, USA

PostPosted: Mon 01 Oct 2007, 11:41    Post subject: dhcpcd  

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
Back to top
View user's profile Send private message 
tempestuous

Joined: 10 Jun 2005
Posts: 5139
Location: Australia

PostPosted: Tue 02 Oct 2007, 07:28    Post subject:  

rerwin, dhcpcd-2.0.4 is now available here
http://www.murga-linux.com/puppy/viewtopic.php?p=144293#144293
Back to top
View user's profile Send private message 
DonT

Joined: 20 Aug 2007
Posts: 12
Location: Panama City Beach, Florida

PostPosted: Tue 02 Oct 2007, 23:28    Post subject:
Subject description: dhcpcd/browser redirection to login
 

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
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 8 of 8 [117 Posts]   Goto page: Previous 1, 2, 3, ..., 6, 7, 8
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0969s ][ Queries: 13 (0.0179s) ][ GZIP on ]