Frisbee Network Manager - Beta 2

[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

[stray_dog]

Joking aside and such, they both seem really smart & I bet them comparing notes would be fascinating.

[rerwin]

Scooby,
Thanks for taking the time to discover the problems you mentioned. Sorry to take so long to respond. Many distractions. Although I have sent you a more detailed PM about it, here is a summary of my answers:

• 1. Removal of dropwait option: I am updating frisbee to remove all code that handled the user adjustment of the delay value, now that I have settled on a dropwait version of dhcpcd 6.4.2 that checks for reconnection after only 1, 2, and 3 seconds before abandoning the link.
  
  2. Single instance execution: I have added the "flock" solution, of which I was unaware. Brilliant!
  
  3. Version numbering: OK. I cave. If we consider the 20140724 version to be 1.2.1, then the new one can be 1.2.2. Right?
  
  4. Hook scripts: The zero-length "99-" hook script files were there to support uninstallation of frisbee, to restore 6 old files from either the Frisbee "betas" or my initial attempt to reorganize the "99ers" -- I am removing those files, so uninstall will no longer restore any old versions of them; the only "99ers" should be 99-notify and 99-network_tray.
  
  5. TERMEMLTR: Actually, it was set in the wrong place in the code; I have moved it to where it works as intended, without an export.
  
  6. DHCPCD messages: They are logged in the system log, which usually is /var/log/messages; but gentoo linux and "metalog" appear to use /var/log/everything/current, instead, resulting in my having frisbee check for the existence of either and reading whichever is present (but not both).

Richard

[rerwin]

I have made Scooby's changes to frisbee and uploaded frisbee-1.2.2 to the usual place on page 21:
http://www.murga-linux.com/puppy/viewto ... 962#780962
The details of the changes are there, as well.

For the best performance and to use the almost-latest dhcpcd with the new dropwait implementation, also install dhcpcd-6.4.2-patched-dropwait, the third (or fourth, for slacko) attachment here:
http://www.murga-linux.com/puppy/viewto ... 629#790629
Richard

UPDATE: The package is back in the usual place, as 20140818.

[rerwin]

I have uploaded another version of the frisbee network manager, frisbee-1.2.3-20140912:
http://www.murga-linux.com/puppy/viewto ... 962#780962

The main improvements are to the dialogs involving selection of items in a table and to the support of multiple wifi devices, plus various bug fixes.

Be sure to use only this version of "1.2.3", because its predecessors, 20140910 & 20140911, contain code that prevents wifi support from operating reliably or even normally. Any of those older copies of the pet packages should be uninstalled (if installed) and deleted permanently, to avoid inadvertent usage.

As usual, please report any problems with "1.2.3", so that I can continue to refine frisbee.
Richard

[stray_dog]

Hi there, rerwin. For other folks, this refers to http://murga-linux.com/puppy/viewtopic. ... 870#800870 & I'm bringing the conversation to the right spot. I'm not sure how much insight I can offer, but I'll try. The first thing I've noticed is the pop-up asking for ssid only happens on the machine I'm using right now, an hp elitebook 8530p that uses the iwlwifi driver. I've also used an hp dv1227us (somewhat old) that has never ever displayed the popup box. So I can only conclude that something about the driver/firmware for each wifi card plays a role. What that is though, I don't know. The other thing I notice is that on this machine I'm using now, it has only happened to me when attempting to connect to open unencrypted wifi networks. But then - most of my time accessing a network is to an open one, so I haven't had enough time trying it out on WPA or other types of networks requiring a password, etc. I've experienced it using the Frisbee version that was built-in to Slacko 5.6. And I've seen it with your Frisbee 1.2-20 as well. If you're on 1.2.3, that kind of gives you a window. One thing I noticed in late spring is that on our university network, when the students are here & there's a lot of network activity, it didn't happen much. But when they left for the summer & there was a lot less activity, it happened a lot more to me. Which was funny, because when I got on, the bandwidth was spectacular, but it could take a while to get on. Now that they're back, it hasn't happened once for weeks and weeks, until today! I've been using your patched dhcpcd 6.4.2 for slacko for most of this summer & fall season. Since the phenomenon literally *just* happened to me trying to get on tonight, I turned off my wifi rfkill switch & ran the frisbee diagnostic to get a tarball, I'll try to attach it here if it could yield any useful information.