Improved Network Wizard (and rc.network)
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.
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
Live Well, Laugh Often, Love Much
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
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.
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.
- Attachments
-
- wpa_supplicant-0.5.10.pet
- for Puppy4.1a5 onwards
- (134.37 KiB) Downloaded 544 times
Last edited by tempestuous on Mon 08 Sep 2008, 13:03, edited 1 time in total.
- Béèm
- Posts: 11763
- Joined: Wed 22 Nov 2006, 00:47
- Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win
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.
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.
Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
Consult Wikka
Use peppyy's puppysearch
Find packages in a snap and install using Puppy Package Manager (Menu).
Consult Wikka
Use peppyy's puppysearch
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.
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
Live Well, Laugh Often, Love Much
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:
I googled around and found some interesting comments:
http://bbs.archlinux.org/viewtopic.php?id=49781
Another guy on another forum said 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.
Way back on page 6 tempestuous wrote:
I have tried all 3; none of them recognize my wireless card.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 googled around and found some interesting comments:
Some there say b43 works if a new copy of "broadcom-wl" is loaded (new firmware, I think). That guy said this: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.
Others had better luck with ndiswrapper. Here is the url: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
http://bbs.archlinux.org/viewtopic.php?id=49781
Another guy on another forum said this:
The url is 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
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.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
USB versions of the Broadcom wifi chipset are not supported by the bcm43xx/b43/b43legacy modules.PaulBx1 wrote:Pupscan tells me I have a "broadcom bcm4310 USB controller".
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.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
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/
See the "Dell Wireless 1395 WLAN MiniCard" listing here
http://ndiswrapper.sourceforge.net/joom ... ,list_c-f/
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
Note that he patched the driver to support his device... it probably means he just added his device/vendor IDs to the array of matching devices in the driver, but it's still something that needs to be done before compiling it.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!
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Dougal, paulh177 has reported a problem with WPA here -
http://www.murga-linux.com/puppy/viewto ... 067#231067
It seems that when the Network Wizard queries the driver with
the new ath5k driver reports itself as "ath5k_pci"! I just read that "ath5k_pci" is the naming convention used in early development versions of this driver, so this might actually be a bug.
Anyway, an easy fix would be just to add "ath5k_pci" to the "wext" line in /usr/sbin/wag-profiles.sh
http://www.murga-linux.com/puppy/viewto ... 067#231067
It seems that when the Network Wizard queries the driver with
Code: Select all
readlink /sys/class/net/$INTERFACE/device/driver
Anyway, an easy fix would be just to add "ath5k_pci" to the "wext" line in /usr/sbin/wag-profiles.sh
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
I think I know why that happens: if you look at the kernel code, some drivers (like ath5k) which support more that one port type will be built of a module with the general functions and a separate modules for the port-specific functions. For example: ath5k_pci.o ath5k_usb.o etc.tempestuous wrote:It seems that when the Network Wizard queries the driver withthe new ath5k driver reports itself as "ath5k_pci"! I just read that "ath5k_pci" is the naming convention used in early development versions of this driver, so this might actually be a bug.Code: Select all
readlink /sys/class/net/$INTERFACE/device/driver
Anyway, an easy fix would be just to add "ath5k_pci" to the "wext" line in /usr/sbin/wag-profiles.sh
So I guess the kernel reports in /sys what it actually uses... ath5k_pci in this case.
I'll just change it to "ath5k*" in wag-profiles.sh.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
Dougal
I've just tried out puppy 4.1b1. and have a couple of minor issues.
On the plus side it identified my firewire interface (I don't have the hardware to test if it works)
1)It took several scans for it to find my AP, having to hit OK or Cancel on the screen to choose an AP and then having to rehit the scan button is not ideal. I don't know how simple it would be to include a Rescan button alongside the OK and Cancel.
2)I'm sure at one point you had an version of the wizard that automatically loaded the WEP key entry box, it no longer does so for me, I have to hit the WEP button. I don't know if this is behaving as intended.
I've just tried out puppy 4.1b1. and have a couple of minor issues.
On the plus side it identified my firewire interface (I don't have the hardware to test if it works)
1)It took several scans for it to find my AP, having to hit OK or Cancel on the screen to choose an AP and then having to rehit the scan button is not ideal. I don't know how simple it would be to include a Rescan button alongside the OK and Cancel.
2)I'm sure at one point you had an version of the wizard that automatically loaded the WEP key entry box, it no longer does so for me, I have to hit the WEP button. I don't know if this is behaving as intended.
ZD1211RW USB dongle (Airlink etc...)
Asked to move my comments over to this thread, so hear goes...been waiting to see if anyone else posted about USB dongle.....and driver .zd1211rw.
First of all it works fine in 2.17.... since then I have had intermittent problems with the versions..
On occasion a wizard will work, sometime I have to use Pwireless to get things to see wireless networks, the nodes.. I revert back to 2.17, the wizard sees the wireless lan and networks....so I have something to compare with.
In latest version, today's latest... 4.1 Beta: puppy-4.1retro-beta-408-k2.6.21.7-seamonkey.iso
The wizard does not even see the LAN connection.
I can unload the module, and reload... as the hardware has been detected...by the initial load of Puppy from the CD. The system sees the hard wired PCI lan... but not the wireless. (processes shows zd1211rw running, as well as USB shows the hardware)
I have run this on two system.. with two dongles.. both work with 2.17. 2.17 runs fine from the CD or usb stick.
Lots of computer experience but not with Linux.. in the learning mode...
1) Is there any way I can force the wizard to see the hardware in this new version????
2) Any way in previous previous versions to help the wizard see the nodes....connections?
As mentioned I am running directly from the CD ISO...
Thank you.
First of all it works fine in 2.17.... since then I have had intermittent problems with the versions..
On occasion a wizard will work, sometime I have to use Pwireless to get things to see wireless networks, the nodes.. I revert back to 2.17, the wizard sees the wireless lan and networks....so I have something to compare with.
In latest version, today's latest... 4.1 Beta: puppy-4.1retro-beta-408-k2.6.21.7-seamonkey.iso
The wizard does not even see the LAN connection.
I can unload the module, and reload... as the hardware has been detected...by the initial load of Puppy from the CD. The system sees the hard wired PCI lan... but not the wireless. (processes shows zd1211rw running, as well as USB shows the hardware)
I have run this on two system.. with two dongles.. both work with 2.17. 2.17 runs fine from the CD or usb stick.
Lots of computer experience but not with Linux.. in the learning mode...
1) Is there any way I can force the wizard to see the hardware in this new version????
2) Any way in previous previous versions to help the wizard see the nodes....connections?
As mentioned I am running directly from the CD ISO...
Thank you.
I have reported a strange network wizard problem in the 4.1b1 thread. It thinks my Ricoh xD Picture card is an ethernet card. I believe it is actually not a network wizard problem, but something to do with differences in how the lspci command works, but I told Barry I'd report the problem here nonetheless. BTW, is the wizard different between 4.1a7 and 4.1b1? It didn't do this in a7...
On a separate issue, wasn't b43legacy supposed to be one of the modules available to load? I think it is in there as (at least in a7) you could load it via the boot manager, but the network wizard still does not show it.
Another interesting point. /etc/networkmodules in a7 shows a b43 module. In b1 it shows a b44 module, but no b43. I don't know how this file works so I have no idea if this is significant at all; I'm sure someone here can tell if it is.
On a separate issue, wasn't b43legacy supposed to be one of the modules available to load? I think it is in there as (at least in a7) you could load it via the boot manager, but the network wizard still does not show it.
Another interesting point. /etc/networkmodules in a7 shows a b43 module. In b1 it shows a b44 module, but no b43. I don't know how this file works so I have no idea if this is significant at all; I'm sure someone here can tell if it is.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
The Wizard might have to be upgraded to show these modules properly. /etc/networkmodules in 4.1beta has these entries:PaulBx1 wrote:I have reported a strange network wizard problem in the 4.1b1 thread. It thinks my Ricoh xD Picture card is an ethernet card. I believe it is actually not a network wizard problem, but something to do with differences in how the lspci command works, but I told Barry I'd report the problem here nonetheless. BTW, is the wizard different between 4.1a7 and 4.1b1? It didn't do this in a7...
On a separate issue, wasn't b43legacy supposed to be one of the modules available to load? I think it is in there as (at least in a7) you could load it via the boot manager, but the network wizard still does not show it.
Another interesting point. /etc/networkmodules in a7 shows a b43 module. In b1 it shows a b44 module, but no b43. I don't know how this file works so I have no idea if this is significant at all; I'm sure someone here can tell if it is.
b43legacy "ssb: Broadcom B43legacy wireless driver"
b43 "pcmcia: Broadcom B43 wireless driver"
b44 "ssb: Broadcom 44xx/47xx 10/100 PCI ethernet driver"
bcm43xx "pci: Broadcom BCM43xx wireless driver"
That 'ssb:' is new, that's what is in the "alias" entries when modinfo is run.
I guess, 'ssb' is an new interface bus. ...I did know what the letters stand for awhile back ...I think the 'b' is for 'bus'.
Anyway, the Wizard needs to recognise 'ssb' as a valid bus, just like 'pcmcia', 'pci' and 'usb'.
[url]https://bkhome.org/news/[/url]
4.1 beta 1 not retaining static IP and gateway addresses
4.1 beta 1 is unchanged from alpha7 (407) in that it forgets the manually entered static IP and gateway addresses after a boot or power cycle. The manually entered DNS address is not forgotten. This problem has been reported by others using post-406 Puppies and may be unique to the use of static addressing. See attached hardware report.
UPDATES:
1. Despite write-protecting the correctly configured /etc/network-wizard/network/interfaces/[mac address] file, the Set Static IP dialog came up with both IP and gateway addresses reset to zeros.
Contents of the file when this occurred:
STATIC_IP='yes'
IP_ADDRESS='192.168.1.200'
NETMASK='255.255.255.0'
DNS_SERVER1='209.193.72.2'
DNS_SERVER2='209.193.72.2'
GATEWAY='192.168.1.1'
IS_WIRELESS=''
2. The module for my NIC (8139too) loads at boot but eth0 is not recognized until Net Wizard is run.
UPDATES:
1. Despite write-protecting the correctly configured /etc/network-wizard/network/interfaces/[mac address] file, the Set Static IP dialog came up with both IP and gateway addresses reset to zeros.
Contents of the file when this occurred:
STATIC_IP='yes'
IP_ADDRESS='192.168.1.200'
NETMASK='255.255.255.0'
DNS_SERVER1='209.193.72.2'
DNS_SERVER2='209.193.72.2'
GATEWAY='192.168.1.1'
IS_WIRELESS=''
2. The module for my NIC (8139too) loads at boot but eth0 is not recognized until Net Wizard is run.
- Attachments
-
- dogone_408_hardinfo_report.html.gz
- (4.45 KiB) Downloaded 299 times
Last edited by dogone on Sat 13 Sep 2008, 14:47, edited 2 times in total.
Yes dogone, I've noticed that too.
The ssb is apparently an internal Broadcom bus:
http://lists.freedesktop.org/archives/h ... 08080.html
The ssb is apparently an internal Broadcom bus:
http://lists.freedesktop.org/archives/h ... 08080.html
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
Ok, I have implemented that. I also went one step further and, right after the scan is run, check if anything was found and, if not, it waits a second and runs the scan again automatically.HairyWill wrote:1)It took several scans for it to find my AP, having to hit OK or Cancel on the screen to choose an AP and then having to rehit the scan button is not ideal. I don't know how simple it would be to include a Rescan button alongside the OK and Cancel.
The WEP fields should only be visible if you press the "WEP" button or if you load a profile that uses WEP.2)I'm sure at one point you had an version of the wizard that automatically loaded the WEP key entry box, it no longer does so for me, I have to hit the WEP button. I don't know if this is behaving as intended.
I could make the correct fields automatically made visible for all types of encryption, by using what the scan dialog reports to you, but it has been reported that it's unreliable -- iwlist scan returns WPA2 sometimes when it's actually WPA1, so I need to completely disable that feature
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind