OsmocomBB

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.

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

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?

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.

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.

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.

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.

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

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.