[libnice] udp ttl on windows

[Philip Withnall]

On Mon, 2014-10-27 at 13:00 +0100, Emanuele Bizzarri wrote:
> Hi,
> I moved on 0.1.8 so should be easy for you make the needed
> modifications.
> In my response I have also added all the steps needed to make this
> version compilable under windows and vc2010 (in addition to
> README.win32)

Thanks for the instructions, but I don’t have a copy of Visual Studio,
and I feel that if I try and replicate your changes to commit them to
master I will muck something up.

Would you be able to provide a git formatted patch of your changes to
the VS project please? I can then get that reviewed and committed so
everyone can benefit.

Though I have a few questions below…

> 5. replace all inline with __inline

Why is this necessary? What error do you get if you don’t do it? All the
uses of ‘inline’ in libnice have previously included glib.h, which
(through glib/gutils.h) redefines ‘inline’ as ‘__inline’ on Windows.

> 13.replace into stun_debug_bytes (debug.c):
> //char bytes[prefix_len + 2 + (len * 2) + 1];
> with:
> char bytes[1000];//ema
> and replace snprintf with _snprintf

I’ve attached a patch which should fix this problem properly. Can you
please test it and let me know if it works? If so, I’ll push it to
master. Thanks.

> Attached you can find log and wireshark.
> 
> I can reproduce the problem.
> The point start from:
> ** (ewmcu_console.exe:4932): DEBUG: component_io_cb: 020EA018:
> received -2 valid messages with 0 bytes
> 
> In my previous test, using the modified code I saw that the reason why
> the receive function returns -2 is:
> 10:08:45.063: ema g_socket_receive_message Error receiving message:
> The connection has been broken due to keep-alive activity detecting a
> failure while the operation was in progress.: 0
> 
> If you set ttl=255, the problem disappears.

So from the log, it looks like you’re getting a decent amount of traffic
in before it fails, but I can’t see any useful information about the
timeout, so it must all be in the kernel rather than on the wire. :-(

I wonder if we should perhaps treat that error (Windows socket error
10052) as transient, and ignore it. If there is a real network problem,
the STUN timeouts will catch it.

Olivier, Youness, what do you think?

Philip

> On 24/10/2014 18:24, Philip Withnall wrote:
> 
> > Hi,
> > 
> > On Thu, 2014-10-23 at 15:10 +0200, Emanuele Bizzarri wrote:
> > > I've implemented  the content of nice_debug (agent-priv.h), in order
> > > to have a log:
> > You shouldn’t have to do that. Just make sure you’re not defining NDEBUG
> > in CPPFLAGS anywhere, and the default implementation of nice_debug() in
> > debug.c should be used automatically.
> > 
> > > I found that this kind of error is related to ttl settings.
> > > The default value on my windows machine is 128.
> > That’s weird, and as you say, a TTL of 128 should be high enough for
> > anything.
> > 
> > Could you possibly attach a full libnice log (run your program with
> > NICE_DEBUG=all G_MESSAGES_DEBUG=all after compiling it with NDEBUG
> > undefined) and a Wireshark log of the problem please? If they’re big,
> > please e-mail them to me personally rather than the entire list.
> > 
> > Thanks,
> > Philip
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-stun-Use-sprintf-instead-of-snprintf-to-support-VS-2.patch
Type: text/x-patch
Size: 1422 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141030/463563a2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141030/463563a2/attachment.sig>