Re: [pupnp-devel] GENA timeouts

[Marcelo R. J. <mar...@gm...>]

Jean-Francois,

I don't need to be convinced that there is an issue. I do believe you in
this matter. On the other hand, I must be convinced that your patch, when
it is ready to be applied, does fix an issue. These are two different
things.

I no longer have the time resources to test stuff, especially in
non-trivial configurations. The least I would need to perform any test is a
full detail step by step procedure on how to reproduce it. Even then, if
the procedure does not involve an easy to setup scenario, I doubt I could
have enough time to perform it. Rest assured, I am deeply sorry for that,
but there is not much I can do about it.

In spite of my limited time resources for this project, I can still find
some time to read code. If you show me that your future patch fixes an
issue and if, maybe after some normal e-mail discussion, I come to agree
with you, I will commit your patch without testing it myself and I will
believe that you did the necessary tests. If anything goes wrong and other
people complain, we can always revert it. If no one complains for a few
weeks, your patch will make it to the next release. The project has been
working like this for a long time due to the lack of active developers.

I will wait for your patch and hope that you can fix the issue. Thank you
for your time, your collaboration on this project will be much appreciated.

Regards,
Marcelo.

On Fri, Jan 30, 2015 at 6:11 PM, Jean-Francois Dockes <jf...@do...> wrote:

> Marcelo Roberto Jimenez writes:
>  > Jean-Francois,
>  >
>  > I would certanly review your patch and commit it if you convince me it
>  > does fix an issue.
>  >
>  > Please use "git format-patch" to generate the patch and send it on the
> patch
>  > tracker in the sourceforge site.
>
> Ok, then I'll try to work on something.
>
> If you want be convinced that there is an issue (apart from the fact that
> this is the second time that this is reported, this time is just to make
> the earlier solution accessible to people with standard Linux packages),
> you need to test.
>
> For this you need one event-generating libupnp-based device (a vanilla
> libupnp of course, not one configured with the earlier fix), and 2 control
> points (not necessarily based on libupnp). Connect both, then block the
> port for incoming events on the first one. Something like the following
> should work on Ubuntu, or use an equivalent on your flavor of firewall:
>
>     sudo ufw default allow
>     sudo ufw deny <port number here>
>     sudo ufw enable
>
> The important point is to silently drop connections, not explicitely reject
> them (this would cause no wait on the device).
>
> You'll see the 2nd control point stop updating after a few seconds. If you
> restart it, you'll see that it can't connect to the device, which is
> "asleep", as all (or too many) libupnp threads are stuck in connect()
> calls.
>
> If you unblock the port, after a while (30 S to a few minutes), you should
> see the control points come back alive.
>
> In real life, this does occur in a number of situations, either because of
> a buggy CP (yes this exists), or because of network issues. Of course this
> is only of importance for devices for which multiple CPs make sense, like
> OpenHome devices (but some of them could be pure displays).
>
> Regards,
>
> jf
>
>