Jump to content
Mumble forums

Failed to set TOS for UDP Socket


cort
 Share

Recommended Posts

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

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...