Project

General

Profile

Bug #3497

udp/gsmtap multicast is broken osmo-bts-virtual and virtphy

Added by dexter over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
-
Target version:
-
Start date:
08/23/2018
Due date:
% Done:

100%

Spec Reference:

Description

Unfortunately libosmocore change I4a8ffb8d598aca88801a4a0322944d7cdd8d4047 introduced than SO_REUSEADDR should be disabled when IPPROTO_UDP is used. Under normal conditions this makes sense and is also necessary to detect when two processes try to use the same port but for multicast situations like we have them with osmo-bts-virtual, virtphy and gsmtap in general this becomes a problem.

Associated revisions

Revision 73196e77 (diff)
Added by dexter over 2 years ago

socket: add flag to enforce SO_REUSEADDR on UDP sockets

When IPPROTO_UDP is used then SO_REUSEADDR omitted since UDP is
connection less we do not have to wait until lingering connections time
out. There were also negative effects such as that two applicatications
could use the same UDP port, normally one of the two applications would
get an error, but with SO_REUSEADDR this is supressed. However, there
are applications (UDP MULTICAST) where two applications must be able to
use the same port. In the osmocom project those are osmo-bts-virtual,
virtphy and gsmtap in general.

Lets introduce a flag that the API user can supply in order to have
SO_REUSEADDR applied.

- Add new flag OSMO_SOCK_F_UDP_REUSEADDR

Change-Id: I94aaf6d5224ab23bde5ea5c4a83569b6145ab32b
Related: OS#3497

Revision 0e11bea2 (diff)
Added by dexter over 2 years ago

osmo_mcast_sock: make sure SO_REUSEADDR is applied

osmo-bts-virtual uses UDP multicast to communicate with its virtphy
counterpart. At the momemnt SO_REUSEADDR is not applied for those
multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This
makes prevents the proper function of UDP multicast.

- Make sure OSMO_SOCK_F_UDP_REUSEADDR is set

Change-Id: I7f27758b7aa786c8dbae669cbcde10baab8e4845
Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497

Revision b8a91625 (diff)
Added by dexter over 2 years ago

gsmtap_util: make sure SO_REUSEADDR is applied for GSMTAP

When gsmtap adding a new sink it does not supply OSMO_SOCK_F_UDP_REUSEADDR
in order to have SO_REUSEADDR applied. In most cases, the gsmtap sink is
just receiving packets to toss them immediately, so having one of them
is sufficient. However, in other use cases - particularly virt_phy -
we actually want to receve and process GSMTAP messages via multicast
Applying SO_REUSEADDR (like we did before disabling it globally for UDP
in I4a8ffb8d598aca88801a4a0322944d7cdd8d4047 on August 1st) resolves
the issue.

Change-Id: I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497

History

#1 Updated by dexter over 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 90

socket.c has now an additional flag (OSMO_SOCK_F_UDP_REUSEADDR) that the user can pass in order to restore the old behavior. Since we do not have much applications that use multicast I think this is a good compromise. Unfortunately it was not possible to set SO_REUSEADDR after calling the osmo_sock... API. This is because the the function would exit with an error. SO_REUSEADDR must be set before the bind(). Also using a flag looks cleaner to me than to modify the socket parameters by hand after the api-call.

See also:
https://gerrit.osmocom.org/#/c/libosmocore/+/10587 socket: add flag to enforce SO_REUSEADDR on UDP sockets
https://gerrit.osmocom.org/#/c/libosmocore/+/10588 gsmtap_util: make sure SO_REUSEADDR is applied for GSMTAP
https://gerrit.osmocom.org/#/c/osmo-bts/+/10589 osmo_mcast_sock: make sure SO_REUSEADDR is applied
https://gerrit.osmocom.org/#/c/osmocom-bb/+/10590 osmo_mcast_sock: make sure SO_REUSEADDR is applied

#2 Updated by dexter over 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

All the patches are through. Also I did not observe any new problems. The communication between osmo-bts-virtual and virtphy looks fine.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)