Puppy 3.00BETA bug reports here

Please post any bugs you have found
Message
Author
richwa4sxz
Posts: 7
Joined: Mon 17 Sep 2007, 23:50
Location: Fort Walton Beach, Florida

still no sounds

#101 Post by richwa4sxz »

Greetings,
Using Toshiba A135-S4427 laptop I am still not getting any sound from the HDA-Intel (built in) sound card. It uses a Realtek AC861 chip set
Alsa config finds the card, runs but no sound. Was wondering if the new alsa rc2 made it into this beta. Also still not finding my Audigy2 ZS pcmcia sound card at all. Added the snd-emu10k1 driver but still no go on the pcmcia sound card recognition. Maybe something I have overlooked.

On the positive side, everything else works hardware wise, and no problems with booting or file system.

Last release that I had working sound on the HDA-intel was 2.14.

Looks good so far. Thanks for your continuing support of the project.

User avatar
klhrevolutionist
Posts: 1121
Joined: Wed 08 Jun 2005, 10:09

#102 Post by klhrevolutionist »

puppy3 beta-2 (Bugs and what not)

Xvesa wizard: Still must press test instead of okay
NetSurf: works, but cannot visit any webpages
hd-install: upon rebooting a couple times will not allow into X
Heaven is on the way, until then let's get the truth out!

User avatar
nyu
Posts: 110
Joined: Tue 14 Mar 2006, 15:30
Location: good earth

#103 Post by nyu »

I am using 800X600X16 screen mode. The desktop is too big
to fit in my screen. Some application windows are too big as well.

Thanks for this great distro. :D

Henry
Posts: 863
Joined: Sun 30 Jul 2006, 02:28
Location: Oregon USA
Contact:

3beta2 Problems (Edited again to simplify)

#104 Post by Henry »

I know there have been great strides in development, and am very pleased that we will have good package handling. However I have been using the new "tiny" (233M iso) installed fluxbox version of PCLOS and it's (rpm) repository seems superior to Slackware. For instance one fetches a Thunderbird version with or without Enigmail in a selected language, and that's it. It installs 8 files, no fiddling with finding the extension and separately installing Gnupg. But hopefully a sparser Puppy with Gslapt will work equally well. I mention this as it seems impossible to use GPG in Seamonkey 1.12 in a pristine Puppy 3beta. Seamonkey closes immediately, as it did previously in 1.08.

I also tried to upgrade my 2.17.1 config., which I have done without problem from 2.13 through 2.17.1. Some programs do not run, most notably the whole Seamonkey suite. The files from both 108 and 112 remain there in /usr/lib/seamonkey but I can run neither. Maybe because folders have changed (or whatever) but it's not realistic for me (or many users) to sort that out. Some sort of adaptation is needed for this, as upgrades are important to the user who has tailored his system over time.

But if I download Seamonkey 1.14 from the Mozilla site and manually install it (into /opt/seamonkey, in this case) it works fine, even in a ver. 3 upgrade.

Henry
Last edited by Henry on Sun 30 Sep 2007, 04:42, edited 2 times in total.

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

#105 Post by veronicathecow »

Hi Barry, hope you are not to worn out. Wanted you to know definite improvement in running Puppy on my machine, many many thanks.
Sound now works
Ethernet now recognised, and connect to the net perfectly
Will try other stuff later.
Cheers
Tony

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