Frisbee Network Manager - Beta 2

[fredx181]

Hi David Andrew,
Did you have the same problems with the included (older) frisbee in DebianDog?

Fred

[David Andrew]

Hi David Andrew,
Did you have the same problems with the included (older) frisbee in DebianDog?

Fred

Yeah. I started off with the default Frisbee that came with Debiandog, then I installed the 1.2 tarball update but the same problem persisted, and then I finally tried the .deb package, also no change.

[Scooby]

In frisbee I was always annoyed with having to sidescroll to find SSID
so I wanted to exchange SSID and Encryption in scan_result output.

I did a hack as:

In /usr/local/bin/frisbee line 510

I exchanged the headers from

Code: Select all

      <label>$(gettext 'BSSID                  |Freq  |Strength|Encryption              |SSID')</label>

to

Code: Select all

      <label>$(gettext 'BSSID                  |Freq  |Strength|SSID              |Encryption')</label>

and in /usr/local/bin/frisbee/func

I exchanged in function get-scan-results line 901 from

Code: Select all

wpa_cli scan_results -i $INTERFACE |grep ^..:..: |sed 's/	/|/g'

to

Code: Select all

wpa_cli scan_results -i $INTERFACE |grep ^..:..:| awk '{print $1"|"$2"|"$3"|"$5"|"$4}'

I think awk is present on most puppies right?

What do you think?

[Scooby]

first:

I don't understand the code in /usr/local/frisbee/func
in function disconnect there is this code line

Code: Select all

	killall wait-disconnect 

But from what I can see function wait-disconnect is never executed in the first place?
and I always get "wait-disconnect: no process found" when I try it.


furthermore wpa_cli -i $INTERFACE status never contains "COMPLETED" during disabling of wireless which is grep'ed for in wait-disconnect. I only get DISCONNECTED

also there is the strange thing of having dhcpcd -k call last in wait-disconnect and in disconnect resulting in it may be callied twice.

I think this part of the code should be reviewed. I am not sure what is intended to be
accomplished with it?

second:

right click on network_tray menu and selecting "Enable wireles network" would result in AppRun being called with "--disconnect"

I changed code in network_tray.c function tray_icon_on_menu

from

Code: Select all

if (if_type_icon_data[wifi].if_type_status == connected) \
				menuitem = gtk_menu_item_new_with_label(_("Disable wireless network"));
else menuitem = gtk_menu_item_new_with_label(_("Enable wireless network"));

g_signal_connect(menuitem, "activate", (GCallback) view_popup_menu_onDisconnect, status_icon);
	

to

Code: Select all

			if (if_type_icon_data[wifi].if_type_status == connected) {
				menuitem = gtk_menu_item_new_with_label(_("Disable wireless network"));
				g_signal_connect(menuitem, "activate", (GCallback) view_popup_menu_onDisconnect, status_icon);
		    }
			else {
			menuitem = gtk_menu_item_new_with_label(_("Enable wireless network"));
			g_signal_connect(menuitem, "activate", (GCallback) view_popup_menu_onReconnect, status_icon);
		    }

After change it runs fine

[gcmartin]

Should a new Frisbee Thread be opened where Frisbee changes can be consolidated in the future? Or can this utility be moved to PUPPY GIT for developer changes as it is now packaged with so many PUP distros.

The updates need to be pushed to the main-line.

[rerwin]

However it doesnt use the dropwait feature and when I looked at script
/usr/bin/dhcpcd_dropwait_option I think I found a inconsistency.

The diffs I found at http://www.murga-linux.com/puppy/viewtopic.php?p=662522
( a bit far down )
are from Sun 04 Nov 2012, 22:55 so maybe this are not the latest ones?

Anyway in script there is check for --dropwait

Code: Select all

DWOPTION="$(dhcpcd --help | grep -o '\--dropwait' | cut -f 1 -d ' ')"

but in the diffs I found there is only

Code: Select all

+	    "              [-r ipaddr] [-s ipaddr] [-t timeout] [-j dropwait]"

That means --dropwait would never be found.

Scooby, The inconsistency is between the version of "dropwait" and the version of the dhcpcd patch you used. The released version of the modified dhcpcd returns this for the --help option:

Code: Select all

usage: dhcpcd	[-ABbDdEGgHJKkLnpqTVw]
		[-C, --nohook hook] [-c, --script script]
		[-e, --env value] [-F, --fqdn FQDN] [-f, --config file]
		[-h, --hostname hostname] [-I, --clientid clientid]
		[-i, --vendorclassid vendorclassid]
		[-j, --dropwait seconds] [-l, --leasetime seconds]
		[-m, --metric metric] [-O, --nooption option]
		[-o, --option option] [-Q, --require option]
		[-r, --request address] [-S, --static value]
		[-s, --inform address[/cidr]] [-t, --timeout seconds]
		[-u, --userclass class] [-v, --vendor code, value]
		[-W, --whitelist address[/cidr]] [-y, --reboot seconds]
		[-X, --blacklist address[/cidr]] [-Z, --denyinterfaces pattern]
		[-z, --allowinterfaces pattern] [interface] [...]
       dhcpcd	-k, --release [interface]
       dhcpcd	-U, --dumplease interface
       dhcpcd	--version
       dhcpcd	-x, --exit [interface]

I have dug around the PC I developed dropwait on and found the source for dhcpcd 5.6.4, which is what is in precise and woof. I made a difference/patch file, which is attached. Please try that with your newer version(s) of dhcpcd. It is for the same source package as posted here:
http://www.murga-linux.com/puppy/viewto ... 311#678311
Richard

EDIT: Replaced attachment with complete difference file.

[Scooby]

I have dug around the PC I developed dropwait on and found the source for dhcpcd 5.6.4, which is what is in precise and woof. I made a difference/patch file, which is attached. Please try that with your newer version(s) of dhcpcd. It is for the same source package as posted here:
http://www.murga-linux.com/puppy/viewto ... 311#678311

Ok I checked it out, its just the argument handling that has changed not the active code.

I need to update if-options.c and if-options.h also but i guess I can dig out the changes
in source from link above. But if you find the time diffs would be useful for these.
I actually tried "--dropwait" with my version and dhcpcd swallowed it so it seems
that it is activated, only helpmessage differs.

In dhcpcd 6.3.2 the code in dhcpcd.c has changed a little bit and I had to change dropwait part to match

for future reference the jemimah code in function handle_carrier morphed into this for 6.3.2

Code: Select all

else if (carrier == LINK_DOWN || (ifp->flags & IFF_UP) == 0) {
		if (ifp->carrier != LINK_DOWN) {
//JEMIMAH START
			if (ifp->wireless) {
     				ts.tv_sec = ifp->options->dropwait;
               		 	ts.tv_nsec = 0;
               		 	nanosleep(&ts, NULL);
 				carrier = carrier_status(ifp);
				if (carrier == 1) return; 
			}
//JEMIMAH END
			if (ifp->carrier == LINK_UP)
				syslog(LOG_INFO, "%s: carrier lost", ifp->name);
			ifp->carrier = LINK_DOWN;
	

[Scooby]

I fixed problem with dhcpcd

questions that remain for me

1. in /usr/local/bin/frisbee line 413, rxvt is explicitly called.
How to fix?

2. code in /usr/local/frisbee/func, investigate purpose of function wait-disconnect
Only call I can see is in function disconnect in same file?

3. Are there icons with better resolution for network_tray?

Otherwise I feel I'm ready to package.

info: I ported 01mickos network_tray 2.7.2. It seems ifconfig displays
very different output on puppy and alphaos. If anyone could
provide sample output for puppy I could create a version that works on both.

[rerwin]

Scooby,
I have been updating my copy of frisbee to address your questions. I add items to the frisbee.conf file for specifying the terminal emulator and text editor to use, with the expectation that a distro developer would set those appropriately.

Code: Select all

terminal=rxvt #terminal emulator that takes the "-e" (execute/command) option
editor=defaulttexteditor

The wait-disconnect issue I handle by changing the line, killall wait-disconnect, to avoid the warning message:

Code: Select all

[ "$(pidof wait-disconnect)" ] && killall wait-disconnect #140607

I leave in the procedure itself in case anyone in the future needs it. It does not hurt to just leave it there.

Re the tray icons, the only alternative I know of is a set that 01micko created from the original frisbee icons. AFAIK the current network_tray set is the only one that supports the combinations of active networks - ethernet, wifi and mobile wireless, and limited support of analog/wireline dialup. I assume that the tray icon size is intended to be 24x24, so the current icons match that. That was Barry's design decision, so I am being consistent with that.

Note, though, that network_tray is designed to handle alternative sets of icons. /usr/local/lib/X11/mini-icons/network_tray is actually a link to the "xpm" set of 41 icons. Mick created an "svn" set of some sort, I assume for slacko. I obtained the set from slacko-5.6 (which I happen to have on my PC) and am attaching an archive of it, to be expanded to:
/usr/local/lib/X11/mini-icons
It replaces the link, to point to the svn set. No need to delete the xpm set. Note that you probably have to rename the current network_tray link, to allow the archive expansion to set the new version of that link.
Richard

UPDATE 6/8/2014: The updated frisbee is now in the "compatibility" frisbee posting on the previous page, here (as 20140607):
http://www.murga-linux.com/puppy/viewto ... 962#780962

It contains the above changes plus:
- Fixed INIT lines in the initialization script, per saintless.
- Reformatted the code in the initialization script for proper indentation, per Scooby, and substitution of a "case" structure for the multiple "if" tests.
- Added --version option to frisbee script
- Eliminated an always-occurring killall warning message in log.
- Re-ordered wireless scan results columns to put SSID before Encryption, per Scooby -- I am concerned that the SSID field is now too narrow; please suggest how wide it should be, considering the longest SSID you have seen.

The modified files are: /etc/frisbee/frisbee.conf, /etc/init.d/frisbee, /usr/local/bin/frisbee and /usr/local/frisbee/func. Those can be copied from the pet to their appropriate locations in DD and archpup.
R

UPDATE 6/14/2014: Updated the "compatibility" frisbee in the posting on the previous page (as 20140614), to accommodate the possibilities that the 'pdiag' or 'dropwait' support files are absent from a distro. The respective buttons are disabled/greyed-out if the function is not present, with tool tip notices of that situation.
R.

[Scooby]

Here is the source code and package of the network_tray with icons on rightclick menu and the IP address shown in the tooltip.

Note the source is just the C code, You can use rerwin's original compile script to compile and generate .pot file.

I'm not sure were to post about issues with 01mickos network_tray 2.7.2? here?

The tool tip text would keep on displaying an ip adress allthough you pressed
"Disable wireless Network".

Upgraded folllowing in network_tray.c

line 114

Code: Select all

              fgets(ipa,sizeof ipa,fp);

to

Code: Select all

   
              if( fgets(ipa,sizeof ipa,fp)==NULL ) ipa[0]='\0';

commented out line 117

Code: Select all

                  if (ipa==NULL) return 1;
    

changed codeblock at line 299

Code: Select all

        if (ipa!=NULL) {
			strcat(infomsg,_("\nIP address: "));
			strcat(infomsg,ipa);
		  }

to

Code: Select all

			
                   strcat(infomsg,_("\nIP address: "));
                   strcat(infomsg,ipa);

[Scooby]

wait-disconnect issue I handle by changing the line, killall wait-disconnect, to avoid the warning message:

Code: Select all

[ "$(pidof wait-disconnect)" ] && killall wait-disconnect #140607

I leave in the procedure itself in case anyone in the future needs it. It does not hurt to just leave it there.

I was just curiuos what wait-disconnect were for, I agree it doesn't hurt to leave it but
I would rather understand it so I can know if I missed something

-- I am concerned that the SSID field is now too narrow; please suggest how wide it should be, considering the longest SSID you have seen.

Hmmm maybe this is different in gtk2 and gtk3.
In gtk3 the fields auto-size themselves after the longest string, nothing is hidden.
I believe in gtk2 if string is longer than column some part gets hidden?

So this is why I wanted to exchange SSID and encryption
since encryption could be very long.

Could post a image of problem tomorrow.

Thanks for updates rerwin, Soon at the finishline now

[Scooby]

I made a disconcerting discovery.

If I had dropwait set to 0 and select right click menu of network_tray
"Disable wireless network" everything seems ok and I get no IP adress
with ifconfig

but

If I had dropwait set to 15 and select right click menu of network_tray
"Disable wireless network" IP adress does not disappear from
ifconfig output. But I cannot connect to internet via browser.

I tried with dhcpcd version 5.6.4 and it behaved correctly in both instances

Deduction tells me I did something wrong when hacking in the dropwait patch
in dhcpcd version 6.3.2?
Who is resident dropwait patch master, need help?

[peebee]

Status notifications seem to have stopped working with Frisbee as installed in Slacko5.7 (and now in Slacko6Beta)

Running frisbee from a terminal does not give any clues why.

Any ideas on how to investigate further please?

[rerwin]

Status notifications seem to have stopped working with Frisbee as installed in Slacko5.7 (and now in Slacko6Beta)

Running frisbee from a terminal does not give any clues why.

Any ideas on how to investigate further please?

I just now tried slacko 5.7.0 and also see that the notifications are absent. The hook file, 99-notify, is not being executed. That is because it is not where slacko keeps its hook scripts. Move /lib/dhcpcd/dhcpcd-hooks/99-notify to /usr/libexec/dhcpcd-hooks/ or make a link to it there.
R

[peebee]

Status notifications seem to have stopped working with Frisbee as installed in Slacko5.7 (and now in Slacko6Beta)

Running frisbee from a terminal does not give any clues why.

Any ideas on how to investigate further please?

I just now tried slacko 5.7.0 and also see that the notifications are absent. The hook file, 99-notify, is not being executed. That is because it is not where slacko keeps its hook scripts. Move /lib/dhcpcd/dhcpcd-hooks/99-notify to /usr/libexec/dhcpcd-hooks/ or make a link to it there.
R

Thanks Richard - I'll make this change in my next LxPup version (14.07 maybe) unless Mick sees this and is able to make it at the Slacko6 level.

[rerwin]

If I had dropwait set to 0 and select right click menu of network_tray
"Disable wireless network" everything seems ok and I get no IP adress
with ifconfig

but

If I had dropwait set to 15 and select right click menu of network_tray
"Disable wireless network" IP adress does not disappear from
ifconfig output. But I cannot connect to internet via browser.

I tried with dhcpcd version 5.6.4 and it behaved correctly in both instances.

Scooby and I have been working this issue over the past month. He is using dhcpcd version 6.3.2 with adapted dropwait modifications. There has been significant development of dhcpcd between 5.6.4 and 6.3.2, and now 6.4.0. For the 6.x series, timeout protection was added such that the delay performed to implement the dropwait function exceeds the timeout period when a connection is intentionally closed (wireless disabled). There does not appear to be a practical way around the 10-second timeout.

For the 6.x versions, I reworked the dropwait logic so that it waits only up to 5 seconds but tests for a reconnection each second of that period, making five attempts instead of only one. The effect of that can be tested by setting a nonzero dropwait value up to 5, although any larger value is treated as 5. I am curious to know whether this reimplementation has any noticeable effect, but need others with weak signals to test it. Of course, a value of zero turns off dropwait.

I am attaching both a 6.3.2 version of dhcpcd-dropwait and one for the last of the 5.6 series. The latter retains the original dropwait technique, with any improvements over puppy's 5.6.4 version. It appears the the new method will be needed for future versions, making it important to determine whether it provides sufficiently improved reliability to justify maintaining a special version of dhcpcd, at all.

These pet packages were built in lucid pup 5.2.8.6 and may need adaptation for slacko, due to the location of the dhcpcd hook files.
Richard

UPDATE 7/16/2014:
Re-uploaded the 6.3.2 tarball and pets, implementing Scooby's recommendations. The maximum dropwait time is 15 seconds, which is what people are used to. But now, there is no option to extend that period. I figure that if a carrier has not been detected in 15 attempts 1 second apart, it must really be gone.

To determine whether the dropwait function has operated successfully with a weak connection, check the log using the following command to show the dropouts:

Code: Select all

grep 'lost temporarily' /var/log/messages

The message(s) will show the number of seconds of outage, rounded upward.

Further recommendations are welcome. I feel I am close to the final version of this, so "last call" for improvements.

UPDATE 7/23/2014:
The packages attached here have now been superceded by those for dhcpcd-6.4.2, posted on the next page:
http://www.murga-linux.com/puppy/viewto ... 629#790629

[Scooby]

Thank you rerwin

I downloaded source and built it here.

Will run it for a while and report back

I saw that you included patch for 6.4.0 also
Did you have to change the patch much between
6.3.2 and 6.4.0

The "Disable wireless network" works fine here now

*edit*
Did the "cellar"-test
and it seems to work
Allthough I had to be fast when I ran back to get signal again witin 5 seconds

Could it be extended from the max 5s to maybe 9s (or 8s)?

There does not appear to be a practical way around the 10-second timeout.

Maybe it could be upped to 20s so that dropwait can be 15s?

The built in 10s timeout is it only for when a connection is intentionally closed?

Where does messages like

Code: Select all

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

end up. in /tmp or /var/log

Do you have to change something to see debug level messages?


I saw something I dunnow if it is a bug or a feature.
But when I wanted to checkout dropwait setting
and then hit cancel the value returned to 0 (was 5)
In my head I was just cancelling wanting to change dropwait at all
so is this intended?

[rerwin]

Scooby,
Thanks for checking out my changes. To answer your items:

1. Re 6.4.0:
I have not provided packages for 6.4.0 because there appear to be several outstanding "To Do" items about regressions from 6.2.1. So it seems 6.4.0 is "not ready for prime time". Nevertheless, the 6.3.2 patch is nearly the same as for 6.4.0, but with one addition. A particular definition (O_CLOEXEC) is not present in 6.3.2 and causes a compilation failure. 6.40 has code to handle that -- to avoid using the item if it is not defined. I made a similar change to 6.3.2 (but differently) to get it to compile.

Code: Select all

#ifdef O_CLOEXEC
		ctx.pid_fd = open(pidfile,
		    O_WRONLY | O_CREAT | O_CLOEXEC | O_NONBLOCK,
		    0664);
#else
		ctx.pid_fd = open(pidfile,
		    O_WRONLY | O_CREAT | O_NONBLOCK,
		    0664);
#endif

2. Extending the timeout value:
I considered trying to add the dropwait value to the timeout value, but am unsure about how to obtain the value at the point where needed. The timeout is currently hard-coded as a loop of 100 0.1-second sleeps. The signal for the "release" of the connection is SIGALRM. So, I can limit the extension to that signal, but cannot limit it to only wireless connections. But, that probably does not matter. BTW, the developer includes (at least at some point in the evolution of the fixes) that a "user" who does not like the timeout can just disable it (somehow). I take that to mean we can extend it if we want to, although I think we should limit the dropwait value to 15 seconds instead of 2 minutes, so that we can hard-code a 10-second sleep before the existing loop. If a connection is lost for 15 seconds, I would say it is not returning -- I think the dropwait implementation is intended as an experiment that requires the user to guess an appropriate value, based on ambiguous performance. I think it is time to convert the option to "on" or "off" instead of open ended. The one-second check for a carrier is more likely to find one than a single check after an arbitrary interval.

3. The timeout logic seems to be for 4 of the 6 signals in play, but we can limit the extension to SIGALRM, which is probably for intentional closure.

4. The "LOG_DEBUG" message I added appears in the the /var/log/messages log, actually wherever the other syslog messages go (as there are other possibilities, too). I could change it to LOG_INFO if that seems better (which I prefer, unless we choose to eventually eliminate it) -- or anything else appropriate. I did not have to do anything special to see either debug or info messages.

5. Bug or feature:

But when I wanted to checkout dropwait setting
and then hit cancel the value returned to 0 (was 5)
In my head I was just cancelling wanting to change dropwait at all
so is this intended?

I discovered that misbehavior, too, as I was experimenting. I will fix that in frisbee. Remember, I trusted that Jemimah knew what she was doing, so did not look for problems, but fixed issues that I or someone else found during usage of frisbee.

Note that I am re-uploading the attachments to clean up some things. I make the package names consistent with previous versions and tidied up my added files in the source tarballs. No functional differences.

Anyone who has opinions on these matters, please mention them so that we end up with an optimal dropwait function.
Richard

[Marv]

dhcpcd-6.3.2-patched_dropwait-spup.pet installed in X-slacko 2.1 (original dhcpcd version in that was 5.5.6-dropwait). dhcpcd-hook symlink created per http://www.murga-linux.com/puppy/viewto ... 100#789100

Most of my laptops use ipw2200 wireless drivers with firmware version 3.0 or 3.1.5. Even with good strong wireless signal, they have problems with dropouts, particularily (I believe) with kernels newer than 3.x.x . Setting the dropwait time to 15 helps but periodically the network will be unavailable just for a second or two. Backing up a page or reloading then works. A minor irk but consistent.

My iwlwifi laptop has no problems at all in the same location and can run happily in all pups with no dropwait.

The 6.3.2 above is up and running fine with a dropwait time of 5 set in X-slacko 2.1 and so far no lapses. The problem is sporadic so it will take some time to get a (admittedly subjective) feel for better or not. I'm using the X-slacko 2.1 as my daily so I should see any difference over a period of a few days.

Thanks for supporting Frisbee and dhcpcd.

[Scooby]

Remember, I trusted that Jemimah knew what she was doing, so did not look for problems, but fixed issues that I or someone else found during usage of frisbee.

Yeah I think Jemimah was a great coder. If I sounded critical it was not my intention
I just want to collaborate to make frisbee better


I am not sure how to change my system to show LOG_DEBUG, maybe at boot
Anyway I made a simple hello world to syslog with LOG_INFO and it showed up.

I think you should keep logging and preferably with LOG_INFO