Improved Network Wizard (and rc.network)

[MU]

package removed, newer version available.

[BarryK]

MU, Dougal,
MU, I have just seen your patch, haven't looked closely at it. Dougal, do you agree that I should update the Network Wizard with this patch?

I'm planning to build 4.1 final in about 12 hours from now, then several hours intensive testing on my PCs, then if all looks ok will release it.

So, if you would like the Network Wizard to have any mods from the Oct 1st version, kindly let me know within the next 10 - 12 hours (I'll check this thread).

[Dougal]

I had to add this modification:

Code: Select all

testInterface()
{
	#INTERFACE="$1"

#MU
ifconfig "$INTERFACE" | grep ' UP ' 
if [ $? -eq 0 ];then #=0 if found
	echo "yes"
	return 0
fi
#MU-end

The reason is, that the code afterwards, does not detect a network.
It uses:

Code: Select all

ifplugstatus "$INTERFACE" | grep -F -q 'link beat detected'

Here is what I get from console, though the network is up, and I am browsing the web:

# ifplugstatus wlan0
wlan0: unplugged

Well, the problem is that ifconfig showing "UP" doesn't mean much... any interface that you run "ifconfig $INTERFACE up" on will show it, so if, for example, I relied on that, rc.network would assume my unplugged ethernet interface is in fact plugged in and go on to start dhcpcd...
That ifplugstatus code is something Barry and Rarsa worked out (note that it uses two versions of ifplugstatus) to try and make sure live networks are detected...

There is another way to try and see if it's plugged: ethtool and (with some HW) mii-tool can be used, but you'll have to try them out and see if they work for you.

[Dougal]

MU, I have just seen your patch, haven't looked closely at it. Dougal, do you agree that I should update the Network Wizard with this patch?

No, as I mention above, your ifplugstatus routine is a must...

I'm planning to build 4.1 final in about 12 hours from now, then several hours intensive testing on my PCs, then if all looks ok will release it.

I should be able to post a little update within the the next 9-10 hours.

[MU]

it should be tested first by others.
Until now, this seemed to be an issue only with the mentioned Fritz Stick.

My Linksys-Stick works as expected without patch.
Rt73 is also detected by ifplugstatus.
current rt73 discussion:
http://www.murga-linux.com/puppy/viewtopic.php?t=34078

I remember there were several reports in the past, that sticks did not connect at startup.
But I think, the latest fixes from dougal could solve that.

Mark

[MU]

ok, the damn Fritz Stick is unusable in Muppy with the new Kernel:
http://www.murga-linux.com/puppy/viewto ... 187#237187

However, in Dingo 4.1rc (409), it still worked, so I could run some tests.

ethtool wlan0

Code: Select all

Settings for wlan0:
No data available

mii-tool wlan0

Code: Select all

SIOCGMIIPHY on 'wlan0' failed: Operation not supported

These were run, while the connection was established:
route

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 wlan0
169.254.0.0     *               255.255.0.0     U     0      0        0 wlan0
default         192.168.0.1     0.0.0.0         UG    0      0        0 wlan0

So I found no solution, to check, if the network is up.
"route" just works, when already a IP was assiged with dhcpcd.

Anyway, as this stick is "tainted" (unfree, requires to set the license from "Propriatary" to "GPL" in the source, a "bad hack"), we should not focus on this stick.
Even if it is wide-spread in germany.
But the long-term support is not guaranteed, as the manufacturer AVM was given a year time to contribute to the new kernel architecture.
OpenSuse meanwhile even removed it completely.

So forget about my patch, if someone really relies on this stick (because he has it already), then he must patch on his own.

Mark

[Dougal]

Another update:
- Add PATH to top of rc.network (in case it is run by acpid etc.).
- Fix the testInterface code in rc.network (up the sleep times to 2 seconds,
like in the wizard) and add use of ethtool (if available).
- In the "Load module" dialog, add a "Ndiswrapper" tab, for better visibility.
- When choosing to use Ndiswrapper, first offer to unload the Linux driver
attached to that hardware!
- Rewrite the Ndiswrapper file selector gui in gtkdialog.

Note that BLACKLIST_FILE has to be modified at the top of net-setup.sh in
order for blaklisting to work.

[MU]

package removed, newer version available.

[cornbreadly]

I am having some newb issues with 4.1rc and i was referred to this thread for some help.

I have an Airlink101 AWLC4130 wireless card (Atheros AR5212 chipset) that i am trying to get working. I upgraded to 4.1rc from macpuppy 4.0 because 4.1rc supports the madwifi .94 drivers and puppy 4.0 does not.

I get alot further in this verision of puppy. Before in macpuppy the interface atho was recognized but i couldn't scan and find any networks. Now in 4.1, I can scan and find networks, but i just can't connect. My home is WPA protected and wpa_supplicant is nowhere to be found.

Also, in 4.1rc, the ath0 interface is the only one recognized. eth0 and wlan0 that were present in macpuppy dont show up and I tried autoprobing. Nothing. All cables are connected.

My troubles are explained at length here.

I would appreciate any help.

[cornbreadly]

please ignore double post... sorry

[zgp152]

here are updated pets again
Mark

Do these pets now add 4.1(final) level functionality to Muppy 008.4c ? I have missed MAC address saving into profile, which was not there before.

Timo

[MU]

just try it out, and post your results, please.
I'm not so deep in the internals of the wizard, I just packaged it as pet for easy installation.
Mark

[Dougal]

I am having some newb issues with 4.1rc and i was referred to this thread for some help.

You didn't really provide any useful information in any of your posts...

Also, in 4.1rc, the ath0 interface is the only one recognized. eth0 and wlan0 that were present in macpuppy dont show up and I tried autoprobing. Nothing. All cables are connected.

The interface names mean nothing -- they're generic. You need to look which modules support those two devices and if they're present or not in 4.1rc (you can try "modprobe modulename" to see if they exist).
If they exist and are loaded, yet there are no interfaces, you need to look at the output of dmesg and see if they gave any errors.
I also don't recall you mentioning which version of 4.1 you are using -- "normal" or "retro".

I have an Airlink101 AWLC4130 wireless card (Atheros AR5212 chipset) that i am trying to get working. I upgraded to 4.1rc from macpuppy 4.0 because 4.1rc supports the madwifi .94 drivers and puppy 4.0 does not.

I get alot further in this verision of puppy. Before in macpuppy the interface atho was recognized but i couldn't scan and find any networks. Now in 4.1, I can scan and find networks, but i just can't connect. My home is WPA protected and wpa_supplicant is nowhere to be found.

Have you only tried (and failed) with your WPA network, or also with open networks?
wpa_supplicant is an application that does the work of connecting to the WPA network. You are not supposed to deal with it directly -- it is used if you're trying to connect to a WPA network (there should be a progressbar with some info, so if it fails you know why).
If the problem is only with WPA connection, then it's probably wpa_supplicant, otherwise it's probably more basic.
Again, maybe dmesg gives any info about problems with the driver.

You also mentioned somewhere that if you skip a step and run dhcpcd it runs ok: but do you get a network connection?
I can run dhcpcd on my ethernet interface, which is not connected to anything, and it will run successfully... it does give a message about not being connected, but it goes on to run in the background and I guess waits to be connected.
So the step of checking if it is connected is a must.
So if running dhcpcd actually gives you a network connection, then the problem is at the part of checking if it's connected.

[zgp152]

here are updated pets again
Mark

Do these pets now add 4.1(final) level functionality to Muppy 008.4c ? I have missed MAC address saving into profile, which was not there before.

Timo

I installed in Muppy 008.4c the pet containing the 1st Oct wizard. I am happy to tell that MAC address is now properly saved in the profile and is there when loaded. Fine.

Timo

[Dpup]

I was redirected here about the madwifi update posted on forum Extras for Puppy 4.1. The modified madwifi posted is for ASUS Eee wifi and does not appear to be based on the current network wizard version that is Sep 25th or later which is much faster and fixes problem of reconnect wifi on boot.

If that is true, how can the modified madwifi be made current for ASUS Eee?

Upon installing the Sep 25th version, the reconnect on boot worked consistently and very fast on my tests of Puppy versions 4 and several variants with ACER 3003, HP6833us laptops internal wifi and all desktops using ZyXEL AG225H, and Airlink AWLL3055 USB wifi adapter. The newest 4.1 release also worked consistently with all of the same PC's.

If I install just the Puppy 4.1 which I understand has the Sept 25th or later network wizard modifications on the Eee, and not install the modified madwifi, then use the ZyXEL, or Airlink USB wifi adapter instead, the fast reconnect on boot works fine. This is a temporary work around, but it would be very desirable to use the internal Eee wifi and not carry the external USB wifi adapter.

Also note that Pupeee b4 on the Eee consistently reconnects wifi on boot to WPA, WPA2 TKIP wireless with the Eee internal wifi.

Thanks for any suggestions.

Dpup

[Dougal]

The modified madwifi posted is for ASUS Eee wifi and does not appear to be based on the current network wizard version that is Sep 25th or later which is much faster and fixes problem of reconnect wifi on boot.

If that is true, how can the modified madwifi be made current for ASUS Eee?

It's not really clear to me what you mean.
The madwifi package should only be the driver and files related to it, which should have nothing to do with the wizard, so you can just use it with any version of the wizard you want.

[Dpup]

Dougal:

Thanks for your response.

When your Sep 25 Network Wizard was posted, I tested it with several Puppy 4.0 and related variants in a number of Laptop and desktop PC's and for the first time, the wifi would consistently reconnect on reboot to WPA and WPA2 TKIP wireless routers. This was also true with the new Puppy 4.1.

The problem is how to make the reconnect on reboot work with the ASUS Eee with Puppy 4.1. If I install the modified madwifi for the Eee it works, and connects fine, but does not reconnect when reboot. Also after installing the Eee specific modified madwifi, other USB wireless adapters that did reconnect after reboot, no longer would.

The remarkable thing I see in your Sep 25 Network wizard is how fast it is able to connect or reconnect on boot. Just amazing even with USB flash drive boot and connect to WPA and WPA2 TKIP wireless in a total of under 25 seconds after power on... the Vista boot and wifi connect takes upwards of 8 times longer, and for online activities does no more than I am doing with Puppy...

I would like to be able to have this fast boot and reconnect on the ASUS Eee. The question is how.

Thanks again,

Dpup

[mawebb88]

See my contribution in thread:

http://www.murga-linux.com/puppy/viewtopic.php?t=34184

Mike

[Dpup]

Mike,

Thanks... will give your method a try...

Puppy 4.1 Standard has worked with reconnect on boot on a half dozen other laptops and desktops that did not need a modified madwifi... so I was curious if others experienced same problem.

Dpup

[tempestuous]

... Puppy 4.1 which I understand has the Sept 25th or later network wizard modifications

Puppy 4.1 contains the Oct-5 version of the Network Wizard, confirmed on the Developer Blog
http://puppylinux.com/blog/?viewDetailed=00399

If you still have the Sep-25 Network Wizard as a tar.gz then you could install this in Puppy 4.1 to see if it makes any difference.