(old)Puppy Linux Discussion Forum

Posted: **Fri 15 Mar 2013, 20:22**

peebee wrote: I think the new way is so counter-intuitive that it will confuse people...

It is not obvious that ticking that box will make Frisbee spring into life - not to me anyway.

All I can say is that I was about to post that the new frisbee is totally broken before I remembered the Richard had mentioned this change...

As I mentioned before the default should be on, unless you want to add a big "scan" button a la network-manager...

Posted: **Sat 16 Mar 2013, 17:56**

Peebee & mavrothal,
Thanks for your further comments. They are not being ignored.

In the pdiag file I see that the entire kit was not installed. The tray icon update logic is moved to the woof_updates package. Please install it. It is separate so that it can be available even if frisbee is omitted; developers or users could set its flag to enable notification with the other network managers. Although the dhcpcd package appears to be optional, but why use only part of the complete frisbee solution!

I am working to reconcile your comments with my concept for frisbee. I probably need to treat the installation experience separately from the experience of initial boot-up after installing a new distro containing frisbee. I want the default states (whatever they turn out to be) to occur at initial boot-up if none of the flags are set, so that a remaster does not need to copy any flags. The flags should represent the exceptions and can be set during package installation or be built into a new distro (so would be copied in a remaster). Developers would then be allowed to pre-set any flag if they want an exception at initial boot-up of their distro/remaster. That is the beauty of using flags for control rather than hard-codded logic.
Richard

Posted: **Sat 16 Mar 2013, 20:22**

rerwin wrote:In the pdiag file I see that the entire kit was not installed.

Hi Richard

My apologies for not understanding that the new Frisbee needed some infrastructure changes - if I load all 3 pets from the tarball then the network tray icon in Racy55 does change to the connected state.

Have you lengthened the refresh interval? There can be a very long delay between closing Frisbee for the 1st time and being asked if you want it to be the default.

I certainly support your efforts to separate user and developer setup functions....

Thanks
Peter

Posted: **Sat 16 Mar 2013, 22:27**

peebee wrote:Have you lengthened the refresh interval? There can be a very long delay between closing Frisbee for the 1st time and being asked if you want it to be the default.

I have not changed any interval other that that before the "no wireless connection" message pops up. That is done by a separate process (invoked with an "&").

The refresh interval remains at 15 seconds.
Richard

Posted: **Mon 18 Mar 2013, 05:10**

Looks like that when X is restarted network_tray is not properly informed of the net state.
Starting a latter instance behaves as expected (see picture).
That is on precise 5.5 with frisbee 0314 and woof-additions 0314.

Posted: **Mon 18 Mar 2013, 14:10**

Hi,
I'm a newbie using linux but I had no problem until last weekend.
Frisbee stops to work ( don't detect wireless connections) and I want to uninstall it, but with no success.
I uninstalled it from setup/installed packages but it still working.
I stop it from start-up boot but it still working.

How can I get rid of it ??

I'm using Puppy Linux Slacko last version.

I'd appreciate any help.

JW

Posted: **Mon 18 Mar 2013, 14:57**

jackwise wrote:Frisbee stops to work ( don't detect wireless connections) and I want to uninstall it, but with no success.
. . .
How can I get rid of it ??
I'm using Puppy Linux Slacko last version.

JW,
Welcome to the frisbee thread. Rather than uninstalling frisbee, simply do not let it be the default network manager. To do that, click the "connect" icon and change the radio button selection to anything other than frisbee.

Beyond trying that, we need to wait for advice from slacko's owner, 01micko.
Richard

Posted: **Mon 18 Mar 2013, 16:29**

rerwin wrote:
jackwise wrote:Frisbee stops to work ( don't detect wireless connections) and I want to uninstall it, but with no success.
. . .
How can I get rid of it ??
I'm using Puppy Linux Slacko last version.
JW,
Welcome to the frisbee thread. Rather than uninstalling frisbee, simply do not let it be the default network manager. To do that, click the "connect" icon and change the radio button selection to anything other than frisbee.

Beyond trying that, we need to wait for advice from slacko's owner, 01micko.
Richard

Thanks for your answer. Ill try tonight and give feedback.
JW

Posted: **Mon 18 Mar 2013, 21:32**

mavrothal wrote:Looks like that when X is restarted network_tray is not properly informed of the net state.

It's the same for me (on precise 5.5).

Posted: **Wed 20 Mar 2013, 01:22**

peebee, mavrothal and others,
Here is another shot at reconciling your reports and preferences. Frisbee is the only package that changed in the attached kit. Highlights:

- Installation defaults to a compatible puppy-type network manager configuration with all wireless options off except for pop-up notifications.
- If the "frisbee as default network manager" option is chosen during installation, all options are "on", wifi enabled and connected at startup (similar to the "beta" way).
- Most of the flags are replaced by a configuration file, frisbee.conf, because the flags became unwieldy.
- The "restart X" problem is managed; to restore normal network_tray function after an X restart, go into frisbee and click on either "Restart Networks" or "Restart DHCP".
- The "Enable WiFi" and "Connect Automatically" checkboxes are now separate checkboxes; previously one did both.
- "Enable WiFi" now greys-out the wireless fields if it is not checked (off), as would be expected of such an option; when not checked, wireless activity should be prevented, although I may have missed a place (so please report any inconsistency).
- Debugged the "Change Interface" button logic, using an added USB WiFi stick; did not test actual operations with two WiFis, so we may find issues to work -- I think frisbee uses only one at a time.
- Modified the pop-up notification feature so that it can be used with other network managers without conflict from frisbee; frisbee should control it independently but restore it upon exit (but not actually tested).

Richard

UPDATE 3/20/2013: Uploaded version 20130320 to correct the network_tray_modeset startup script to use the new configuration file instead of the old frisbee_mode flag file, an inadvertent omission. This should result in the correct setup of frisbee after a reboot.

UPDATE 3/22/2013: Oops! I inadvertently included the tarball inside the tarball, instead of the frisbee package. I have now re-uploaded the kit containing an updated version of the package that may address the issue with openvpn. (Sorry to be so slow, but real-life distractions occurred.)

UPDATE 3/24/2013: Re-uploaded to enable wifi and autoconnect for all frisbee installations, omit "Scanning..." pop-up if wifi or autoconnect are disabled and to update network_tray icons for better visibility in the dark blue tray area of precise pup 5.5.

UPDATE 3/25/2013: Re-uploaded to improve the logic for avoiding automatic wireless connection at boot-up and to ensure frisbee mode is set at boot-up, when appropriate, so that the frisbee network icons are used.

UPDATE 4/1/2013: Re-uploaded the kit, as 20130331, to restore the "scanning" message when automatic connection is deselected and to restore the functioning of the "dropwait" feature. The released version of the interface to it does not detect correctly the presence of the dropwait feature, so does not use it. Also split the 99-notify code file into 2, adding 99-frisbee, to separate out the frisbee-network_tray-specific logic. (Eventually, the network_tray logic will be removed from 99-frisbee.) The updated packages are frisbee and woof_updates.

UPDATE 4/20/2013: Note that a better version of the kit, frisbee-1.1/network_tray-2.7, is available on page 17:
http://www.murga-linux.com/puppy/viewto ... 497#698497
with an improved tray icon and continued functioning after an X restart.

Posted: **Wed 20 Mar 2013, 05:09**

rerwin wrote: - The "restart X" problem is managed; to restore normal network_tray function after an X restart, go into frisbee and click on either "Restart Networks" or "Restart DHCP".

That was always the case and does not look like a proper solution.
As far as I can see the problem is the call from /root/Startup/network_tray_modeset of frisbee_mode_enable.
$(ls /usr/local/lib/X11/mini-icons/networkdead-eth* 2>/dev/null) is always true since is a symlink to networkdead.xpm and thus "killall -35 network_tray" is executed. The last command is the offending one that actually turns the networkup icon to networkdead.
There are a couple of strange things with this. "killall -l" does not list "35" as an option so I'm not sure what is it doing.

Issuing "killall -35 network_tray" from the terminal can turn networkup to networkdead only soon (<30sec) after X restart but not latter

Setting permissions of /root/Startup/network_tray_modeset to 000 , "solves" this problem but generates another. Now network tray icon shows as connected as soon as the interface is up regardless of an established connection.

What "killall -35 network_tray" is doing exactly?...

Posted: **Wed 20 Mar 2013, 16:21**

mavrothal wrote:That was always the case and does not look like a proper solution.
As far as I can see the problem is the call from /root/Startup/network_tray_modeset of frisbee_mode_enable.
$(ls /usr/local/lib/X11/mini-icons/networkdead-eth* 2>/dev/null) is always true since is a symlink to networkdead.xpm and thus "killall -35 network_tray" is executed. The last command is the offending one that actually turns the networkup icon to networkdead.
There are a couple of strange things with this. "killall -l" does not list "35" as an option so I'm not sure what is it doing.
Issuing "killall -35 network_tray" from the terminal can turn networkup to networkdead only soon (<30sec) after X restart but not latter
Setting permissions of /root/Startup/network_tray_modeset to 000 , "solves" this problem but generates another. Now network tray icon shows as connected as soon as the interface is up regardless of an established connection.
What "killall -35 network_tray" is doing exactly?...

mavrothal,
Thanks for your comments. From your mention of network_tray_modeset, I find that I missed an update to use the frisbee.conf file instead of the flags. So, the script does not recognize that frisbee mode is in effect, so does not run frisbee_mode_enable. Fixed for next upload (20130320).

The "/usr/local/lib/X11/mini-icons/networkdead-eth*" test is to determine whether the network_tray program can accept the signals created for frisbee. network_tray-2.5 cannot, and would terminate if signaled. With 2.6 as the current version, yes, the test will always be true.

Re: "killall -l" does not list "35", that is because it is user defined. Although I cannot right now find my source, I found that the named signals are numbered below 32; numbers 32-or-33 (it is ambiguous) through 63-or-64 are left to users to define. I define 35-40 for frisbee to use to communicate with network_tray. They are not valid in any other context. I found that the prefix SIGRT is used for such signal numbers. As the name SIGRTfrisbeeup implies, it tells network_tray that frisbee mode is in effect, so the extended icons are to be used. In my next upgrade of network_tray, I plan to drop that signal and SIGRTfrisbeedown (40) and always display the full set of icons (once the logic is cleaned up).

Re: the restarts after restarting X, actually, they have been ineffective because a newly started network_tray does not know about frisbee mode until told through SIGRTfrisbeeup, and that was not done by the two restart functions. Now, they always send that signal. The bottom line is that without that signal after an X restart, network_tray behaves as it always has for standard puppies.
Richard

EDIT: I just now tried X restart on a clean puppy with only the woof_updates package installed. After restarting X, the tray icon has the red X. This may have been due to the installing of the package without a subsequent reboot. After I restarted networks and restored the correct icon state, a subsequent X restart did not result in the "X" icon. I have not sorted that out. So, please disregard the X icon after woof_update installation followed by a "restart X". The restart-networks/DHCP should straighten things out. The corrected frisbee kit is now uploaded:
http://www.murga-linux.com/puppy/viewto ... 212#693212

Posted: **Wed 20 Mar 2013, 19:39**

Frisbee also let you use a Android phone as a router, connecting using USB.

In the Andriod menu, you need to be there and ready to press the icon where as USB connection is set, within a second or two, if you got a storage device in your phone. This as you insert the USB cable to the PC or Android.

Otherwise the storage device will snag the USB connection. Androids WITHOUT a storage device can take their time and press the check box for USB connection in what i call a normal pace...

Your android will route a Wlan connection or a Mobile internet connection trough the USB cable.

The big benefit of course is that there is no such thing as running out of battery:-)

Posted: **Wed 20 Mar 2013, 19:49**

rerwin wrote: The corrected frisbee kit is now uploaded:
http://www.murga-linux.com/puppy/viewto ... 212#693212

I think there is a problem with the upload. There is no frisbee pet in it.
Here is what I get expanding the tarball

Code: Select all

# tar xvzf frisbee-1.0_puppy-5.5_kit-20130320.tar.gz 
dhcpcd-5.6.4-patched_dropwait-i486.pet
woof_updates-20130314.pet
frisbee-1.0_puppy-5.5_kit-20130320.tar.gz
# tar xvzf frisbee-1.0_puppy-5.5_kit-20130320.tar.gz 
dhcpcd-5.6.4-patched_dropwait-i486.pet
woof_updates-20130314.pet

Posted: **Thu 21 Mar 2013, 16:20**

Tried 0314 frisbee on precise 5.5 with ubuntu openvpn and was poor.
ie as soon as it connected to tun0 dropped the wlan0 connection and then was trying to reconnect to tun0 instead of wlan0.
Maybe was a "misbehaving" open AP, but did anyone tried openvpn with frisbee-1.0-<date> on precise OK?
(Precise 5.4.3 with Fribee-beta2 was OK with openvpn)

Posted: **Fri 22 Mar 2013, 17:49**

Atle wrote:Frisbee also let you use a Android phone as a router, connecting using USB.

In the Andriod menu, you need to be there and ready to press the icon where as USB connection is set, within a second or two, if you got a storage device in your phone. This as you insert the USB cable to the PC or Android.

Otherwise the storage device will snag the USB connection.

That sounds like something usb_modeswitch should handle. If you have an Android with the storage device, could you post the hardware ID of the storage device part as well as that of the phone/router part? We can watch for the possibility that usb_modeswitch eventually can switch to the nonstorage mode.

Posted: **Fri 22 Mar 2013, 18:05**

mavrothal,
Thanks for catching my mistake in updating the kit. I have corrected that, after 2 days away working another project.
http://www.murga-linux.com/puppy/viewto ... 212#693212

mavrothal wrote:Tried 0314 frisbee on precise 5.5 with ubuntu openvpn and was poor.
ie as soon as it connected to tun0 dropped the wlan0 connection and then was trying to reconnect to tun0 instead of wlan0.
Maybe was a "misbehaving" open AP, but did anyone tried openvpn with frisbee-1.0-<date> on precise OK?
(Precise 5.4.3 with Fribee-beta2 was OK with openvpn)

This is new territory for me, but one I want to resolve. I may have found a cause for the reconnection attempts. At least I prevent the repeated testing of the enable-wifi checkbox that might cause a change in connections. Or, at least we can rule that out as a cause. The change is in the 20130322 version of frisbee-1.0.

If the problem continues, could you send me a pdiag (--wpa) file so I can try to understand what is happening. Any further information you have on that operation might be helpful. Also helpful would be a pnetworkdiag of your beta2 run. (Both of those diag files can be initiated from F/frisbee's Diagnostic dialog.)

Does the same thing happen if you connect via ethernet instead of wireless? (Probably not, I expect.)
Richard

An afterthought: The change I made stops an every-15-second test of the connection status and recovery if the connection drops. So, the connection may not be as resilient as before. The change may have to come out because of that. R

Posted: **Sun 24 Mar 2013, 10:41**

rerwin wrote:http://www.murga-linux.com/puppy/viewto ... 212#693212
R

Hi Richard

Tested the above package on my laptop.

Seems to be working as designed for me.

My thoughts:

if you select "no" on initial install it seems a bit odd that you get both the "detecting devices" and "scanning for signals" popup messages but then get a screen with no detected signals and both wifi tick boxes disabled.

if after a "no" install I click the connect icon on the desktop and then deliberately choose to try Frisbee then it would be better if the 2 wifi tick boxes were enabled by default.

or...I agree with mavrothal that a "Scan for wifi" button which also enabled the 2 tick boxes would be a more intuitive interface.

Just "My Thoughts"
Cheers
PeeBee

Posted: **Mon 25 Mar 2013, 03:41**

peebee wrote:if you select "no" on initial install it seems a bit odd that you get both the "detecting devices" and "scanning for signals" popup messages but then get a screen with no detected signals and both wifi tick boxes disabled.

if after a "no" install I click the connect icon on the desktop and then deliberately choose to try Frisbee then it would be better if the 2 wifi tick boxes were enabled by default.

or...I agree with mavrothal that a "Scan for wifi" button which also enabled the 2 tick boxes would be a more intuitive interface.

Well...I caved. I see your point in that there should be no impediment to the first encounter of frisbee after installation. I now suppress the "scanning for signals" message, but keep the "detecting" message, which covers the long frisbee startup, whatever it is doing. The text is probably not accurate, but I am open to better text. I think frisbee is mainly preparing its dialogs.

I am still not completely satisfied with the "don't auto-connect" logic because it actually just does not start wpa_supplicant and thus does not display the available networks without connecting to the last-known network. I need to see if there is a way to start wpa_supplicant but prevent it from connecting.

Also, I was bothered by the tray icons in precise pup 5.5, so created replacements and added that package to the kit. The green added to the towers and ethernet cable indicate that the interfaces are "bound", which I interpret as meaning that they have IP addresses.

Thank you for your thoughts on this. Try version 20130324 at the usual place on page 15. More work to do for the don't-connect situation, in due time.
Richard

Posted: **Mon 25 Mar 2013, 23:10**

rerwin wrote:Try version 20130324 at the usual place on page 15. More work to do for the don't-connect situation, in due time.
Richard

All looks good to me - many thanks
Peebee

(old)Puppy Linux Discussion Forum

Frisbee Network Manager - Beta 2

Re: 5.5_kit test

Another frisbee update

Re: Another frisbee update

Re: Another frisbee update

Re: Another frisbee update