Feature #5503


expose GPRS user plane via tun device

Added by laforge 10 months ago. Updated 10 days ago.

OsmocomBB mobile (host)
Target version:
Start date:
Due date:
% Done:


Spec Reference:


In order to expose the GPRS user plane data from within LLC/SNDCP to the host system running OsmocomBB, we should create a tun device. The local IP and point-to-point peer IP should be configured based on the information received from the network during PDP context establishment.

Actions #1

Updated by laforge 7 months ago

  • Tags set to ARDC
Actions #2

Updated by pespin 2 months ago

  • Description updated (diff)
Actions #3

Updated by pespin 2 months ago

After speaking with fixeria , we agreed so far that this can be done in a new program under osmocom-bb/src/host/layer23/src/modem.

The use case for such a program, as far as I understand, should be:
  • Receive a C0 arfcn as input parameter
  • Tune and Sync to the C0 ARFCN (L1CTL towards osmo-ms-trx?)
  • Send a RACH.req asking for a UL TBF assignment
  • Wait for ImmAss on AGCH/PCH, and retrieve from there the PDCH ARFCN+TS
  • Change to the PDCH ARFCN/TS waiting to receive matching USF
  • Do GPRS Attach REq+Resp+...
  • CreatePDPContextReq+Resp
  • Once CreatePDPContextResp is received, create the tun device with the info provided from the network
  • Start forwarding IP traffic over the tun interface IP <-> SNDCP <-> LLC <-> RLC/MAC <-> L1CTL <-> osmo-ms-trx <- Um -> BTS/PCU

As a first step, the main app can simply encode a few hardcoded GMM messages drectly into LLC and send LLC over UDP to osmo-sgsn. Same goes for data, hardcode an ICMP echo req and encapsulate it over SNDCP and LLC and send to osmo-sgsn.

Actions #4

Updated by Hoernchen 2 months ago

I am somewhat surprised that you are discussing this, since you both are working on the rlcmac/lower parts, and the "gmm" side was left for me?

Actions #5

Updated by pespin 2 months ago

first thing I did this morning before starting was asking for feedback on jabber regarding state of different parts, in order to coordinate (and I'm still waiting for it).

My impression when reading the "tasks" wiki was that you still had stuff to do on the lowest side of things, and since fixeria is actively wroking on the RLC/MAC side of things I though I'd start filling holes from LLC up the stack.

In any case, I don't see what's wrong with writing down and discuss stuff so that we all agree on what needs to be done.

So far I prepared a skeleton modem app so that we can all work on top of it as needed:

If you are already working on something upper layers please let us know.

Actions #6

Updated by laforge 2 months ago

On Mon, Nov 21, 2022 at 04:54:42PM +0000, pespin wrote:

In any case, I don't see what's wrong with writing down and discuss stuff so that we all agree on what needs to be done.

Indeed. The most important part is to make sure we have a plan, and we all agree on the plan. The plan is not "Developer X works on Z" but the plan is a technical plan. The three wiki pages we discussed one week ago are the starting point of that plan.

Actions #7

Updated by pespin 17 days ago

  • Assignee set to pespin

I plan to work on this together with VTY support to configure the tun, as discussed with fixeria, while he finishes some lower GRR parts (trxcon).

Actions #8

Updated by pespin 17 days ago

  • Status changed from New to In Progress
Actions #9

Updated by pespin 17 days ago

  • % Done changed from 0 to 30

Initial tun support (with some config taken from VTY) has been submitted here:
remote: layer23: Introduce APN VTY node [NEW]
remote: layer23: Introduce netdev.{c,h} [NEW]
remote: layer23: Introduce tun.{c,h} [NEW]

This is by no means a complete implementation, since it still needs to interact with other parts which are also WIP (SDNCP) or even not yet started (GMM).
Still it already provides the first pieces to have the tun created according to VTY config per APN.

Actions #10

Updated by pespin 14 days ago

  • % Done changed from 30 to 50

After code review I was requested to move part of the code to some shared library so that stuff like tun can be reused.
Here it is: Introduce netdev API Introduce netns API Introduce tundev API

Updated commits in osmocom-bb using the above mentioned APIs:
remote: layer23: Introduce APN VTY node
remote: layer23: Initial integration of tun device
remote: Depend on libosmo-gprs-{llc,sndcp}
remote: modem: Initial integration of libosmo-gprs-{llc,sndcp}

Actions #11

Updated by pespin 10 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 50 to 80

Waiting for review of libosmocore.git and osmoco-bb.git patches.
Patches currently support tundev with netns, set ifupdown, set address, set route all with netlink internally.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)