Improved Network Wizard (and rc.network)

[Dougal]

I know for certain on the Senao card that it will not scan unless I load a profile first, even a blank one works on Dingo 4 (kernel 2.6.21.7) I will try to gather all my cards and test each one individually as soon as I find the time.

This is very strange... I looked very closely at everything that happens
when you do something like load a profile, then at what happens when you
press the "Scan" button, and cannot see anything that can affect the scan...

Pressing the different buttons just sets various GUI-related parameters,
while running the scan literally does just that -- run "iwlist $INTERFACE scan"
(except for the Prism2 card, which uses wlanctl-ng) -- and then parse the
output.

So the only thing I can think of which might be the cause is some timing
problem(?), where the extra delay before the scan does the trick... which
is odd, since I assume you don't always run it immediately upon boot, so
quickly that those couple of seconds matter.

Maybe you should try running a scan manually (iwlist $INTERFACE scan) before
you do the profile loading/button pressing -- see if the scan really fails
or it is the wizard (you'll need to run ifconfig $INTERFACE up before scanning).
Also, maybe try running "tail /var/log/messages" and see if something
happens that might be related to the interface...

I just looked again and this time it loaded the hostap_cs module. These cards, Senao, nl-2511cd plus seem to be detected differently every few times they load. Could be a bad batch of cards?

No, it's something that Barry needs to sort in the startup scripts:
First, the prism2_ modules support the same devices as the hostap_ modules,
but the hostap_ are in-tree and should be the ones used. The only prism2_
module that actually should be included in Puppy is prism2_usb (since there
is no usb support in the hostap_ drivers) -- that is how it used to be in
the past.

Second, I just checked the modules.alias file for my 2.6.24 kernel and it
turns out a lot of device IDs matching hostap_cs also match orinoco_cs!
So you need to get Barry to do something about it -- give one preference
over the other at boot time.
To see the overlap between the two, the following command can be run:

Code: Select all

grep 'hostap_cs\|orinoco_cs' /lib/modules/`uname -r`/modules.alias | sort

(the "full" modules.alias is needed, obviously)
then you just look for identical adjacent lines ending with orinoco_cs and
hostap_cs.
(Turns out there is also overlap between orinoco_nortel and hostap_plx,
orinoco_plx and hostap_plx, orinoco_pci and hostap_pci, and orinoco_tmd
and hostap_plx! Tempestuous, where art thou? It seems the hostap drivers
have been updated more recently, so maybe they are the better ones? Also,
they support WPA in the wizard.)

Now I am off to look into rutilt. I do a lot of wireless network bridges, routers and repeaters and that has been very helpful when it works.

Yes, RutilT is very useful for quickly connecting and getting stats about
the network, but it doesn't have all the little tricks we use to get things
working in the wizard... (also the set_ip.sh script could be improved.)

[Dougal]

I was looking for a difference in the average value. I will admit that
sixteen data points is on the small size for estimating a statistical mean value from an average. However, I did check the overall combined data set for the standard deviation.

I wasn't being that smart about it... I was just thinking about the temporal
accuracy of the measurement (i.e. it is easier to measure how long it takes
you to drive a kilometer and divide by a thousand than to measure how long
it takes to drive a meter...).

I tried use a low sleep value and the number of times through the loop (COUNT) to get an estimate of time required. I kept getting widely different values. I decided to use a simple command (echo $COUNT > /dev/null) to put a small, but unknown delay.

I was actually afraid that if you check too frequently you might add
latency... I don't know what effect the repeated "wpa_cli status" commands
might have.

In any case, I didn't think we need too accurate a measurement, since I only
think the latency is a problem if it's tangible: if it takes 2 seconds to
connect normally but 4 seconds with the extra parameter or something.

The bad news is Puppy 4 alpha 7 network wizard on my system does not work with a wpa2 network using a hidden SSID. It never connects. I checked with wpa_cli status and found wpa_suplicant never gets past ap association. Additionally, one has to use the scan twice to detect the hidden SSID.

And when you try manually (with a script), it does work? Were the above
measurements with WPA or WPA2?

There is one thing in the wizard that might be relevant here: in the
validateWpaAuthentication function, I included something I got from wicd,
where, if it doesn't authenticate in 3 seconds, I run "wpa_cli scan".
Here's the explanation given in wicd:

# This works around authentication validation sometimes failing for
# wpa_supplicant because it remains in a DISCONNECTED state for
# quite a while, after which a rescan is required, and then
# attempting to authenticate. This whole process takes a long
# time, so we manually speed it up if we see it happening.

To see if that is the problem, you can comment out the "*DISCONNECTED*)" part
of the case structure in validateWpaAuthentication (lines 998-1008 in
wag-profiles.sh (the new version I'm just posting)).

[Dougal]

I've just updated the attachment in the parent post.
It only adds the option to reset a pcmcia card if the wireless scan fails
and WPA support for ndiswrapper.


I have also written code for detecting the firewire ethernet interface,
but have not included it yet, since there's one thing I wasn't sure about:
We probably want to configure it with a static IP, right?
The problem is that the static IP code in the wizard requires that
you give a valid set of IP, netmask and gateway -- it even checks.
So just telling it to use 10.0.0.11 isn't enough... (and telling it to
use 10.0.0.11, 10.255.255.255 and 255.0.0.0 didn't work... or maybe that
was just because I was trying with an interface that was not connected to
anything.)

So I need to know if the interface will be configured with the usual
static IP code, or if I need to add a special function that just sets a
IP address and that all (for connecting two computers).

[Béèm]

I have a live network which works ok with following info:

Code: Select all

# ifconfig eth2
eth2      Link encap:UNSPEC  HWaddr 00-06-1B-00-20-0B-01-EC-00-00-00-00-00-00-00-00  
          inet addr:10.0.0.11  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:209 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:37053 (36.1 KiB)  TX bytes:394095 (384.8 KiB)

# 

I only give

Code: Select all

ifconfig eth2 10.0.0.11

If you want you can sent me your code so I can test.

[JustGreg]

Dougal, Thank you for the information"

Dougal

I wasn't being that smart about it...

I did not think that. In fact, the old engineer in me said, you sure you did enough measurements. That is why I checked a couple of references and confirmed it was on the small side. I did learn you do not want to take too many. . It results in missed pings or a couple of longer ping times.

Dougal

I was actually afraid that if you check too frequently you might add latency... I don't know what effect the repeated "wpa_cli status" commands might have. "

In that case, I did try various values of sleep. It appears the best value was about 0.2 seconds for sleep. Once again, ever so often, I would get one case where it took much longer to connect. This occurred with all test cases. There were some minor differences, but no major difference stood out.

Dougal

And when you try manually (with a script), it does work? Were the above measurements with WPA or WPA2?

Yes, I was able to connect manual with the normal Tempestuous script to either a broadcast or hidden SSID on my WPA2 network. The Puppy 4 alpha 7 network wizard works fine for open. It is on a hidden SSID that the problem occurs. I think most users connect to broadcast SSID network. So, the problem needs to be worked, but is not a killer.

I will try the new version you just posted. I have also looked at the documentation for wpa_supplicant. There is a way to start wpa_supplicant and then configure it with wpa_cli. I will try to do that. If I have some success, then I report it.

Lastly, I have been trying Ubuntu out as an alternative for Window$ on my wife's computer. The Ubuntu connect wizard does not handle a WPA2 network well. It completes forgetting the settings and thinks the network is a WPA one. You have to set up the WPA2 network ever time you want to connect. This is non-starter for my wife. So, it appears everyone has a problem with WPA2.

[peppyy]

(Turns out there is also overlap between orinoco_nortel and hostap_plx,
orinoco_plx and hostap_plx, orinoco_pci and hostap_pci, and orinoco_tmd
and hostap_plx! Tempestuous, where art thou? It seems the hostap drivers
have been updated more recently, so maybe they are the better ones? Also,
they support WPA in the wizard.)

Ah ha! That is why those cards sometimes are detected as a Farallon Skyline or an Orinoco at boot. I believe half the EIP problem is from improper hardware detection then. I will have to go back with some of the alphas that would not boot and try them with the minimum of hardware available.

Yes, RutilT is very useful for quickly connecting and getting stats about
the network, but it doesn't have all the little tricks we use to get things
working in the wizard... (also the set_ip.sh script could be improved.)

I agree, as a stand alone ap it is very handy, It seems that the latest version has some bugs in it though. Might be a project for another day.

On another note. my Orinoco Gold minipci card is performing admirably in this laptop. It scans well with your Improved wizard and connects without any issues. It's a keeper.

Thanks

[Dougal]

I will try the new version you just posted. I have also looked at the documentation for wpa_supplicant. There is a way to start wpa_supplicant and then configure it with wpa_cli. I will try to do that. If I have some success, then I report it.

The latest version shouldn't change anything -- what you need to do is comment out those lines I mentioned and see if that solves it.
Using wpa_cli to configure it is what is done by the wizard, where it adds the network-specific info, saves the config file, then kills wpa_supplicant before starting it again...

Lastly, I have been trying Ubuntu out as an alternative for Window$ on my wife's computer. The Ubuntu connect wizard does not handle a WPA2 network well. It completes forgetting the settings and thinks the network is a WPA one. You have to set up the WPA2 network ever time you want to connect. This is non-starter for my wife. So, it appears everyone has a problem with WPA2.

I have noticed a lot of people complaining about Network Manager and they usually move to using wicd, since it solves their problems (that's how I heard of wicd).

[tempestuous]

Turns out there is also overlap between orinoco_nortel and hostap_plx, orinoco_plx and hostap_plx, orinoco_pci and hostap_pci, and orinoco_tmd and hostap_plx! Tempestuous, where art thou?
It seems the hostap drivers have been updated more recently, so maybe they are the better ones?

I have a new job, so I only have enough time to quickly scan the forum these days.
Yes, that overlap is because the Intersil Prism2 chipset is quite similar to the earlier Orinoco chipset. So some (not all) Orinoco-based devices will work with the hostap family of drivers. Certainly the hostap drivers are more advanced, but I can't say for sure whether they work better. If the answer is yes, then we need to ask Barry to change the PREFLIST line in /etc/rc.d/MODULESCONFIG as such:

Code: Select all

PREFLIST=' rt2500usb:rt73usb orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci '

Also, they support WPA in the wizard.

Yes, the hostap drivers support WPA encryption, but not all Prism2 and Orinoco devices are capable of WPA. I understand that only the most recent Prism2 (or maybe Prism3) devices support WPA, and only when they are flashed with the latest firmware.

Is it necessary to do eject/insert, rather than just restart?

Yes, that's possible. I know for sure that

Code: Select all

pccardctl eject
pccardctl insert

works because I tested it. But I don't have access to a laptop at the moment.

[urban soul]

I have a Prism 2.5 chipset, flashed to version 1.7.4 (if I remember well) and I can report the following:
- I prefer ejecting the card physically when switching Orinoco/hostAP drivers because sometimes computer hangs with cardctl script. (My cardctl script comes from an auditor cd)
- both drivers do not perform well here when connecting; I use ralink or hermes I for that.
- WPA not supported here

I havent tested latest firmware or Prism 3.x chipsets though.

[Aitch]

Hi guys

Is a pup/pet of Etherape possible?

http://www.murga-linux.com/puppy/viewto ... 1d06ce9056

http://etherape.sourceforge.net/

Thanks,

Aitch

[JustGreg]

I got burned with my testing. I set the wifi router to a "hidden" (non-broadcast) SSID. All of my scripts that tested fine with Puppy 4.1 apha 7 stopped working. I spent a day trying to get them to work and became fustrated.

I decided to work on Ubuntu 8.04 for something different. Previously, Ubuntu worked (a bit strangely) with my wifi network. But, Ubuntu would not connect and got the same errors, wpa_supplicant would hang either scanning or associating. An idea poped into my head, I tried Puppy 4.01 and it worked fine. All three operating systems uses the same version of wpa_supplicant. The only difference is the kernel module for the RT73 wireless device. Puppy 4.01 uses the older rt73 module, while, Puppy 4.1 alpha 7 and Ubuntu use the new RT73usb module.

I checked my notes and found I only re-initialized the router when changing the test conditions. I made the assumption that stopping and re-starting wpa_supplicant would re-initialize the kernel module for the device. It does not.

I re-did the test. I found going from an open SSID broadcast to hidden
SSID broadcast and only re-initializing the router everything work fine as previously. However, if I re-initialized both the desktop computer and wifi router then the scripts in Puppy 4.1 alpha 7 would not work.

However, when using Puppy 4.01 (rt73 kernel module), all the scripts worked with either an open or hidden SSID broadcast. Re-initializing the router or the desktop computer had no effect. Everything worked.

I think this points to the rt73usb kernel module as part of the problem with WPA networks and hidden SSID broadcasts. Hopefully, Tempestuous can provide some guidance on this one.

[tempestuous]

Well I don't have firm answers, just suggestions.
It seems that generally the new rt73usb doesn't like hidden SSID's.
I think it's time to upgrade wpa_supplicant. The latest stable version now attached.
This package contains only the application files, and does not overwrite any configuration scripts.
I have enabled the "ipw" -D parameter for compatibility with the new Realtek rtl8180 and rtl8187 drivers. Of course, 99% of modern Linux wifi drivers use the standard "wext" -D parameter.

DON'T use this version of wpa_supplicant in versions of Puppy older than about 4.1alpha5, because this new versions lacks the "Ralink" -D parameter necessary for the old rt61 and rt73 drivers.

[Dougal]

I've just updated the attachment to the parent post.

I have added detection of firewire ports and have improved the static IP dialog and handling.

[Béèm]

In fact I am on a 10+ days leave, but did have quickly looked at the new wizard.
I still have the 192.168.1.1 in the gateway and dns 1.
dns 2 stays now at 0.0.0.0

I'll check in more detail later when back.

[JustGreg]

Thank you, tempestuous. The new version (0.5.10) of wpa_supplicant allowed me to connect. I did find that to connect to a hidden SSID, one had to set scan_ssid=1 in the network section of the wpa_supplicant configuration file. Both the test script and my normal connection script work now even after rebooting both the router and computer. Puppy 4.1 (if it uses the new wext device modules) should contain wpa_supplicant version 0.5.10. If one has to use the older legacy drivers, then wpa_supplicant 0.5.8 is available as pet from puppy 4.01.

Lastly, to those reading this and thinking I should try the hidden SSID broadcast on my system. Hidden SSID broadcast is not worth the trouble and it does not provide any more security. Rarsa (forum name) provide a post explaining it under topic #=30484. If you want a secure wireless network, then use wpa2 with a very good random pass phase. See Rarsa post for more details.

I am posting this using my wireless network with a hidden SSID broadcast. The time difference between an open and hidden SSID connection was not significant.

For an open broadcast SSID, I found that the defaults (no scan parameters set) in wpa_supplicant configuration file worked fine.

I hope this helps.

[PaulBx1]

Pupscan tells me I have a "broadcom bcm4310 USB controller". Anyway I think this is the wireless card. I thought windows told me it was a 4311 chipset, and also tells me I have the "Dell Wireless 1395 WLAN Mini-card". The sticker on the bottom says "Broadcom BCM94312MCG". Maybe I should open up the machine and see what the silkscreen on the card says.

Way back on page 6 tempestuous wrote:

The bcm43xx module is deprecated in k2.6.25.
You should use b43 or b43legacy.

This is more a kernel issue than a Network Wizard issue.

I have tried all 3; none of them recognize my wireless card.

I googled around and found some interesting comments:

I have also learned that although Dell does offer this laptop [Dell Inspiron 1525, same as mine] with Ubuntu installed, they changed the wireless card on the ubuntu version.

Some there say b43 works if a new copy of "broadcom-wl" is loaded (new firmware, I think). That guy said this:

b43 supported cards

* bcm4303 (802.11b-only chips)
* bcm4306
* bcm4309 (only the 2.4GHz part)
* bcm4311 rev 1 / bcm4312
* bcm4311 rev 2 / bcm4312 (needs patches for 2.6.24)
* bcm4318

Others had better luck with ndiswrapper. Here is the url:
http://bbs.archlinux.org/viewtopic.php?id=49781

Another guy on another forum said this:

Re: dv2020, broadcom 4311 problems
Fixed! I got it working by compiling the latest wireless-2.6 kernel (domesday branch), patching for PCI-E support, manually patching bcm43xx to recognize 4311, and installing the correct firmware (wl_apsta.o). No problem!

(who said linux wasn't user friendly?? )

More information here:
http://bcm43xx.spugna.org/index.php?topic=137.0

The url is this:
http://ubuntuforums.org/showthread.php?t=250083

My wife got me this nice new computer. I sure would like to see Puppy 4.1 work on it. Otherwise I am stuck, AGAIN, back at Puppy 2.16.1. Guess it's time to start fiddling with ndiswrapper.

[PaulBx1]

Well, I tried ndiswrapper in the network wizard, and it didn't work either. Couldn't detect a wireless card, just like everything else I tried.

[tempestuous]

Pupscan tells me I have a "broadcom bcm4310 USB controller".

USB versions of the Broadcom wifi chipset are not supported by the bcm43xx/b43/b43legacy modules.

In the Puppy4.1alphas there is a new driver called "rndis_wlan" which supports Broadcom USB devices, but apparently only the model 4320.

Bottom line: your only option is ndiswrapper.

[PaulBx1]

ndiswrapper didn't work. I guess my only options now are to try to find another minicard or get a usb dongle.

[tempestuous]

Success may depend on the particular version of Windows driver you use.
See the "Dell Wireless 1395 WLAN MiniCard" listing here
http://ndiswrapper.sourceforge.net/joom ... ,list_c-f/