Hello, dear Barry!
I haven't to do my posting to your Blog (for "Pwireless2 now in Quirky"). Becase I posts it here.

The Pwireless2 tool, as it's I shown in the assembly Puppy eee-431-b35 (I was tested it; see my report here: http://murga-linux.com/puppy/viewtopic.php?p=391423#391423), does not allow to users manually settings: do not it for Wi-Fi (for manually entering parameters such as: put a SSID, Channed, Frequency, Mode and others), and also it allows not use a fixed IP and uses manually entered DNS -- but it *need* to many users! Also, this tool does not allow to manually configure the Ethernet.
Pwireless2 may be usuable tools for connecting to 'open wireless networks' such as has in an airport, restourant or 'net-cafe' networks, but not for security powered private wireless networks.
The posting below as wrote mr. bruce, he is absolutely right, when he wrote (Posted on 17 Feb 2010, 8:01 by bruce: http://bkhome.org/blog/?viewDetailed=01403) that it was necessary to allow users to freely use *AND* Pwireless2, *AND* Pwireless tools!
It old network configuration tool is very good for many real cases, and I was do setting network under Pwireless (such as traditional Puppy Network Manager). And I used it for about year, without any complaints.
But the newest tool -- such as Pwireless2 -- haven't many user's needly features. For example, I could not be used It for me networking about testing Puppy 431-b5 at January 2010...
If Pwireless will be excluded from the new assembly of Puppy, -- many users will either have to abandon the new Puppy; or either to alone manually include the Pwireless to newest Puppy, taking it from an old release of Puppy...
Note. Unfortunately I have to admit: in a recent increase in cases where developers of software very uncritically, and without considering all possible consequences -- as roughly "modernist" action -- when alter conditions of use of their products!..
This is evident of many examples. For example, recall the recent case of the erroneous change of value data=writeback onto kernel 2.6.30.5; or remember please most recent cause: with kernel 2.6.33 this is a blatant case of unjustified exceptions are always used before passage of the hardware diagnostic test (for USB -- in this case: http://bkhome.org/blog/?viewDetailed=01404) for PCs devices...
This is not good actions!
I hope that Barry Kauler, as founder the PuppyLinux, fall not into this mental trap. And do not be too eager (as a young foolish people) -- as to do excluding from the OS very reasonable subsystems such is Pwireless tools, which previously worked wery good for many Puppy users.
Because not necessarily in order to introduce new features, and at one time to do exclude from the OS a well-proven technical solutions, pass it is old tools.
Thank you for the opportunity of understanding.

Forgive my ignorance, but why is puppy series so far behind in wireless?
All the major distros now auto-detect the chipset/card and auto-configure it.
Using the old was a nightmare for beginners (I am sure you guys don't develop Linux only for geeks, but wish it to go more mainstream), and replacing it with a limited new version (without wpa, if what I am reading is true) isn't a solution either.
Surely there is a subsystem that works, that is available from somewhere, without having to rewrite the code yourselves, and that you can integrate quickly?

Believe me, if I thought there was any chance in hell of getting an existing wireless subsystem working in Puppy without adding a lot of bloat I wouldn't have bothered with Pwireless2.

Connman and Network Manager were both epic failures, although Network Manager might to be heading in the right direction now that HAL is gone - I haven't tried to compile it recently. The Connman project might have been updated by now but I can't seem to find any updated source. WICD - needs python - too big. And that's all the options that I know about.

Wpa_gui works, but Pwireless2 is much smaller and easier to use.

--

On old hardware or hardware with crappy drivers, the traditional Network Wizard will often work when other tools fail. For instance, Pwireless2 needs drivers with solid WPA support to work - you won't even be able to connect to an open network otherwise.

Well, for the record, Pwireless2 isn't in Quirky. It was briefly (not in any official release version of Quirky though). Then in a mad moment I decided to write my own wireless tool, named Simple Network Setup, that is now in Quirky. My SNS has a different emphasis, is simple, um, lacks roaming capability that Jemimah put into Pwireless2._________________http://bkhome.org/news/

P.S. It's my mind about it. A last release N.M.. for example on Q.030, setupped Wi-fi fine.
Any problems workaround Net setupping by Pwireless2 (only as first releases, my be), IMHO, is permit not to do of user's MANUALLY setupping own Net: for example, I prefer use fixed IP, without DHCP, and manually put SSID and Security Key, and other settings too... =)

I second Abnormalter.
It's great to have nice automatic networking for a client machine. But please ensure that facilities for manual configuration are still available.
Some of us want them, some of us need them.
(When i run puppy as a router I need to be able to configure the down-stream interface manually.)

The point is not whether "supports" or not Pwireless2 static IP. The fact is that, least at the time of publication of this topic in the forum, when I was testing a new releases of Puppy, at January or February 2010, when I watched about it situation as I described in the topic (the details I cannot remember exactly now, but the overall essence of the phenomenon remember with absolute accuracy).
What happened then:
- The user manually adjusts any parameters for own Network. Then, in current session of the OS, it works OK.
- Work is nearing completion, OS restarting (eg once or tomorrow) and will start it... Shit! -- at attempt the script automatically (re) configured the Network (for using DHCP, in particular).
On that cause, any user preferences are going to the forest!.. =)

If similar abnormal behavior of the Network settings you have not met in own practice, then I'm very sorry. But then there is reason to further discuss this issue here. A different it seems everything is clear.
Thank you.

Thank you, I understand your opinion. But it somehow belatedly for it...
I note only that you do not know the background of this situation that manifested itself not just in Puppy, not only in early 2010, and approximately two years earlier, in other distributions of Linux. And then, not only at February 2010, but two years earlier I have discussion for developers about abnormally behavior this Network subsystems at start of OS, with adequate current discussion. But it pass and done roughly similar to the current result...
I note in the finale, which is quite strange me to argue about all this problems after 3-4 months after actual times.
Moreover, the problem is solved successfully, such as Lupu 5, where the Network Menager Subsystem working fine for most discerning of many users, IMHO.
Thanks for the discussion.

I just did a little test:
I hooked up a second ethernet device (eth1).
Added the following to /etc/dhcpcd.conf

Code:

interface eth1
static ip_address=192.168.3.1/24

and then ran

Code:

dhcpcd -d eth1

This configured eth1 with the address 192.168.3.1 and put an appropriate entry in the route table.
So I unplugged the cable from the ethernet switch, and dhcpcd removed the entry form the route table, and removed the IP from the interface, although it left eth1 still with a status of UP. I then plugged the cable back in, and dhcpcd added the IP address to eth1 again, and added the entry into the route table.
I thought, this is great!
All I would like to do now is replicate this using the command line, with no eth1 entry in /etc/dhcpcd.conf.
So I tried

Code:

dhcpcd -d -s 192.168.3.1/24 eth1

Sadly, this did not work so well.
1) It continuously sent an "INFORM" message out eth1, but of course there's no dhcp server out there.
2) It did not respond to the ethernet cable being unplugged.

So if you know the proper incantation to use from the command line so that dhcpcd behaves like it did when I had an eth1 entry in /etc/dhcpcd.conf, please let me know.

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