Improved Network Wizard (and rc.network)

Under development: PCMCIA, wireless, etc.
Message
Author
JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#161 Post by 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.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

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

#162 Post by 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.
Attachments
wpa_supplicant-0.5.10.pet
for Puppy4.1a5 onwards
(134.37 KiB) Downloaded 540 times
Last edited by tempestuous on Mon 08 Sep 2008, 13:03, edited 1 time in total.

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

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

User avatar
Béèm
Posts: 11763
Joined: Wed 22 Nov 2006, 00:47
Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win

#164 Post by 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.
Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
[url=http://puppylinux.org/wikka/HomePage]Consult Wikka[/url]
Use peppyy's [url=http://wellminded.com/puppy/pupsearch.html]puppysearch[/url]

JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#165 Post by 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.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#166 Post by 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. :roll:

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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#167 Post by 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
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#168 Post by tempestuous »

PaulBx1 wrote: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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#169 Post by PaulBx1 »

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

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

#170 Post by 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/

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#171 Post by Dougal »

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

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

#172 Post by tempestuous »

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

Code: Select all

readlink /sys/class/net/$INTERFACE/device/driver
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

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#173 Post by Dougal »

tempestuous wrote:It seems that when the Network Wizard queries the driver with

Code: Select all

readlink /sys/class/net/$INTERFACE/device/driver
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
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.
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

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#174 Post by HairyWill »

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.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

Minnesota
Posts: 326
Joined: Thu 11 Sep 2008, 11:25

ZD1211RW USB dongle (Airlink etc...)

#175 Post by Minnesota »

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.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#176 Post by PaulBx1 »

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.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#177 Post by BarryK »

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.
The Wizard might have to be upgraded to show these modules properly. /etc/networkmodules in 4.1beta has these entries:

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]

User avatar
dogone
Posts: 202
Joined: Tue 22 Apr 2008, 02:53
Location: Arizona, USA

4.1 beta 1 not retaining static IP and gateway addresses

#178 Post by dogone »

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.
Attachments
dogone_408_hardinfo_report.html.gz
(4.45 KiB) Downloaded 293 times
Last edited by dogone on Sat 13 Sep 2008, 14:47, edited 2 times in total.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#179 Post by PaulBx1 »

Yes dogone, I've noticed that too.

The ssb is apparently an internal Broadcom bus:
http://lists.freedesktop.org/archives/h ... 08080.html

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#180 Post by Dougal »

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.
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.
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.
The WEP fields should only be visible if you press the "WEP" button or if you load a profile that uses WEP.
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

Post Reply