Feature #5503
closedexpose GPRS user plane via tun device
Added by laforge over 2 years ago. Updated 15 days ago.
100%
Description
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.
Related issues
Updated by pespin over 1 year 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.
Updated by Hoernchen over 1 year 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?
Updated by pespin over 1 year ago
Hi,
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:
https://gerrit.osmocom.org/c/osmocom-bb/+/30260
If you are already working on something upper layers please let us know.
Updated by laforge over 1 year 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.
Updated by pespin over 1 year 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).
Updated by pespin over 1 year ago
- % Done changed from 0 to 30
Initial tun support (with some config taken from VTY) has been submitted here:
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/30992 layer23: Introduce APN VTY node [NEW]
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/30993 layer23: Introduce netdev.{c,h} [NEW]
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/30994 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.
Updated by pespin over 1 year 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:
https://gerrit.osmocom.org/c/libosmocore/+/31019 Introduce netdev API
https://gerrit.osmocom.org/c/libosmocore/+/31024 Introduce netns API
https://gerrit.osmocom.org/c/libosmocore/+/31025 Introduce tundev API
Updated commits in osmocom-bb using the above mentioned APIs:
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/30992 layer23: Introduce APN VTY node
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/30996 layer23: Initial integration of tun device
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/30999 Depend on libosmo-gprs-{llc,sndcp}
remote: https://gerrit.osmocom.org/c/osmocom-bb/+/31007 modem: Initial integration of libosmo-gprs-{llc,sndcp}
Updated by pespin over 1 year 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.
Updated by pespin over 1 year ago
With osmocom-bb patches now in gerrit (https://gerrit.osmocom.org/c/osmocom-bb/+/32590) I can already set the IP address (IPv4 only tested) allocated by the network.
Updated by pespin over 1 year ago
I submitted a couple more patches which improve APN lifecycle, uses proper NSAPI and LLC SAPI and also brings up the tunnel interface after setting the allocated IP address on it:
https://gerrit.osmocom.org/c/osmocom-bb/+/32596
https://gerrit.osmocom.org/c/osmocom-bb/+/32597/
After that, I can use ping in the netns created to ping the GGSN IP address. The IP packets are correctly entering the tunnel and getting into "modem" app which feeds it to the SNDCP layer.
However, there seems to be still some problem in the SNDCP layer (described in comments in https://gerrit.osmocom.org/c/osmocom-bb/+/32597/) where the TLLI is still not known at the "modem" app and hence it is still using a hardcoded TLLI. As a result, the SNDCP is unable to find the related MS (SME) and fails to push below the PDU.
Updated by pespin over 1 year ago
pespin wrote in #note-13:
I submitted a couple more patches which improve APN lifecycle, uses proper NSAPI and LLC SAPI and also brings up the tunnel interface after setting the allocated IP address on it:
https://gerrit.osmocom.org/c/osmocom-bb/+/32596
https://gerrit.osmocom.org/c/osmocom-bb/+/32597/
Merged.
However, there seems to be still some problem in the SNDCP layer (described in comments in https://gerrit.osmocom.org/c/osmocom-bb/+/32597/) where the TLLI is still not known at the "modem" app and hence it is still using a hardcoded TLLI. As a result, the SNDCP is unable to find the related MS (SME) and fails to push below the PDU.
Fixed by:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32635
https://gerrit.osmocom.org/c/libosmo-gprs/+/32636/
https://gerrit.osmocom.org/c/osmocom-bb/+/32637
Updated by pespin about 1 year ago
Some notes I wrote to fixeria regarding permissions required by the modem app due to having to configure the tun interface:
One cannot fully run the modem app as unprivileged user like we do in osmo-ggsn with systemd .netdev, .network and .service files to create the tun interface.
In osmo-ggsn, we can do so because we apply a statically known IP address in osmo-ggsn tun device, so we can write that IP address in the system .network file.
However, with the modem app, we cannot do that, because the local IP address to apply to the tun device is not known prior to starting the process and retrieving it from the GSM network.
Hence, it is the modem app which has to set the IP address on the tunnel.
In order for a process to set an IP address (as well as other iface config like MTU) on the iface, it must have the CAP_NET_ADMIN capability. Hence, it is possible to run the modem app without root user, but it must have the CAP_NET_ADMIN capability set.
Running with an unpriviledged user but with the CAP_NET_ADMIN capability can be accomplished in 2 ways:
- Setting the CAP_NET_ADMIN capability on the binary with "setcap".
- Configuring the modem app systemd .service file (not provided in the repo so far) to add the capability to the process, using something like CapabilityBoundingSet=CAP_NET_ADMIN or AmbientCapabilities=CAP_NET_ADMIN
Regarding privileges, the modem app also requires some other privileges in order to set up real time scheduling priority through the VTY, which is encouraged in order to avoid potential delays transmitting blocks.
Updated by fixeria 11 months ago
- Related to Feature #6115: modem: MTU not set properly on tun iface added