Frisbee Network Manager - Beta 2
Thank *you*, rerwin! Tried frisbee 1.3-20140930 this morning, saw no error message at all so far. I'll keep using this version and will take note of what happens.
- Attachments
-
- pdiag-20141002.tar.gz
- (147.87 KiB) Downloaded 310 times
Dear rerwin but I should probably say Richard because you sign your messages that way,
Wow, this whole thing continues to fascinate me. So tonight, I came home, used your most recent frisbee 1.3 with the patched dhcpcd for slacko, to get on the web to do some $$ stuff. The connection was immediate. When I was done, I wanted to go surf and have some browsing fun with the news and such, so I rebooted, installed the same stuff in the same order, and ... and ... and I'm waiting ... and waiting ... and I thought this is weird, it worked instantly a minute ago. So I ran the pdiag and looked at the interactive mode (love that, by the way) and lo and behold, I saw something interesting. I'm trying to connect to an open university network with numerous AP's in my scanning range. Since there are several in range that I can see, I want the closest one with the best signal - especially because tonight it's raining and damn. In the frisbee gui, I pick one particular one I want. Then when I look at the interactive mode, and I notice it's not just trying to contact the particular AP I want, not just the particular bssid I selected, but it's cycling through all the bssid's with the common ssid CaseGuest, in different frequencies. Trying one, timeout, try another, timeout, try another, timeout. I thought gosh, this is really interesting, because it's doing something that kind of makes sense, but I didn't ask it to do it, and would in fact prefer to choose a particular access point closest with least amount of noise, instead of one further away.
I'm not exactly sure what this means for coding, but I thought I would mention it and post the logs & stuff if it could be helpful. I uninstalled 1.3 and reloaded 1.2-20140724 with the patched dhcpcd for slacko and tried again for connection with the same AP. Connection was immediate. I'm not sure what it means, but I hope it can help some.
Here's one moment of output in interactive mode, you can see the switching between bssid's:
wpa_cli v1.0
Copyright (c) 2004-2012, Jouni Malinen <j@w1.fi> and contributors
This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.
Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.
Interactive mode
<3>WPS-AP-AVAILABLE
<3>Trying to associate with 08:d0:9f:87:f5:af (SSID='CaseGuest' freq=5180 MHz)
<3>Authentication with 08:d0:9f:87:f5:af timed out.
<3>WPS-AP-AVAILABLE
<3>Trying to associate with f4:7f:35:38:0d:10 (SSID='CaseGuest' freq=2437 MHz)
<3>Authentication with f4:7f:35:38:0d:10 timed out.
<3>WPS-AP-AVAILABLE
<3>Trying to associate with f4:7f:35:38:0d:10 (SSID='CaseGuest' freq=2437 MHz)
<3>Authentication with f4:7f:35:38:0d:10 timed out.
<3>WPS-AP-AVAILABLE
<3>Trying to associate with 08:d0:9f:87:f5:af (SSID='CaseGuest' freq=5180 MHz)
<3>Authentication with 00:00:00:00:00:00 timed out.
>
interesting because the AP I asked for was bssid 08:do:9f:87:f5:a0
Alright - cheers, puppy people.
Wow, this whole thing continues to fascinate me. So tonight, I came home, used your most recent frisbee 1.3 with the patched dhcpcd for slacko, to get on the web to do some $$ stuff. The connection was immediate. When I was done, I wanted to go surf and have some browsing fun with the news and such, so I rebooted, installed the same stuff in the same order, and ... and ... and I'm waiting ... and waiting ... and I thought this is weird, it worked instantly a minute ago. So I ran the pdiag and looked at the interactive mode (love that, by the way) and lo and behold, I saw something interesting. I'm trying to connect to an open university network with numerous AP's in my scanning range. Since there are several in range that I can see, I want the closest one with the best signal - especially because tonight it's raining and damn. In the frisbee gui, I pick one particular one I want. Then when I look at the interactive mode, and I notice it's not just trying to contact the particular AP I want, not just the particular bssid I selected, but it's cycling through all the bssid's with the common ssid CaseGuest, in different frequencies. Trying one, timeout, try another, timeout, try another, timeout. I thought gosh, this is really interesting, because it's doing something that kind of makes sense, but I didn't ask it to do it, and would in fact prefer to choose a particular access point closest with least amount of noise, instead of one further away.
I'm not exactly sure what this means for coding, but I thought I would mention it and post the logs & stuff if it could be helpful. I uninstalled 1.3 and reloaded 1.2-20140724 with the patched dhcpcd for slacko and tried again for connection with the same AP. Connection was immediate. I'm not sure what it means, but I hope it can help some.
Here's one moment of output in interactive mode, you can see the switching between bssid's:
wpa_cli v1.0
Copyright (c) 2004-2012, Jouni Malinen <j@w1.fi> and contributors
This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.
Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.
Interactive mode
<3>WPS-AP-AVAILABLE
<3>Trying to associate with 08:d0:9f:87:f5:af (SSID='CaseGuest' freq=5180 MHz)
<3>Authentication with 08:d0:9f:87:f5:af timed out.
<3>WPS-AP-AVAILABLE
<3>Trying to associate with f4:7f:35:38:0d:10 (SSID='CaseGuest' freq=2437 MHz)
<3>Authentication with f4:7f:35:38:0d:10 timed out.
<3>WPS-AP-AVAILABLE
<3>Trying to associate with f4:7f:35:38:0d:10 (SSID='CaseGuest' freq=2437 MHz)
<3>Authentication with f4:7f:35:38:0d:10 timed out.
<3>WPS-AP-AVAILABLE
<3>Trying to associate with 08:d0:9f:87:f5:af (SSID='CaseGuest' freq=5180 MHz)
<3>Authentication with 00:00:00:00:00:00 timed out.
>
interesting because the AP I asked for was bssid 08:do:9f:87:f5:a0
Alright - cheers, puppy people.
- Attachments
-
- pdiag-20141003.tar.gz
- (148.84 KiB) Downloaded 303 times
stray_dog,
Thanks for your report. Coincidentally, I have seen similar behavior when trying to connect to an open guest account on a router that requires a password to get in. It does not appear to prompt for the password -- and does not connect, even though there are other indications of a connection. That searching for other APs for the same SSID is probably related to that password problem -- if your guest network requires a password.
First, tell me whether you are expected to enter a password for the guest account. That would reveal whether the password prompt is where the problem lies, or if it is all open networks that would show the problem. Since the network I have access to is mine to control, I can test both cases. I did not take time to pursue the issue because I thought it might be related to the router's confusing behavior. Your report suggests that is not the problem.
I am eager to resolve that issue.
Richard
Thanks for your report. Coincidentally, I have seen similar behavior when trying to connect to an open guest account on a router that requires a password to get in. It does not appear to prompt for the password -- and does not connect, even though there are other indications of a connection. That searching for other APs for the same SSID is probably related to that password problem -- if your guest network requires a password.
First, tell me whether you are expected to enter a password for the guest account. That would reveal whether the password prompt is where the problem lies, or if it is all open networks that would show the problem. Since the network I have access to is mine to control, I can test both cases. I did not take time to pursue the issue because I thought it might be related to the router's confusing behavior. Your report suggests that is not the problem.
I am eager to resolve that issue.
Richard
Good morning, rerwin - you're welcome, no problem. It's interesting! So - with this guest account, we're definitely not expected to enter a password. I have gone over to my grocery store cafe where they provide free wifi, it's wpa protected and they post the password on the wall for anyone to enter as desired. When doing that, connection was very fast. But with this CaseGuest network, no password is needed. I haven't yet had the chance to test this on other networks that don't require passwords, but I think we have one of those at work, so I can try that one out, too.
stray_dog,
I have now tested with my guest network with confusing results. But first, I need to clarify what I meant by "password" with open networks. Actually, it is a "login ID" that you see when you first use your browser on the guest account. I got confused about that detail, so kept expecting to be prompted for it before opening a browser.
The confusing part: initially I could not connect to the guest account in that it would not provide an IP address, so the icon would not show as connected. I tried with several versions of frisbee (20140724, 20140912 and 1.3). None worked. Then I tried precise-5.7.1 which connected at bootup (so the guest account must have been the last one I used). After that, when I went back to the others -- all of them with lupusuper2 -- the guest account connected every time! Maybe the precise run woke up the router, which then remembered my wireless MAC address; I'm just guessing, here.
Back at home, I changed my router to "no encryption" and connected right away. Each of the tests initially deleted the guest profile, to create a new one on the next "connect."
I am puzzled. Maybe there is something special about the initial contact -- at least after the router (with the guest account) gets rebooted. That's a test for another day.
Richard
I have now tested with my guest network with confusing results. But first, I need to clarify what I meant by "password" with open networks. Actually, it is a "login ID" that you see when you first use your browser on the guest account. I got confused about that detail, so kept expecting to be prompted for it before opening a browser.
The confusing part: initially I could not connect to the guest account in that it would not provide an IP address, so the icon would not show as connected. I tried with several versions of frisbee (20140724, 20140912 and 1.3). None worked. Then I tried precise-5.7.1 which connected at bootup (so the guest account must have been the last one I used). After that, when I went back to the others -- all of them with lupusuper2 -- the guest account connected every time! Maybe the precise run woke up the router, which then remembered my wireless MAC address; I'm just guessing, here.
Back at home, I changed my router to "no encryption" and connected right away. Each of the tests initially deleted the guest profile, to create a new one on the next "connect."
I am puzzled. Maybe there is something special about the initial contact -- at least after the router (with the guest account) gets rebooted. That's a test for another day.
Richard
Rerwin, hello - hmm, interesting! I do like confusing results and mysteries, sometimes. It's interesting you mentioned that difference between password and login id. The main open unencrypted network I use the most requires neither, which was what prompted my curiosity in the first place, about why it would ask for an ssid sometimes. Sure, I've seen public networks where you had to enter an id and password that were the same, like 'cma' and 'cma' or whatever.
I'm not sure I can help too much, but I have had experiences where I was on the web with an ok connection, decided to get off and do a hard rfkill with a hardware switch. The information about the default network was left in Frisbee, and I would let the screensaver go on overnight, just to get up in the morning, turn the rfkillswitch back on, to have Frisbee automatically and immediately connect to the network (and bssid/access point) last used.
The main thing I notice just from what we've talked about so far is that if I select an access point broadcasting open unencrypted wifi with no need for id or password, try to connect to it, it drops from the window of scanned access points immediately, and then as I watch Frisbee rescan, networks come back, and then more come back, then when my chosen network is detected, it usually connects then. It's as if, after a scan, by asking to connect, it has to scan again, wait for results, then the handshake. Which takes time. If I get sick of waiting and try to connect again while the scanning/associating process hasn't finished, then (if I'm using the older version of Frisbee) it will ask me for an ssid. It seems with version 1.3, it scans fast, finds the access point I prefer fast, but 2 seconds or so is not long enough for the handshake to happen, so it skips on to the next access point with the same ssid name, which isn't long enough, so it skips on to the next one, and the next one, etc. etc.
Ok. Yea, let's test more! Very curious.
I'm not sure I can help too much, but I have had experiences where I was on the web with an ok connection, decided to get off and do a hard rfkill with a hardware switch. The information about the default network was left in Frisbee, and I would let the screensaver go on overnight, just to get up in the morning, turn the rfkillswitch back on, to have Frisbee automatically and immediately connect to the network (and bssid/access point) last used.
The main thing I notice just from what we've talked about so far is that if I select an access point broadcasting open unencrypted wifi with no need for id or password, try to connect to it, it drops from the window of scanned access points immediately, and then as I watch Frisbee rescan, networks come back, and then more come back, then when my chosen network is detected, it usually connects then. It's as if, after a scan, by asking to connect, it has to scan again, wait for results, then the handshake. Which takes time. If I get sick of waiting and try to connect again while the scanning/associating process hasn't finished, then (if I'm using the older version of Frisbee) it will ask me for an ssid. It seems with version 1.3, it scans fast, finds the access point I prefer fast, but 2 seconds or so is not long enough for the handshake to happen, so it skips on to the next access point with the same ssid name, which isn't long enough, so it skips on to the next one, and the next one, etc. etc.
Ok. Yea, let's test more! Very curious.
I haven't run into the error message this week at all. Connected this morning just fine without a lot of going from bssid to bssid. Posting diagnostics. Experienced one odd thing - connection dropped for a second, and since I had closed the Frisbee window, I thought I'd click on the desktop icon to connect and open it again, to see what was up. But then, I got a notification that Frisbee was already running. It was like, once I opened Frisbee for the first time and closed it, I couldn't re-open it without killing the first instance of Frisbee running. This is a new phenomenon with 1.3. Interesting!
- Attachments
-
- pdiag-20141012.tar.gz
- (147.81 KiB) Downloaded 300 times
stray_dog,
Note that frisbee stays locked until all of its windows are closed, not just the main frisbee window. Were the "Manage saved profiles" and "Diagnostics" windows also closed?
To avoid that problem, I could add logic to close those windows whenever the main window is closed. But that could get messier than we think. So, we need to decide whether that is worth doing.
Richard
Note that frisbee stays locked until all of its windows are closed, not just the main frisbee window. Were the "Manage saved profiles" and "Diagnostics" windows also closed?
To avoid that problem, I could add logic to close those windows whenever the main window is closed. But that could get messier than we think. So, we need to decide whether that is worth doing.
Richard
Patch for Slacko 5.7.0 for network status notification
Slacko 5.7.0, and possibly earlier versions, do not display the "gtkdialog-splash" notifications of the progress of connecting to wired and wireless networks. This is due to the incorrect placement of the 99-notify.conf file in the directory used by non-slacko distributions. The attached package moves that file to the correct directory, thus restoring the notifications.
The package can be uninstalled without "undoing" the move.
The package can be uninstalled without "undoing" the move.
- Attachments
-
- dhcpcd_slacko_hook_fix-20141010.pet
- Fix for Slacko only. Moves the dhcpcd hook 99-notify.conf from /lib/dhcpcd/ to the correct directory for Slacko,
/usr/libexec. - (464 Bytes) Downloaded 295 times
Last edited by rerwin on Sun 12 Oct 2014, 19:20, edited 1 time in total.
dhcpcd "dropwait" update
Attached are new versions of dhcpcd with the "DropWait" feature added, which tolerates brief connection dropouts of up to 3 seconds.
There are versions for Lucid, Slacko and all other pups beginning with Precise pup, as well as the source tarball with additional files related to building it for puppy. Note that releases after 6.4.3 could not be compiled by Lucid Pup without some risky changes. The Lucid variant was compiled in Lucid Pup; the others were compiled in Precise Pup 5.7.1.
UPDATE 10/19/2014: Re-uploaded the source tarballs with minor corrections to the README-dropwait files section on how to create an upgraded version of a future version of dhcpcd. Added the 'pinstall.sh' file to the set of files to propagate to a future source package; corrected numbering. The compilations are unchanged. Added new "workaround" package to prevent interference during hotplugging of a wireless device, which would start wpa_supplicant for the new device, in conflict with SNS/netwiz control of only one connection; it adds a "nohook" entry for the hook file into /etc/dhcpcd.conf.
UPDATE 3/7/2015: I have uploaded several versions of dhcpcd-6.7.1 and its source code here:
http://www.murga-linux.com/puppy/viewto ... 546#832546
There are versions for Lucid, Slacko and all other pups beginning with Precise pup, as well as the source tarball with additional files related to building it for puppy. Note that releases after 6.4.3 could not be compiled by Lucid Pup without some risky changes. The Lucid variant was compiled in Lucid Pup; the others were compiled in Precise Pup 5.7.1.
UPDATE 10/19/2014: Re-uploaded the source tarballs with minor corrections to the README-dropwait files section on how to create an upgraded version of a future version of dhcpcd. Added the 'pinstall.sh' file to the set of files to propagate to a future source package; corrected numbering. The compilations are unchanged. Added new "workaround" package to prevent interference during hotplugging of a wireless device, which would start wpa_supplicant for the new device, in conflict with SNS/netwiz control of only one connection; it adds a "nohook" entry for the hook file into /etc/dhcpcd.conf.
UPDATE 3/7/2015: I have uploaded several versions of dhcpcd-6.7.1 and its source code here:
http://www.murga-linux.com/puppy/viewto ... 546#832546
- Attachments
-
- dhcpcd_6.x_wpa_workaround-20141019.pet
- Patch to avoid use of new wpa_supplicant "hook" script.
- (578 Bytes) Downloaded 513 times
-
- dhcpcd-6.5.0-patched-dropwait-i686.pet
- For distributions Precise Pup and other non-slacko distributions.
- (122.96 KiB) Downloaded 422 times
-
- dhcpcd-6.5.0-patched-dropwait-slacko-i686.pet
- For Slacko distributions and others with dhcpcd-hooks in /usr/libexec.
- (123.7 KiB) Downloaded 433 times
-
- dhcpcd-6.4.3-patched-dropwait-lucid-i686.pet
- For Lucid Pup variant
- (125.88 KiB) Downloaded 410 times
Last edited by rerwin on Sun 08 Mar 2015, 22:34, edited 5 times in total.
dhcpcd "exitwait" update
Attached are new versions of the dhcpcd with the extended timeout value for lost connections. This is not the "dropwait" variant, but is only the released version with 8 seconds added to the period that allows the running dhcpcd process to end.
There are versions for Lucid, Slacko and all other pups beginning with Precise pup, as well as the source tarball with additional files related to building it for puppy. Note that releases after 6.4.3 could not be compiled by Lucid Pup without some risky changes.
UPDATE 10/19/2014: Re-uploaded the source tarballs with minor corrections to the README-dropwait files section on how to create an upgraded version of a future version of dhcpcd. Added the 'pinstall.sh' file to the set of files to propagate to a future source package; corrected numbering. The compilations are unchanged. Added new "workaround" package to prevent interference during hotplugging of a wireless device, which would start wpa_supplicant for the new device, in conflict with SNS/netwiz control of only one connection; it adds a "nohook" entry for the hook file into /etc/dhcpcd.conf.
UPDATE 3/7/2015: I have uploaded several versions of dhcpcd-6.7.1 and its source code here:
http://www.murga-linux.com/puppy/viewto ... 546#832546
There are versions for Lucid, Slacko and all other pups beginning with Precise pup, as well as the source tarball with additional files related to building it for puppy. Note that releases after 6.4.3 could not be compiled by Lucid Pup without some risky changes.
UPDATE 10/19/2014: Re-uploaded the source tarballs with minor corrections to the README-dropwait files section on how to create an upgraded version of a future version of dhcpcd. Added the 'pinstall.sh' file to the set of files to propagate to a future source package; corrected numbering. The compilations are unchanged. Added new "workaround" package to prevent interference during hotplugging of a wireless device, which would start wpa_supplicant for the new device, in conflict with SNS/netwiz control of only one connection; it adds a "nohook" entry for the hook file into /etc/dhcpcd.conf.
UPDATE 3/7/2015: I have uploaded several versions of dhcpcd-6.7.1 and its source code here:
http://www.murga-linux.com/puppy/viewto ... 546#832546
- Attachments
-
- dhcpcd_6.x_wpa_workaround-20141019.pet
- Patch to avoid use of new wpa_supplicant "hook" script.
(Duplicate of same-named package in previous message for the "dropwait" group) - (578 Bytes) Downloaded 388 times
-
- dhcpcd-6.5.0-patched-i686.pet
- For Precise Pup and other non-slacko distributions.
- (122.84 KiB) Downloaded 418 times
-
- dhcpcd-6.5.0-patched-slacko-i686.pet
- For Slacko Pup only. (Also, any other distros with dhcpcd-hooks in /usr/libexec.)
- (123.58 KiB) Downloaded 405 times
-
- dhcpcd-6.4.3-patched-lucid-i686.pet
- For Lucid Pup only.
- (125.77 KiB) Downloaded 406 times
Last edited by rerwin on Sun 08 Mar 2015, 22:28, edited 4 times in total.
Dear rerwin, wow! I will definitely try these attached files you just uploaded. Thank you for putting those up!
Thank you for all your thought and work on this stuff. I'm grateful.
Yea, actually I *thought* closed the diagnostics & manage profiles windows first, then the main Frisbee window. I got the notification it was already running after clicking on the 'connect' icon. But today, I cannot reproduce the phenomenon unless I purposefully leave one of those windows open. So I think since I can't seem to reproduce it, I *must* have left one of those windows open without realizing it. So I think, adding logic to close windows, nah, I think that's not necessary.Note that frisbee stays locked until all of its windows are closed, not just the main frisbee window. Were the "Manage saved profiles" and "Diagnostics" windows also closed? To avoid that problem, I could add logic to close those windows whenever the main window is closed. But that could get messier than we think. So, we need to decide whether that is worth doing.
Thank you for all your thought and work on this stuff. I'm grateful.
Bugfix frisbee package 1.3.1 uploaded
I have posted an update to frisbee to restore the ability to switch between network managers. When I changed the name of the initialization script to frisbee.sh, I missed changing the name in the script for switching out of frisbee. That prevented the other managers from starting successfully. The update is frisbee-1.3.1, at the usual place:
http://www.murga-linux.com/puppy/viewto ... 962#780962
I also added a package for the updated dhcpcd versions, above on this page, to address the presence of the relatively new "hook script" that may start wpa_supplicant outside of the control of any of puppy's network managers, specifically when a wifi device is "hot plugged" in. It tells dhcpcd to skip running that new script. Because frisbee has its own configuration file, the "1.3.1" version also now skips running the script. Since all of the puppy network managers were designed without that hook script, it should not be necessary; my testing found no impact from skipping that hook.
If any of the network managers are modified to utilize the new hook script, then the "unhook" line for wpa_supplicant in the relevant dhcpcd.conf file should be removed.
For the dhcpcd upgrades, I made minor changes to the README-exitwait/dropwait files, to get them right, in the source code tarballs. I wanted to be sure the instructions for updating a new release of dhcpcd are complete. That does not affect the result of compilation and installation from the source packages.
I hope this gets frisbee and dhcpcd to a point where no more fixes are needed for a while. But definitely notify me if there are any "showstoppers".
Richard
http://www.murga-linux.com/puppy/viewto ... 962#780962
I also added a package for the updated dhcpcd versions, above on this page, to address the presence of the relatively new "hook script" that may start wpa_supplicant outside of the control of any of puppy's network managers, specifically when a wifi device is "hot plugged" in. It tells dhcpcd to skip running that new script. Because frisbee has its own configuration file, the "1.3.1" version also now skips running the script. Since all of the puppy network managers were designed without that hook script, it should not be necessary; my testing found no impact from skipping that hook.
If any of the network managers are modified to utilize the new hook script, then the "unhook" line for wpa_supplicant in the relevant dhcpcd.conf file should be removed.
For the dhcpcd upgrades, I made minor changes to the README-exitwait/dropwait files, to get them right, in the source code tarballs. I wanted to be sure the instructions for updating a new release of dhcpcd are complete. That does not affect the result of compilation and installation from the source packages.
I hope this gets frisbee and dhcpcd to a point where no more fixes are needed for a while. But definitely notify me if there are any "showstoppers".
Richard
Editing earlier post. With these updated dhcpcd's for slacko, I'm getting the fastest connection results with frisbee and peasywifi. Taking some time to try the different options correctly, I've been getting really good results. It's really working well for me. Thank you - very much.
Last edited by stray_dog on Tue 04 Nov 2014, 10:50, edited 1 time in total.
up/dn status of wireless?
i just upgraded to slacko 5.7 from 5.6 yesterday to try to fix a problem i was having with fldigi - BUT
i like 5.7 except the network_tray icon doesnt work. it never changes. i got onto this thread & think this is the proper place to ask this question:
i see how you are working hard to solve the entire intricate problem, and that it has been elusive over a substantial period of time.
PERSONALLY, and i think i am speaking for many of us - the ONLY thing i care about on the wireless monitor icon, is whether the link is UP or DOWN. i don't need to see the blinkenlights for up/download.
Would it be trivial to produce an app that only gave up/down indication?
right now, my icon says 'dead' all the time. useless.
i applaud and appreciate your hard work & await your reply
regards
lars.
i like 5.7 except the network_tray icon doesnt work. it never changes. i got onto this thread & think this is the proper place to ask this question:
i see how you are working hard to solve the entire intricate problem, and that it has been elusive over a substantial period of time.
PERSONALLY, and i think i am speaking for many of us - the ONLY thing i care about on the wireless monitor icon, is whether the link is UP or DOWN. i don't need to see the blinkenlights for up/download.
Would it be trivial to produce an app that only gave up/down indication?
right now, my icon says 'dead' all the time. useless.
i applaud and appreciate your hard work & await your reply
regards
lars.
belay my last
i apologize for my last post. while the symptom was accurate, and i thought i had narrowed down the issue, this morning i noticed in the icon folder that there were a bunch of strange symlinks, and lots of things were linked to ethernet-active.svg, but ethernet-active.svg was the 'dead' icon for some strange reason. anyway, when i cleaned up the links, and put an appropriate image for ethernet-active.svg, it does what i want now, ie shows up/dn state of (wireless) link. it still does not blink with activity, but as i said last night that doesnt bother me (at least for now).
i have loaded so many pets trying to fix this problem and pulled files from my backup of 5.6 slacko, that i can't tell you where the links got messed up, or if i was somehow responsible (i don't see how, but i suppose it's possible).
if anything regarding my recent experience here is useful to you let me know & i will post, otherwise i'm back in quiet monitoring mode of this thread.
thanks & regards
lars.
i have loaded so many pets trying to fix this problem and pulled files from my backup of 5.6 slacko, that i can't tell you where the links got messed up, or if i was somehow responsible (i don't see how, but i suppose it's possible).
if anything regarding my recent experience here is useful to you let me know & i will post, otherwise i'm back in quiet monitoring mode of this thread.
thanks & regards
lars.
-
B.K. Johnson
- Posts: 807
- Joined: Mon 12 Oct 2009, 17:11
rerwin/Richard,
you will find here:
http://www.murga-linux.com/puppy/viewto ... 748#806748
my complaint about xpupsay's big ugly windows used for notifications in the version of frisbee imstalled in tahrpup-6.0 CE.
In your revisions of jemimah's original work, have you addressed this (I haven't had the time to go through the thread) or do you plan to? If you agree that it is tacky, then I think as the maintainer the change should come from your group, with assistance from the spup crew of course. Ir would benefit all kennels.
B.K. Johnson
you will find here:
http://www.murga-linux.com/puppy/viewto ... 748#806748
my complaint about xpupsay's big ugly windows used for notifications in the version of frisbee imstalled in tahrpup-6.0 CE.
In your revisions of jemimah's original work, have you addressed this (I haven't had the time to go through the thread) or do you plan to? If you agree that it is tacky, then I think as the maintainer the change should come from your group, with assistance from the spup crew of course. Ir would benefit all kennels.
B.K. Johnson
Wireless Status
Is this the right place to ask?...
I'm using Frisbee on LXPUP and it works fine apart from one thing...
When booting up, the initial status of the wireless networking is OFF and I need to click the Frisbee networking control and choose Enable Wireless after which it connects and everything is fine.
Now I'm configuring this machine (Acer Aspire One netbook) for my mother (who is in her late 80s) and she won't cope with having to turn the wireless on manually each time it boots up.
So surely there is some way of booting up with it already enabled?
I'm using Frisbee on LXPUP and it works fine apart from one thing...
When booting up, the initial status of the wireless networking is OFF and I need to click the Frisbee networking control and choose Enable Wireless after which it connects and everything is fine.
Now I'm configuring this machine (Acer Aspire One netbook) for my mother (who is in her late 80s) and she won't cope with having to turn the wireless on manually each time it boots up.
So surely there is some way of booting up with it already enabled?