Cellular Network Infrastructure » OsmoGSMTester

A publicly reachable network segment is now available in the office.
Brief test shows: when connected to the publicly available net, the gsm-tester APU of the R&D setup registers as 10.9.25.101 (needs power cycle or network restart).
So far still connected to the in-office setup as before...

The office-internal address for the gsm-tester R&D main unit is/will be 10.9.25.101. This exact address is already reachable from jenkins.osmocom.org.

Next todo: setup the osmo-gsm-tester main unit as a build slave in jenkins.osmocom.org.

A build slave is now added to jenkins.osmocom.org, next up is setting it up to update and run the tester.

An open decision is which way to give permissions for things like:

- access to UHD
- tcpdump

maybe later:

- create tun for GGSN
- restart ofono service
- call uhubctl to power cycle modems

The build slave is currently running as jenkins. We could run it as root.

We could still run the jenkins build slave in user land, but grant permissions to launch the tester script as sudo without password. (Since we're also allowing permissions to update script, that's a free root pass there as well, safety wise).

The safest but most time consuming way is to give explicit permissions to the jenkins user as needed and document that -- various different steps specific to each type of permission needed.

I am tempted to just grant passwordless sudo for now. Am I allowed to do that? I assume that it safe enough in the sense that the sysmocom private network cannot be compromised by root access to the main unit -- right?

neels wrote:

An open decision is which way to give permissions for things like:

- access to UHD

that should be standard with any reasonable udev rules.

- tcpdump

If you instead use tshark, it will use dumpcap and the associated privilege separation, just like wireshark itself (which I presume you run as normal user on your laptop). dumpcap has CAP_NET_ADMIN and can thus sniff the packets, while the interpretation of the traffic runs inside the tshark (or wireshark) binaries as non-root. See e.g. https://superuser.com/a/319870

tshark even has a mostly compatible command line syntax, i.e. you can use "tshark -npi eth0 -w /tmp/foo.pcap" or the like.

- create tun for GGSN

should be possible with root creating a persistent tun device (like "tunctl -b -u laforge -g users -3 -t gtp0") once at start-up/boot time and then using that from a non-root openggsn. Have never tried this myself with OpenGGSN, but it's a standard feature of tun devices.

UPDATE: I quickly had a look at this. Seems like OpenGGSN wants to create the device and set the address, rather than being able to inherit/use an existing tun device. Should be rather trivial, I created #2250 for that.

- restart ofono service

not sure if/how that can be done by non-root using systemd-internal mechanisms. At least with sudo it's of course possible, and should be fairly secure as it's a single static systemctl command without any caller-supplied arguments, etc. (https://serverfault.com/a/772786)

- call uhubctl to power cycle modems

that might again be possible using udev rules, given that the quad-modem internal usb hub has a unique VID/PID, so a udev rule can simply chown the associated device to a given non-root user/group

The build slave is currently running as jenkins. We could run it as root.

We could still run the jenkins build slave in user land, but grant permissions to launch the tester script as sudo without password. (Since we're also allowing permissions to update script, that's a free root pass there as well, safety wise).

The safest but most time consuming way is to give explicit permissions to the jenkins user as needed and document that -- various different steps specific to each type of permission needed.

I am tempted to just grant passwordless sudo for now. Am I allowed to do that? I assume that it safe enough in the sense that the sysmocom private network cannot be compromised by root access to the main unit -- right?

I'm not overly worried here. It is a separate network segment. But then, I think in the general context of explaining our users how to configure more secure Osmocom setups, it might be worth to investigate and document the above-mentioned strategies to avoid having to run any osmocom software as root. I mean, if not even we are able to set our own system up that way, we cannot expect our users to do so, can we?

The first successful trial has run on the public jenkins!
It was using code from my branch, containing the simplifications the jenkins build slave brings.
These need to pass review and be merged to master, but basically we're done here.

http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/
http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/11/

Documentation to setup is also quite far, but not complete; on branch osmo-gsm-tester in the osmo-gsm-manuals

http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/
documented in all detail in http://git.osmocom.org/osmo-gsm-manuals/tree/OsmoGSMTester http://ftp.osmocom.org/docs/latest/osmo-gsm-tester-manual.pdf