Hello all,
I have recently tried migrating an OsmoNITB setup to the new standard using mostly this guide right here: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I… <https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…>
However, while my nanoBTS works perfectly fine in the old setup, it just doesn not work at all in the new one. When I start osmo-bsc the LED on the BTS starts flashing green after a few seconds and then stops flashing and just stays green all the time, which is the expected behaviour. Unfortunately though, after another couple of seconds, the LED starts flashing green again and then turns red.
This is what the log shows:
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1154
****
** l2_bch.c#1154:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (1063).
****
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1154 (1063).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error:
.
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1154 (1063)
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#260:BCHbcchSItypeValid( prim_p->infoType )
20180328072641280 DLINP <0013> input/ipaccess.c:247 Sign link vanished, dead socket
20180328072641281 DLINP <0013> input/ipaccess.c:71 Forcing socket shutdown with no signal link set
20180328072641282 DCTRL <000e> osmo_bsc_ctrl.c:160 No more BTS connected, sending TRAP.
Now I'm not claiming that my config is already 100% correct but I feel like this isn't a configuration issue. I'm using the most recent nightly builds of the entire osmocom library.
Does anyone know what could be at fault here?
Kind regards,
Michael Spahn
Dear list,
I'm having trouble using the A5/3 encryption in my setup. A5/1 works perfectly fine [attachment a5_1.pcapng]. As soon as I switch to A5/3 and e.g. send an SMS, the last valid message I see in the Wireshark traces of the GSMTAP of osmo-bts-trx is the Ciphering Mode Command requesting A5/3. After that, several messages arrive at the bts, but it seems like it can't make any sense of them. The MS repeatedly tries to send the SMS but never succeeds [attachment a5_3.pcapng]. Both MSs are connected to the same bts.
According to the Classmarks of all MSs, A5/1 as well as A5/3 are supported.
This is my Setup:
- USRP N210
- osmo-trx
- osmo-bts-trx
- osmo-nitb
- osmo-pcu
- osmo-sgsn
- osmo-ggsn
I'm using a Debian 9 VM and tried both the packages from osmocom-latest as well as osmocom-nightly.
The MSs I've tested are two Nexus 6 and one Samsung Galaxy S I9000. All three with sysmocom nano USIMs.
Could the decryption at the bts be incorrect? Has anyone tested/used it recently?
I'll be happy to provide additional information if needed.
Thanks,
Jan
Hi All,
Can anyone confirm if the maximum MO-SMS that can be sent is less than 60 characters including spaces?
For OSMO-NITB, we reach a maximum of 59 characters for MO-SMS, while for OSMO-BSC, we only reach a maximum of 50 characters (MO-SMS).
Is this a known issue?
TIA.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Dear All,
I have just uploaded my modified osmo-iuh, which a new version asn1c is
applied, to :
https://github.com/brchiu/osmo-iuh/tree/new-asn1c
Code generated by this new asn1c can handle necessary ASN.1 information
object class feature used in several 3gpp specs, thus it remove the need of
asn1tostruct.py.
Because Lev Walkin has not accepted corresponding pull requests yet, it
should be built from Velchkov's repository :
https://github.com/velichkov/asn1c/tree/s1ap
And link to new libasn1c :
https://github.com/brchiu/libasn1c/tree/new-asn1c
I use RANAP 14.1.0, RUA 14.0.0 and HNBAP 14.0.0 to generate files.
There are still several compilation error which are irrelevant to this new
asn1c.
https://gist.github.com/brchiu/17b5d306dd3e95f5e7b255a7dbb81344
Hope someone can help solving them.
Because I do not have test environment nor have no time to verify this
porting, you are welcomed to use this result on your own.
thanks.
regards,
Bi-Ruei, Chiu.
Hi all,
I've set git.osmocom.org to read-only while I'm doing the migration
to the new server. So don't be surprised if you won't be able to push
there (or if gerrit is not able to push there).
I'll try to make this quick, should be back within the afternoon.
--
- 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)
When libosmocore/contrib/fsm-to-dot.py hinted me at errors in the new gscon FSM
in osmo-bsc, I took a moment to render and look at all our FSM definitions.
The osmo-bsc ones are fixed by https://gerrit.osmocom.org/7501
I also found OS#3110 and OS#3111
I published the FSM graphs as rendered today at
http://people.osmocom.org/neels/osmo_fsm_graphs/ and might do so every now and
then. If anyone likes, we could do it from jenkins regularly.
~N
Hi stsp,
I noticed in the recent gsm0808_cell_id_list2 a review item slipped by:
A "LAI" is by definition a PLMN (MCC+MNC) plus a LAC.
So saying "LAI and LAC" is like saying "My family and my brother".
So maybe we want to rename the "lai_and_lac" member of struct
gsm0808_cell_id_list2 before it gets tagged for release. Just "lai" would be
accurate, as its type (struct osmo_location_area_id) suggests.
~N
Hi Support,
In Half Rate configuration of OSMO-BSC, is there a way to used ETSI TS 101 318 standard for its RTP Payload Format? As per testing, the RTP Payload format used by OSMO is RFC5993.
Can this be configured in OSMO-BSC or OSMO-BTS-TRX? Or the configuration of this is hard coded?
Logs from OSMO-BTS-TRX:
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.[0;m<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14)
TIA!
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
In recent weeks, many of you have encountered and worked at failures of
OsmoMSC's subscriber conn FSM / the conn itself to handle corner cases and/or
cleanly handle error situations.
I have plans for that FSM to be reviewed, adding probably two more states to
it, a) to properly handle the early startup and b) gracefully release in all
situations; and to probably more closely glue the conn struct to the FSM.
My humble suggestion is to wait for me to review it and not spend more time on
it until that is through. I wrote the FSM initially, and it makes sense that I
clarify its structuring before all of you need to learn its current quirks.
I hope it won't take too long, just need to sort the priorities of this fix
versus the other tasks I have...
~N
Dear all,
I've changed some details related to logging:
* we now generate per-testcase merged TITAN log files with the same name
prefix as the pcap files (Module.Testcase.{pcap,merged}) and remove
the hundreds of per-component log files generated by the parallel
executor after merging them.
* the console log verbosity has been incresed to include all output from
explicit "log()" statements. This is particularly useful when running
the tests interactively.
Unrelated to the above, I removed our own copies of the MTP3/M3UA/SCCP
emulation and replaced it with the proper upstream git repositories
under 'deps' like most other external modules. This means that you
will need to
* update your 'deps' (make deps-update)
* remove/re-generate your symlinks (gen_links.sh) from e.g. 'bsc' or 'msc'
* re-generate the makefile subsequently
It may be that the make file dependency logic doesn't pick this up
automatically, so if you see some strange build errors, it may be a good
idea to clean your local work tree.
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)
Dear all,
as I explained in https://osmocom.org/issues/3070 for some reason BSC_Tests.ttcn
fails to work under TITAN 6.1.0 anymore. Rather than debugging old TITAN
versions, I decided to update to the latest stable release (6.3.1) in the
debian-stretch-titan container that we use on jenkins.
Please keep this in mind when running tests locally:
* for containerized setups, switch to latest docker-playground master and
re-build the debain-stretch-titan container before building any of the ttcn3-*-test
containers based on it
* if you build+run the ttcn-3 code on your native machine/distro, pleaes switch to
TITAN 6.3.1. If you run Debian 9, you can use the package from network:osmocom:latest
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)
Do I have permission to move the docker-playground.git to gerrit? I have a
bunch of patches already in my various branches. I could just push them onto
master, but I guess some code review would be good?
Should we also add a gerrit job that tests the changes? Kind of hard to make a
failure decision though while when some tests are normally failing, like they
still are.
~N
In the file
BSSGP_Types.ttcn -> ../deps/titan.ProtocolModules.BSSGP_v13.0.0/src/BSSGP_Types.ttcn
I notice many PLMN definitions like
type record PLMN_Identity
{
OCT1 iEI,
BIT1 ext,
LIN2_2a lengthIndicator,
HEX1 mccDigit1,
HEX1 mccDigit2,
HEX1 mccDigit3,
HEX1 mncDigit3,
HEX1 mncDigit1,
HEX1 mncDigit2
}
which at first glance looks like they got the MCC-MNC digits ordered wrongly.
It is correct as long as the less significant nibble comes first. And using
these in PLMN tests gives the expected results.
Now I assume that the HEX1 means that it's a nibble, where the less significant
nibble comes first, sort of a "network nibble order" if that makes any sense.
It is weird, though -- do we need to compose hex strings "reversed" as well??
~N
I have a trivial patch adding the new data item to the PCUIF_Types.ttcn (see
branch neels/pcu in osmo-ttcn3-hacks.git), but I can't get the TC_pcu_act_req()
to pass.
I have trouble understanding where in that the PCUIF version would take effect,
I can't find any place where it is populated. That would need a bump to version
9. Maybe that's not needed at all.
All I get is
21:13:27.702570 mtc BTS_Tests.ttcn:1883 setverdict(fail): none -> fail reason: "Timeout waiting for PCU R
TS.req", new component reason: "Timeout waiting for PCU RTS.req"
and I can't figure out why. It doesn't seem related to the pcuif_proto.h
anyway.
~N
Hi all,
I'm interested in upgrading my 2G setup to also support 3G.
My current setup is: USRP N210, osmo-trx, osmo-bts-trx, osmo-nitb, osmo-pcu,
osmo-sgsn, osmo-ggsn.
On the software side I understand I'd have to migrate from osmo-nitb to the
new split components and add the 3G components.
Regarding the hardware it seems most people are using the ip.access nano3G
femtocell. Is this the same one that's included in the sysmocom 3.5G starter
kit?
Are there any alternatives I'm not aware of other than using non-Osmocom
projects?
Thanks,
Jan
Hi everyone,
I few days ago, during some usual R&D process, I noticed the following
messages, appearing in the log output of OsmocomBB/mobile application:
"ACCH message type 0xXX unknown."
The network, a phone was connected to, was may own and based on more
or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I
used to see such messages before, I didn't pay too much attention.
But this time I've decided to figure out, what's wrong there...
The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch():
static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg)
{
// ...
struct gsm48_system_information_type_header *sih = msgb_l3(msg);
// ...
switch (sih->system_information) {
case GSM48_MT_RR_SYSINFO_5:
return gsm48_rr_rx_sysinfo5(ms, msg);
case GSM48_MT_RR_SYSINFO_5bis:
return gsm48_rr_rx_sysinfo5bis(ms, msg);
case GSM48_MT_RR_SYSINFO_5ter:
return gsm48_rr_rx_sysinfo5ter(ms, msg);
case GSM48_MT_RR_SYSINFO_6:
return gsm48_rr_rx_sysinfo6(ms, msg);
default:
LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n",
sih->system_information);
return -EINVAL;
}
}
To get I bit more details, I modified this function to print the
whole L3 payload, and got some interesting results. As it turned
out, the payloads were shifted one byte left - there was no
'l2_plen', which is assumed by:
/* Section 9.1.3x System information Type header */
struct gsm48_system_information_type_header {
uint8_t l2_plen;
uint8_t rr_protocol_discriminator :4,
skip_indicator:4;
uint8_t system_information;
} __attribute__ ((packed));
So, my first idea was that this is a bug of OsmocomBB, that
would be fairly easy to fix, so after a quick look at the
GSM 04.08 specification I wrote (and merged :/) this:
https://gerrit.osmocom.org/#/c/5204/
And everything was great, until I connected a 'patched' mobile to
a commercial mobile network... And all SI messages during a
dedicated connection were false-identified as SI5ter. This seemed
strange to me, so I decided to compare a SI message from commercial
network with a message captured in my own one:
https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png
And this confused me even more, then I've expected. Why there is 0x49?
Wireshark false-identified this message as something related to SMS...
What if this is exactly the 'l2_plen' assumed in OsmocomBB before?
I looked at the specifications again, and found out that initially I
refered an outdated 5.3.0 version, which was the first link in Google:
http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p…
while the latest one is 7.21.0:
http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100…
So, I compared the 9.1.37-40 sections of both versions, and bingo!
In the higher version ACCH System Information messages do have the
'L2 Pseudo Length' (10.5.2.19) field.
Finally, what I've learned:
- OsmocomBB / mobile follows the new version here (with l2_plen);
- OsmoNiTB generates the ACCH SI messages without the l2_plen;
- Recent Wireshark versions fail to decode the ACCH SI messages
with l2_plen, while older ones are able to do that;
- I should not merge the changes so quick.
My questions are:
- Which way of composing the SI messages is correct?
- If both are correct, how to parse them correctly?
- Should we change OsmoNiTB / OsmoBSC to follow the latest specs?
And of course, I have to revert the change I've merged.
With best regards,
Vadim Yanitskiy.
Dear list,
anyone know if osmo-nitb can send sms to all subscribers like blast sms?
it would be nice if we can implemented it.
Thanks
--
Best Regards,
DUO
The 'laforge/trx' branch of OsmocomBB was used to make basic
TTCN3 tests, such as the 'max_ta', work ASAP. Now all required
changes and some bug fixes have been merged to the 'fixeria/trx'.
Change-Id: If86dcd677cd8a8bf62821028e17ebdf99a7a004e
---
osmocom-bb-trxcon/Dockerfile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/osmocom-bb-trxcon/Dockerfile b/osmocom-bb-trxcon/Dockerfile
index 1d29051..ca8ac2c 100644
--- a/osmocom-bb-trxcon/Dockerfile
+++ b/osmocom-bb-trxcon/Dockerfile
@@ -2,7 +2,7 @@ FROM laforge/debian-jessie-build
MAINTAINER Harald Welte <laforge(a)gnumonks.org>
-ARG OSMO_BB_BRANCH="laforge/trx"
+ARG OSMO_BB_BRANCH="fixeria/trx"
ARG OSMOCOM_REPO="http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_…"
--
2.16.2
Hi all,
Does anyone have a working OsmoBsc_Nat with osmux working example? I
just want to take a look in osmux, so it doesn't matter if it's with old
NITB-era stack or new split stack.
Thanks,
Rafael Diniz
Hey,
pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario.
In terms of scenario knobs I can see:
- #MS
- CDF function
- IMSI generator (start with XXX and count upwards)
- virtphy vs. trxcon?
The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config?
holger
Hey neels, pespin,
while looking at configuration handling for the MS driver I started to have sone questions about scenarios. I see that we have multiple yaml files and through scenarios can control ciphering, the timeslot configuration, which BTS model to test, and more.
What would it take to get this abstraction one step further? When I diff the aoio_sms and sms suite the difference is in setup (and then naming of msc vs. nitb)? Wouldn't this be something we can get into the scenario as well? The requirements for this test are two connected and routable subscribers?
low priority thing but what do you think?
holger
Hi Philipp,
I promised you to look at handover_test.c on the new fsm4 branch.
Looking at it now, I immediately ran into FSM events being dropped on the floor
because it was in the wrong state. When I initially fix that, the test runs
into the MGCP FSM not existing.
So at the end of the day, it is all related to the recently added FSMs and how
they interact, and it seems to me that you are more familiar with those than
me. In other words, I'm playing the ball back into your corner now:
Look at osmo-bsc branch neels/fsm4, here are the differences to pmaier/fsm4:
- right at the start, I add a patch to properly wrap abis_rsl_sendmsg(). That's
just cosmetic, really. It was doing its job well, just I don't trust that
implicit linking. It's at the start because I also submitted it to gerrit.
5eaaf6120e21
(I'd link to git.osmocom.org but after 10 minutes the branch still isn't
synced there, strange.)
- I add the DMSC logging category to handover_test.c. That enables the FSM's
error messages to be logged. This only makes sense as long as that FSM is
actually logging on DMSC, which doesn't seem a good fit.
8128a49a6c6ce4ae
- I kick the gscon into the ACTIVE state when a conn is created. That might be
taking a shortcut, since I'm not sure how e.g. the conn->user_plane.fi_bts
should be populated...
c2f90c36c445b2a38
So, e.g. when running './handover_test 1', my code state enabled the logging
for them and uncovered the errors:
DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{INIT}: Event HO_START not permitted
and then
DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{WAIT_CC}: Event HO_START not permitted
These two are fixed, and now I'm stuck at:
DMSC handover_logic.c:333 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: Received Event HO_COMPL
DMSC bsc_subscr_conn_fsm.c:710 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: state_chg to WAIT_MDCX_BTS_HO
Assert failed fi ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_fsm.c:603
i.e. the handover_test.c is trying to indicate a 'Handover Complete' to the
libbsc machinery by calling handover_test.c:send_ho_complete(), and it runs
into a wall of the fake conn having conn->user_plane.fi_bts == NULL.
At this point I could start figuring out how to fake the fi_bts, but in fact I
assume you're more proficient in that area, so please take over from here.
Thanks!
~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,
I wonder if someone has got the limesdr mini (hardware v1.1, gateway 1.24)
running with osmo-trx ?
I've been able to get it working with the non-mini version (the "big" mimo
limesdr) but with the mini version it crashes after a few tenth seconds
with apparently something going wrong on the tx side (see attachments)
Any feedback is welcomed :)
Cyril
Hello,
How do you select the log level with the libosmocore logging system
introduced in commit 3da1f83 ? What is the equivalent of '-l DEBUG' command
line option now ?
Thanks !
Cyril
Dear Osmocom community,
it's already end of January and OsmoDevCon 2018 in April is getting closer
and closer.
As indicated before, I would like to group the topics by days and put
together at least a rough framework shcedule, so that people
with specific interests don't have to be present for four full days to make
sure they don't miss anything.
So I'd like to re-invite all attendees to consider adding a topic/porposal
to the wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018#section-9
so that we can group different topic areas and put together a rough schedule
outline.
A proposal doesn't mean you have to give a talk. It could be anything, including
* a talk that you would want to listen to, and you're looking for somebody to give it
* a discussion about a certain topic
* a workshop / hands on session
* lightning talks?
Like any community event, OsmoDevCon lives by its contributors. I can't wait to
hear about all the things you've been up to. Thanks!
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)
Hi all,
today I've docker-ized the latest TTCN-3 test suite I've been developing over
the last week or so. They're now running nightly in our Jenkins, you can see
the results analyzer at
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resu…
(don't forget the "Expand All" button)
Out of all the test suites I've written in recent months, the OsmoBTS
test suite is what I'm particularly happy about. While of course not
achieving 100% coverage it actually tests a lot of things, including
various cases that would be very hard to impossible to achieve in manual
testing.o
A larger number of tests is also relate to the BTS<->PCU socket
interface, where [almost] each of the message types occurring in Rx/Tx
is triggered + tested accordingly.
The system information scheduling test cases were working for me 2 days
ago, I'm not sure what I did wrong to break them again, I'll
investigate.
In terms of important needed OsmoBTS tests, I see:
* verification of PCU -> Um for all different coding schemes
(requires PDCH support in trxcon first, or fall-back to virt_phy
instead)
* testing of timing advance loop
* testing of uplink power control loop (needs fake_trx extension)
* testing of voice channels in all codec modes
* memory leak related testing
It was a loooong week full of late night and early morning shifts, but
I'm happy that progress was possible in a rather short amount of time.
Thanks to Vadim "fixeria" for his work on trxcon + fake_trx, which means
we can test a fully unmodified osmo-bts-trx ("the real thing"), rather
than osmo-bts-virtual, which is a BTS model that doesn't exist this way
in reality.
The nice part is that the test cases only use L1CTL on one hand side and
RSL/PCUIF/VTY/CTRL on the other side, and as such they should in theory
work equally with the followign setups:
a) TTCN3 -L1CTL-> trxcon -> fake_trx -> osmo-bts-trx -> TTCN3 (current)
b) TTCN3 -L1CTL-> virt_phy osmo-bts-virtual -> TTCN3
c) TTCN3 -L1CTL-> OsmocomBB-firmware -RF-> osmo-bts-{sysmo,lc15,octphy} -> TTCN3
Only 'a)' is currently used, but it would definitely be interesting to
be able to use the exact same test cases (minus TA/power-control loop
test) with real hardware and the different PHYs.
Any contributions are as always very much welcome. With all the
existing test cases out there and the dockerized setup, it should be
super easy to reproduce the test results on your local machine, and to
copy+paste+edit an existing test to extend test coverage even further.
The development of the test suite has already resulted in dozens (!) of
bugs being discovered some of them quite severe. Check the increased
activity since february 22nd at http://osmocom.org/projects/osmobts/issues?utf8=%E2%9C%93&set_filter=1&f%5B… for more information
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)
Hi Harald,
> fake_trx must be able to insert additional false "delay"
> ...
> 1) Implementation of TA in fake_trx
> ...
> 2) implementation of "fake delay" in fake_trx
> ...
Done. Great collaborative work!
> fake_trx must be able to insert additional false "path loss"
> ...
> For RSSI processing it's slightly more complicated:
This needs to be discussed.
> fake_trx would need to know the nominal transmit power
> of both MS and BTS. For this example, let's assume MS
> nominal power is +30dBm and BTS +23 dBm...
Do we really need to specify the nominal transmit power for both?
At the moment, trxcon is capable to parse the L1CTL_PARAM_REQ
messages from the higher layers, and it basically forwards
exactly TX power instead of TX attenuation to transceiver...
Or should we change this value to attenuation,
and go by the way you suggested above?
This task doesn't seem too complicated, so I'll implement this.
By the way, I have another idea. We are talking about path loss,
which does not only affect power levels, but also introduces
some bit corruption level. This could be also simulated in
FakeTRX, but first of all, it's good to know, do we need
this feature? I think it makes sense, because a MS also
reports BER in its Measurement Reports.
With best regards,
Vadim Yanitskiy.
Hi All,
Does anyone tried enabling the A5/1 Encryption using osmo-bsc and osmo-msc?
We are using an UPBOARD with the following elements; osmo-bsc, osmo-bts-trx and osmo-trx in it; and a NUC with osmo-hlr, osmo-msc, osmo-mgcp, and osmo-stp.
Both servers are using Ubuntu 16.04 OS.
We enabled the a5/1 encryption in both osmo-bsc and osmo-msc. Then provisioned the programmable SIM to osmo-hlr with aud2g comp128v1 auth.
OsmoHLR# subscriber imsi 515941234567890 show
ID: 9
IMSI: 515941234567890
MSISDN: 09271234567
2G auth: COMP128v1
KI=00112233445566778899aabbccddeeff
We are not really sure what causes the LOCUP Reject.
Can anyone help us with this issue?
Attached are the configuration used during the testing and a trace taken during the testing.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>