Frisbee Network Manager - Beta 2

[rerwin]

Scooby,
I did not read your comment as being critical of Jemimah. I was only defending myself regarding not having caught the "cancel" bug already. I just had never noticed it.

Now, when I fix that bug I can also edit the text about the maximum dropwait time, in some backward-compatible way.

I have followed your recommendations to make the message LOG_INFO and the max 15 seconds. To do that, I add the dropwait maximum time to the timeout wait for the "release" signal, SIGALRM. I expect no harm is done by waiting excessively for non-wireless releases before timing out. If I am wrong, I can add a loop or other logic to shorten the wait time in that case.
EDIT: After sleeping on it, I think I need to re-do the added wait time, to avoid impacting the non-wireless timeout performance. I plan to merely extend the loop count for the current tenth-second tests for release completion.

The updated files are here:
http://www.murga-linux.com/puppy/viewto ... 191#789191
along with a command that should list (in a console) any messages about the carrier being resumed after a brief outage.

[Marv]

Running the updated 6.3.2 spup version in X-slacko 2.1. It's handling the dropouts gracefully as can be done, but just for a snort, here's the record of lost connections from this ipw2200 1.6GHz Pentium M Fujitsu S6230 laptop. Excellent signal strength, ipw2200 v3.1.5 firmware, router independent. Fairly typical of for this class machine. Shows what I thought was happening. A loss of connection almost exactly every 108 seconds

Code: Select all

# grep 'lost' /var/log/messages
Jul 17 16:51:31 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:53:19 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:55:07 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:56:55 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:58:42 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 17:00:30 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 17:02:17 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 17:04:04 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost

[Scooby]

Marv's message got me thinking and looking at code

Am I right in my conclusion that dropwait is only active for wifi and not ethernet?

Is your wireless adapter denoted as "eth0" Marv?

[Marv]

@ Scooby,

Yes, the wireless interface on these laptops is eth0. I'll toggle this one back and forth from 0 to 15 secs and look at it. I know the older ones did work with this interface. Ipw2200 wireless was basically useless on the newer kernels due to the dropouts above with the dropwait time at 0, and usable if a bit irky with the dropwait time at 15. What I really need to do is figure out the why of the regular dropouts It has eluded me for quite a while now.

[rerwin]

Am I right in my conclusion that dropwait is only active for wifi and not ethernet?

Is your wireless adapter denoted as "eth0" Marv?

You are correct. But the test is not for eth? versus wlan?. I don't know how dhcpcd makes the determination, which should not depend on the interface name prefix.

I have continued experimenting with a 5.6.8 version of dhcpcd as well as 6.3.2. Both versions have the new timeout logic, necessitating the extension of the timeout period. I have concluded that, despite the dropwait delay, the kernel detects the loss of carrier and starts a closure process. I suspect that it waits about 10 seconds before "unauthorizing", making longer dropwaits ineffective.

In testing, the repeated 1-second checks for a resumed carrier seem effective. But now I see that the "disable wireless" test still fails to completely kill the interface. If the carrier somehow resumes -- or was slow in being stopped, the carrier loss is ignored and the dhcpcd release logic does not execute. "Back to the drawing board" to sort that out -- again.

Regarding Marv's regular 108-second dropouts, I have seen postings (outside of the puppy forum) about routers doing that. I think the solution was to updates its firmware. But that does not apply to Marv's standalone connection without a router. So, I am clueless about that.

BTW, thank you, Marv, for joining our dropwait session and reporting your testing. It sounds like the new 1-second-apart carrier checks are just what you need, if your dropouts last only a few seconds. Now, if could only figure out Scooby's "disable wireless" solution.
Richard

[Marv]

BTW, thank you, Marv, for joining our dropwait session and reporting your testing. It sounds like the new 1-second-apart carrier checks are just what you need, if your dropouts last only a few seconds. Now, if could only figure out Scooby's "disable wireless" solution.
Richard

Indeed, duration of my dropouts is 3 seconds. See below. Makes for an interesting testbed. The 6.3.2 spup versions continues to work well subjectively with the dropwait time set to 4 seconds for now.

Code: Select all

Jul 19 09:45:10 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:46:50 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:46:51 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:48:31 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:48:32 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:50:12 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:50:13 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds

Thank you

[Scooby]

Code: Select all

> cat /var/log/everything/current | grep carrier
Jul 21 16:23:26 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:23:26 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:23:26 [dhcpcd] enp4s0: carrier acquired
Jul 21 16:23:26 [dhcpcd] enp4s0: carrier lost
Jul 21 16:25:49 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:25:49 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:27:01 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:27:01 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:27:32 [dhcpcd] enp4s0: waiting for carrier

been running for a while( a couple of hours) with dropwait 5 sec

I never seem to get these messages

Code: Select all

syslog(LOG_INFO, "%s: carrier lost temporarily for %d seconds", ifname, i);

If I have dropwait set to 0 I get some carrier's lost
but with 5 secs I have not experienced any!?

[Marv]

If I set dropwait to 0 on the above system, no 'carrier temporarily lost' messages at all are generated but it forces a reconnect and renews the lease pretty much every minute or two. With a dropwait of 4 seconds, 'carrier temporarily lost' messages are logged every 108 seconds but dhcpcd waits them out as (I assume) it is supposed to do. Over several days now with dropwait set at 4 seconds and normal use, lid suspend, browsing, sfs creation etc., no reconnecting at all on this system. I'm running right now with dropwait of 0 and it's reconnected 4 times while I wrote this.

[rerwin]

Marv, Scooby and other dropwait users,
After much experimentation I have settled on my adaptation of dhcpcd, to provide some tolerance of carrier dropouts while also ensuring that disabling (disconnecting) wireless continues to work reliably as expected. My goal is to minimize the risk of any mods inadvertently impacting the complicated operation of dhcpcd. I have narrowed the purpose of dropwait to be only for ignoring short outages, so that any delays caused by dropwait are minimal, particularly for link terminations during boot-up that would slow the process.

Now that the developer has made more bug fixes to the 6.4.x version, I start with 6.4.2. However, I discovered that the releasing of a wireless link requires 11 seconds on my Pentium II (266 MHz) laptop, which I consider the "worse case" to support. My netbook require almost as long. Since a timeout limit of 10 seconds results in killing the release process, leaving the situation Scooby has reported regarding the IP address remaining in the network status report.

The attached "patched" version of dhcpcd-6.4.2 has the timeout increased to 15 seconds. I propose that that version be considered the standard version because it retains all of the original design. The "patched-dropwait" version is offered for those needing more tolerance for carrier dropouts of short duration. I selected a fixed value of 3 seconds based on Marv's report of a 1 second dropout followed by a 2-second one. For this version, I added 3 seconds to the increased timeout value. Both versions are suitable for all puppies -- they adapt themselves for slacko installations.

Because I discovered that the network tray icon and link notification popups did not work when the user disabled wireless, I include a fix in the pinstall script for both patched versions. Instead of using the RELEASE "hook" when a link is released, the STOP hook is now used. the network_tray and notify hook scripts did not respond to the STOP hook, so indicate the link is still up. The pinstall script updates those hook scripts, which need to be fixed in the woof versions of them.

In the source tarballs, I include the patch file that would convert an original dhcpcd to the modified version. I also include a "README-...wait" file with patch instructions and configuration commands. (I would like to add commands for 64-bit systems, if someone would give them to me.)

Please try these latest packages and tell me of any problems that make them unacceptable for general use. Thanks for your help.
Richard

EDIT - Additional details of this "dropwait" implementation:

• 1. The two new or modified "info" messages are:
  • version 6.4.2-dropwait starting
    momentary carrier loss ignored
  2. The "-j --dropwait" option argument is eliminated. The user or developer uses either the standard dhcpcd or the "dropwait" version. The minimalist modifications to the original should avoid inadvertent impact to the operation of dhcpcd.
  
  3. The primary difference in behavior of the "disable wireless" (release) function since 5.6.4 appears to be that signal interruption of the daemon controlling the wifi link is limited, preventing the dropwait delay from being interrupted to release a link. I am reluctant to interfere with the developer's design, to try to enable interruption during the wait period.

UPDATE 7/25/2014: I repackaged the "pets" to make a separate set for use in Slacko puppies, rather than trying to be clever and make single, adaptable versions. The difference in the Slacko versions is that the "hook" files and script reside in /usr/libexec instead of /lib/dhcpcd. They function the same as the previous set with the workaround for slacko.

During testing of dhcpcd, using frisbee, I found some things to fix in frisbee-1.2, so will be uploading that shortly. With the new 6.4.2 dhcpcd, frisbee will no longer contain the button for setting the drop timeout value, because the value is fixed at 3 seconds. R

[Marv]

Testing the above pet in X-slacko 2.1 on a Pentium M ipw2200 laptop, the identical setup used to sucessfully test the 6.3.2 spup dhcpcd with dropwait.
6.3.2 uninstalled, wireless disconnected, profile and resolv.conf deleted. 6.4.2 installed from pet, Frisbee used to reconnect. IP acquired correctly but resolv.conf not written so no DNS available. Rechecked with a reboot, with and without the resolv.conf stub (no nameservers) in place with the same results. Switched back to 6.3.2 after uninstalling 6.4.2. Resolv.conf immediately created and correct. Back to 6.4.2 again. Same result as before. Dropouts seem to be handled fine, just no resolv.conf. Copying in a resolv.conf or using a resolv.conf.head gets it going. Posting running with it now.

The tar.gz attached contains a sample of the dropout handling and a dhcpcd log snippet for 6.3.2 and 6.4.2.

Anything else I should try or log for now?

Edited once, added 'copy in resolv.conf and running now' stuff

[rerwin]

Marv,
Thanks for your report. I now have both slacko-5.7.0 and xslacko-2.1 installed on my netbook for testing. I see the problem you report occurring in both of my slackos but not in lupusuper2 or precise-5.7.1. That narrows it a bit. It may take some time to find the culprit in the slackos. I also see that the new wpa-supplicant hook is reporting an exit code of 127, whatever that means, but only in the slackos. They are probably related.

On a hunch, I added 2 dhcpcd-hooks links from /lib/dhcpcd to /usr/libexec. That cured both problems! The WEXIT... message implies that it was issued by a file in /lib/dhcpcd, which has never had the dhcpcd-run-hooks script in slacko. So, that is a mystery. But we have the workaround.

Code: Select all

ln -snf /usr/libexec/dhcpcd-hooks /lib/dhcpcd/dhcpcd-hooks
ln -snf /usr/libexec/dhcpcd-run-hooks /lib/dhcpcd/dhcpcd-run-hooks

Hmmm. Maybe the configure command affects the directory name compiled into the dhcpcd executable. If so, I need to make separate pet packages for slacko. I assumed the names are set only in the scripts; maybe not.
R

[Marv]

On a hunch, I added 2 dhcpcd-hooks links from /lib/dhcpcd to /usr/libexec. That cured both problems! The WEXIT... message implies that it was issued by a file in /lib/dhcpcd, which has never had the dhcpcd-run-hooks script in slacko. So, that is a mystery. But we have the workaround.

Code: Select all

ln -snf /usr/libexec/dhcpcd-hooks /lib/dhcpcd/dhcpcd-hooks
ln -snf /usr/libexec/dhcpcd-run-hooks /lib/dhcpcd/dhcpcd-run-hooks

Hmmm. Maybe the configure command affects the directory name compiled into the dhcpcd executable. If so, I need to make separate pet packages for slacko. I assumed the names are set only in the scripts; maybe not.
R

Running correctly with the workaround here.

Thanks

[rerwin]

"Running correctly" is good to hear! Thanks.

I have uploaded separate pet packages for slacko puppies and re-uploaded the main versions with the "adaptation" logic removed:
http://www.murga-linux.com/puppy/viewto ... 629#790629
Be sure to use the appropriate slacko/all-others package for your puppy.

While testing the various dhcpcd versions, I fixed some minor bugs in frisbee-1.2 that might be useful where the new dhcpcd is in use (although there is no dependency between them). The new frisbee package is 20140724 at:
http://www.murga-linux.com/puppy/viewto ... 962#780962

[Scooby]

Sounds good

I will bundle them up for alphaos.

I will be less usefull as a tester cause I got optical fibre with ethernet port
in my wall in my new apartement so I am not using wlan at the moment

[Marv]

Currently running the most recent dhcpcd-6.4.2-patched-dropwait-slacko-i686.pet and the updated Frisbee 1.2 in X-slacko 2.1 on the 1.6GHz Pentium M with intel ipw2200 wireless. All prior versions and configuration files/profiles stripped before installation. All seems well. WPA2 connection works, resolv.conf populated correctly, carrier dropouts of 1 and 2 seconds 'waited out', and the Frisbee dialog boxes in the Diagnostics pane correctly reflect my configuration.

dhcpcd-6.4.2-patched-dropwait-i686.pet running correctly on Carolite 1.2 (with Battleshooters 3.15 kernel swap). Resolv.conf ok, 3 second dropouts waited out ok.

I can't check the current Frisbee completely on that as it needs a newer net_tray than Carolite has and in general I run peasywifi there as it handles the wpa2/ipw2200 combo better (both in original and 3.15 kernel). Just why THAT is remains a mystery to me. Peasywifi and Frisbee are calling the same wpa_supplicant and requesting the newer wext driver for the ipw2200. I can get Frisbee to create a wpa2 profile and not provoke me with the 'invalid password' nag if I put my lucky hat on and modprobe mac82011 and the crypt libraries in JUST the right order in the proper phase of the moon. Once the profile exists, all is cool. Frisbee 1.2 run from a terminal and Frisbee beta-4 behave identically in this respect. Peasywifi, on the other hand, starting from scratch in Carolite (either kernel) just accepts the password, creates the profile and connects. I've looked at the line that calls wpa_supplicant in both and see no significant differences. Just an aside and pretty much a nonevent as Frisbee works perfectly with that troublesome card/WPA2 combo in all newer pups I've run, both precise and slacko based.

Given a rainy (non-firewood cutting) day I'll install the above on my iwlwifi laptop and test.

Edited to add Carolite test.

[rerwin]

I can get Frisbee to create a wpa2 profile and not provoke me with the 'invalid password' nag if I put my lucky hat on and modprobe mac82011 and the crypt libraries in JUST the right order in the proper phase of the moon. Once the profile exists, all is cool.

The modprobing of the modules you mention may be something I can automate with a modprobe configuration file. Please tell me more about what you know about your technique. Thanks. R

[Marv]

I can get Frisbee to create a wpa2 profile and not provoke me with the 'invalid password' nag if I put my lucky hat on and modprobe mac82011 and the crypt libraries in JUST the right order in the proper phase of the moon. Once the profile exists, all is cool.

The modprobing of the modules you mention may be something I can automate with a modprobe configuration file. Please tell me more about what you know about your technique. Thanks. R

It.. or I.. isn't consistent enough so I can explain or implement it. To be honest, I now usually just snitch a working profile from one of my other pups. I'm going to continue to try and understand why peasywifi, which does no explicit modprobing, works in Carolite 1.2 and Frisbee (either beta-4 or 1.2) doesn't in exactly the same installation. I'm quite sure that the failure is due to the ipw2200 being WPA capable but not 'officially' so.

Sorry I can't do better.

[stray_dog]

Dear rerwin, between the frisbee 1.2 and the updates to dhcpd, you really made a big difference to how easily my wifi works & connects to open networks with slacko 5.6! Thank you! Would you like to get married?

[Scooby]

Found some time for packaging frisbee for alphaos

1. frisbee-1.2-20140724.pet has removed /usr/sbin/dhcpcd_dropwait_option

But I think /usr/local/frisbe/func still uses it?

Will you please confirm if it should be included or safely discarded?

2. About /usr/local/bin/frisbee
I want to discuss the way you check for only one script running at the time.
The drawback with your aproach is that you have to add a lot of grep -v
like the one you've added for geany ( I would have to add emendo for instance)

Does puppy contain flock command? if so maybe try
( from here )

Code: Select all

LOCKFILE="/tmp/frisbee.lock"
LOCKFD=99

# PRIVATE
_lock()             { flock -$1 $LOCKFD; }
_no_more_locking()  { _lock u; _lock xn && rm -f $LOCKFILE; }
_prepare_locking()  { eval "exec $LOCKFD>\"$LOCKFILE\""; trap _no_more_locking EXIT; }

# ON START
_prepare_locking

# PUBLIC
exlock_now()        { _lock xn; }  # obtain an exclusive lock immediately or fail
exlock()            { _lock x; }   # obtain an exclusive lock
shlock()            { _lock s; }   # obtain a shared lock
unlock()            { _lock u; }   # drop a lock

if ! exlock_now; then
	gtkdialog-splash -placement center -timeout 10 -bg orange -text "$(gettext 'Frisbee is already running.')"
	exit
fi

*UPDATE* fuser aproach doesn't seem to work if you restart wpa_supplicant
it will retain filehandle and then you cannot start frisbee.
I will keep fuser approach below for reference


--------------------------------- BEGIN does not work -----------------------------------------------------

Does puppies have fuser command? if so I like
(from here a little bit down)

Code: Select all

#       mutex file
#
# Open a mutual exclusion lock on the file, unless another process already owns one.
#
# If the file is already locked by another process, the operation fails.
# This function defines a lock on a file as having a file descriptor open to the file.
# This function uses FD 9 to open a lock on the file.  To release the lock, close FD 9:
# exec 9>&-
#
mutex() {
    local file=$1 pid pids 

    exec 9>>"$file"
    { pids=$(fuser -f "$file"); } 2>&- 9>&- 
    for pid in $pids; do
        [[ $pid = $$ ]] && continue

        exec 9>&- 
        return 1 # Locked by a pid.
    done 
}
mutex /var/run/frisbee.lock || { echo "Already running." >&2; exit 1; }

*UPDATE* tried below it didn't work but it seems to work if you put both
mutex function and check in frisbee file
OBS! doesn't work! You could put function mutex in /usr/local/frisbee/func and
only keep last codeline(or modified to fit) in frisbee file.
--------------------------------- END does not work -------------------------------------------

also I think I would have to adjust "which frisbee"
for me it returns "frisbee is /usr/local/bin/frisbee"
And it is not the same for you right?

Okay remered now that I have which aliased to "type -a"

3. Shouldn't you up the version maybe to something like 1.2.1???
I mean in --version output

4. I didn't get the new dhcpcd-hook scripts, they were files of size 0
Will test and see if they work. answer: don't work
re-added old 99-notify, and they work aagain.

5. *UPDATE* variable TERMEMLTR must be exported in frisbee

6. *UPDATE* on "Network interfaces" tab when pressing "view DHCP log"
/var/log/messages is used. My log is at /var/log/everything/current.
This could be solved with a symlink, Is this the way we should solve it or an entry
in frisbee.conf?


I will make a test package for alphaos and run for a while

I am very pleased with the new version, good job

[bigpup]

rerwin,

rcrsn51 has maybe invented the better mouse trap for wifi connection.
Maybe you two could get together and compare notes.
At least bounce ideas off each other.

His wifi connection manager is here:
PeasyWiFi
http://murga-linux.com/puppy/viewtopic.php?t=94501