
SrsLTE: Open Source 3GPP LTE Library - BuuQu9hu
https://github.com/srsLTE/srsLTE
======
zmanian
Can I use this to enumerate LTE base stations? i.e. find Stingrays?

~~~
metafex
Yes. It says "Cell search and synchronization procedure for the UE" under
features (UE stands for User Equipment, e.g. a LTE modem).

edit: cell search example
[https://github.com/srsLTE/srsLTE/blob/master/srslte/examples...](https://github.com/srsLTE/srsLTE/blob/master/srslte/examples/cell_search.c)

------
jimrandomh
It's good to see an open source implementation of this, since the closed-
source nature of most radio implementations (especially in cell phone
basebands) is a serious problem. But I'm a little concerned to see that this
is all written in C. While I can see some good reasons for that (easier
porting to microcontrollers, for example), the C programming language has a
well-deserved reputation for being extremely hard to write securely. Has
anyone looked at this closely enough to comment on whether it's likely to hold
up against people looking for vulnerabilities, as-is or after some careful
auditing?

~~~
mtanski
Speed matters. According to the authors of this software "Highly optimized
Turbo Decoder available in Intel SSE4.1/AVX (+100 Mbps) and standard C (+25
Mbps)".

Also, a lot of alternatives are just not there. Rust is not mature; today it
doesn't "fully" support SIMD. Go requires a runtime, does not support SIMD,
and has a penalty for calling C code.

------
cavemanmike
Awesome! Interesting that they're using the USRP, but have opted to use C
directly rather than Gnuradio (python). I imagine the performance is pretty
good because of this.

Looks awesome, wish I had the time to play with it.

~~~
deutronium
A lot of GNU Radio is actually written in C++. Looking at some examples, it
seems you don't need Python to create the flow graph either, that can be done
in C++.

~~~
lima
All performance critical stuff is implemented in C++. Python is just for the
high-level part.

~~~
deutronium
Gotcha, cheers

------
hlandau
This is very nice to see.

I would note however that the use of the AGPL instead of the GPL here is
probably legally meaningless. I wrote about this:
[https://www.devever.net/~hl/agplunenforceable](https://www.devever.net/~hl/agplunenforceable)

~~~
BuuQu9hu
IIRC the extra clauses of the AGPL are triggered on modification of the work
(which is restricted to copyright holders and licensees), not on public
performance or communicating over the network. So if you are running the exact
same version you downloaded, there are no extra provisions. If you patch the
code to, say, fix a typo, then you have to distribute the code to network
users.

~~~
hlandau
This presupposes that modification of a copy of a copyrighted work that one
lawfully owns is, in itself (even without subsequent distribution), an act
restricted by copyright. I contest this assertion.

Even if it were the case, the permissions granted by the AGPL are not mutually
exclusive with any other set of permissions. Dual licencing, for example, is a
common practice. Thus, I'd argue one can take advantage of provisions of the
AGPL permitting modification, but not rely on it, but instead on the
provisions of copyright law itself, to actually execute the software. The AGPL
_is not a contract_ , it is a copyright licence; as such, the set of actions
you can take for an AGPL-licenced piece of software is by definition a strict
superset of the set of actions you can take for "all rights reserved"
software.

~~~
BuuQu9hu
You don't own the work, the copyright holder does.

~~~
hlandau
Um, yes. And?

~~~
bjornsing
Under US copyright law the "preparation of a derivative work" (in this context
more or less making a change to the code base) is one of the six exclusive
rights under the control of the copyright holder [1].

1\.
[https://www.law.cornell.edu/uscode/text/17/106](https://www.law.cornell.edu/uscode/text/17/106)

