Please help me with wireless.conf parameters (Solved)

[PaulBx1]

I've got a Netgear WG511T (chipset Atheros, lspci gives 168c:0013), and the Puppy version is 2.0.1. This setup works when I boot Win 98, although sometimes I have to give it a kick by unplugging and plugging the card - haven't bothered to chase that down.

I tried the madwifi driver; sometimes it works, but only for 15 minutes or so and then the driver goes into some loop reauthenticating forever (I'm guessing a driver bug).

So anyway I decided to try ndiswrapper. I used the beta package which had a driver inside it that looks like it works (neta3ab). But I am not sure what I need to put into the wireless.conf to get the card talking.

Here is what I get when I do an "iwlist wlan0 scanning":

Code: Select all

Cell 01 - Address: blah:blah:etc
ESSID:"MySSID"
Protocol:IEEE 802.11g
Mode:Managed
Frequency:2.437 GHz (Channel 6)
Quality:0/100 Signal level:-46dBm Noise level:-256dBm
Encrytion key:on
Bit rates:...54 Mb/s
Extra:bcn-int=100
Extra:atim=0
IE: WPA Version 1
 Group Cipher : TKIP
 Pairwise ciphers (1) : TKIP
 Authentication Suites (1) : PSK

I thought that "Quality" line looked strange.

Here is my wpa_supplicant.conf that made it sorta work in madwifi (just for reference):

Code: Select all

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=2
ap_scan=1
fast_reauth=1
network={
 ssid="MySSID"
 key_mgmt=WPA-PSK
 proto=WPA
 pairwise=TKIP
 group=TKIP
 psk=mydecodedpsk...
}

Here is what I currently have for wireless.conf

Code: Select all

ESSID="MyESSID"
MODE="Managed"
KEY="s:mypsk"

Everything else is commented out. I'm assuming that KEY is the one that is the passphrase, not the one that is expanded or decoded into a 64-char string.

When I do "dhcpcd -t 20 -d wlan0" it spits back the correct MAC address, but I never see any evidence of an IP, and the blinking lights on the card never indicate any change from the "looking for network association" condition.

Oh, by the way, the file rc.wireless had an invocation of /sbin/insmod, which didn't seem to work (couldn't find ndiswrapper), so I replaced it with "/sbin/modprobe ndiswrapper". Hope that is kosher...

If anyone can give a hint what else I need in that wireless.conf, or any other ideas, I'd appreciate it. I've been spending many hours trying to get this working.

[r__hughes]

Your wifi driver should be installed as a folder in /etc/ndiswrapper (mine is netdlwl installed from wifi-1.0.4-beta-2.pup).

Check to see if your driver has been associaed with some hardware:
in Xterm type (note ~# is the prompt)
~# ndiswrapper -l
Installed drivers:
2802w driver installed
airplus driver installed
bcmwl5 driver installed
bcmwl5a driver installed
gplus driver installed
mrv8k51 driver installed
mrv8ka51 driver installed
net8180 driver installed
neta3ab driver installed --- looks like yours
netadm11 driver installed
netdlwl driver installed, hardware present -- mine
ntpr11ab driver installed
rt2500 driver installed
w22n51 driver installed
w70n51 driver installed
~#
~# modprobe ndiswrapper (type this to associate he driver with wlan0 or eth0)
~# dmesg (at the bottom you'll see see something like this---

ndiswrapper: using irq 5
wlan0: vendor: 'D-Link Air Wireless LAN Adapter'
wlan0: ndiswrapper ethernet device 00:0f:3d:85:92:a3 using driver netdlwl, 1186:3300.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA; AES/CCMP with WPA
~#
then in Xterm type something like:
~# iwconfig wlan0 channel 3 essid Tango key 8877662109 mode Managed
~# dhcpcd -t 40 -h puppypc -d wlan0

(this is for a network named 'Tango' with WEP encryption key '8877662109' dishing out IPs
on channel 3) - change these parameters as appropriate

If all this works ie if you use Xterm and:
~#ipaddr (gives you your IP address)
~#ifconfig (confirms IP address)
~#iwconfig (gives you all your network parameters)
~#ping www.google.com (gives a line/sec of connection roundtime/ ctrl-c to exit)

then you can edit files to make it connect on bootup

1) Edit /etc/rc.d/rc.local to add:
. /etc/rc.d/rc.wireless

2) In rc.wireless I had to change this
# /sbin/insmod ndiswrapper if_name=$DEVICE
modprobe ndiswrapper if_name=$DEVICE ##### RH 08jun06

and uncomment this at the end
##################################################################
# Uncomment the following lines if you have a local DHCP server #
##################################################################

if [ -e /etc/dhcpc/*.pid ]; then
rm /etc/dhcpc/*.pid
fi
dhcpcd $DEVICE

3) In wireless.conf I entered
# ESSID (extended network name) : My Network, any
ESSID="Tango"
# NWID/Domain (cell identifier) : 89AB, 100, off
NWID=""
# Operation mode : Ad-Hoc, Managed, Master, Repeater, Secondary, auto
MODE="Managed"
# Frequency or channel : 1, 2, 3 (channel) ; 2.422G, 2.46G (frequency)
FREQ=""
CHANNEL="3"
# Sensitivity (cell size + roaming speed) : 1, 2, 3 ; -70 (dBm)
SENS=""
# Bit rate : auto, 1M, 11M
RATE=""
# Encryption key : 4567-89AB-CD, s:password
KEY="8877662109"
# RTS threshold : off, 500
RTS=""
# Fragmentation threshold : off, 1000
FRAG=""
# Other iwconfig parameters : power off, ap 01:23:45:67:89:AB
IWCONFIG=""
# iwspy parameters : + 01:23:45:67:89:AB
# IWSPY=""
# iwpriv parameters : set_port 2, set_histo 50 60
# IWPRIV=""

That's it - it comes up every time
Good Luck (and sorry this is so long)

[PaulBx1]

Sorry my response is so late; I was out of town.

Just going down the steps you did, I got this far:
1) the driver is in /etc/ndiswrapper
2) "ndiswrapper -l" shows "neta3ab driver installed, hardware present"
3) dmesg shows this:

Code: Select all

ndiswrapper version 1.15 loaded (preempt=no,smp=no)
ndiswrapper: driver neta3ab () loaded
(couple lines about PCI and ACPI)
ndiswrapper: using irq 11
wlan0: vendor: ' '
wlan0: ndiswrapper ethernet device blah:blah:blah using serialized driver neta3ab, 168c:0013.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA; AES/CCMP with WPA

4) when I had previously done the "iwlist wlan0 scan" it showed the AP using Channel 6. However when I set channel 6 in my iwconfig command, "dmesg" gives this result:

Code: Select all

ndiswrapper (iw_set_freq:382): setting configuration failed (C0010015)

The actual command I use to set frequency is "iwconfig wlan0 channel 6" which responds in the terminal window with

Code: Select all

Error for wireless request "Set Frequency" (8b04):
   SET failed on device wlan0; Invalid argument.

...and it goes downhill from there.

I found this discussion about iwconfig and it mentions to use "iwpriv". When I do that, I don't see the ioctl 8B04 being available. Or maybe I'm reading it wrong...

[r__hughes]

iwconfig wlan0 channel 6

It looks to me as though your iwconfig command is missing the network-name , WEP status. and DHCP/IP management.

Try a 10-hex-digit WEP instead of a code-phrase and specfy the network name eg
iwconfig wlan0 channel 3 essid Mercury key 1112223336 mode Managed

Sometimes it's advisable to remove all router network WEP security and ensure the network name is broadcast while you get yourself connected - then introduce security aspects one at a time. Also , if your router is issuing IP addresses you must put 'mode managed'

good luck

[PaulBx1]

It looks to me as though your iwconfig command is missing the network-name , WEP status. and DHCP/IP management.

Actually no. I had earlier tried the whole thing in the form you suggested (but modified for my needs of course), e.g. "iwconfig wlan0 channel 3 essid Tango key 8877662109 mode Managed", with the same result, complaints about the channel.

I reported it simply as "iwconfig wlan0 channel 6" because I assumed, perhaps incorrectly, that I could configure it one piece at a time, and was distilling it down to the piece that it had problems with. Is that an incorrect assumption? Either way I do it, it complains about the channel setting.

BTW, this page does not imply you cannot do one command at a time. However it does have this interesting comment:

All these parameters and statistics are device dependant. Each driver will provide only some of them depending on the hardware support, and the range of value may change. Please refer to the man page of each device for details.

So I guessed, maybe that's telling me the driver neta3ab does not support "channel" setting, using freq instead. I did do a simple "iwconfig" and it reported "Frequency:2.437 GHz", not saying anything about channel. Just for yuks I tried setting the frequency instead, and it complained like it did about channel setting! I guess I'd look up the man page for this device to get the definitive syntax of the command, except there ain't any! Driver source would be the next bet (what are my chances of prying the neta3ab driver out of the vendor?), but maybe I won't bother because it appears to be set at the right frequency anyway. So I'll just leave the channel and frequency parameters off it (but heaven help me the first time I try to hook up to an internet cafe).

Try a 10-hex-digit WEP instead of a code-phrase and specfy the network name eg
iwconfig wlan0 channel 3 essid Mercury key 1112223336 mode Managed

Ha ha, I was assuming <doh!> this key referred to a WPA key, which is what the AP uses. Strange, the "man" page I mentioned does not make any distinction between WEP and WPA. I am having difficulty understanding what is wanted here. Or if a WPA key is even supported with this driver or with ndiswrapper.

When I got it running, for a while anyway, under madwifi, I had used a 12-character passphrase that had been converted into a 64-hex digit number via the wpa_passphrase command as described here. But that iwconfig "man" page I mentioned earlier had the comment, "Passphrase is currently not supported." Interestingly, I was able to change the key reported back in the "iwconfig" command to the 64-hex digit number I had used with WPA. However I still do not get any indication (via the blinking lights on the card) that it is communicating with the AP, even after issuing the modprobe and dhcpcd commands again.

Sometimes it's advisable to remove all router network WEP security and ensure the network name is broadcast while you get yourself connected - then introduce security aspects one at a time. Also , if your router is issuing IP addresses you must put 'mode managed'

Yeah, I know. Unfortunately the AP and internal wifi setup, along with my external wimax connection, was done by my wimax vendor, and I don't have access to the AP internal setup to turn the encryption off. Maybe I ought to nag the vendor about that. Please recall though, this does work under Windows. So I hope I can get this done without turning encryption off first. I realize it adds an extra element of difficulty.

On the other thing, I did tell it "managed" with no problem.

[r__hughes]

Hi Paul - the good news is that you seem to be 95% of the way there - the bad news is that the devil is in the details of the remaining 5%.

On my Notebook card (D-Link DWL-610 pcmcia) and the corresponding two PC cards (D-Link DWL-510 PCI) that I have tried, one light starts flashing immediately after the 'modprobe ndiswrapper' command - I think this means it's powered and scanning. The other light comes on steady after the 'iwconfig etc etc' to show it's communicating with a network - but hasn't necessarily got an IP address - if it does get an IP address it drops out of the iwcommand line to the next instruction (or if you're doing it from Xterm, it drops to the prompt)

Keep on slogging and keeping notes on what you're doing - once you've got it working from the command line you're there - then configure a WAG profile and put the winning code in the /etc/rc.d files as mentioned.

Just a thought, are you sure there's no router firewall or MAC filter locking you out?

[PaulBx1]

Thanks for your support r, it is really helping me out.

I can report some further success!

First some preliminaries. I believe iwconfig "key" command refers only to WEP encryption. No site I read actually came out and said it, but it can be inferred as you will see later. If I do anything with that, I'm guessing I simply need to set "key" to "off" (yet to be checked). That is, tell it not to bother with WEP encryption.

Also, I finally realised that in WEP, 40 bit and 64 bit encryption are the same thing, and 104-bit and 128-bit encryption are the same thing. Just an FYI; that had confused me.

Another FYI, I read somewhere (sorry, can't find it now) that ndiswrapper doesn't support the link quality parameter you can show under the iwconfig command, which explains why many of them are zeroed (which had bothered me).

OK, the deal is that if you use WPA under ndiswrapper, you also have to use wpa_supplicant! Just like you have to do under madwifi or any linux native mode wireless driver I suppose. This link shows how to do that; you have to modify /etc/modprobe.conf! Of course some changes have to be made under puppy. What I ended up with was this:

Code: Select all

alias wlan0 ndiswrapper (already there, from the modprobe at boot, I guess)
install ndiswrapper /bin/modprobe --ignore-install ndiswrapper && /usr/bin/wpa_supplicant -Dndiswrapper -iwlan0 -c/etc/wpa_supplicant.conf -B
remove ndiswrapper /sbin/modprobe -r --ignore-remove ndiswrapper

Note the parameters for wpa_supplicant do NOT have spaces between the switch and the parameter, unlike the command-line invocation of it. Also pay attention to the paths in that; it may differ among the different puppy revs or where you install things.

Anyway, end result is that my card lights are flashing properly to show an "associated" link between the card and the AP!

Next problem, my dhcpcd invocation always times out, and I never get an IP out of the dang thing. <sigh> Sure wish madwifi had been more solid, I could have avoided a lot of this.

Oh, and one other fly in the ointment. Looking at dmesg, I see this:

Code: Select all

ndiswrapper: WPA support through 'ndiswrapper' interface is deprecated; use 'wext' interface.

[PaulBx1]

Well, I changed that "-Dndiswrapper" to "-Dwext", and it got rid of the deprecated message.

I also tried fooling with the iwconfig key command, and can report that turning these keys off (so that nothing is found in "iwlist wlan0 key") makes the card lose the connection every so often. So I put a key back in there just to get it going again. Strangely, iwlist wlan0 key now shows something unredictable. You never know what key slot is off, or loaded with who knows what.

None of this caused the dhcp to start working. Also, I'm seeing messages complaining about setting frequency in dmesg again, even though I left that and the channel setting of wireless.conf disabled. Maybe wext does it automatically. Doesn't matter, the freq is always correct.

[marksouth2000]

Next problem, my dhcpcd invocation always times out, and I never get an IP out of the dang thing.

Sometimes, when messing around with wireless settings, a file named

Code: Select all

/etc/dhcpc/dhcpcd.pid

gets left behind. If this already exists, dhcpcd will not run, and dhcp requests will always time out.

In a terminal, type

Code: Select all

# ps aux | grep dhcp

to check that dhcpcd is running after your dhcp request. If not, look for the ".pid" file and delete it, then try again.

Good luck,
Mark

[PaulBx1]

Why thank you Mark. I had left that snippet of code at the bottom of rc.wireless commented. I uncommented it, but still no IP address.

BTW, I notice that wireless.conf is the file that is supposed to be edited with the configuration, while rc.wireless interprets the contents of wireless.conf. However, rc.wireless still needs to be itself edited, not only down at the bottom, but also changing "insmod" to "modprobe", and who knows what else. Wouldn't it be cleaner to just combine rc.wireless and wireless.conf? For example, wireless.conf has this:

Code: Select all

# Bit rate : auto, 1M, 11M
RATE=""

while rc.wireless interprets it thus:

Code: Select all

if [ -n "$RATE" ] ; then
    $IWPATH/iwconfig $DEVICE rate $RATE
fi

Combining the two would be cleaner, and make clear what command is being used thus suggesting recourse to man pages and such:

Code: Select all

# Bit rate: To set, uncomment below command and append rate, e.g. auto, 1M, 11M
#$IWPATH/iwconfig $DEVICE rate <desired rate>

I will do it for next revision Puppy if it makes any sense. To me, sometimes when details are obscured from users, it just makes for unnecessary complexity, especially in areas like wireless setup where it's unavoidable grinding through this stuff.

<later>
I've got it!

I was getting this in dmesg:

Code: Select all

bind(PF_UNIX): Address already in use

I googled around and found the explanation here, about in the middle of the page. I deleted the offending file (actually, socket link) and the now-uncommented dhcpcd finally worked, and I am able to get on the internet! Yay!

Looks like I will have to add another snippet of code to the bottom of rc.wireless.

Now I will work a while to see if it is solid, or dies in a while like madwifi did.

[PaulBx1]

Well, it is solid; that's what I'm using now to write this post. The one weird thing is that when I do "iwlist wlan0 key" it shows 4 key slots (apparently what this card supports) and those slots are filled with strange, occasionally changing 256-bit keys, my guess is WEP keys. Seems like it has no effect on anything, though.

I should do a little cleanup and a recap before I mark this one "solved".

[tempestuous]

I have come in on this discussion a little late, but I suggest that rc.wireless and wireless.conf, which I presume are created by WAG, may be difficult to deal with since neither was designed to accommodate wpa_supplicant.
It would be easier to ignore or remove these scripts, and instead add your own setup commands to /etc/rc.d/rc.local ... or create your own script which can be used to connect to a wifi network "on-demand".

If you're using wpa_supplicant-0.4.9.pup which I provided here http://www.dotpups.de/dotpups/Wifi/wireless-drivers/
then the correct setup commands are explained in /root/my-applications/wpa_supplicant_README.txt

[keenerd]

WAG does not involve itself with either of those files.

Bladehunder's Wifibeta did that.

[PaulBx1]

Well, I did look at that readme, back when I was trying to get madwifi to work. I had forgotten about it in the meantime. It took me quite a while to realize I had to use wpa_supplicant at all.

I also have little doubt there are better ways to do it than I did. But I was really in the dark on this, just like any newbie would be. I am going to recap what I did to get this working so others might have at least some guidance.

OK, again this is a Netgear WG511T with the Atheros chipset (5212 I think). lspci gives 168c:0013. I originally tried the madwifi driver in conjunction with wpa_supplicant (our network uses WPA rather than WEP), but found the connection to be difficult to establish, and it also dropped it and went into an endless loop trying to re-establish after 15 or 20 minutes. This sounded like some bugs recorded on the madwifi site, so I decided to give up on madwifi and try ndiswrapper.

I got the wifibeta dotpup installed which included ndiswrapper and various (windows I guess) driver. "ndiswrapper -l" shows:

Code: Select all

sh-3.00# ndiswrapper -l
Installed drivers:
2802w           driver installed 
airplus         driver installed 
bcmwl5          driver installed 
bcmwl5a         driver installed 
gplus           driver installed 
mrv8k51         driver installed 
mrv8ka51                driver installed 
net8180         driver installed 
neta3ab         driver installed, hardware present 
netadm11                driver installed 
netdlwl         driver installed 
ntpr11ab                driver installed 
rt2500          driver installed 
w22n51          driver installed 
w70n51          driver installed 

My wireless.conf looks like this:

Code: Select all

sh-3.00# cat wireless.conf
# Config for wireless card
# Change to suit your needs
# If a value is unneeded leave it as is
    # ESSID (extended network name) : My Network, any
    ESSID="myssid"
    # NWID/Domain (cell identifier) : 89AB, 100, off
    NWID=""
    # Operation mode : Ad-Hoc, Managed, Master, Repeater, Secondary, auto
    MODE="Managed"
    # Frequency or channel : 1, 2, 3 (channel) ; 2.422G, 2.46G (frequency)
    FREQ=""
    CHANNEL=""
    # Sensitivity (cell size + roaming speed) : 1, 2, 3 ; -70 (dBm)
    SENS=""
    # Bit rate : auto, 1M, 11M
    RATE=""
    # Encryption key : 4567-89AB-CD, s:password
    KEY="mysecretkeywhichmaybeirrelevant"
    # RTS threshold : off, 500
    RTS=""
    # Fragmentation threshold : off, 1000
    FRAG=""
    # Other iwconfig parameters : power off, ap 01:23:45:67:89:AB
    IWCONFIG=""
    # iwspy parameters : + 01:23:45:67:89:AB
    # IWSPY=""
    # iwpriv parameters : set_port 2, set_histo 50 60
    # IWPRIV=""

My rc.wireless looks like this:

Code: Select all

#!/bin/sh

# rc.wireless for Puppy 0.9.8 > (Rob Murphy 22/1/05)
# Bring up wireless card 
# Sections from
# wireless network 1.63 2000/02/09 03:12:42 (David Hinds/Jean Tourrilhes)


DEVICE="wlan0"
IWPATH="/usr/sbin"
. /etc/rc.d/wireless.conf

# Load the driver with default wlan0 interface name
# 
# /sbin/insmod ndiswrapper

# Load the driver with $IFACE interface name and give the driver a chance
# to finish loading
#/sbin/insmod ndiswrapper if_name=$DEVICE
# Use modprobe instead of insmod
/sbin/modprobe ndiswrapper
sleep 3

    # Mode need to be first : some settings apply only in a specific mode !
    if [ -n "$MODE" ] ; then
         $IWPATH/iwconfig $DEVICE mode $MODE
    fi

    if [ -n "$ESSID" ] ; then
         $IWPATH/iwconfig $DEVICE essid $ESSID
    fi

    # This is a bit hackish, but should do the job right...
    if [ ! -n "$NICKNAME" ] ; then
        NICKNAME=`/bin/hostname`
    fi
    if [ -n "$ESSID" -o -n "$MODE" ] ; then
         $IWPATH/iwconfig $DEVICE nick $NICKNAME >/dev/null 2>&1
    fi
    # Regular stuff...
    if [ -n "$NWID" ] ; then
         $IWPATH/iwconfig $DEVICE nwid $NWID
    fi
    if [ -n "$FREQ" ] ; then
         $IWPATH/iwconfig $DEVICE freq $FREQ
    elif [ -n "$CHANNEL" ] ; then
         $IWPATH/iwconfig $DEVICE channel $CHANNEL
    fi
    if [ -n "$SENS" ] ; then
         $IWPATH/iwconfig $DEVICE sens $SENS
    fi
    if [ -n "$RATE" ] ; then
         $IWPATH/iwconfig $DEVICE rate $RATE
    fi
    if [ -n "$KEY" ] ; then
         $IWPATH/iwconfig $DEVICE key $KEY
    fi
    if [ -n "$RTS" ] ; then
         $IWPATH/iwconfig $DEVICE rts $RTS
    fi
    if [ -n "$FRAG" ] ; then
         $IWPATH/iwconfig $DEVICE frag $FRAG
    fi
    # More specific parameters
    if [ -n "$IWCONFIG" ] ; then
         $IWPATH/iwconfig $DEVICE $IWCONFIG
    fi
    if [ -n "$IWSPY" ] ; then
         $IWPATH/iwspy $DEVICE $IWSPY
    fi
    if [ -n "$IWPRIV" ] ; then
         $IWPATH/iwpriv $DEVICE $IWPRIV
    fi
   ################################################################## 
   # Uncomment the following lines if you have a local DHCP server  #
   ################################################################## 
    
   if [ -e /etc/dhcpc/dhcpcd-$DEVICE.pid ]; then
   rm /etc/dhcpc/dhcpcd-$DEVICE.pid 
   fi
   dhcpcd $DEVICE

   ################################################################## 
   # Uncomment the following lines if you use wpa_supplicant        #
   ################################################################## 

   if [ -e /var/run/wpa_supplicant/$DEVICE ]; then
   rm -f /var/run/wpa_supplicant/$DEVICE 
   fi

   ################################################################## 
   # Uncomment the following lines and plug in your values if you   #
   # need to define the IP address of your Puppy machine and set    #
   # the default route. Also remember to edit /etc/resolv.conf      # 
   # to include the addresses of the DNS servers                    #
   ################################################################## 
   
##  ifconfig $DEVICE 192.168.xxx.xxx netmask 255.255.255.0
##  route add -net default gateway 192.168.yyy.yyy $DEVICE

Notice I have changed "insmod" into "modprobe", and have added a cleanup for a wpa_supplicant file just like the one for the dhcpcd pid file.

My wpa_supplicant.conf file looks like this:

Code: Select all

# WPA-PSK/TKIP

ctrl_interface=/var/run/wpa_supplicant
#ctrl_interface_group=0
#eapol_version=2
#ap_scan=1
#fast_reauth=1


network={
        ssid="myssid"
        key_mgmt=WPA-PSK
        proto=WPA
        pairwise=TKIP
        group=TKIP
        #psk="mywpapassphrase"
        psk=thehexrepresentationofmywpapassphrase
}

I got the hex representation of my WPA passphrase by running the "wpa_passphrase" command. I believe this is the real passphrase, and not that stuff that is sent over in the rc.wireless script (which is WEP stuff), however for some strange reason it didn't work to simply turn the WEP passphrase off. Also now when I run "iwlist wlan0 key" it returns garbage in the key slots:

Code: Select all

h-3.00# iwlist wlan0 key
wlan0     2 key sizes : 40, 104bits
          4 keys available :
                [1]: 8813-005C-7501-E674-37E8-4161-2EA0-6D14-F2CC-A03D-404D-E67F-A127-BF9B-F7AA-8B16 (256 bits)
                [2]: 3C24-7035-1167-EB45-E795-C4E1-D9C4-90A3-A465-F67F-05D3-9A9B-011E-A6FA-8A85-D0C9 (256 bits)
                [3]: 9004-D52E-EDF8-646D-92AD-A477-C95E-457D-AA18-9344-F743-F058-44CD-2638-E90E-7075 (256 bits)
                [4]: C877-0C4F-1430-254E-9EB1-7555-6E6E-5CFD-A179-8DA2-B736-8907-2F3A-9515-635C-7983 (256 bits)
          Current Transmit Key: [1]
          Authentication capabilities :
                WPA
                CIPHER TKIP
                CIPHER CCMP
          Current key_mgmt:0x2
          Current cipher_pairwise:0x4
          Current cipher_group:0x4

The garbage there also changes over time. Looks messy but I don't think it hurts anything.

Also I had to change the way the modprobe loaded ndiswrapper, by editing the bottom of modprobe.conf:

Code: Select all

alias wlan0 ndiswrapper
install ndiswrapper /sbin/modprobe --ignore-install ndiswrapper && /usr/bin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -B
remove ndiswrapper /sbin/modprobe -r --ignore-remove ndiswrapper

Note instead of invoking "-Dndiswrapper" I am invoking "-Dwext" because wpa support through ndiswrapper is deprecated, according to a message I got at boot time.

Here is what dmesg looks like when I boot:

Code: Select all

ndiswrapper version 1.15 loaded (preempt=no,smp=no)
ndiswrapper: driver neta3ab () loaded
PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:02:00.0 to 64
ndiswrapper: using irq 11
wlan0: vendor: ''
wlan0: ndiswrapper ethernet device 00:0f:b5:eb:2f:ce using serialized driver neta3ab, 168C:0013.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA; AES/CCMP with WPA
ndiswrapper (iw_set_freq:382): setting configuration failed (C0010015)
ndiswrapper (miniport_tx_packets:562): packet d24d0d80 dropped

I don't know why ndiswrapper is complaining in those two messages at the end. Everything seems to work though.

It ain't pretty, or elegant, but I'm satisfied. If anyone else has any cleanup hints I will try them out. My connection has been 100% reliable.

[tempestuous]

Yes, that's not pretty.
Most alarming is the frequent reference to iwconfig. When your encryption is WPA, not WEP, wpa_supplicant takes care of the wifi connection parameters, namely SSID and passphrase/passkey, via its configuration file /etc/wpa_supplicant.conf. iwconfig is completely unnecessary.
I can think of some possible exceptions ... if, say the channel needed to be forced, or the wifi device defaulted to "master" mode or "adhoc" mode instead of the usual "managed" mode ... but these are exceptional circumstances.
In theory, this is all you should need -

modprobe ndiswrapper
ifconfig wlan0 up
wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant.conf -B
sleep 20
if [ -e /etc/dhcpc/*.pid ]; then rm /etc/dhcpc/*.pid; fi
dhcpcd -t 30 -h puppypc -d wlan0

Notice the "sleep 20" line. This gives wpa_supplicant the time it needs to complete the complex WPA authentication process before dhcpcd is run.

Changing subject slightly, the MADWiFi driver I compiled (SVN rev. 1545) has now been reported by several people as being problematic, so I have just updated to the latest stable version 0.9.1 here http://www.dotpups.de/dotpups/Wifi/wireless-drivers/
You might want to try that.

Ironically, the one time I tested wpa_supplicant myself was with a D-Link DWL-G650r4 PCMCIA card using the MADWiFi driver ... it worked perfectly. But that was an older version of MADWiFi and an older kernel.

[PaulBx1]

tempestuous, I will give the madwifi another try, since you have gotten another one.

Might I make a suggestion? Your madwifi readme makes the unstated assumption WEP is being used (with the iwconfig command), yet the small script (wpa_connect) you have supplied assumes WPA. Now, while this may be obvious to you, and by now is obvious to me too, I can tell you it is very confusing to a newbie. Remember, most of them really have little idea what these commands are doing, and apply any recipe they can find pretty blindly - leading to messes like I reported above.

What you need to do is explain right out front that the user will have two choices, depending on his network, and give him two script examples, one explicitly being WEP and one WPA (and maybe even one w/o encryption, if anyone is rash enough to run that way). And maybe what is the best way to invoke them at boot, too.

I am sorry to be suggesting more work for you, but it might save you some support work in the future.

I notice by the way that your examples do not include cleanup of that one wpa_supplicant file, as I found was needed during this work:

Code: Select all

   if [ -e /var/run/wpa_supplicant/$DEVICE ]; then
   rm -f /var/run/wpa_supplicant/$DEVICE
   fi

I will let you know how this new madwifi works.

[PaulBx1]

Unfortunately, this new madwifi is little better than the old one. It works for a while, then gets into a loop reauthenticating over and over. See this log fragment:

Code: Select all

Jul 07 19:03:17.567565: State: GROUP_HANDSHAKE -> COMPLETED
Jul 07 19:03:17.567594: CTRL-EVENT-CONNECTED - Connection to 00:0e:2e:3a:c3:0c completed (reauth)
Jul 07 19:03:17.567615: EAPOL: External notification - portValid=1
Jul 07 19:03:17.567669: EAPOL: External notification - EAP success=1
Jul 07 19:03:17.567689: EAPOL: SUPP_PAE entering state AUTHENTICATING
Jul 07 19:03:17.567708: EAPOL: SUPP_BE entering state SUCCESS
Jul 07 19:03:17.567727: EAP: EAP entering state DISABLED
Jul 07 19:03:17.567747: EAPOL: SUPP_PAE entering state AUTHENTICATED
Jul 07 19:03:17.567766: EAPOL: SUPP_BE entering state IDLE
Jul 07 19:03:18.537661: Wireless event: cmd=0x8c02 len=77
Jul 07 19:03:18.537735: Custom wireless event: 'MLME-REPLAYFAILURE.indication(keyid=4 unicast addr=00:0f:b5:eb:2f:ce)'
Jul 07 19:03:19.550179: Wireless event: cmd=0x8c02 len=77
Jul 07 19:03:19.550252: Custom wireless event: 'MLME-REPLAYFAILURE.indication(keyid=4 unicast addr=00:0f:b5:eb:2f:ce)'
Jul 07 19:03:19.689006: EAPOL: startWhen --> 0
Jul 07 19:03:20.562625: Wireless event: cmd=0x8c02 len=77
Jul 07 19:03:20.562699: Custom wireless event: 'MLME-REPLAYFAILURE.indication(keyid=4 unicast addr=00:0f:b5:eb:2f:ce)'
Jul 07 19:03:21.575139: Wireless event: cmd=0x8c02 len=77
Jul 07 19:03:21.575214: Custom wireless event: 'MLME-REPLAYFAILURE.indication(keyid=4 unicast addr=00:0f:b5:eb:2f:ce)'
Jul 07 19:03:22.587606: RX EAPOL from 00:0e:2e:3a:c3:0c

Over and over again. Authenticates, just gets to idle, then a second later falls on its face again. <sigh>

Back to ndiswrapper...

[tempestuous]

I think the problem may be with wpa_supplicant not being able to deal with the newer versions of MADWiFi. When the next stable version of wpa_supplicant is available, I will compile it.
Stick with ndiswrapper for now.

Your madwifi readme makes the unstated assumption WEP is being used

This is something of an historical error. (Notice my traditional grammar!)
iwconfig is part of the wireless-tools package and is quite established in the Linux world. It was developed before WPA came onto the scene, and the latest versions still don't support WPA. Another wireless-tools utility "iwpriv" can support WPA with certain drivers, but that's another story.

wpa_supplicant is a newer, and distinctly separate, development project. There are some Linux distributions which do include it, but having compiled this utility myself, I know that wpa_supplicant must be explicitly configured for compatibility with various wifi drivers, and it requires the presence of that driver source code as it compiles. So I wonder whether all possible driver-compatibilities were enabled in some of the wpa_supplicant versions out there.

What I'm saying is that WPA compatibility is not the norm in Linux, so Puppy Linux is well-endowed in this respect.
A few months ago I saw a post on the DamnSmallLinux forum ... "How do I use WPA in DSL?" There was no response. Presumably no one there knew. I was tempted to answer ... "Use Puppy Linux"!

Back to your question ... yes, I will address your concerns in the near future. I need to make this information as simple as possible, I don't want to bamboozle newbies. The wifi situation is complex enough as it is, and this situation was not created by me.
But the bottom line is that some effort is required to achieve certain hardware compatibility and certain configurations. I must commend you for the amount of effort you spent, and the fact that you did achieve a workable result!

We had an extraordinary post on this forum by a new user who wanted to know what buttons to press to enable his/her wifi connection, and became quite indignant when he/she learned from one of our helpful members (not me) that it was not so easy.
Is that naivety or arrogance? Thankfully for everyone, that was a one-post forum member.

I notice by the way that your examples do not include cleanup of that one wpa_supplicant file, as I found was needed ...

Thanks for this info. I will definitely add this to the wpa_supplicant_README.

[tempestuous]

PaulBx1,
I just compiled the latest wpa_supplicant-0.5.4 against the source code for madwifi-0.9.1
Do you want to test it?

EDIT: wpa_supplicant-0.5.4.pup download removed. Now get version 0.5.5 here http://www.dotpups.de/dotpups/Wifi/wireless-utilities/

[PaulBx1]

OK. Is 0.9.1 the madwifi I was using? (The pupget package manager says that is the last one I installed, so it probably is.) Can I just write over my previous install, or do I have to remove the old wpa_supplicant first?

<later> Now I have become reluctant. It's one thing to experiment with madwifi, but I am using wpa_supplicant with my current setup. I would hate to break it when it took so much pain to get it going in the first place. If you can tell me a way to do it so I can get back to a working condition with ndiswrapper without too much pain, I will give it a try.