Good work!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.
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.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.
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 -valpy wrote:/usr/sbin/wag_profiles.sh associates rtl8187 with the "ipw" parameter
Did that yesterday...tempestuous wrote:Dougal, please change only the "rtl8180" and "rtl8187". The older "r8180" and "r8187" modules are still definitely compatible with the "ipw" parameter.
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 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...).
Please don't think of it as "fault" - all your efforts are greatly appreciated.Yes, that was my fault
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).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.
Yes, that might make life harder for wpa_supplicant and, as you noted, does not help security-wise.4) On my wireless Access Point device, I configure it to broadcast my ESSID/SSID. (It's the strong encryption that provides the security.)
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.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.
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.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.)
Hi DougalDougal wrote: Ok, I think I've managed to fix the problem with the $ in the key (also " and `)
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.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 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.Dougal wrote: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.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.
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...
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".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.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
The most basic reason it doesn't work is that we've never had to deal with a bluetooth interface before...cthisbear wrote:http://www.murga-linux.com/puppy/viewtopic.php?t=35962
