Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 02 Sep 2014, 21:19
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Network
Frisbee Network Manager - Beta 2
Post new topic   Reply to topic View previous topic :: View next topic
Page 23 of 25 [363 Posts]   Goto page: Previous 1, 2, 3, ..., 21, 22, 23, 24, 25 Next
Author Message
Scooby

Joined: 03 Mar 2012
Posts: 305

PostPosted: Sun 08 Jun 2014, 16:29    Post subject:  

rerwin wrote:
wait-disconnect issue I handle by changing the line, killall wait-disconnect, to avoid the warning message:
Code:
[ "$(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

rerwin wrote:

-- 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
Back to top
View user's profile Send private message 
Scooby

Joined: 03 Mar 2012
Posts: 305

PostPosted: Tue 10 Jun 2014, 13:19    Post subject:  

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?
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 1403
Location: Malvern, Worcs, UK

PostPosted: Sat 12 Jul 2014, 04:37    Post subject: Status notifications  

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?

_________________
LxPup-14.03 = Puppy + LXDE
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Mon 14 Jul 2014, 10:25    Post subject: Re: Status notifications  

peebee wrote:
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
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 1403
Location: Malvern, Worcs, UK

PostPosted: Mon 14 Jul 2014, 12:57    Post subject: Re: Status notifications  

rerwin wrote:
peebee wrote:
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.

_________________
LxPup-14.03 = Puppy + LXDE
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Mon 14 Jul 2014, 19:30    Post subject: Dropwait in later versions of dhcpcd  

Scooby wrote:
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:
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/viewtopic.php?p=790629#790629
dhcpcd-6.3.2-patched_dropwait-upup.pet
Description  For most puppies -
Last of the 6.3.x series - new dropwait function
dhcpcd-hooks in /lib/dhcpcd
dropwait maximum: 15 seconds
pet

 Download 
Filename  dhcpcd-6.3.2-patched_dropwait-upup.pet 
Filesize  115.82 KB 
Downloaded  16 Time(s) 
dhcpcd-6.3.2-patched_dropwait-spup.pet
Description  For Slacko puppies -
Last of the 6.3.x series - new dropwait function
dhcpcd-hooks in /usr/libexec
dropwait maximum: 15 seconds
pet

 Download 
Filename  dhcpcd-6.3.2-patched_dropwait-spup.pet 
Filesize  116.06 KB 
Downloaded  22 Time(s) 
dhcpcd-6.3.2-patched_dropwait.tar.gz
Description  source tarball
dropwait max of 15 seconds
gz

 Download 
Filename  dhcpcd-6.3.2-patched_dropwait.tar.gz 
Filesize  200.47 KB 
Downloaded  19 Time(s) 
dhcpcd-5.6.8-patched_dropwait-upup.pet
Description  last of the 5.6.x series - traditional dropwait function
dhcpcd-hooks in /lib/dhcpcd
pet

 Download 
Filename  dhcpcd-5.6.8-patched_dropwait-upup.pet 
Filesize  67.68 KB 
Downloaded  18 Time(s) 
dhcpcd-5.6.8-patched_dropwait.tar.gz
Description  source tarball
gz

 Download 
Filename  dhcpcd-5.6.8-patched_dropwait.tar.gz 
Filesize  123.67 KB 
Downloaded  18 Time(s) 

Last edited by rerwin on Wed 23 Jul 2014, 21:04; edited 4 times in total
Back to top
View user's profile Send private message 
Scooby

Joined: 03 Mar 2012
Posts: 305

PostPosted: Tue 15 Jul 2014, 13:48    Post subject:  

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)?
Quote:

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:
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?
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Tue 15 Jul 2014, 17:05    Post subject:  

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:
#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:
Quote:
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
Back to top
View user's profile Send private message 
Marv


Joined: 04 May 2005
Posts: 338
Location: SW Wisconsin

PostPosted: Tue 15 Jul 2014, 22:18    Post subject:  

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/viewtopic.php?p=789100#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.

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.1, Lxpup 14.07, and not to forget trusty Carolina/Carolite (now with 3.15 kernel). All lean and steady pups.
Back to top
View user's profile Send private message 
Scooby

Joined: 03 Mar 2012
Posts: 305

PostPosted: Wed 16 Jul 2014, 14:55    Post subject:  

rerwin wrote:
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
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Wed 16 Jul 2014, 22:09    Post subject:  

Scooby,
I did not read your comment as being critical of Jemimah. I was only defending myself regarding not having caught the "cancel" bug already. I just had never noticed it.

Now, when I fix that bug I can also edit the text about the maximum dropwait time, in some backward-compatible way.

I have followed your recommendations to make the message LOG_INFO and the max 15 seconds. To do that, I add the dropwait maximum time to the timeout wait for the "release" signal, SIGALRM. I expect no harm is done by waiting excessively for non-wireless releases before timing out. If I am wrong, I can add a loop or other logic to shorten the wait time in that case.
EDIT: After sleeping on it, I think I need to re-do the added wait time, to avoid impacting the non-wireless timeout performance. I plan to merely extend the loop count for the current tenth-second tests for release completion.

The updated files are here:
http://www.murga-linux.com/puppy/viewtopic.php?p=789191#789191
along with a command that should list (in a console) any messages about the carrier being resumed after a brief outage.
Back to top
View user's profile Send private message 
Marv


Joined: 04 May 2005
Posts: 338
Location: SW Wisconsin

PostPosted: Thu 17 Jul 2014, 18:20    Post subject:  

Running the updated 6.3.2 spup version in X-slacko 2.1. It's handling the dropouts gracefully as can be done, but just for a snort, here's the record of lost connections from this ipw2200 1.6GHz Pentium M Fujitsu S6230 laptop. Excellent signal strength, ipw2200 v3.1.5 firmware, router independent. Fairly typical of for this class machine. Shows what I thought was happening. A loss of connection almost exactly every 108 seconds Confused

Code:
# grep 'lost' /var/log/messages
Jul 17 16:51:31 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:53:19 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:55:07 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:56:55 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 16:58:42 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 17:00:30 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 17:02:17 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost
Jul 17 17:04:04 puppypc23386 daemon.info dhcpcd[5770]: eth0: carrier lost

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.1, Lxpup 14.07, and not to forget trusty Carolina/Carolite (now with 3.15 kernel). All lean and steady pups.
Back to top
View user's profile Send private message 
Scooby

Joined: 03 Mar 2012
Posts: 305

PostPosted: Fri 18 Jul 2014, 12:40    Post subject:  

Marv's message got me thinking and looking at code

Am I right in my conclusion that dropwait is only active for wifi and not ethernet?

Is your wireless adapter denoted as "eth0" Marv?
Back to top
View user's profile Send private message 
Marv


Joined: 04 May 2005
Posts: 338
Location: SW Wisconsin

PostPosted: Fri 18 Jul 2014, 14:10    Post subject:  

@ Scooby,

Yes, the wireless interface on these laptops is eth0. I'll toggle this one back and forth from 0 to 15 secs and look at it. I know the older ones did work with this interface. Ipw2200 wireless was basically useless on the newer kernels due to the dropouts above with the dropwait time at 0, and usable if a bit irky with the dropwait time at 15. What I really need to do is figure out the why of the regular dropouts Confused It has eluded me for quite a while now.

_________________
tweaked 412 based boxpup, well honed 'lina-lite-005, alphaOS 321 Wink , X-slacko 2.1, Lxpup 14.07, and not to forget trusty Carolina/Carolite (now with 3.15 kernel). All lean and steady pups.
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Fri 18 Jul 2014, 21:40    Post subject:  

Scooby wrote:
Am I right in my conclusion that dropwait is only active for wifi and not ethernet?

Is your wireless adapter denoted as "eth0" Marv?
You are correct. But the test is not for eth? versus wlan?. I don't know how dhcpcd makes the determination, which should not depend on the interface name prefix.

I have continued experimenting with a 5.6.8 version of dhcpcd as well as 6.3.2. Both versions have the new timeout logic, necessitating the extension of the timeout period. I have concluded that, despite the dropwait delay, the kernel detects the loss of carrier and starts a closure process. I suspect that it waits about 10 seconds before "unauthorizing", making longer dropwaits ineffective.

In testing, the repeated 1-second checks for a resumed carrier seem effective. But now I see that the "disable wireless" test still fails to completely kill the interface. If the carrier somehow resumes -- or was slow in being stopped, the carrier loss is ignored and the dhcpcd release logic does not execute. "Back to the drawing board" to sort that out -- again.

Regarding Marv's regular 108-second dropouts, I have seen postings (outside of the puppy forum) about routers doing that. I think the solution was to updates its firmware. But that does not apply to Marv's standalone connection without a router. So, I am clueless about that.

BTW, thank you, Marv, for joining our dropwait session and reporting your testing. It sounds like the new 1-second-apart carrier checks are just what you need, if your dropouts last only a few seconds. Now, if could only figure out Scooby's "disable wireless" solution.
Richard
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 23 of 25 [363 Posts]   Goto page: Previous 1, 2, 3, ..., 21, 22, 23, 24, 25 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Network
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1304s ][ Queries: 12 (0.0115s) ][ GZIP on ]