Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hi all,
Today I'm working on updating my NuRAN unit with the new osmo stack in
order to try to reproduce the same behavior of old osmo-nitb we use in
production in Rhizomatica (with subscriber_create_on_demand feature on).
I'm writing just in case someone already put online a set of config
files with the parameters needed by such behavior set?
; )
ps: I have the new splip stack working fine here, I just need to modify
my setup with new features to support subscriber_create_on_demand.
Best regards,
Rafael Diniz
Dear all,
I've been asked by a number of pepole about a possible Osmocom village at the
CCC Camp 2019. I personally didn't really have any plans, but given related
e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
see
https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
I also created a wiki page (as nobody else did, despite earlier discussion on IRC,
SCNR) for coordinating related efforts at
https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
One of the bigger questions is about having a tent as well as some tables/benches
to sit on and work. The Camp orga team nas been negotiating rates with a tent
rental company, but to be honest I'm rather surprised by the extremely steep
pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not
sure we want to raise that amount of money? Even if we'd be 10 people sharing
it, its still 82.50 EUR per person. And that excludes any tables/chairs.
I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
Please note there also is some kind of fragmentation / overlap with the
team planning to run the GSM/3G networks at the camp, see Lynxis'
related post at
https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003…
It's questionable whether it makes sense to have tow distinct
'villages', but given that e.g. I don't know anyone of that singularity
city, I'm not sure if we'd either be welcome there, nor whether we'd
want to associate us with them? Also, while the GSM network operation
for sure has good reasons to mingle with the POC and whatever facilities
they have, I'm not sure if the wider Osmocom community attendees
unrelated to the GSM network operation wouldn't just be a
disturbance/nuisance.
In the end, to be honest, I personally do not feel I have the time and
mental capacity to take on any additional tasks in terms of organizing
anything. I just created the entry in c3assemblies as I was asked to,
and I similarly created the related mailing list and wiki page.
So please, anyone interested in making an Osmocom village happen one way
or another, step up [and continue this discussion on the
camp2019-village(a)lists.osmocom.org mailing list, without crossposting
everywhere else :)
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)
Hello Vadim,
I'm working on the TTCN3 tests for OsmoPCU. Harald told me, that there
are a few tests existing tests (such as TC_ul_tbf), that had been
developed with osmo-bts-virtual/virt_phy.
He also said that since there is trxcon/fake_trx nowadays, it would be
better to use that instead, if it supports PDCH. From a quick "git
grep", it looks like PDCH is supported in trxcon.
What do you think, should it work well enough to do the switch?
Thanks,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Hello All,
I am working on get OpenBSC connected to a 3rd party MSC, I read from the
Osmo document that I can use the bsc only mode and the osm-bsc instead of
the osmo-nitb.
Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp
configured and and running, but I see a lot of below error logs in the
osmo-stp console:
```````````````````````````
DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb():
sctp_recvmsg() returned 56 (flags=0x80)
DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA)
DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer
DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header:
opc=337=0.42.1 dpc=185=0.23.1
DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not
local, message is for routing
DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route!
````````````````````````````
On the BSC console, I am seeing a lot of:
```````````````````````````````
<0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP
RESET message...
<0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP
```````````````````````````````
Can anyone identify what is the issue here?
Appreciates!
Regards,
Weiqi
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)
Dear Osmocom community,
during recent years we have developed a quite extensive set of test suites
for virtually all interfaces on all protocol levels of our 2G stack, and
recently even extended at least with some 3G IuCS coverage.
Those test suites are considerably valuable for testing any kind of
implementation of 2G / 3G network elements, even beyond Osmocom. I'm a
bit worried that they might be used to test proprietary implementations,
which would bring no value to growing FOSS in mobile communications.
Whether we license the test suites under GPL or AGPL doesn't actually
change much here: Imagine "EvilCorp" developing a BSC, using our test
suites against it. They neither distribute the test suite, nor do they
provide "access over a network" to it, an hence they could keep any
modifications/extensions/derivatives private without having to
contribute those back.
I think this is problematic. We develop those test suites because we
care about having well-tested FOSS in cellular communications, whether
Osmocom or other FOSS projects. I certainly don't want to spend my
spare time, or invest sysmocom resources towards improving the test
coverage of any non-FOSS implementations. If such users are out there,
they should at the very least contribute to the development effort in
one way (code) or another (funding).
For 2G/3G, I think this discussion is quite theoretical, as there is
unlikely anyone else implementing those old technologies in proprietary
systems - Osmocom is probably typically the latest player in the market
to do so.
However, as I'm currently working on a first set of TTCN3 tests for
testing a LTE MME (initially attacing to S1 and SGs), I'm wondering if
we should continue to release related code under traditional copyleft
licenses.
One idea would be to have a license that permits the use of the test
suites to test only FOSS software. In theory, that would mean that all
projects we care about (such as currently srsLTE, nextepc, OAI EPC, ...)
could use the test suites to test their software. On the other hand,
if some vendor of proprietary MME/EPC software would want to [legally]
use the tests, they would need to obtain a different (paid) license to
the test suite. Of course they could simply ignore the license and we'd
have little chance to learn about it - but I would argue most proper
companies typically would obtain a license if they used some software
they knew they had to license.
This is a very double-edged sword. Drafting such a new license would
cause license proliferation, which is always bad. It also raises
quesetions of license compatibility with e.g. some of our common
existing 'library' code that would need to be investigated. Finally, it
also means that we'd no longer be writing "free software" nor "open
source", as the respective relevant definitions always require "non
discriminatory use for any purpose", which would no longer be the case
here.
This is currently an early stage brainstorming. Now is the right point
in time to talk about this, before we release any LTE/EPC related tests.
Let me know if you have any thoughts to share. While I'm cross-posting
this to openbsc@ and nextepc@ lists, pleaes follow-up-to
openbsc(a)lists.osmocom.org, as that's the main Osmocom mailing list and
we don't have any specifically only for the test suites.
--
- 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 ML,
I'm wondering why we do not have gsmtap logging enabled for TTCN3
testsuites, and if there are any reasons against doing that.
Personally I find it very useful to have gsmtap logs in pcap files,
because then then there is no need to manually match the timestamps of
the log file and interesting parts of the pcap dump.
Especially in the TTCN3 testsuites, where we generate a separate pcap
file for each test, but have one big log file of the SUT (e.g. osmo-hlr)
for the entire testsuite run.
Thoughts?
Thanks,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Hi Holger,
I was planning to add osmo-pcap recipes to meta-telephony soon, and
first of all I wanted to make a new release since last tag (0.0.6)
looked quite old. But then I found in debian/changelog that actually a
lot of new releases exists, but their git tags are missing in the
osmo-pcap git repository.
So after making sure I updated my tag list from the server (gerrit). I got:
$ git tag
0.0.1
0.0.2
0.0.3
0.0.4
0.0.5
0.0.6
but according to git log from debian/changelog, releases 0.0.7-0.0.11 do
exist.
Interestingly, tags 0.0.5 and 0.0.6 point to the same commit.
Commits adding new releases without tags, see for instance:
a316c9394aa27d25b3d7fba004563890a43ab1bc (0.0.7 added)
fbdcf593f80d4fe5330376674136fd76fcef5ea2 (0.0.8 added
c016b5d3824923c2b35c67cfb9930a30e564f07e (0.0.9 added)
fdebd88059df3a8f717614548dcd7247e8890f9a (0.0.10 added)
17f5b005066a15312525e53e7b4a574d40011f96 (0.0.11 added)
4776b2972e84ef75b3a1c884da19604d87fc7f68 (a new commit added to 0.11
section?)
So, I want to ask if there's some explanation for those tags missing or
you simply forgot to push them when creating the releases (or they got
somehow lost in the server).
Do you happen to have the tags locally and can push them? or otherwise
generate the tags now and push them. I can also do it if you want, I'll
push tags on the commits from the list I wrote above.
BTW, in case you run into a Make error while building current master, it
may be fixed here:
https://gerrit.osmocom.org/c/osmo-pcap/+/14666
Regards,
Pau
--
- Pau Espin Pedrol <pespin(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
Hello,
Has anybody tested PS (either 2G or 3G) with Samsung phones?
Have you experienced any problems? (like having no internet though at
the same time PDP is active and GTP traffic is flowing in both
directions)
Kind regards,
Mykola Shchetinin
