Hi Xaver,
[posting this on the mailing list, as it may be of interest to others]
On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote:
> This is a dynamic linking.
this is true, but the nature of the linking does not matter in terms of
what creates the derivative work.
> Is this a problem even if I do not distribute the resulting binary?
The AGPL (contrary to the GPL) conditions start when users remotely interact
with your software (See Section 13 of AGPLv3). This means even operating
a network with remote users already means you need to provide the complete
and corresponding source code to the entire work under AGPLv3, which is
impossible if you have a proprietary dependency.
So if you build the software, and you make sure that nobody but yourself
every uses the resulting GSM network, you are fine. But as soon as any
third party uses it, you would be putting yourself in the impossible position
to providing the source code to a proprietary library.
> I can simply add a warning to the file that the compiled program cannot be distributed.
One might consider this a "further restriction" which by itself is a
violation of AGPLv3:
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. [...] You may not impose
any further restrictions on the exercise of the rights granted or
affirmed under this License.
But even beyond that: How many users do you think willread that warning
in the source code vs. how many will simply run it (and possibly allow
others to register). Even if you added a message to start-up, and to
the user manual, I still would think many people don't look at that.
I don't think we should distribute something that "tricks" people into
committing license violations or putting them in an impossible position,
legally speaking.
> Is it a violation that someone assembles and uses it on their own machine?
It is not a violation as long as they are they only person using the
resulting GSM network (or using its VTY or its TRXC/TRXD interface).
I would compare distributing source code like that to shipping a product
that is almost impossible to use safely, but very easy to use in a
[legally] unsafe way.
> Is it a violation to even have sources and build instructions for it?
Maybe not, but see above, I don't want to make it too easy for people to
shoot themselves into their foot.
> Can we agree to leave it as a starting point until someone will have the
> time to do it using IPC?
I'm very sorry (really), but we will not merge this code to the
mainline osmo-trx code base on osmocom.org.
Kind regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello GSM network side folks,
I assume that most of you are probably aware of the existence of a
certain hack called CalypsoBTS: it's a rather unbelievable hack that
takes a piece of hw meant to be a GSM MS and turns it into a poor
man's GSM BTS, all inherent asymmetry in the GSM air interface be
damned. As a manufacturer of Calypso-based GSM MS devices I
occasionally get approached by people who seek to acquire a Calypso
device seemingly for the sole purpose of running that CalypsoBTS hack,
and every time I get approached by someone of that sort, I always
shake my head in bewilderment - isn't there a better way to get your
own little toy BTS running than to misuse GSM MS hardware?
The purpose of the present post is to solicit advice from the community
as to what I should tell those poor souls who are seeking to set up
their own toy BTS and are looking to do it via the CalypsoBTS route -
is there some better way that we as a community can steer them toward
instead?
It is my understanding - please correct me if I'm wrong - that the
least expensive way to set up your own GSM BTS for toy purposes (as
opposed to running a real operational GSM network which people will
depend on for real communication) is to use a generic SDR device of
one of several types that are supported by osmo-bts-trx/osmo-trx - but
this is where my knowledge in this area ends, as this particular mode
of GSM toying has never been an area of interest for me. But for
those people who (unlike me) *are* interested in setting up their own
toy BTS in the least expensive way, what SDR hardware should we as the
community recommend for them? What is the cheapest option that will
be good enough - especially if the criteria for "good enough" are
compared to CalypsoBTS? What would be the least expensive option that
is just good enough to be advocated as a better alternative to the
CalypsoBTS hack?
In the case of my current FCDEV3B hardware the price tag seems to be
an effective deterrent against people misusing it as CalypsoBTS:
FCDEV3B is expensive, and someone whose actual need is to run their
own BTS rather than MS can easily buy a suitable SDR device for the
same price or less, it seems. But the issue is beginning to rear its
ugly head again because I have another development board in the works
(not here yet, probably won't have the hw until December), and there
is a possibility (nothing is certain yet) that it might be a bit less
expensive than FCDEV3B.
Is there an SDR-based option (or any other non-CalypsoBTS option) for
running a toy BTS with osmo-bts-trx and the Osmocom CNI stack behind
it that would cost $250 or less in hardware? The $250 number comes
from my anticipated-around-December new FreeCalypso development board
- there is a chance that it might be that cheap (but again, absolutely
nothing is certain at the present moment) - and if there is no SDR or
other option for running your own toy BTS for the same or lower hw
price, then I fear that I am going to be flooded with support requests
from people asking for help with using my new board as CalypsoBTS,
which I absolutely dread. Hence my present attempt to pre-emptively
seek some better solution for those people.
(It would be nice if that stream of support requests from people
seeking to run the CalypsoBTS hack could be redirected to Sysmocom or
some other commercial entity who could make some money helping those
people, but my experience is that these people are not the kind who
would ever pay for commercial support, so no hope there...)
It may also be worth mentioning that the filter replacement hack
(removing or replacing Rx SAW filters that are meant to limit the GSM
MS device's Rx capability to only specific GSM downlink bands) will
not be possible on the new FreeCalypso GSM MS board that will be
coming around December - that design uses an integrated RF FEM (front
end module) instead of discrete antenna switch and SAW filter
components. But I've also heard that plenty of people run the
CalypsoBTS hack without doing any filter rework, just letting the
strong signal from a nearby GSM MS force its way through wrong SAW
filters and not caring about the 40 dB or so of attenuation being
incurred - I cringe at the thought, but that's what people do...
M~
Hi Thomas,
it's been some time, hope you're doing fine!
Today on IRC we were collectively wondering about one detail in the osmo-trx
mcbts implementation that has been there from day one:
Your're creating the Channelizer and Synthesis class for four channels of 800kHz
within the 3.2Mbps wideband-channel. So far so good.
But why does the code ever only use up to three of them?
And why is there a specific re-ordering, see radioInterfaceMulti.cpp in
getLogicalChan() ?
It would be great if you could share your thoughts on that.
To me, it looks like the constraint to 3 channels is arbitrary and we should just
as well be able to use all four?
Thanks,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
That library does a lot of work. Configures HW, sends samples to FPGA via
DMA, does calibration, normalization, format conversions ... Highly
optimized for Intel CPU. If everything were to be done in an equivalently
closed version, it would take several years of work for me. I would like to
start with a simple proof-of concept. Implementing only the functions used
in osmo-trx-pciesdr. In the first phase, these can be only dummy functions
writing or reading zeros.
I assume that the GPL violation problem will be solved from the moment I
will be able to build the library and link it with osmo-trx and run it.
The next step is just a matter of effort from anyone in the community.
Xaver
Hi Xaver,
On Fri, Sep 11, 2020 at 07:51:50AM +0200, Xaver Zu wrote:
> I created a short Wiki page. Please see if it's enough as a link to a
> commit message.
> https://osmocom.org/projects/sdr/wiki/PCIeSDR
Thanks. For sure it is sufficient in terms of content. I did some minor reformatting
while reading.
However, I found a major problem. You state:
> The higher-level driver (in userspace) includes a DSP, a calibration stage, and the gateware update. It is in the form of a closed source dynamic library named libsdr.so. The C API for Linux / x86 is in the form of a header file libsdr.h which also serves as brief documentation.
This is incompatible with the strong copyleft licensing (AGPLv3) of osmo-trx!
You cannot directly link with a proprietary library.
The only way I can see a PCIeSDR backend for osmo-trx would be via osmo-trx-ipc,
which provides a general-purpose sharde memory interface to another process. The
other process can then use the non-free library, if you want that.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear fellow Osmocom developers,
as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year. At the time, we discussed to re-visit the situation
in October 2020.
While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.
Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.
I'm not 100% in favour and not 100% against. Hence, I would like to get
your input. Should we
a) try to get an event organized on-site in Berlin? We'd have to move
to a larger venue than IN-Berlin with proper ventilation and sufficient
space so we can keep physical distance, but I think that's
manageable for sysmocom as organizer.
b) simply postpone to 2021? I'm convinced the situation will not change
significantly (in a positive way) until late April 2021, so it's not
really a "solution" as it will likely mean we have to think of late
2021 or 2022.
c) plan some kind of online conference? To be honest, I think this
model works fine for events where a single speaker wants to give
lectures to hundreds or thousands of participants. But OsmoDevCon
is much more interactive. We could record or live-stream some talks
or screencasts from home, sure. But that only captures one part of
the event. We could also try to set a date for a collaborative
mumble, or the like - for the "hallway track".
What are your thoughts? Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on openbsc(a)lists.osmocom.org.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On Tue, Aug 25, 2020 at 02:49:39AM +0000, scan-admin(a)coverity.com wrote:
> *** CID 212862: Error handling issues (CHECKED_RETURN)
> /source-Osmocom/osmo-pcu/src/pdch.cpp: 211 in gprs_rlcmac_pdch::packet_paging_request()()
> 205
> 206 /* loop until message is full */
> 207 while (pag) {
> 208 if (log_check_level(DRLCMAC, LOGL_DEBUG)) {
> 209 struct osmo_mobile_identity omi = {};
> 210 char str[64];
> >>> CID 212862: Error handling issues (CHECKED_RETURN)
> >>> Calling "osmo_mobile_identity_decode" without checking return value (as is done elsewhere 20 out of 22 times).
> 211 osmo_mobile_identity_decode(&omi, pag->identity_lv + 1, pag->identity_lv[0], true);
> 212 osmo_mobile_identity_to_str_buf(str, sizeof(str), &omi);
> 213 LOGP(DRLCMAC, LOGL_DEBUG, "Paging MI - %s\n", str);
> 214 }
I'd like to let you guys know that I intentionally don't check the return value
here. This is only for logging the mobile identity, and if decoding fails, the
logging should just show "NONE".
~N
Hello!
I was able to use the experimental osmo_dia2gsup converter to successfully
enable circuit switched fallback in a test network, but have a couple fixes
for it and osmo_ss7 needed to work with the latest 2G CN components. I
would open a change request in gerrit, but I see that the rebar.conf of
osmo_dia2gsup already depends on a WIP branch from osmo_ss7. How best
should I provide patches for review? Is there ongoing work in
http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be
merged first, and is there a reason it has not been merged already?
Otherwise should I open a change request towards the WIP branch?
Also, do folks have any opinions on how best to package erlang components?
I was going to generate a Debian package for a stand-alone erlang “release”
of osmo_dia2gsup, and am happy to contribute the debian metadata and build
files upstream, but I am not an erlang expert and want to make sure it’s
structured in the correct way if there is a convention I should follow.
>From a random sample it looks like none of the other erlang components are
packaged, so I don’t have a good example to go from. If there is no opinion
I will make an attempt, but I wanted to ask first!
Thanks for your help and patience!
-Matt J.
Hello,
I see that currently openBSC/osmoBSC works with a number of old commercial
BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis. My question
is, did somebody try something newer than Nokia UltraSite? I have an
ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find
out if maybe it was already tried and had some unresolveable problems?
Please let me know if any.
Thank you
Ivan
Hi all,
What are the plans to expand support for new SDR devices?
When I check the contents of osmo-trx/Transceiver52M/device/ on the git
master I see the supported lms, uhd and usrp1 devices. For example the XTRX
SDR was presented at OsmoDevCon 2018. I expected it to be included in the
master soon. At this point I see its addition in the fairwaves /
libxtrx-wip branch from 2018. That doesn't give me much encouragement for
my next question.
Would it be possible to add support for PCIe SDR from Amarisoft?
Some information about SDR is here
https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288
Based on the
https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive…
I tried to create support by myself. I've gotten into a state that some MS
with weak requirements for signal quality and timing can connect. My branch
is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle
gr-osmosdr support is here
https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR
This osmo-trx is able to run for a few tens of seconds then it quits and I
have to restart it, so I would need a deeper understanding of the timing
and scheduling of processes within osmo-trx. Who should be a clock master
SW stack or SDR device?
I see a lot of log error messages as
0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst
in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0
<0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending
IND CLOCK 1408899
or
0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver
<0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device
<0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start
<0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR...,
sample rate:1.08333e+06
<0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush
<0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok:
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> radioInterface.cpp:202 [tid=140137328043776] Radio started
<0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task
18522) set name: TxLower
<0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task
18524) set name: RxUpper0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
POWERON 0'
<0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task
18523) set name: RxLower
<0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
timestamp is not valid
<0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task
18525) set name: TxUpper0
<0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960,
length = 262144, time_start = 6765960, time_end = 6766960, data_start =
223320, data_end = 224320
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:10976 ts:10960 hwts:6762040
<0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0
<0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in
thread RxLower, requesting stop
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:13476 ts:13460 hwts:6762278
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETRXGAIN 40'
<0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB.
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETRXGAIN 0 40'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETPOWER 0'
<0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60
dB. device:0x1f6e0e0 chan:0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETPOWER 0 0'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 0 5'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 0 5'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 1 7'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 1 7'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 2 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 2 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 3 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 3 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 4 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 4 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 7 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 7 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 13'
<0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver...
<0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver
<0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device
<0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop
<0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped
<0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped
<0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device
Yours XK1Zu
