- Dillo-dev - lists.mailman3.com

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Tue, Feb 09, 2010 at 06:24:48PM +0100, Johannes Hofmann wrote: > On Mon, Feb 08, 2010 at 02:16:08PM -0300, Jorge Arellano Cid wrote: > > On Sun, Feb 07, 2010 at 07:15:59PM +0100, Johannes Hofmann wrote: > > > On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > > > > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > > > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > > > > bf wrote: > > > > > > > > Because blackhole(4) is a common security measure, and because this > > > > > > > > problem did not exist under the previous dpi framework, it must be > > > > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > > > > thinking on what we would do for Minix? > > > > > > > > > > > > At some point in time Minix 3 will have to implement UDS. > > > > > > In the meanwhile they can use the version with inet sockets. > > > > > > > > > > What shall we do about this TCP blackhole issue? > > > > > Should we try to switch back to UDS before release? > > > > > > > > Sorry for the delayed answer Johannes (I was out of the city). > > > > > > > > IMO, UDS before the release is too risky. It will need lots of > > > > testing time. > > > > > > Just came to the same conclusion ... > > > > > > > > > > I believe we may choose the solution bf has found > > > > to work better as workaround, make a patch with it and release. A > > > > few times in the past I rushed a "better" solution into an rc, > > > > only to learn not to do it! :) > > > > > > What patch exactly would you propose? I see > > > > > > * increasing dpid_idle_timeout > > > * adding a linger variable > > > * and a shell wrapper to start dillo > > > > a dpid_linger dillorc variable would save the user the trouble > > of re-compiling, but it would add the burden of prefs parsing in > > dpid. So, I'd say centinel solution could work: > > > > e.g. "touch ~/.dillo/DPID_LINGER" > > > > and dpid acting accordingly. > > > > Also a mention of the shell wrapper script in the README, with > > a link to a working example in our site would do the rest. An > > entry in the FAQ could help too. > > Jorge, as you might have seen already I committed a different fix > after reproducing the issue here on my system. Yes. When back home, I started answering email, then saw the patch ;-) > Please check it in the repo: > http://hg.dillo.org/dillo/rev/3a159d7e5098 +1 I think the committed solution is much better. My only concern with this type of solution is that it fails when the dpid gets hung (and then "kill -9" doesn't help). Maybe adding an unlink() call in dpidc's stop part is worth the effort. That way "dpidc stop" would always clear the centinel. ... but checking whether dpid is still alive after dpibye, killing it and thence going after each dpi with a kill signal looks like overkill (pun intended!) to me. ;) > * \todo what is the most portable way to ignore the signo > argument of without generating a warning? Is "int signo __unused" > gcc specific? a_Http_ccc() uses this nice trick: (void)Data2; /* suppress unused parameter warning */ -- Cheers Jorge.-

Feb. 9, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by Johannes.Hofmann＠gmx.de

On Mon, Feb 08, 2010 at 02:16:08PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 07, 2010 at 07:15:59PM +0100, Johannes Hofmann wrote: > > On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > > > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > > > bf wrote: > > > > > > > Because blackhole(4) is a common security measure, and because this > > > > > > > problem did not exist under the previous dpi framework, it must be > > > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > > > thinking on what we would do for Minix? > > > > > > > > > > At some point in time Minix 3 will have to implement UDS. > > > > > In the meanwhile they can use the version with inet sockets. > > > > > > > > What shall we do about this TCP blackhole issue? > > > > Should we try to switch back to UDS before release? > > > > > > Sorry for the delayed answer Johannes (I was out of the city). > > > > > > IMO, UDS before the release is too risky. It will need lots of > > > testing time. > > > > Just came to the same conclusion ... > > > > > > > I believe we may choose the solution bf has found > > > to work better as workaround, make a patch with it and release. A > > > few times in the past I rushed a "better" solution into an rc, > > > only to learn not to do it! :) > > > > What patch exactly would you propose? I see > > > > * increasing dpid_idle_timeout > > * adding a linger variable > > * and a shell wrapper to start dillo > > a dpid_linger dillorc variable would save the user the trouble > of re-compiling, but it would add the burden of prefs parsing in > dpid. So, I'd say centinel solution could work: > > e.g. "touch ~/.dillo/DPID_LINGER" > > and dpid acting accordingly. > > Also a mention of the shell wrapper script in the README, with > a link to a working example in our site would do the rest. An > entry in the FAQ could help too. Jorge, as you might have seen already I committed a different fix after reproducing the issue here on my system. Please check it in the repo: http://hg.dillo.org/dillo/rev/3a159d7e5098 Cheers, Johannes

Feb. 9, 2010

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by onepoint＠starurchin.org

On Sun, Feb 07, 2010 at 09:10:44AM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 04, 2010 at 06:32:29PM +0000, Jeremy Henty wrote: > > On Wed, Feb 03, 2010 at 08:07:13AM +0000, corvid wrote: > > > > > > I've been wondering whether it is possible to check dpid and the > > > dpis as well. [...] > > > > [...] > > The tricky thing is identifying the process - currently I just > > slurp the whole output before doing anything, by which time the > > dpi might have died. It might be better to process it > > line-by-line so I can check the process table right away. That > > would need a little re-engineering. Or maybe it would be better > > to replace the dpis with wrappers that run valgrind? > > I'd definitely try with wrappers! I think you're right. It's a little kludgy but at least it's robust - you know for sure which program the output is from and you don't get scrambled results from multiple processes writing to the same stream. Regards, Jeremy Henty

Feb. 9, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by corvid＠lavabit.com

I wrote: > Thomas wrote: > > one feature I motivated is not interacting as it should. > > It is the middle-click pasting into the browser window to trigger loading of the pasted URL, activated via > > > > middle_click_drags_page=NO > > > > in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. Please try the attached patch...

Feb. 9, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sun, Feb 07, 2010 at 07:15:59PM +0100, Johannes Hofmann wrote: > On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > > bf wrote: > > > > > > Because blackhole(4) is a common security measure, and because this > > > > > > problem did not exist under the previous dpi framework, it must be > > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > > thinking on what we would do for Minix? > > > > > > > > At some point in time Minix 3 will have to implement UDS. > > > > In the meanwhile they can use the version with inet sockets. > > > > > > What shall we do about this TCP blackhole issue? > > > Should we try to switch back to UDS before release? > > > > Sorry for the delayed answer Johannes (I was out of the city). > > > > IMO, UDS before the release is too risky. It will need lots of > > testing time. > > Just came to the same conclusion ... > > > > I believe we may choose the solution bf has found > > to work better as workaround, make a patch with it and release. A > > few times in the past I rushed a "better" solution into an rc, > > only to learn not to do it! :) > > What patch exactly would you propose? I see > > * increasing dpid_idle_timeout > * adding a linger variable > * and a shell wrapper to start dillo a dpid_linger dillorc variable would save the user the trouble of re-compiling, but it would add the burden of prefs parsing in dpid. So, I'd say centinel solution could work: e.g. "touch ~/.dillo/DPID_LINGER" and dpid acting accordingly. Also a mention of the shell wrapper script in the README, with a link to a working example in our site would do the rest. An entry in the FAQ could help too. -- Cheers Jorge.-

Feb. 8, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sun, Feb 07, 2010 at 05:04:18PM +0000, corvid wrote: > Jorge wrote: > > With regard to UDS, it can be scheduled into the repo shortly > > after the release; Thereafter users can help us polish it from > > there. > > Do you expect that you will have time to do it yourself? Yes. > Would it make sense to make a 2.2.1 with just the uds dpi changes and > nothing else that isn't rather trivial? I guess it'll be UDS plus other things as the testing period needs to extend around a few weeks. -- Cheers Jorge.-

Feb. 8, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by corvid＠lavabit.com

Thomas wrote: > one feature I motivated is not interacting as it should. > It is the middle-click pasting into the browser window to trigger loading of the pasted URL, activated via > > middle_click_drags_page=NO > > in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. I'll take a look at this. Can you add it to the bug tracker?

Feb. 8, 2010

dillo-2.2-rc2

by thomas-forum＠orgis.org

Am Mon, 8 Feb 2010 12:52:50 +0100 schrieb Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Please give it a try and report back soon. > The intention is to release dillo-2.2 this week. This is not specific to dillo-2.2, and should not hinder the release, I guess, but I have to admit that one feature I motivated is not interacting as it should. It is the middle-click pasting into the browser window to trigger loading of the pasted URL, activated via middle_click_drags_page=NO in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. I say that here just to have it mentioned... not blaming anyone but myself. But perhaps someone of you guys has an easy fix available for that? Of course one fix could be to drop the whole paste-in-window-for-URL thing but I rather like the feature... just not when I intended to paste into a form field. Also, note that the middle-click-drags-page mode is always a no-op for me as holding down the middle mouse button triggers scrolling mode via X11 anyway (a sensible setup for a Thinkpad with Trackpoint, or trackballs on desktop systems). Hm... regarding that... horizontal scroll events are not handled by dillo. One might need to investigate that in FLTK... Well, at least I have, after long time, given this little piece of feedback about the URL pasting... sorry that I didn't tell earlier, and sorry that I don't have a patch at hand. Alrighty then, Thomas.

Feb. 8, 2010

dillo-2.2-rc2

by Johannes.Hofmann＠gmx.de

Hello, I just made a new release candidate for our upcoming dillo-2.2 release. It mainly addresses the blackhole(4) timeouts reported in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-January/007247.html The rc2 tarball can be found as usual at: http://www.dillo.org/download/dillo-2.2-rc2.tar.bz2 SHA1: 38221d3499ce5f91a0c6a945a23b066e9e46ef84 Please give it a try and report back soon. The intention is to release dillo-2.2 this week. Cheers, Johannes

Feb. 8, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by Johannes.Hofmann＠gmx.de

On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > bf wrote: > > > > > Because blackhole(4) is a common security measure, and because this > > > > > problem did not exist under the previous dpi framework, it must be > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > thinking on what we would do for Minix? > > > > > > At some point in time Minix 3 will have to implement UDS. > > > In the meanwhile they can use the version with inet sockets. > > > > What shall we do about this TCP blackhole issue? > > Should we try to switch back to UDS before release? > > Sorry for the delayed answer Johannes (I was out of the city). > > IMO, UDS before the release is too risky. It will need lots of > testing time. Just came to the same conclusion ... > I believe we may choose the solution bf has found > to work better as workaround, make a patch with it and release. A > few times in the past I rushed a "better" solution into an rc, > only to learn not to do it! :) What patch exactly would you propose? I see * increasing dpid_idle_timeout * adding a linger variable * and a shell wrapper to start dillo > > With regard to UDS, it can be scheduled into the repo shortly > after the release; Thereafter users can help us polish it from > there. ok. Cheers, Johannes

Feb. 7, 2010