> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
HI.
A little heads up: uhd version in jenkins building osmo-trx should be
updated to 3.9.0 - this would allow gerrit #1117 to be properly verified
by jenkins.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
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)
On Sat, Dec 31, 2016 at 01:10:30PM +0000, Vadim Yanitskiy wrote:
> Regarding to the change, there is a problem: despite all tests
> pass without any problems on my machine, some tests fail on Jenkins.
> I will try to find out, what's wrong.
Let me know if I should install some library dependencies or similar on the
build slaves...
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hello, list.
I have umtrx v2.1 and I have already built GSM and GPRS components. Now I want to know which way of configuring timeslots in osmobsc.cfn is the best. I want GPRS, calls and SMS work.
My current configuration is:
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config PDCH
hopping enabled 0
timeslot 5
phys_chan_config PDCH
hopping enabled 0
timeslot 6
phys_chan_config PDCH
hopping enabled 0
timeslot 7
phys_chan_config PDCH
hopping enabled 0
Is there a better way to configure? Maybe better use TCH/F_TCH/H_PDCH, but I have heard, that TCH/F is currently not working in dynamic configurations - only TCH/H does. And there is no only TCH/H_PDCH mode. So, could you please give me an advice?
Merry x-mas!
Just now I found a curious problem with the current osmo-nitb ciphering key.
I'm working on the new VLR, which will inherently fix this issue, but in the
course of that I recapped the current osmo-nitb's sequence of events for 2G
ciphering as it is on the openbsc master branch.
It so happens that I'm using a SIM card with a fabricated Ki value of hex:
000102030405060708090a0b0c0d0e0f
i.e. starting with a zero byte.
I was able to store this in and retrieve from the hlr.sqlite3 db:
sqlite> INSERT INTO "AuthKeys" VALUES(57,2,X'000102030405060708090A0B0C0D0E0F');
sqlite> select hex(a3a8_ki) from AuthKeys;
000102030405060708090A0B0C0D0E0F
So there were 16 bytes worth of BLOB in the Ki column for sure.
But in openbsc's db.c in db_get_authinfo_for_subscr(), I always got
DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=0)
Curious, could it be the zero byte? Just to check, I put the zero byte further left:
sqlite> select hex(a3a8_ki) from AuthKeys;
hex(a3a8_ki)
F00102030405060008090A0B0C0D0E
^ nonzero ^^ zero
Now the log says:
DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=5) f1 f3 f4 f5 f6
That's even weirder. I was expecting a 7 byte BLOB, of
f0 01 02 03 04 05 06
and not
f1 f3 f4 f5 f6
... what on earth ...
It appears that we've so far always been unable to use Ki keys that contain a
zero byte, or apparently anything that's outside the 7bit ascii space ... ?
To be able to recap what the old osmo-nitb is doing (without going to fetch a
card reader from the office and reprogram the Ki on the SIM card), I fixed this
bug with this funny little hack: https://gerrit.osmocom.org/1504
Todo: are other BLOB values also affected? Is there a better way to fix?
Even though the new VLR is on its way, it might be good to get a fix like this
out in the meantime ... though it appears that no-one is using ciphering on 2G
anyway?
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi Thomas,
We're porting osmo-trx to our XTRX and we see some weird
constellation (https://goo.gl/photos/1KycUsv26Z6T6aN97). It looks like
a normal GMSK circle is there, but there is also a square like if a
signal is clipped. Do you have any idea what could cause this from
your previous experience?
We're running osmo-trx at 4 SPS. Then we double sample rate in
software (XTRX can't handle sample rates below 2 MSPS yet) and then
transmit. See first image above.
Then we tried to increase sample rate and enabled 4x interpolation in
LMS7 - that led to a distorted cicrle + square constellation
(https://goo.gl/photos/zMZRecxmZsqiCYMHA).
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Hi Team
Has anybody seen error like below while running osmo-stack on B210?
What could be the reason of this failure? We are seeing this randomly.
ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1039:check_rx_md_err: An
internal receive buffer has filled at 31.9377 sec.
ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer
data: timestamp=8696668 time_end=8651398
ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer
data: timestamp=8696668 time_end=8651398
ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer
data: timestamp=8696668 time_end=8651398
ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer
data: timestamp=8696668 time_end=8651398
NOTICE 140460079380224 20:17:34.0 Transceiver.cpp:306:stop: Stopping the
transceiver
ALERT 140460079314688 20:24:03.3 radioInterface.cpp:323:pullBuffer: Receive
error 0
ERR 140460079314688 20:24:03.4 UHDDevice.cpp:1039:check_rx_md_err: An
internal receive buffer has filled at 437.017 sec.
Regards
Mayuri
