(old)Puppy Linux Discussion Forum

valpy wrote:If I manually change the WPA config file for my card in the /etc/network-wizard/wireless/profiles directory (something like 00:55:BC:94:E0:A0.WPA.conf) so that the WPA_DRV="ipw" line becomes WPA_DRV="wext", then it works.

Good work!
I guess all those modules are slowly being converted to use wireless-extensions, so now need the "wext" parameter... I should probably go over all of them and see if any others need changing.

PaulBx1 wrote:Or, you might compare the new one with the last used one, and if the contents are the same, just delete the last used one. I can see the value of saving files with different info in them, but if they are all the same it may be less useful.

I don't know if it's worth bothering, though... the user isn't likely to look at them and if it's older than the last -- they're not likely to know when it's from.
I could have some rotation, saving them as .last1 .last2 .last3 and such (and on the next boot, 3->4, 2->3, 1->2 and the previous one moves to 1), but I just don't know if it's worth bothering with (especially at boot time...).

valpy wrote:/usr/sbin/wag_profiles.sh associates rtl8187 with the "ipw" parameter

Yes, that was my fault. During the testing phase of Puppy 4.0 we needed to learn the correct wpa_supplicant parameters for the new range of wifi drivers -
http://www.murga-linux.com/puppy/viewto ... 620#194620

And according to the project site
http://rtl-wifi.sourceforge.net/wiki/FAQ
"ipw" is the correct parameter to use with wpa_supplicant ... but apparently no longer.

Dougal, please change only the "rtl8180" and "rtl8187". The older "r8180" and "r8187" modules are still definitely compatible with the "ipw" parameter.

tempestuous wrote:Dougal, please change only the "rtl8180" and "rtl8187". The older "r8180" and "r8187" modules are still definitely compatible with the "ipw" parameter.

Did that yesterday...
The rtl* drivers are the re-writes of the r* drivers for the mac80211 stack, so use the wext param.
You might want to do a grep for "mac80211" in drivers/net/wireless and see if there are any others we are missing.

For ja_JP.UTF-8
http://qyg01263.googlepages.com/net-setup.mo.ja

Put it /usr/share/locale/ja/LC_MESSAGES/ and rename net-setup. .


11/21 fix buildScanWindow section

I could have some rotation, saving them as .last1 .last2 .last3 and such (and on the next boot, 3->4, 2->3, 1->2 and the previous one moves to 1), but I just don't know if it's worth bothering with (especially at boot time...).

Yeah. I just noticed this is a very old problem - my /etc in my Puppy 2.16 also has multiple copies of these files.

I just like to keep a clean system, without directories filling up with trash. Can I just delete all of them, or will that break something? Or delete all but the most recent or the one with the largest number in the name?

I have 59 of these files, and I don't think I'm doing anything out of the ordinary.

I admit this is a nit.

PaulBx1 wrote:I admit this is a nit.

It isn't. There is no reason why those files should keep accumulating, crowding up your /etc.

Puppy 4.11 seems to have the old rt61 driver, not the newer rt61pci. I understand there are some issues with rt61pci, but there's a worse problem with rt61: it doesn't support PCMCIA cards.

Not mine, at least (D-Link DWA-610).

I have to stick to Puppy 4.1, as a result (it has rt61pci). If anyone knows how I could copy the driver from one version to another that might help...

Information about improving stability of connections with rtl8187 driver for those who still have issues with rtl8187

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

@tempestuous

Yes, that was my fault

Please don't think of it as "fault" - all your efforts are greatly appreciated.

Apologies if I've posted this in an inappropriate place.

I've installed Puppy 4.1.1 and sucessfully configured wifi on an EeePC 701 and a Lenovo ThinkPad R61e, no problem.
Click on "Scan", choose my SSID from the list, click on "WPA2", paste my key into "Key" field, click on "Save", click on "Use this profile", then "Auto-dhcp", etc... Everything works. Even after a reboot I am automatically re-connected to my wifi network.

Thanks Dougal.

But may be there are some things that helped my configuration to work so easily:

1) I am lucky enough to have hardware that is supported by working drivers.

2) I do my testing in the same room, and less than 2 metres from the wireless Access Point. This simply means that signal strength is eliminated as a problem.

3) On my wireless Access Point device, I disable "UPnP". I'm not sure why, but I just think Windows and Linux more happily co-network if I do. I know that IP needs only dhcp to configure itself seamlessly. Also gives me confidence that the device is working exactly how I configured it via it's WWW interface.

4) On my wireless Access Point device, I configure it to broadcast my ESSID/SSID. (It's the strong encryption that provides the security.)

5) I know that my key is identical on all devices because I store it in a text file on a USB stick, so I can cut and paste it into all devices, including the "Key" field in the puppy wizard. This provides confidence, even on devices that only display dots or "*" in the key field.

6) On WPA2 I don't use the "s:key" construct, that is supposed to work in WEP. I paste just the plain ASCII string. As long as it's less than 64 characters WPA assumes it's an ASCII key.

7) I don't use a key string that will cause problems on any device. I use a key of 30 random alpha-numeric characters, with no spaces, with a few special characters thrown in. I avoid special characters that can cause problems, e.g. "$" character could be a problem in scripts like the puppy wizard. (Though I think Dougal might have fixed that one now.) For your first key, use just alpha-numeric characters and no spaces, just to be sure that the key can not be a problem. You can change it to a more complex key after it is working.

Hopefully, something in all this will help someone else have a successful experience with wifi and the puppy network wizard.

Alan

gyro wrote:2) I do my testing in the same room, and less than 2 metres from the wireless Access Point. This simply means that signal strength is eliminated as a problem.

JustGreg has actually mentioned to me that WPA doesn't seem to work if your signal is less than 50/100 or so, but that is apparently beyond our control: it's probably wpa_supplicant that can't handle it and might be partially the result of not-so-good Linux drivers (which might explain why some users manage to connect with ndiswrapper and not with the native module).

4) On my wireless Access Point device, I configure it to broadcast my ESSID/SSID. (It's the strong encryption that provides the security.)

Yes, that might make life harder for wpa_supplicant and, as you noted, does not help security-wise.

6) On WPA2 I don't use the "s:key" construct, that is supposed to work in WEP. I paste just the plain ASCII string. As long as it's less than 64 characters WPA assumes it's an ASCII key.

The wizard detects which one you gave and if it's the ascii one, it converts it to hex -- that's what it saves to the wpa_supplicant profile and what is used.

7) I don't use a key string that will cause problems on any device. I use a key of 30 random alpha-numeric characters, with no spaces, with a few special characters thrown in. I avoid special characters that can cause problems, e.g. "$" character could be a problem in scripts like the puppy wizard. (Though I think Dougal might have fixed that one now.)

I might have fixed that, but it's only in the experimental package I posted earlier (page 31 or 32) and is untested -- I need somebody to verify that it works (and doesn't botch up anything else) so I can add it to the "official" version.

Dougal wrote: Ok, I think I've managed to fix the problem with the $ in the key (also " and `)

Hi Dougal

Just got around to testing this, as I've now clean-installed iscraigh's AAO-specific Puppy - I was OK with the hand-edited config file before.

Sad to say, it's not fixed - looks as if the hex key is being generated from a PSK string with the backslashes left in, i.e. NOT absorbed by being interpreted as escape characters! For example, if PSK="bla\$BLA" the hex is generated from bla\$BLA, not bla$BLA

It's fairly easy to test, by comparing the output of wpa_passphrase with the contents of the config file. HOWEVER, you have to get wpa_passphrase to read the PSK from stdin - if you put it on the command line then it gets corrupted...

Hope this helps - I'll try to test any updates a bit quicker this time!

Best regards

Jonathan

I'm using a Gateway ML-3109 laptop and Realtek 8185 with Puppy 4.1.1 but am still unable to connect to my home wlan.
Footnote: My son's Kanotix/XP desktop using NDISWRAPPER (also a Realtek 8185) could not see the home network unless I broadcast my SSID. But it's working great for him now.
I was very happy that Puppy 4.1.1 finally detects the Realtek 8185 in my laptop, and it can see my home network! But I am using WPA2 TKIP+AES with a 64 bit hex key and for some reason Puppy will not connect to the router and pull an ip address from the router's dhcp server.
I haven't tried static ip yet but does it really matter? The issue would seem to be that Puppy out of the box does not support this level of encryption.
Is there a patch available, or am I doomed to tinker from the command line?
Heeeeeeeeeeeelp!
I don't get why the 8185 works on one machine, and not the other and I'm afraid to try NDISWRAPPER with puppy because last time it so corrupted my pup save file I had to delete and start from scratch.
Of course, I am a total noob and I am sure it's something really simple that I've overlooked but if anyone has ideas I'm eager to hear from you.
Thanks!
Rich

imnotrich wrote:I was very happy that Puppy 4.1.1 finally detects the Realtek 8185 in my laptop, and it can see my home network! But I am using WPA2 TKIP+AES with a 64 bit hex key and for some reason Puppy will not connect to the router and pull an ip address from the router's dhcp server.
I haven't tried static ip yet but does it really matter? The issue would seem to be that Puppy out of the box does not support this level of encryption.

I think a more correct statement would be that it doesn't work for you out of the box -- plenty of other users have WPA2 working fine in Puppy.

There could be a few reasons why it doesn't work:
- You didn't mention which kernel driver is used. Could it be rtl8187? Look a fewe messages above for the fix in that case.
- How strong is the signal detected when you run a wireless scan? It seems like WPA connections don't work when the signal is less than 50/100.
Note that if your problem is a weak signal, using Ndiswrapper might help, since the windows driver has a good chance of working better...

Dougal:

I wish to thank you and tempestuous for all the great work you are
doing. There are others helping out too...Just Greg? etc.
If I have missed anyone....my apologies.
Anyway... thanks to all in the puppy genius factory
for your efforts.

""""""""""

This is one problem I couldn't solve.
I don't have access to this laptop any more though.
Works OK until you allow Vista to stitch it up.
And of course wonder of wonders.....
Network Magic came to the rescue to connect the
encrypted wireless in Windows. A brilliant program.
I hope that Cisco don't stuff it up now that they have
bought it.

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

::::::::::::
In puppy 4.1.1 I have found that the wireless
networking menu works for me most times.
Faster than Windows.

If I can't get things going I try this:

Connect a network cable, setup the network ethernet 0,
test ethernet 0, then click auto dhcp, test for available connections,
type in password... and try to connect.

If I'm successful...I pull out the cable...
redo the setup for wireless.....wlan0 ?
and go through all the steps again. "

Regards...................Chris.

Dougal wrote:

imnotrich wrote:I was very happy that Puppy 4.1.1 finally detects the Realtek 8185 in my laptop, and it can see my home network! But I am using WPA2 TKIP+AES with a 64 bit hex key and for some reason Puppy will not connect to the router and pull an ip address from the router's dhcp server.
I haven't tried static ip yet but does it really matter? The issue would seem to be that Puppy out of the box does not support this level of encryption.

I think a more correct statement would be that it doesn't work for you out of the box -- plenty of other users have WPA2 working fine in Puppy.

There could be a few reasons why it doesn't work:
- You didn't mention which kernel driver is used. Could it be rtl8187? Look a fewe messages above for the fix in that case.
- How strong is the signal detected when you run a wireless scan? It seems like WPA connections don't work when the signal is less than 50/100.
Note that if your problem is a weak signal, using Ndiswrapper might help, since the windows driver has a good chance of working better...

I am using the 8185 and the version included with puppy seems does not support the level of encryption on my home network. That's why I posted, because nothing in previous posts seemed to help.

Signal Strength is 36" from 100mw running through dual 9db gain antenna. Not sure what that works out to but probably pretty good. SO that's not it.

And yes, I have tried puppy's version of ndiswrapper. Also fails. But what perplexes me is ndiswrapper, an xp driver (not vista ), the pci version of the 8185 and my son's desktop running kanotix works just fine with my encryption. The only workaround was that I had to un-mask the ssid.

I've experimented running less or no encryption with puppy and several different adapters but they won't connect for me either and I cannot run open or wep all the time because my neighborhood is very dense with WLANS. That's why I upgraded my antenna and firmware to dd-wrt so I could crank up the output a bit from the stock 28mw.

Everyone else on my home network is able to connect ok so it's probably not the router.

But wait - it just occurred to me that I have mac filtering enabled on the router. Does Puppy change or suppress the MAC id? I'll have to play with that.

Sad to say, it's not fixed - looks as if the hex key is being generated from a PSK string with the backslashes left in, i.e. NOT absorbed by being interpreted as escape characters! For example, if PSK="bla\$BLA" the hex is generated from bla\$BLA, not bla$BLA

Seems to me, this is the desired behavior. We want the user to be able to put any old thing in there, and have each character be treated as part of the code, not some sort of "escape".

On second thought, maybe that is not the correct criterion. What matters is consistency. If we enter a key into our AP, and the same key into the wireless wizard, and the same key into Windows, they should all play together. You want people using different OS's to be able to access the same AP.

I suspect this means that backslash should not be for escaping characters, but is just another character itself.

h4yn0nnym0u5e wrote:Sad to say, it's not fixed - looks as if the hex key is being generated from a PSK string with the backslashes left in, i.e. NOT absorbed by being interpreted as escape characters! For example, if PSK="bla\$BLA" the hex is generated from bla\$BLA, not bla$BLA

Ok, I think I fixed it.
Let me know if it works.

Another update:
- change rtl818[07] to use "wext" param with wpa_supplicant
- delete old backup copies of /etc/resolve.conf
- fix problem with wpa passphrases that have `, $ or " in them

In the parent post.

cthisbear wrote:http://www.murga-linux.com/puppy/viewtopic.php?t=35962

The most basic reason it doesn't work is that we've never had to deal with a bluetooth interface before...

Judging by what is written here, I assume the first thing you need to do is modprobe the "bnep" module.

Now, according to what they write, you actually need the bluetoth-utilities package ("bluez") and use the "pand" utility -- and your router do some things for you...
I don't know about all that (note that they also talk about it being a PAN). I would try loading the module and then seeing if the interface appears when you run "ifconfig -a".