Failed to set TOS for UDP Socket

[cort]

Hello -- I'm getting an error message when I run murmur:

Server: Failed to set TOS for UDP Socket

 

Subsequent client connections also give an error indicating that UDP isn't working:

UDP packets cannot be received from the server. Switching to TCP mode.

I assume this is undesirable. :)

Any ideas why the server might be failing to initialize UDP? I'm running Mumble/Murmer 1.2.3 on OSX Snow Leopard, on the default port (64738). Any help would be appreciated; thanks!

- cort

[kissaki]

Well, if your server can’t initialize UDP correctly, no wonder ppl. connected to it won’t be able to use UDP.

For the actual problem, I dunno.

[cort]

Yes, I understand that the error on the client is clearly related to the error on the server. I mentioned it because the server's error message doesn't necessarily scream "hey, UDP totally failed to initialize!"; to somebody unfamiliar with the details of network protocols, it sounded like it could just be a warning.

So, yeah, it's the server error I'm curious about. I'm sure the client error will take care of itself :)

[ngollan]

Check if the server or another application is listening on the UDP port. The server should report "Failed to bind UDP Socket to " when binding fails, so I guess that's not the real issue.

[cort]

Yeah, I don't see any messages about failing to bind the socket. In fact, the previous log message seems to indicate that the socket was bound successfully:

2011-02-21 09:49:24.730 1 => Server listening on [::]:64738

2011-02-21 09:49:24.733 1 => Server: Failed to set TOS for UDP Socket

Having done a little bit of research, it doesn't sound like failing to set the TOS bits for UDP should be a fatal error. TOS is just a way for packets to provide hints to routers as to how they should be handled (maximize reliability, minimize delay, etc.) Now I'm suspicious whether the server's TOS error and the client's TCP fallback error are actually related...

[mkrautz]

Failing to set the TOS bit is not a fatal error.

There's an issue that I identified late in the 1.2.3 cycle (and decided to wait to fix until 1.2.4 because it seemingly has been present since 1.2.0, without anyone complaining :-)). I didn't want to jump to conclusions before I had more time to play with it.

Here's what happens:

1. Murmur binds the TCP socket to [::].

2. It uses getsockname(2) on the TCP socket to get the address to bind the UDP socket to.

3. The call to getsockname returns an IPv6-mapped IPv4 address, more specifically, ::ffff:0:0. (i.e. 0.0.0.0)

Since clients are unable to connect via UDP to the same address that they use for TCP, UDP traffic won't go through. (The TCP address is an IPv6 address, the UDP address is an IPv4 address.)

So UDP listening doesn't actually fail, which is why Murmur doesn't warn about it. It just listens on an unexpected address.

As a workaround you can specify your hosts manually, using the host= field in the ini. Note that it takes multiple addresses to listen on (say, host="192.168.1.50 10.0.0.20")

I've not yet tried to poke around with the bug enough to suggest a sound fix yet, but the workaround will work.

[cort]

Thanks, that workaround works like a charm!