Frisbee Network Manager - Beta 2

Configuration wizards, scanners, remote desktop, etc.
Message
Author
Scooby
Posts: 599
Joined: Sat 03 Mar 2012, 09:04

#331 Post by Scooby »

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

Code: Select all

[ "$(pidof wait-disconnect)" ] && killall wait-disconnect #140607
I leave in the procedure itself in case anyone in the future needs it. It does not hurt to just leave it there.
I was just curiuos what wait-disconnect were for, I agree it doesn't hurt to leave it but
I would rather understand it so I can know if I missed something
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

Scooby
Posts: 599
Joined: Sat 03 Mar 2012, 09:04

#332 Post by Scooby »

I made a disconcerting discovery.

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

but

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

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

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

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Status notifications

#333 Post by peebee »

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

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

Any ideas on how to investigate further please?
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Re: Status notifications

#334 Post by rerwin »

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

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Re: Status notifications

#335 Post by peebee »

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.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Dropwait in later versions of dhcpcd

#336 Post by rerwin »

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: Select all

grep 'lost temporarily' /var/log/messages
The message(s) will show the number of seconds of outage, rounded upward.

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

UPDATE 7/23/2014:
The packages attached here have now been superceded by those for dhcpcd-6.4.2, posted on the next page:
http://www.murga-linux.com/puppy/viewto ... 629#790629
Attachments
dhcpcd-6.3.2-patched_dropwait-upup.pet
For most puppies -
Last of the 6.3.x series - new dropwait function
dhcpcd-hooks in /lib/dhcpcd
dropwait maximum: 15 seconds
(115.82 KiB) Downloaded 248 times
dhcpcd-6.3.2-patched_dropwait-spup.pet
For Slacko puppies -
Last of the 6.3.x series - new dropwait function
dhcpcd-hooks in /usr/libexec
dropwait maximum: 15 seconds
(116.06 KiB) Downloaded 297 times
dhcpcd-5.6.8-patched_dropwait-upup.pet
last of the 5.6.x series - traditional dropwait function
dhcpcd-hooks in /lib/dhcpcd
(67.68 KiB) Downloaded 257 times
dhcpcd-5.6.8-patched_dropwait.tar.gz
source tarball
(123.67 KiB) Downloaded 240 times
Last edited by rerwin on Thu 24 Jul 2014, 01:04, edited 4 times in total.

Scooby
Posts: 599
Joined: Sat 03 Mar 2012, 09:04

#337 Post by Scooby »

Thank you rerwin

I downloaded source and built it here.

Will run it for a while and report back

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

The "Disable wireless network" works fine here now

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

Could it be extended from the max 5s to maybe 9s (or 8s)?
There does not appear to be a practical way around the 10-second timeout.
Maybe it could be upped to 20s so that dropwait can be 15s?

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

Where does messages like

Code: Select all

syslog(LOG_DEBUG, "%s: carrier briefly lost for %d seconds", ifname, i);
end up. in /tmp or /var/log

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


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

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#338 Post by rerwin »

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

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

Code: Select all

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

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

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

5. Bug or feature:
But when I wanted to checkout dropwait setting
and then hit cancel the value returned to 0 (was 5)
In my head I was just cancelling wanting to change dropwait at all
so is this intended?
I discovered that misbehavior, too, as I was experimenting. I will fix that in frisbee. Remember, I trusted that Jemimah knew what she was doing, so did not look for problems, but fixed issues that I or someone else found during usage of frisbee.

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

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

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#339 Post by Marv »

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

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

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

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

Thanks for supporting Frisbee and dhcpcd.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Scooby
Posts: 599
Joined: Sat 03 Mar 2012, 09:04

#340 Post by Scooby »

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

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#341 Post by rerwin »

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/viewto ... 191#789191
along with a command that should list (in a console) any messages about the carrier being resumed after a brief outage.

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#342 Post by Marv »

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

Code: Select all

# 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
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Scooby
Posts: 599
Joined: Sat 03 Mar 2012, 09:04

#343 Post by Scooby »

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?

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#344 Post by Marv »

@ 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 :? It has eluded me for quite a while now.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#345 Post by rerwin »

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

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#346 Post by Marv »

rerwin wrote:
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
Indeed, duration of my dropouts is 3 seconds. See below. Makes for an interesting testbed. The 6.3.2 spup versions continues to work well subjectively with the dropwait time set to 4 seconds for now.

Code: Select all

Jul 19 09:45:10 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:46:50 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:46:51 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:48:31 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:48:32 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Jul 19 09:50:12 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 2 seconds
Jul 19 09:50:13 puppypc23386 daemon.info dhcpcd[29460]: eth0: carrier lost temporarily for 1 seconds
Thank you :!:
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Scooby
Posts: 599
Joined: Sat 03 Mar 2012, 09:04

#347 Post by Scooby »

Code: Select all

> cat /var/log/everything/current | grep carrier
Jul 21 16:23:26 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:23:26 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:23:26 [dhcpcd] enp4s0: carrier acquired
Jul 21 16:23:26 [dhcpcd] enp4s0: carrier lost
Jul 21 16:25:49 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:25:49 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:27:01 [dhcpcd] enp4s0: waiting for carrier
Jul 21 16:27:01 [dhcpcd] wlp3s0: waiting for carrier
Jul 21 16:27:32 [dhcpcd] enp4s0: waiting for carrier
been running for a while( a couple of hours) with dropwait 5 sec

I never seem to get these messages

Code: Select all

syslog(LOG_INFO, "%s: carrier lost temporarily for %d seconds", ifname, i);
If I have dropwait set to 0 I get some carrier's lost
but with 5 secs I have not experienced any!?

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#348 Post by Marv »

If I set dropwait to 0 on the above system, no 'carrier temporarily lost' messages at all are generated but it forces a reconnect and renews the lease pretty much every minute or two. With a dropwait of 4 seconds, 'carrier temporarily lost' messages are logged every 108 seconds but dhcpcd waits them out as (I assume) it is supposed to do. Over several days now with dropwait set at 4 seconds and normal use, lid suspend, browsing, sfs creation etc., no reconnecting at all on this system. I'm running right now with dropwait of 0 and it's reconnected 4 times while I wrote this.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Hopefully nearly final versions of latest dhcpcd

#349 Post by rerwin »

Marv, Scooby and other dropwait users,
After much experimentation I have settled on my adaptation of dhcpcd, to provide some tolerance of carrier dropouts while also ensuring that disabling (disconnecting) wireless continues to work reliably as expected. My goal is to minimize the risk of any mods inadvertently impacting the complicated operation of dhcpcd. I have narrowed the purpose of dropwait to be only for ignoring short outages, so that any delays caused by dropwait are minimal, particularly for link terminations during boot-up that would slow the process.

Now that the developer has made more bug fixes to the 6.4.x version, I start with 6.4.2. However, I discovered that the releasing of a wireless link requires 11 seconds on my Pentium II (266 MHz) laptop, which I consider the "worse case" to support. My netbook require almost as long. Since a timeout limit of 10 seconds results in killing the release process, leaving the situation Scooby has reported regarding the IP address remaining in the network status report.

The attached "patched" version of dhcpcd-6.4.2 has the timeout increased to 15 seconds. I propose that that version be considered the standard version because it retains all of the original design. The "patched-dropwait" version is offered for those needing more tolerance for carrier dropouts of short duration. I selected a fixed value of 3 seconds based on Marv's report of a 1 second dropout followed by a 2-second one. For this version, I added 3 seconds to the increased timeout value. Both versions are suitable for all puppies -- they adapt themselves for slacko installations.

Because I discovered that the network tray icon and link notification popups did not work when the user disabled wireless, I include a fix in the pinstall script for both patched versions. Instead of using the RELEASE "hook" when a link is released, the STOP hook is now used. the network_tray and notify hook scripts did not respond to the STOP hook, so indicate the link is still up. The pinstall script updates those hook scripts, which need to be fixed in the woof versions of them.

In the source tarballs, I include the patch file that would convert an original dhcpcd to the modified version. I also include a "README-...wait" file with patch instructions and configuration commands. (I would like to add commands for 64-bit systems, if someone would give them to me.)

Please try these latest packages and tell me of any problems that make them unacceptable for general use. Thanks for your help.
Richard

EDIT - Additional details of this "dropwait" implementation:
  • 1. The two new or modified "info" messages are:
    • version 6.4.2-dropwait starting
      momentary carrier loss ignored
    2. The "-j --dropwait" option argument is eliminated. The user or developer uses either the standard dhcpcd or the "dropwait" version. The minimalist modifications to the original should avoid inadvertent impact to the operation of dhcpcd.

    3. The primary difference in behavior of the "disable wireless" (release) function since 5.6.4 appears to be that signal interruption of the daemon controlling the wifi link is limited, preventing the dropwait delay from being interrupted to release a link. I am reluctant to interfere with the developer's design, to try to enable interruption during the wait period.
UPDATE 7/25/2014: I repackaged the "pets" to make a separate set for use in Slacko puppies, rather than trying to be clever and make single, adaptable versions. The difference in the Slacko versions is that the "hook" files and script reside in /usr/libexec instead of /lib/dhcpcd. They function the same as the previous set with the workaround for slacko.

During testing of dhcpcd, using frisbee, I found some things to fix in frisbee-1.2, so will be uploading that shortly. With the new 6.4.2 dhcpcd, frisbee will no longer contain the button for setting the drop timeout value, because the value is fixed at 3 seconds. R
Attachments
dhcpcd-6.4.2-patched-i686.pet
"Standard" package - as released but with wait for daemon exit extended by 5 seconds.
(Not for slacko)
(112.44 KiB) Downloaded 266 times
dhcpcd-6.4.2-patched-slacko-i686.pet
For Slacko installations and any pups using dhcpcd-hooks in /usr/libexec.
"Standard" package - as released but with wait for daemon exit extended by 5 seconds.
(113.16 KiB) Downloaded 244 times
dhcpcd-6.4.2-patched-dropwait-i686.pet
Optional package for ignoring carrier dropouts up to 3 seconds.
(Not for slacko)
(112.57 KiB) Downloaded 248 times
dhcpcd-6.4.2-patched-dropwait-slacko-i686.pet
For Slacko installations and any pups using dhcpcd-hooks in /usr/libexec.
Optional package for ignoring carrier dropouts up to 3 seconds.
(127.33 KiB) Downloaded 283 times
Last edited by rerwin on Fri 25 Jul 2014, 23:34, edited 2 times in total.

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

dhcpcd-6.4.2-patched-dropwait-i686.pet testing

#350 Post by Marv »

Testing the above pet in X-slacko 2.1 on a Pentium M ipw2200 laptop, the identical setup used to sucessfully test the 6.3.2 spup dhcpcd with dropwait.
6.3.2 uninstalled, wireless disconnected, profile and resolv.conf deleted. 6.4.2 installed from pet, Frisbee used to reconnect. IP acquired correctly but resolv.conf not written so no DNS available. Rechecked with a reboot, with and without the resolv.conf stub (no nameservers) in place with the same results. Switched back to 6.3.2 after uninstalling 6.4.2. Resolv.conf immediately created and correct. Back to 6.4.2 again. Same result as before. Dropouts seem to be handled fine, just no resolv.conf. Copying in a resolv.conf or using a resolv.conf.head gets it going. Posting running with it now.

The tar.gz attached contains a sample of the dropout handling and a dhcpcd log snippet for 6.3.2 and 6.4.2.

Anything else I should try or log for now?

Edited once, added 'copy in resolv.conf and running now' stuff
Attachments
dhcpcdlogs.tar.gz
two dhcpcd log snips and a temp dropout sample
(1.31 KiB) Downloaded 252 times
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Post Reply