Improved Network Wizard (and rc.network)

[gyro]

Is your eth0 configured statically, or with dhcpcd?

Both use dhcpcd. But I never actually use both at once.
On my desk I plug in an ethernet cable(eth0), wireless device disabled. In other room I enable wireless device, and use wifi(ath0), but no ethernet cable plugged in. That's when I had the problem because I then have 2 configured devices.

That's a great discovery! (Do you know why it flushes all devices?)

No, looks like it's part of busybox. But I now have some code that does the right thing.

What I did to get past that is move the cleanUpInterface instances (run before trying to configure each interface) to the beginning, so after you've started configuring them you won't cause any damage -- maybe I just missed some places where it is run if configuring fails...

When an interface is configured but not plugged in. In "rc.network" just after:

Code: Select all

    echo "interface $INTERFACE does not seem to be plugged in... skipping"

My patch to the file "/usr/bin/wag-profiles.sh", probably useful for any puppy 4.1 with multiple configured network devices:
In "cleanUpInterface()", replace

Code: Select all

	ip route flush dev "$1"

with

Code: Select all

# gyro - begin - really delete only routes for interface
#	ip route flush dev "$1"
	if [ "$1" ] ; then
		for XNET in $(iproute | grep "$1" | cut -f 1 -d " ") ; do
			route del -net "$XNET" 
		done
	fi
# gyro - end - really delete only routes for interface

Alan

[Dougal]

My patch to the file "/usr/bin/wag-profiles.sh", probably useful for any puppy 4.1 with multiple configured network devices:
In "cleanUpInterface()", replace

Code: Select all

	ip route flush dev "$1"

with

Code: Select all

# gyro - begin - really delete only routes for interface
#	ip route flush dev "$1"
	if [ "$1" ] ; then
		for XNET in $(iproute | grep "$1" | cut -f 1 -d " ") ; do
			route del -net "$XNET" 
		done
	fi
# gyro - end - really delete only routes for interface

Yes, hat's a good solution, though I feel like getting Barry to put in the "proper" version of ip will be much nicer...
The way I did it in the latest version, that line is commented out and cleaning the routing table is done only when rc.network is started (either at boot time or when you right-click the "Connect" icon).
Flushing the routing table is something that I only added a month or two ago, so I guess people can live without it some more, if they were ok without it until now...

[HairyWill]

I feel like getting Barry to put in the "proper" version of ip will be much nicer...

This would get my vote too.
pptpconfig also uses "ip route" functionality and busybox's implementation is not good enough. Considering that busybox is probably used in a number of embedded network devices I find this surprising.

[h4yn0nnym0u5e]

Hi there

Hope this is the right place to post this - looks reasonable to me, but...

Trying to set up my Acer Aspire One for wireless, and I believe I've run into a wizard bug. The driver's installed OK, and I can connect at work all right. I can also connect at home, but only if I change from my default passphrase. If I use my normal one, the wizard corrupts it - it looks as if my using a dollar sign ($) in the passphrase causes problems. It may not solely be a wizard problem, as editing the right passphrase into the .conf file doesn't help.

Am I right, or am I being dim?!

Cheers

Jonathan

Edit: using wpa_passphrase to translate my ASCII passphrase into the corresponding hex works - I can put the hex in the wizard and establish a connection...

[Dougal]

I can also connect at home, but only if I change from my default passphrase. If I use my normal one, the wizard corrupts it - it looks as if my using a dollar sign ($) in the passphrase causes problems. It may not solely be a wizard problem, as editing the right passphrase into the .conf file doesn't help.

I think the wizard probably does have a problem with it, though, as you mention, if editing the .conf file manually doesn't help, it might be that wpa_supplicant also has a problem with it.

The problem is that the shell interprets the $ as a variable expansion... so the $ and everything after it will be replaced with nothing.
This can easily be solved by "escaping" it (putting a backslash before it), so I'll just add that to the wizard (I've already added escaping of single- and double-quotes).

[Dougal]

Code: Select all

# gyro - begin - really delete only routes for interface
#	ip route flush dev "$1"
	if [ "$1" ] ; then
		for XNET in $(iproute | grep "$1" | cut -f 1 -d " ") ; do
			route del -net "$XNET" 
		done
	fi
# gyro - end - really delete only routes for interface

I've tried it and there's a problem with it:
I configured two interfaces with static IP, which resulted in the routing table containing two "default" networks -- one for each interface.
So if you chose to flush the first interface, the first entry will be deleted properly, but trying to delete "default" actually results in deleting the "default" for the second interface...

[Dougal]

Dougal, I was just going to write that the eth2 FireWire device was detected and working on each boot. That was so for the las 7 days or until today.
No eth2 device anymore and the eth1394 module wasn't loaded.

I loaded by hand run the NW Wizard and got the FireWire device back.

I keep forgetting to reply to this...

This is a udev issue -- rc.network only handles existing interfaces, the modules for which are loaded by udev.
You could force loading eth1394 by adding it with the bootmanager, but the best way is probably to find out why it isn't loaded automatically...

[Dougal]

If I use my normal one, the wizard corrupts it - it looks as if my using a dollar sign ($) in the passphrase causes problems.

Ok, I think I've managed to fix the problem with the $ in the key (also " and `):
It was getting lost already when the output from gtkdialog was read:

Code: Select all

eval PROFILE_KEY="bla$BLA"

already turns into PROFILE_KEY="bla"...
Then, when that is fixed, we write the (AP) profile and

Code: Select all

KEY="$PROFILE_KEY"

does the same thing when we read it...

Hopefully it will be ok now.

Note one thing I'm not sure of:
In the wpa_supplicant config files, the key is included just for reference (it is commented out: a line with #psk=).
You can actually run wpa_supplicant with the key, by uncommenting that line and commenting
out the one after it (with the hex key).
What I'm not sure is whether the chars should be escaped there, too, for wpa_supplicant.
I.e, maybe

Code: Select all

#psk="bla$BLA"

should be changed to

Code: Select all

#psk="bla\$BLA"

(or, more importantly, double quotes (") might need escaping, to differentiate them from the
ones enclosing the psk...).

[NicolasHoTaylor]

I've just done a frugal install of Puppy 4.1.1 on an old Thinkpad 1200 with a D-Link wireless G card (RaLink RT61 chipset, rt61pci driver). Files saved in /sda1/puppy411.

The Wizard scans for my network successfully, then after I supply the passphrase, it fails to connect. Looks like the passphrase is getting lost. The error dialogue reads 'Failed to connect to wpa_supplicant - wpa_ctrl_open : No such file or directory'.

Similar problem with the 'old' network wizard (which is very old), but no error message.

Still works OK booting from the version in /sda1/puppy410. That's what I'm using right now...

This post is a copy of one in this thread: http://murga-linux.com/puppy/viewtopic.php?t=35153
- which should probably be closed off, if prehistoric is OK with that.

[Béèm]

Nicolas
In your 410 issue in a console lsmod | grep wpa and make a note which modules are loaded

Then do the same in the 411 and see if they match.

[NicolasHoTaylor]

Thanks Béèm. My mistake - I neglected to check the MD5. The file size was only 4 bytes different from version 4.1... so I thought it was OK. Not so!

The ibiblio servers seem to be rather busy, lots of dropouts. Everyone and his brother wants the new Puppy...

[Béèm]

Thanks Béèm. My mistake - I neglected to check the MD5. The file size was only 4 bytes different from version 4.1... so I thought it was OK. Not so!

OK you sorted it out. Fine
Success with Puppy

[gyro]

I configured two interfaces with static IP, which resulted in the routing table containing two "default" networks -- one for each interface.
So if you chose to flush the first interface, the first entry will be deleted properly, but trying to delete "default" actually results in deleting the "default" for the second interface...

Sorry Dougal, but I have to disagree with your assessment.
There are no "default networks", only a single "default route" which contains a gateway that resolves to an IP address on one of the previously defined networks. This "default route" is used by the IP stack to determine where to send packets whose destination address does not match any of the other routes defined in the routing table.
So, no matter how many interfaces are defined, either static or dhcp, only 1 default route should be configured.

Alan

[PaulBx1]

A lot of extraneous resolv.conf files are accumulating in /etc. They all say the same thing. I suspect the network wizard is needing an extra line of cleanup code?

[edea]

Where is the pet package? Thanks

[Dougal]

Sorry Dougal, but I have to disagree with your assessment.
There are no "default networks", only a single "default route" which contains a gateway that resolves to an IP address on one of the previously defined networks. This "default route" is used by the IP stack to determine where to send packets whose destination address does not match any of the other routes defined in the routing table.
So, no matter how many interfaces are defined, either static or dhcp, only 1 default route should be configured.

Ah, but, alas, that doesn't seem to be how the wizard does it...
The wizard always uses "default", so what happened was that iproute showed two "default" entries: one for each interface.
So when you grep for the interface and then cut only the first field, you end up with the two items: the IP/something that you want, plus "default"... and when you choose to remove "default", it removes the last one added, which could mess things up for you...
Just telling it the way it happens with the wizard... (remember that the wizard was originally designed to only support one interface at a time -- I modified it to work with more than one but mentioned I'm not sure about the route commands.)

[Dougal]

A lot of extraneous resolv.conf files are accumulating in /etc. They all say the same thing. I suspect the network wizard is needing an extra line of cleanup code?

You are using a static IP, right? Before overwriting it, the wizard always saves the old copy... I guess I'll add something to clean up old saved copies.

[Dougal]

Where is the pet package? Thanks

There's a tarball on the first post. You can run tgz2pet on it.

[valpy]

@Dougal

Although I still haven't managed to get the new network wizard to make a connection to a WPA network using ndiswrapper (WG111V2 usb) in Puppy 4.1 (2.6.25 kernel) (- earlier post of 12Oct08), I have made some progress using the native driver rtl8187.

At first I found that if I used the new network wizard to set up the required profiles, the rtl8187 didn't work - it went through the sequence "SCANNING - ASSOCIATING - DISCONNECTED - SCANNING ..... etc" that many people have reported.

However, I noticed from 'top' that wpa_supplicant had been launched with the D parameter "ipw".

If I manually change the WPA config file for my card in the /etc/network-wizard/wireless/profiles directory (something like 00:55:BC:94:E0:A0.WPA.conf) so that the WPA_DRV="ipw" line becomes WPA_DRV="wext", then it works.

(I need to load the profile for the network, click on "use this profile" and confirm I want to use it for the next boot ...... but it's rock solid and the network connection is established every time I reboot).

Top confirms I am running wpa_supplicant with "wext".

Same workaround succeeds for Puppy 4.1.1 with rtl8187.

If I'm reading it correctly, /usr/sbin/wag_profiles.sh associates rtl8187 with the "ipw" parameter - if other people confirm that wext works for WPA, perhaps this should be "wext" instead, so that the wizard will set up the config file accordingly?

Thanks for all your efforts!

valpy

link to recent related post: http://www.murga-linux.com/puppy/viewto ... 251#246251

[PaulBx1]

You are using a static IP, right?

Yes, that's right. Saving 3 or 4 might be all right, but I've got a pile of them by now.

Or, you might compare the new one with the last used one, and if the contents are the same, just delete the last used one. I can see the value of saving files with different info in them, but if they are all the same it may be less useful.