LimeSuite and friends in LInux Containers

Showing promise of maybe being able to bundle working systems (OpenBTS, osmosdr, oai) for delivery into linux containers (lxc) - after passing the LimeSDR thru to a test Ubuntu instance it shows up:

root@test:~# LimeUtil --find

  • [LimeSDR-USB, media=USB 3.0, module=STREAM, addr=1d50:6108, serial=0009060B00…]

I did try the snap system - using

# snap info limesdr-pothos
commands:

  • limesdr-pothos.PothosGui
  • limesdr-pothos.PothosUtil
  • limesdr-pothos.SoapySDRUtil

only to hit this:

# limesdr-pothos.SoapySDRUtil --find
######################################################
## Soapy SDR – the SDR abstraction library
######################################################

Init Error -99
Segmentation fault (core dumped)

which strace says is some kind of permissions thing

socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT) = -1 EPERM (Operation not permitted)
write(1, “Init Error -99\n”, 15Init Error -99
) = 15
— SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} —
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Even tho running as root and have the udev rules in place

/etc/udev/rules.d/64-limesuite.rules

At the present time there is no “hotplug” support in snapd and so you need to install with --devmode so that snaps can get access to the hardware.

Excellent - this is a snap!

# snap remove limesdr-pothos
limesdr-pothos removed

# snap install --devmode limesdr-pothos
limesdr-pothos 0.4.3.0 from ‘goq’ installed

# limesdr-pothos.SoapySDRUtil --find
######################################################
## Soapy SDR – the SDR abstraction library
######################################################
Found device 0
addr = 1d50:6108
driver = lime
label = LimeSDR-USB [USB 3.0]

# limesdr-pothos.SoapySDRUtil --probe
######################################################
## Soapy SDR – the SDR abstraction library
######################################################

Probe device
[INFO] Make connection: 'LimeSDR-USB [USB 3.0]

Success getting osmo-trx and OpenBTS running in a linux container (lxc)

That adds a lot of functionality for juggling multiple versions in isolation, taking snapshots and experimenting, reverting to known working snapshots, and also being able to export and import stripped down containers for distribution.

The LimeSDR just needs to be piped into a container with

$ lxc config device add <container> <limesdr> usb vendorid=1d50 productid=6108

and it’s available inside.

Verified - osmo-trx, OpenBTS, sipauthserve, smqueue and asterisk all running in a managable Linux Container. Next is to strip out everything not needed after the build, it’s over 3GB as it is and the osmocom uhd build instructions have you install everything + kitchenSink.

This is what we like to see for the first time GSM user:

Another one with the provisioned SIM gets the 1dbm test tone when you dial 2602 - so all that verifies smqueue, asterisk and sipauthserve are functioning.

There is ONE issue with smqueue running in an unprivileged container - it wants to change /proc/sys/fs/mqueue/msg_max and cannot, but that is not a show stopper if you do not expect to have >10 sms texts in flight, plus there’s a workaround.

1 Like

The container is stripped down best I could and still run - it’s 362M OpenBTSLimeSDR.tar.gz

If anyone is game to use it - I can upload somewhere - installs with this process -

$ lxc image import OpenBTSLimeSDR.tar.gz --alias OpenBTSLimeSDR_img
Image imported with fingerprint: 9f06e995f26332cdac536e446c3b6011bbca56e5326c281559872a737dc55736

Create the container:
$ lxc init OpenBTSLimeSDR_img OpenBTSLimeSDR
Creating OpenBTSLimeSDR

add device:
$ lxc config device add OpenBTSLimeSDR limesdr usb vendorid=1d50 productid=6108
Device limesdr added to OpenBTSLimeSDR

Start it up:
$ lxc start OpenBTSLimeSDR

$ lxc list
| OpenBTSLimeSDR | RUNNING | 10.209.139.70 (eth0) |

Get a shell inside and inject your ssh keys:
$ lxc exec OpenBTSLimeSDR bash
root@OpenBTSLimeSDR:~# cd /home/ubuntu/
root@OpenBTSLimeSDR:/home/ubuntu# vi .ssh/authorized_keys

exit and now you can login with keys:
$ ssh ubuntu@10.209.139.70

sudo, start a ‘screen’ (or just login another session) and launch osmo-trx:
root@OpenBTSLimeSDR:~# osmo-trx -f -b4 -s4

ctrl-a,d to disconnect from the ‘screen’ session and start the services:
root@OpenBTSLimeSDR:~# systemctl start sipauthserve
root@OpenBTSLimeSDR:~# systemctl start smqueue
root@OpenBTSLimeSDR:~# systemctl start asterisk
root@OpenBTSLimeSDR:~# systemctl start openbts

start the GSM Console:
root@OpenBTSLimeSDR:~# cd /OpenBTS
root@OpenBTSLimeSDR:/OpenBTS# ./OpenBTSCLI
OpenBTS Command Line Interface (CLI) utility
Copyright 2012, 2013, 2014 Range Networks, Inc.
Licensed under GPLv2.
Includes libreadline, GPLv2.
Connecting to 127.0.0.1:49300…
Remote Interface Ready.
Type:
“help” to see commands,
“version” for version information,
“notices” for licensing information,
“quit” to exit console interface.
OpenBTS> config GSM.Radio
GSM.Radio.ARFCNs 1 [default]
GSM.Radio.Band 900 [default]
GSM.Radio.C0 51 [default]
GSM.Radio.MaxExpectedDelaySpread 4 [default]
GSM.Radio.PowerManager.MaxAttenDB 0
GSM.Radio.PowerManager.MinAttenDB 0 [default]
GSM.Radio.RSSITarget -50 [default]
GSM.Radio.SNRTarget 10 [default]

1 Like

Nice work! We could put this on downloads.myriadrf.org. Will PM you.

Osmocom LimeSDR page just updated with pix and specs: https://osmocom.org/projects/osmotrx/wiki/LimeSDR_Family

Also verified the currently version specific LimeSuite/osmo-trx for OpenBTS works with running only those in the container, and the rest outside by binding to public IPs instead of localhost.

In the container, startup with, for example:
# osmo-trx -f -s4 -b4 -j 10.209.139.70 -i 192.168.1.226
-j ip to bind so that OpenBTS can connect, the container IP
-i ip of the BTS

and change OpenBTS to use it:
# sqlite3 /etc/OpenBTS/OpenBTS.db
sqlite> select * from CONFIG where KEYSTRING=‘TRX.IP’;
TRX.IP|127.0.0.1|1|0|IP address of the transceiver application. Static.
sqlite> select VALUESTRING from CONFIG where KEYSTRING=‘TRX.IP’;
127.0.0.1
sqlite> update CONFIG set VALUESTRING=‘10.209.139.70’ where KEYSTRING=‘TRX.IP’;
sqlite> select VALUESTRING from CONFIG where KEYSTRING=‘TRX.IP’;
10.209.139.70

Building another version specific container (as root, hopefully privileged this time)
for late 2017 LimeSuite and latest osmo-trx that works best for gprs, to run the rest of the osmocom GSM stack as it was with only this change to osmo-bts.cfg:

phy 0
   ! osmotrx ip local 127.0.0.1
   ! osmotrx ip remote 127.0.0.1
   osmotrx ip local 192.168.1.226
   osmotrx ip remote 10.209.139.70
1 Like

FWIW there is a working Linux Container image published at

index - powered by h5ai v0.29.1 (https://larsjung.de/h5ai/)

has everything to start up OpenBTS with default settings and a few subscribers - users will need to add their own IMSI per the book

http://openbts.org/site/wp-content/uploads/ebook/Getting_Started_with_OpenBTS_Range_Networks.pdf

Next goal is a more popular Docker image with OsmoGSM / LimeSDR setup.

This is great and thanks for taking the time to upload and document.

We have a basic osmoGSM stack (osmo-trx, nitb and bts-trx) running in a docker container with a GalaxyS4 and a DZ09 cheapwatch camped on it - I’ll see about publishing it to be publically available. I actually had to move the image (save/load) to another box to run stably so it’s transportable and self contained :slight_smile: No gprs yet and not entirely satisfied with the versions packaged in but it worked.

The bad news is it’s 715MB - I’d like to break the LimeSuiteGUI out from the base drivers and LimeUtil as that appears to have pulled in 400MB of gui support packages.

1 Like

Publish early, often - likely not perfect but should work:
https://hub.docker.com/r/cswiger/limeosmogsm01/

1 Like

Will be uploading another image to docker hub that has a working gprs system and a startup script - system starts up in seconds from an image

start a container in detached mode with:

root@DellOptiPlex9010:~# docker run -it --device=/dev/bus/usb/004/023 --privileged --userns host --cap-add SYS_NICE -d --name osmogsm u16limeosmogsm3d bash

then start it up with:
root@DellOptiPlex9010:~# docker exec osmogsm /osmogsm.sh

Maintenance and monitoring with
root@DellOptiPlex9010:~# docker attach osmogsm
root@e8849684dc69:/# screen -r to see running named screen sessions
root@e8849684dc69:/# screen -r trx

To build deb packages w/o the heavy LimeSuiteGUI - magic is the $ cmake -D ENABLE_GUI=OFF ../ so add to debian/rules:

dh_auto_configure -- \
        -DBUILD_SHARED_LIBS=ON \
        -DCMAKE_AUTOSET_INSTALL_RPATH=FALSE \
        -DUDEV_RULES_PATH=/lib/udev/rules.d \
        -DLIB_SUFFIX="/$(DEB_HOST_MULTIARCH)" \
        -DLIME_SUITE_EXTVER="$(DEB_VERSION_EXTRA)" -DENABLE_GUI=OFF     <-- add 

and change a few files - debian/limesuite.install

usr/bin/LimeSuiteGUI	<-- remove
usr/bin/LimeUtil
usr/share/Lime		<-- remove

debian/limesuite.postinst

#if [ "$1" = "configure" ]; then
#       /usr/share/Lime/Desktop/install    <-- comment out
#fi

and debian/limesuite.prerm

#if [ "$1" = "remove" ]; then
#       /usr/share/Lime/Desktop/uninstall        <-- comment out
#fi

Then in debian/control remove xdg-util which is the dependency hog that pulls in 333M of packages, or nearly half the image size.

Package: limesuite
Section: comm
Architecture: any
Depends:
    liblimesuite17.12-1 (= ${binary:Version}),
    ${shlibs:Depends},
    ${misc:Depends},
    xdg-utils               <-- remove

NOW docker full LimeSDR / SoapySDR / osmocom GSM stack is under 230MB :slight_smile:

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
u16limesdrosmogsm      latest              11a7e2245c2d        6 seconds ago       226 MB
u16limesdr             latest              d2328cc0727f        8 minutes ago       210 MB