failure of r8187 with pup 412 and 421 using WPA

Message
Author
davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

failure of r8187 with pup 412 and 421 using WPA

#1 Post by davesurrey »

Having problems getting wpa to work with a friend's laptop.
It has Windows Vista and I've installed puppy 431 both of which can find a wpa AP and connect to the net.

But with Puppy 412 and 421 it doesn't work.

Did

Code: Select all

cat /proc/bus/usb/devices 
which returned
Vendor=0bda
ProdID=8189 rev2.00
Product= RTL8187B_WLA_NAdapter
(note it really is spelled NAdapter in the last line)

With Puppy 431 it uses the rtl8187b driver.

Searching through the forum I found that with the 2.6.25.16 kernel it needs tempetuous's r8187-B-FEB09-k2.6.25.16.pet which I have installed, done modprobe r8187, but even after a reboot it still shows as Module rtl8187 in Network Manager.

Scan finds local networks but after putting in the Shared Key it fails to acquire a WPA connection.

Has anyone got this to work in 421 or 412?
Anyone can help please?

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#2 Post by tempestuous »

davesurrey wrote:modprobe r8187, but even after a reboot it still shows as Module rtl8187 in Network Manager.
It appears that Puppy's PREFLIST mechanism is not working, and this has only come to light recently.
rerwin is looking for a fix. See progress here
http://www.murga-linux.com/puppy/viewto ... 431#368431

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#3 Post by davesurrey »

tempestuous:

Thanks for the reply but rerwin seems to be looking at puppy 431 with the 2.6.30.X kernel.

As I said wifi in my 431 is working fine. It's puppy 421 and 412 where I have the problem.

I checked in puppy 412 and found:

/etc/modprobe.conf has a long line to install r8187.
there was no

Code: Select all

remove rtl8187
so I added one

/etc/rc.d/modules.config has

Code: Select all

rtl8187:r8187
in the PREFLIST.

/tmp/pup_event_modprobe.conf doesn't show any blacklist of rtl8187

In the Network manager if I go to load a module I see r8187 in the module list and when I load it, it confirms loaded.

Checking in Bootmanager the r8187 also seems to be loaded.

So, are you saying that pup 412 and 420 also have this problem with PREFLIST?

Thanks
Dave

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#4 Post by tempestuous »

davesurrey wrote:So, are you saying that pup 412 and 420 also have this problem with PREFLIST?
In theory, yes. The PREFLIST mechanism is related to Puppy's version of udev (pup_event) which is common to all official Puppy versions from kernel 2.6.25.16 onwards.
davesurrey wrote:As I said wifi in my 431 is working fine.
That's because the standard kernel module works fine with that kernel. There are no competing modules for the same device in this situation.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#5 Post by davesurrey »

Thanks tempestuous for the explanation.

I find it surprising that this hasn't been picked up until recently if it goes back that far but let's hope rerwin will fix this.

Thanks again for all your efforts for drivers etc.

Dave

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#6 Post by davesurrey »

@tempestuous

Richard, rerwin, and I have had a series of PM and exchanged files and he is now of the conclusion that the problems I am having with r8187 and 412 (2.6.25.16 kernel) are not to do with any preflist issue.

The modules.alias file shows no duplicates of the hardware ID and also show that r8187 is installed. Checking Bootmanager all seems as would be expected with r8187 available and not blacklisted.

So may I ask you to have another look at this. Please let me know what I can do to help you to help me.

Thanks
Dave

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#7 Post by tempestuous »

OK, I looked into this further.
I see now that the standard rtl8187 driver in Puppy 4.1/4.2 is not compatible with your device ID of 0bda:8189. So the r8187 driver is loading (as it should) ...
but this driver appears to report itself to the Network Manager as "rtl8187". That's what caused the confusion.

And this problem is probably also messing up WPA configuration in the Network Wizard.
First we need to check exactly how the Network Wizard sees the r8187 driver. Please run this command -

Code: Select all

readlink /sys/class/net/wlan0/device/driver
Obviously replace "wlan0" if that's not your wifi interface.
Is the result of this command "rtl8187"? If so, the solution should be a simple change to the Network Wizard.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#8 Post by davesurrey »

Thanks for getting back to me.

It does use wlan0.

Your readlink cmd returned:

Code: Select all

../../../../../../bus/usb/drivers/rtl8187
HTH
Dave

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#9 Post by 8-bit »

This is not a fix for blacklisting a module, but when I want one to be bypassed that is loaded I just rename the module to old_name of module.
That way, the module is not found, bypassed, and the correct module is loaded.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#10 Post by tempestuous »

8-bit, the problem in this case is not conflicting modules as I originally suspected, it's a simple case of wpa_supplicant configuration.

davesurrey, I just posted a fix here -
http://www.murga-linux.com/puppy/viewto ... 339#252339

If WPA connections still fail, all is not lost. You can still try pre-loading some of the encryption-related modules, and run the wpa_supplicant command manually. Let me know if you need further help.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#11 Post by davesurrey »

tempestuous,
I installed your NetWiz-fix.pet on a fresh install of puppy 412 (new save file) just in case anything in the save file would cause any problems.

Sorry to say that I experienced the same problem,

ie Scan finds my AP.
But when I put in my shared key (for WPA) and it goes to "Acquiring wpa connection" it crashes. ie the mouse freezes and I can't get any response eg ctlr+alt+backspace so have to force a power down.

Before this I checked in Bootmanager.

It tells me I have a pref rtl8187:r8187.
No sign of rtl8187 being installed but shows that r8187 is available.

However Network Manager still shows rtl8187 in the gui.

So yes I'd appreciate some more help please.

Cheers
Dave

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#12 Post by tempestuous »

davesurrey wrote:It tells me I have a pref rtl8187:r8187.
No sign of rtl8187 being installed but shows that r8187 is available.
Don't worry about module preferences. The newly installed r8187 is the only driver (under kernel 2.6.25.16) which is compatible with your device, so there's no chance of a conflict.

Now it's time for some troubleshooting.
First we must check that your version of Puppy has a suitable version of wpa_supplicant.
The r8187 driver requires the old "ipw" driver interface, which was definitely enabled in older versions of Puppy with wpa_supplicant v0.5.10 (I should know, I contributed that wpa_supplicant package).
Check by running this command

Code: Select all

wpa_supplicant
hopefully you will see this -

Code: Select all

 ...
drivers:
  wext = Linux wireless extensions (generic)
  hostap = Host AP driver (Intersil Prism2/2.5/3)
  atmel = ATMEL AT76C5XXx (USB, PCMCIA)
  ipw = Intel ipw2100/2200 driver (old; use wext with Linux 2.6.13 or newer)
  wired = wpa_supplicant wired Ethernet driver
If you see "ipw" listed as such, move on to the next step.
But at some point in Puppy's development wpa_supplicant was upgraded to v0.6.0 and the "ipw" interface was not enabled. If so, download and install the older version -
http://distro.ibiblio.org/pub/linux/dis ... 0.5.10.pet

Now it's time to manually configure your WPA configuration file.
Open /etc/network-wizard/wireless/wpa_profiles/wpa_supplicant.conf
in Geany (or if your router uses WPA2, open wpa_supplicant2.conf)
Modify this file to include your SSID and Personal Security Key (PSK). Save.

Now run the command to connect -

Code: Select all

wpa_supplicant -i wlan0 -D ipw -c /etc/network-wizard/wireless/wpa_profiles/wpa_supplicant.conf -dd
If you see a successful connection reported, go ahead and open a second xterminal, and do this -

Code: Select all

rm -f /var/lib/dhcpcd/*.info
rm -f /var/run/*.pid
dhcpcd -t 30 -h puppypc -d wlan0
If no successful connection, there's still a chance that an earlier version of wpa_supplicant is necessary - as reported by forum member mikeb. So terminate the wpa_supplicant process with Ctrl>c, then download and install
http://distro.ibiblio.org/pub/linux/dis ... atch-1.pet
A reboot is probably a good idea before trying the wpa_supplicant command again.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#13 Post by davesurrey »

wpa_supplicant told me I had v0.5.8 and I confirmed under the driver section there was an ipw entry.

Added my ssid and psk into /etc/network-wizard/wireless/wpa_profiles/wpa_supplicant.conf and saved it.

Ran the long supplicant cmd but it continued trying and failing to make a connection. So I terminated it with Ctlr+c.

Just in case other experiments had corrupted wpa_supplicant I downloaded the wpa_supplicant-0.5.10.pet and installed it.

No difference.

So did a new install, new save file.
Installed r8187 driver, your NetWiz_fix.pet, added my AP parameters to /wpa_supplicant.conf file and did long wpa_supplicant cmd again. Same problem. Also tried without your NetWiz-fix.pet just in case. Seemed to produce same results.

Large amount of information passing the terminal but did spot
"no keys have been configured-skip key clearing"
Please see attached. (wpa supp terminal report)

Then I added the 0..5.8-rt73patch.pet rebooted and ran long cmd again.
Didn't see the "no keys...." message but still very similar result.
Please see attached. (with rt73 patched)

Sorry but I have always had a brain-clog in doing cut and paste in Linux, especially from the terminal.

I saw somewhere recently that it was suggested not to use a psk in ordinary ascii but in hex instead. eg I am using eg "psk=fred_bloggs" rather than something like "4383aed0272bd8d67dbaf9ba". Hope that makes sense. But I wouldn't know how to find what my ascii psk translates into hex.

HTH
Dave
Attachments
with rt73 patch pet.txt.tar.gz
(534 Bytes) Downloaded 459 times
wpa_supplicant terminal report.txt.tar.gz
(582 Bytes) Downloaded 451 times

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#14 Post by tempestuous »

We're running out of possibilities, but it would be worth checking whether encryption-related modules are loaded.
Once booted, run "lsmod" and check that ieee80211_crypt_tkip-rtl is loaded. (I'm working on the assumption you're using WPA encryption, not WPA2).
If anyone is confused about the name of this module, relax, it's unique to the older Realtek proprietary drivers.
If it's not loaded, do so -

Code: Select all

modprobe ieee80211_crypt_tkip-rtl
Now try the wpa_supplicant command again.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#15 Post by davesurrey »

Yes using wpa not wpa2.

Okay I found ieee80211_crypt_tkip_rtl. Note not ieee80211_crypt_tkip-rtl.

Not trying to be pedantic but just want to make sure about anything and everything at this stage.

Did a

Code: Select all

modprobe ieee80211_crypt_tkip-rtl
anyway and also

Code: Select all

modprobe ieee80211_crypt_tkip_rtl
then wpa long cmd and got a very different looking report on the terminal including what looked like some hex encryption..the psk?

However it then froze the system. :-(

To eliminate what I can I've even re-booted the router to no avail.

One last point I just looked and can't find any /var/run/wpa_supplicant file which wpa_supplicant.conf talks about.

Dave

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#16 Post by davesurrey »

More fun and games:

I thought I better check that it worked in Open and WEP modes so I quickly changed my AP settings (don't like doing this for long).

Despite Network Wizard telling me it had been unsuccessful in connecting to a network I carried on and it was assigned an IP address. It then reported success and now could get onto the net. That confirms I guess we can eliminate a lot of possibilities.

I put the AP back tpo WPA and rebooted (un-connected to this) and a strange thing happened. Network Wizard now doesn't crash/freeze the system in acquiring a wpa connection and gets as far as 4-way handshake but then times out at 30 secs.

Also in /etc/network-wizard/wireless/wpa_supplicant.conf I now have an extra file
0F:00:00:00:00:00:WPA.conf which contains not just my ssid and psk (in fred_blogs ascii style) but also a 64 bit hex code psk. I think it read my previous post :-)

and Network Wizard reports Successful Connection but still can't get onto the net. Looks like we are making progress but frankly no idea what changed.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#17 Post by tempestuous »

davesurrey wrote:I found ieee80211_crypt_tkip_rtl. Note not ieee80211_crypt_tkip-rtl.
That's a quirk with modprobe/modinfo - they report hyphens as underscores. Either will do.

It seems that pre-loading those extra modules helped, so let's go all out and load all encryption-related modules.
First the ones unique to the r8187 driver -

Code: Select all

modprobe ieee80211_crypt-rtl
modprobe ieee80211-rtl
modprobe ieee80211_crypt_tkip-rtl
Now the generic ones -

Code: Select all

modprobe arc4
modprobe ecb
modprobe crypto_blkcipher
modprobe aes_generic
modprobe crc32c
Now run the wpa_supplicant command. If it freezes, try a different version of wpa_supplicant.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#18 Post by tempestuous »

By the way, wpa_supplicant converts your Personal Security Key to hex values with the "helper" utility wpa_passphrase.
But to eliminate this potential source of error, you can pre-convert it by running this command -

Code: Select all

wpa_passphrase YOURSSID YOURPSK
then enter the result (hex values) in your wpa_supplicant.conf file.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#19 Post by davesurrey »

Did all the modprobing.

It finds my network, reports that it can't connect, gets as far as broadcasting for a lease then times out but reports Successful !!! Weird. I wish it would make up its mind.

I also noticed nothing in /etc/resolve.conf

I generated the hex psk and checked it agreed with the 0F:00:00:00:00:00:WPA.conf file

So with that strange behaviour I thought of trying jemimah's pwireless2. Still no luck but I did see it report that the driver was not wpa capable??

Then I saw it was recognising my network as using WEP. So I am wondering if there are some files left over from when I tried to connect to WEP.

So I deleted /etc/wpa_supplicant.conf and /etc/network-wizard/wireless/wpa_profiles/00:00:....file and reset wpa_supplicant.conf back to default and deleted /var/run/wpa_supplicant. But couldn't get rid of my network in pwireless2 still showing.

Here is a log from pwireless2 FWIW.

HTH and I am really appreciative of your resilience and help in all this.

Cheers
Dave
Attachments
wpa_supplicant.log.tar.gz
(3.04 KiB) Downloaded 300 times

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#20 Post by tempestuous »

Dave, your testing is first rate.
But I think this driver is simply not playing well with wpa_supplicant.
Let's put this into perspective: the standard rtl8187 module in the 2.6.25 kernel fails to support your Realtek RTL8187B device, and what we're dealing with here is the older proprietary driver, hacked by an individual developer to add support for your more modern chipset!

I think it's time for you to upgrade to the 2.6.30.5 kernel, where the rtl8187 driver should work fine. Is there any reason why you need to stick with 2.6.25.16?

Post Reply