Hi!
Four builds ago, from build 585 onwards, we are seeing massive regressions
in the BTS_Tests.ttcn test suite on osmo-bts master:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resu…
I think this matches roughly when the TRXDv1 protocol changes were merged,
it would be great if anyone making changes to osmo-bts or the test suite around
July 21/22nd could investigate what's happening here.
Tests against osmo-bts-latest are doing fine, so I think we can exclude a bug
in the test suite.
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,
I'm writing some tools for using with HF radio and SDR modems [1], and
I'm using multi-threaded architecture. Do you know the status and/or
which branch should I use of libosmocore in a multi-threaded application?
Regards,
Rafael Diniz
[1] https://github.com/DigitalHERMES/rhizo-uuardop
Good evening,
My name is Tyler Wood, I was wondering how much yall would charge to create a dongle with OpenBSC on it and mail it to me. If I have contacted the wrong emails please let me know who I need to contact. Thank you for your time.
Very Respectfully,
Tyler Wood
Obrigado Romeu!
On 7/19/19 4:58 PM, Romeu Medeiros wrote:
> Hello Rafael
>
> I just configure the NextEPC to connect via SGS to OSMO-MSC, like this:
>
> sgsap:
> addr: 127.0.0.1
> port: 29118
> name: vlr.example.net <http://vlr.example.net>
> tai:
> plmn_id:
> mcc: 724
> mnc: 21
> tac: 12345
> lai:
> plmn_id:
> mcc: 724
> mnc: 4
> lac: 51544
>
> And the configuration in the MSC:
>
> sgs
> local-port 29118
> local-ip 0.0.0.0
> vlr-name vlr.example.net <http://vlr.example.net>
>
> And configure the IMSI in the Osmo-HLR and NextEPC-HSS
>
> If you need more help tell me.
>
>
> Thanks
>
> Romeu Medeiros
>
>
> And
>
> On Fri, Jul 19, 2019 at 1:31 PM Rafael Diniz <rafael(a)rhizomatica.org
> <mailto:rafael@rhizomatica.org>> wrote:
>
> Hi all,
>
> I'd also like to test SMS and CSFB in LTE. I have some experience with
> the Osmocom GSM stack, but not much with the NextEPC LTE. Could you
> point me which fields should I set in the configuration files?
>
> Thanks,
> Rafael Diniz
>
> On 7/13/19 6:35 PM, Romeu Medeiros wrote:
> > Hello Sukchan and friends.
> >
> > I'm trying to use the CSFB in test lab, and every time that
> nextepc send
> > the UEContextModificationRequest, the UE respond with an
> > UEContextModificationFaliure [ Protocol-cause=semantic-error ].
> >
> > image.png
> >
> > I'm looking why I'm getting this. Someone have any idea?
> >
> > Thanks
> >
> > Romeu Medeiros
> >
> > On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom(a)gmail.com
> <mailto:acetcom@gmail.com>
> > <mailto:acetcom@gmail.com <mailto:acetcom@gmail.com>>> wrote:
> >
> > Dear Osmocom & NextEPC Community,
> >
> > Today I've added CS Fallback and released NextEPC v0.5.0
> >
> > So, I'd just like to test this part with Osmocom project, but it
> > seems to be a difficult task. The reason is why I have little
> > knowledge about 2G/3G. Nevertheless, I will try to do it
> >
> > BTW, I don't know if there is anyone who wants to integrate
> this big
> > thing.
> > Even though I'm not sure if this will help, but let me
> introduce the
> > configuration of the NextEPC.
> >
> > To use SGsAP, change the mme.conf as follows:
> >
> > #
> > # <sgsap>
> > #
> > # o Single MSC/VLR
> > # sgsap:
> > # addr: 127.0.0.2
> > # plmn_id:
> > # mcc: 001
> > # mnc: 01
> > # tac: 4130
> > # lac: 43690
> > #
> > # o Multiple MSC/VLR
> > # sgsap:
> > # - addr: 127.0.0.2
> > # plmn_id:
> > # mcc: 001
> > # mnc: 01
> > # tac: 4131
> > # lac: 43692
> > # - addr
> > # - 127.0.0.3
> > # - fe80::2%lo0
> > # plmn_id:
> > # mcc: 001
> > # mnc: 01
> > # tac: 4132
> > # lac: 43692
> > # - name: msc.open5gs.org <http://msc.open5gs.org>
> <http://msc.open5gs.org>
> > # plmn_id:
> > # mcc: 001
> > # mnc: 01
> > # tac: 4133
> > # lac: 43693
> > #
> >
> > FYI, I also attach the pcap that I run with nextepc simulator
> as below.
> >
> > $ ./tests/testcsfb
> > mo-idle-test : SUCCESS
> > mt-idle-test : SUCCESS
> > mo-active-test : SUCCESS
> > mt-active-test : SUCCESS
> > All tests passed.
> >
> > Feel free to raise any questions about this things.
> >
> > Best Regards,
> > Sukchan
> >
>
Hi all,
I'd also like to test SMS and CSFB in LTE. I have some experience with
the Osmocom GSM stack, but not much with the NextEPC LTE. Could you
point me which fields should I set in the configuration files?
Thanks,
Rafael Diniz
On 7/13/19 6:35 PM, Romeu Medeiros wrote:
> Hello Sukchan and friends.
>
> I'm trying to use the CSFB in test lab, and every time that nextepc send
> the UEContextModificationRequest, the UE respond with an
> UEContextModificationFaliure [ Protocol-cause=semantic-error ].
>
> image.png
>
> I'm looking why I'm getting this. Someone have any idea?
>
> Thanks
>
> Romeu Medeiros
>
> On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom(a)gmail.com
> <mailto:acetcom@gmail.com>> wrote:
>
> Dear Osmocom & NextEPC Community,
>
> Today I've added CS Fallback and released NextEPC v0.5.0
>
> So, I'd just like to test this part with Osmocom project, but it
> seems to be a difficult task. The reason is why I have little
> knowledge about 2G/3G. Nevertheless, I will try to do it
>
> BTW, I don't know if there is anyone who wants to integrate this big
> thing.
> Even though I'm not sure if this will help, but let me introduce the
> configuration of the NextEPC.
>
> To use SGsAP, change the mme.conf as follows:
>
> #
> # <sgsap>
> #
> # o Single MSC/VLR
> # sgsap:
> # addr: 127.0.0.2
> # plmn_id:
> # mcc: 001
> # mnc: 01
> # tac: 4130
> # lac: 43690
> #
> # o Multiple MSC/VLR
> # sgsap:
> # - addr: 127.0.0.2
> # plmn_id:
> # mcc: 001
> # mnc: 01
> # tac: 4131
> # lac: 43692
> # - addr
> # - 127.0.0.3
> # - fe80::2%lo0
> # plmn_id:
> # mcc: 001
> # mnc: 01
> # tac: 4132
> # lac: 43692
> # - name: msc.open5gs.org <http://msc.open5gs.org>
> # plmn_id:
> # mcc: 001
> # mnc: 01
> # tac: 4133
> # lac: 43693
> #
>
> FYI, I also attach the pcap that I run with nextepc simulator as below.
>
> $ ./tests/testcsfb
> mo-idle-test : SUCCESS
> mt-idle-test : SUCCESS
> mo-active-test : SUCCESS
> mt-active-test : SUCCESS
> All tests passed.
>
> Feel free to raise any questions about this things.
>
> Best Regards,
> Sukchan
>
Hi Harald,
The srsLTE implementation is taken from the ETSI specs simulation program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and http://cryptome.org/uea2-uia2/snow_3g_spec.pdfhttps://www.etsi.org/intellectual-property-rights#mytoc3 and https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing details for software incorporated in ETSI standards however I have not taken legal advice on compatibility of this license with AGPLv3.
>From a quick review, it looks like the CryptoMobile and NextEPC versions have taken the same approach.
It would be good as you say to have a "clean copyright" implementation - perhaps this is something we could help with.
Best regards,
Paul
> Hi!
>
> I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for
> NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME.
>
> However, it seems there is no real FOSS implementation of the SNOW-3G algoritm
> around? All I could find was:
>
> * https://github.com/mitshell/CryptoMobile with unclear source of the code,
> without a copyright statement or license annotation
>
> * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main…
> without a copyright statement or license annotation
>
> * https://github.com/Jadson27101/SNOW_3G in go,
> without a copyright statement or license annotation
>
> * https://github.com/KsirbJ/SNOW-3G
> without a copyright statement or license annotation
>
> * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c
> without a copyright statement or license annotation. Looks rather similar
> to CryptoMobile. Possible just copy+pasted from ETSI reference implementation?
>
> * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc
> also contains no coypright statement or license, but might be construed
> to be AGPLv3 like all of srsLTE. However, it states it is "adapted"
> from ETSI/SAGE specifications. Does that mean it is an independent
> implementation of the algorithm by just reading the specs, or does it
> contain actual ETSI-copyrighted code?
>
> It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement)
> don't contain any actual information but all just point to the ETSI SAGE specification
> which can be found (at the very least) here:
> https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf
> and interestingly doesn't contain any copyright statement whatsoever.
>
> This discussion is not about any potentially 'essential patents' that may or may
> not apply in some jurisdictions on the algorithm itself. I'm currently only interested
> in a "clean copyright" implementation of any of the EIA/EEA implementations used
> on the LTE NAS layer.
>
> I'd appreciate any useful comments. Thanks!
>
> --
> - Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/openbsc>> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
--
________________________________________________________________
Paul Sutton Ph.D.
Software Radio Systems (SRS)
http://www.softwareradiosystems.com
paul(a)softwareradiosystems.com
PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
________________________________________________________________
Dear Osmocom & NextEPC Community,
Today I've added CS Fallback and released NextEPC v0.5.0
So, I'd just like to test this part with Osmocom project, but it seems to
be a difficult task. The reason is why I have little knowledge about 2G/3G.
Nevertheless, I will try to do it
BTW, I don't know if there is anyone who wants to integrate this big thing.
Even though I'm not sure if this will help, but let me introduce the
configuration of the NextEPC.
To use SGsAP, change the mme.conf as follows:
#
# <sgsap>
#
# o Single MSC/VLR
# sgsap:
# addr: 127.0.0.2
# plmn_id:
# mcc: 001
# mnc: 01
# tac: 4130
# lac: 43690
#
# o Multiple MSC/VLR
# sgsap:
# - addr: 127.0.0.2
# plmn_id:
# mcc: 001
# mnc: 01
# tac: 4131
# lac: 43692
# - addr
# - 127.0.0.3
# - fe80::2%lo0
# plmn_id:
# mcc: 001
# mnc: 01
# tac: 4132
# lac: 43692
# - name: msc.open5gs.org
# plmn_id:
# mcc: 001
# mnc: 01
# tac: 4133
# lac: 43693
#
FYI, I also attach the pcap that I run with nextepc simulator as below.
$ ./tests/testcsfb
mo-idle-test : SUCCESS
mt-idle-test : SUCCESS
mo-active-test : SUCCESS
mt-active-test : SUCCESS
All tests passed.
Feel free to raise any questions about this things.
Best Regards,
Sukchan
Hi!
I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for
NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME.
However, it seems there is no real FOSS implementation of the SNOW-3G algoritm
around? All I could find was:
* https://github.com/mitshell/CryptoMobile with unclear source of the code,
without a copyright statement or license annotation
* https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main…
without a copyright statement or license annotation
* https://github.com/Jadson27101/SNOW_3G in go,
without a copyright statement or license annotation
* https://github.com/KsirbJ/SNOW-3G
without a copyright statement or license annotation
* https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c
without a copyright statement or license annotation. Looks rather similar
to CryptoMobile. Possible just copy+pasted from ETSI reference implementation?
* https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc
also contains no coypright statement or license, but might be construed
to be AGPLv3 like all of srsLTE. However, it states it is "adapted"
from ETSI/SAGE specifications. Does that mean it is an independent
implementation of the algorithm by just reading the specs, or does it
contain actual ETSI-copyrighted code?
It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement)
don't contain any actual information but all just point to the ETSI SAGE specification
which can be found (at the very least) here:
https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf
and interestingly doesn't contain any copyright statement whatsoever.
This discussion is not about any potentially 'essential patents' that may or may
not apply in some jurisdictions on the algorithm itself. I'm currently only interested
in a "clean copyright" implementation of any of the EIA/EEA implementations used
on the LTE NAS layer.
I'd appreciate any useful comments. Thanks!
--
- 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,
I'm very happy to have received the below attached news via the Eclipse
bugzilla.
This is great, as it permits us to have "real" SI rest octet as well as
RLC/MAC support in our TTCN3 test suites while still using declarative
RAW codec syntax.
Just to be clear there's no misunderstanding: This doesn't mean that
CSN.1 syntax can be parsed by TITAN. It just means that we can use RAW
codec annotations to describe something that matches the CSN.1 encoding.
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)
