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
