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
We get this more often than not in the openbsc build job, I'm still not sure
how to fix it:
======================================================================
ERROR: testBSCreload (__main__.TestVTYNAT)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./vty_test_runner.py", line 785, in testBSCreload
b0 = nat_bsc_sock_test(0, "lol")
File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test
ipa_handle_resp(bsc, tk, verbose)
File "./vty_test_runner.py", line 1260, in ipa_handle_resp
x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8'))))
error: [Errno 32] Broken pipe
----------------------------------------------------------------------
Ran 43 tests in 51.717s
FAILED (errors=1)
Reducing the nr of executors hasn't had an effect yet. Could there be another
cause? Too fragile timing or something?
~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
When committing a change that needs a specific change from another project, but
that other change is still in the gerrit queue and has no final git commit hash
yet, it is handy to use the Change-Id to reference the given decision.
Harald recently requested that I always include the Change-Id in the commit
log.
Now Max says:
> It's better to update commit log with git commit hash instead of change-id
> before final submission.
Can we get consensus? Should we modify the commit log from Change-Id to git
hash once the required other commit is through?
The Change-Id is always there and can be searched for in the git log; and
should we ever decide to rehash the git history or move to another version
control software (losing all git hashes), the Change-Id would still be there.
But the git hash, once it is finalized, can be used directly on the git
commandline.
I wouldn't have done the extra effort, but if all agree that the git hash is
better, I'll change it (and hopefully remember to do it, too).
~N
When I now change pretty much anything in libosmocore that I want to use in
e.g. openbsc.git, I would like to bump the minor revision and reference that in
other projects' configure.ac.
The effort is ok if it entails only tagging a revision and using that elsewhere.
However, this has come down to a lengthy process:
"
cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE)
update debian/changelog using "gbp dch" command
"
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_releas…
So, pretty much every commit in libosmocore will be followed by another commit
that is adjusting the changelog...? :/
Should we adjust the changelog along with pretty much any change used outside
of libosmocore? :/ (probably not, because reverting anything is made cumbersome)
Should we rather, like, make a libosmocore release only once a week and somehow
track wich other projects need a bump to the required libosmocore version?
I think most projects out there make a release tag only every now and then. We
could limit to noting the required libosmocore change-id in other projects'
commit logs until the next (minor) release is made...?
Can we add a fourth level of version that doesn't require a changelog/debian
release? So for every small change I make I would tag 0.9.6.1, 0.9.6.2, etc.,
and at some point we make 0.9.7 along with a changelog adjustment?
Thoughts?
~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 Gerrit users,
I follow the gerrit mails to get notified of comments and to catch failing
builds. The message that a build started or was successful though doesn't
help me much, only clutters up space, really.
Do you agree?
If yes, I would try to silence the "Build started" and "Build successful"
messages in our gerrit, if possible without too much effort...
~N
