[Dillo-dev] Starting dpis on FreeBSD: blackhole(4) timeouts

[Jorge Arellano Cid]

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