(old)Puppy Linux Discussion Forum

Frisbee is working again with the latest bash update version 4.3.27-1

Please send me the debug.log file or a pdiag containing it, or just post the content of the file if it is small. Thanks for your help with this.

Thank you, rerwin - I will try this when I get home.

Frisbee-1.3 Now Available
I have uploaded another version of the frisbee network manager, frisbee-1.3-20140930:
http://www.murga-linux.com/puppy/viewto ... 962#780962

The main improvements are further improvements to the main dialog "Connect" function, particularly a bug fix in connecting to the selected wireless network. The details are in the usual place at the above link.

I bumped the version to 1.3 because of the many upgrades to the button and field "greying out" and other bug fixes begun in 1.2.3, which constitute visible and operational improvements over 1.2.

Please report any regressions or annoyances, so that I might address them. Thank you for your continued interest in frisbee.

BTW, do not install the "debug" package on the previous page into "1.3", because it would "undo" some of the latest fixes. I suspect that the debug package is unlikely to find anything to log, due to one of the fixes in 1.2.3 -- and now 1.3 -- which appears to avoid the problem that would trigger the logging.
Richard

Hello, rerwin! Of course I was all ready to encounter the phenomenon, then it didn't happen. But tonight I installed your debug .pet and got the error message! The debug file contains:

add-profile - INTERFACE: wlan0 FLAGS: [ESS]
12866 add-profile - BSSID: '08:d0:9f:87:f5:a0' STATE: 'wpa_state=SCANNING' SSID: '' scan_results:
'bssid / frequency / signal level / flags / ssid'

I'll attach the pdiag tarball if it turns out to be useful. I'm using the original frisbee that came with slacko 5.6 and your updated dhcpcd for slacko. I'll try more updated versions of frisbee according to your comments above and see what happens.

Also, thank you for your explanation of what frisbee is doing in your earlier post. It's interesting - I often have clicked on a displayed network to connect to it, only to have the screen go blank & then repopulate networks bit by bit & never understood why that was happening. It's interesting!

stray_dog wrote:add-profile - INTERFACE: wlan0 FLAGS: [ESS]
12866 add-profile - BSSID: '08:d0:9f:87:f5:a0' STATE: 'wpa_state=SCANNING' SSID: '' scan_results:
'bssid / frequency / signal level / flags / ssid'

Thanks for trying the debug package. Your result confirms my suspicion that the "connect" logic looked for results while the periodic scan was in progress. Frisbee-1.2.3 and 1.3 should prevent that from happening.

In 1.3, if the scanning were to take a long time, then maybe the "connect" would see 'scanning'. If that happens we would see the new message "Network information for [interface] not available. Please try again to connect.". That would mean that I need to add logic to wait for any slow scanning. So, if anyone sees that message, please tell me about it.
Richard

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.

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.

I suppose it's interesting too, because 'authentication with xxxyyyzzz timed out' is a little weird considering it's an open wifi network with no need for authentication. Well, I should say, authentication as 'I' understand it. Which is pretty limited.

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

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

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 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!

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

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.

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

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

Dear rerwin, wow! I will definitely try these attached files you just uploaded. Thank you for putting those up!

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.

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.

Thank you for all your thought and work on this stuff. I'm grateful.

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

These paired versions of 1.3 and 6.5.0 have worked *really* well for me over the last several days.