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...

Quote:

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:

(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.)

Quote:

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.)_________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

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...).

Quote:

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.

Quote:

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:

Quote:

# 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))._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

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)._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

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

Quote:

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

Quote:

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._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

(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.

Quote:

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.

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...

Quote:

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)._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

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:

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.

Dougal wrote:

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

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

Code:

pccardctl eject
pccardctl insert

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

Joined: 05 Mar 2008Posts: 276Location: "Killing a nerd is not as much fun as ist sounds" B.Simpson

Posted: Mon 01 Sep 2008, 19:49 Post subject:

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 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._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

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.

I have added detection of firewire ports and have improved the static IP dialog and handling._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Posted: Fri 05 Sep 2008, 20:30 Post subject:
Subject description: I got the a hidden SSID to work after reboot of both router and computer

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._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum