Hello all and Sukchan,
I'll try to use another database with nextepc. (PostgreSQL).
Let me ask something, only the HSS need the database connection?
Thanks
Romeu Medeiros
Hi all,
During the Chaos Communication Camp 2019 (an international hacker camp
with about 5500 participants) last week, there is a tradition to operate
Osmocom based 2G and more recently also 3G networks.
This time I operated a nextepc based 4G/LTE network next to the camp 2G/3G
networks. In order to share one subscriber database, I have implemented
osmo_dia2gsup, which can translate the S6a/S6d diameter into Osmocom GSUP
protocol, so nextepc can be used without nextepc-hssd but with osmo-hlr instead.
The network was operating six Ericsson RBS6402 in Band 7 (2600 MHz).
Some more details can be found at
Regarding the nextepc side:
* 2439 uniqua IMSIs were seen
** 147 unique IMSIs of CCC SIM cards (26242)
** 2292 non-CCC IMSIs
** 75 unique MCC-MNC tuples
** 34 unique MCCs
** The usual suspects (Europe + North America), but also...
*** Malaysia, Indonesia, Australia, New Zealand, South Africa
* 560 Attach accept (CCC SIM cards)
* 46590 Attach reject (commercial operator SIM cards)
* 629 PDN context (APN) activations
* 235 handovers between cells (X2)
* 64 crashes + restarts of nextepc-mme
* 9 crashes + restarts of nextepc-pgw
* 0 crashes + restarts of nextepc-sgw
* 10 crashes + restarts of nextepc-pcrf
In general, it worked quite nicely, and I have to congratulate Sukchan on
his work at nextepc.
I investigated some of the crashes, reported them to the issue tracker and
attempted to fix some of them on-site. The actual codebase that was running
can be found at https://github.com/laf0rge/nextepc/commits/laforge/cccamp19
>From my experience with operating such a "large" nextepc network for the first
time, I have the following overall feedback, which basically boils down
to three major areas:
== the use of assert() ==
ASSERT should never be triggered by anything that is received from another
network entity. So if a eNB sends an unknown S1AP-ID, or if a SGW sends
an unknown TEID, or if the NAS MAC validation fails, or a EMM message
cannot be decoded - all of those must be handled gracefully without
terminating the program. This 'fail fast' way of programming can be
done when writing code in C++ (exceptions that are caught) or in erlang
(one process per message, crashing that one doesn't bring the entire MME
down).
I've tried my best to review all ogs_assert() in the MME and came up
with the following patch:
https://github.com/laf0rge/nextepc/commit/3b528af8fd51c85769123338eb57a4635…
which requires
https://github.com/laf0rge/ogslib/commit/dc36ccbb080038306666931bdc97f6204f…
which introduces ogs_expect() and ogs_expect_or_return() macros that can
be used in many places instead of ogs_assert().
It would also be possible to use this kind of 'fail fast' approach in C
programs, but then one would have to use longjmp() from the 'assert',
and you would have to use some kind of hierarchical memory allocator so
that in the 'exception handler' you can release any dynamic allocations
that were made before.
== the lack of introspection ==
When you operate a network, it is vital to have some visibility. For the
MME you want to inspect how many subscribers are currently attached, where
they are attached (TAC), whether they currently have an UE Context (and at
which eNB), which TMSI/GUTI was allocated, etc.
Likewise, for both SGW and PGW you want to see which PDN contexts exist, from
which peer IP adresses, which APN was used, what IP addresses have been allocated, etc.
In the Osmocom world, we implement this introspection in two ways:
* by means of the VTY interface (for the human user)
* by means of the CTRL interface (for other programs)
If I hadn't been busy with debugging various other issues, I would have actually
attempted to add a basic VTY interface to nextepc-mmed.
For sure there may be better ways to expose this state (ideally with the same
piece of code providing access to both human users as well as external programs),
but I'm not aware of any nice C language implementation in FOSS that one could
use right away.
== logging without context ==
When looking at log file output, it is very important that this log file output
always carry sufficient context. IF there are many subscribers acting in parallel,
you need to know which subscriber / pdn context / ... a given log message relates
to, otherwise the log message is rather useless.
For example, if you get
[mme] DEBUG: [MME] Authentication-Information-Answer (mme-fd-path.c:211)
then even at DEBUG level you have no indication what so ever for which
particular subscriber this AIA was received. I would normally expect
that the UE is resolved from the DIAMETER session-id, and then the UEs
identity (IMSI) can be printed.
I also find it suboptimal that log lines often span multiple lines, which means
you cannot simply 'grep' for something, as you always need to check some lines
before and/or after. But I guess conrary to the lack of context, this
is a matter of teste and one can have different opinions about it.
I'll try to contribute as much as I can regarding bug fixes and
enhancements. Thanks again for all the great work so far!
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 Community People.
Some people are asking about next plan. I didn't answer correctly because I
don't know how much time I have or how much my abilities are possible. But
now I think I need to start sharing what I want to do.
I don't know if it's possible to this, but I'd just like to prepare to move
5G Core. But there are a lots of things before that and I don't know
exactly when this project is going on.
Anyway, in order to share the code used by 4G/5G, I will separate the
repository as follows:
Repo1 : libogscore - apt install libogscore-dev
Repo2 : libogs-asn1c
- common : apt install libogs-asn1c-common-dev
- s1ap : apt install libogs-asn1c-s1ap-dev
Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev
- libfdcore
- libfdproto
Repo4 : libogslib - apt install libogslib-dev
- s1ap : apt install libogs-s1ap-dev
DEPEND libogs-asn1c-common-dev libogs-asn1c-s1ap
- nas : apt install libogs-nas-dev
- gtp : apt install libogs-gtp-dev
- diameter : apt install libogs-diameter-dev
DEPEND libogs-freeDiameter-dev
- app : apt install libogs-app-dev
Repo5 : ogs-mme - apt install ogs-mme
; DEPEND libogs-app-dev libogs-s1ap-dev libogs-nas-dev libogs-gtp-dev
libogs-diameter-dev
Repo6 : ogs-hss - apt install ogs-hss
; DEPEND libogs-app-dev libogs-diameter-dev
Repo7 : ogs-pcrf - apt install ogs-pcrf
; DEPEND libogs-app-dev libogs-diameter-dev
Repo8 : ogs-sgw - apt install ogs-sgw
; DEPEND libogs-app-dev libogs-gtp-dev
Repo9 : ogs-pgw - apt install ogs-pgw
; DEPEND libogs-app-dev libogs-gtp-dev libogs-diameter-dev
Repo10 : ogs-epc
; if all stuff are available, current nextepc repo is changed to ogs-dev
for managing issues list
This approach is similar to the osmocom project. In fact, I'm not sure
whether this is good or not. However, osmocom manages 2G/3G like this and I
believe that experience.
So I'll do it from now.
P.S.
Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;
Thanks a lot!
Best Regards,
Sukchan
Hi everyone,
Does someone know the difference between these two projects:
https://github.com/open5gs/nextepchttps://github.com/nextepc/nextepc
They seem to share some code, but the second one seems to be owned by a
US company, and the code as not been updated for months. (only 14
commits in the repo)
There are nextepc packages in the universe ubuntu repo too now, but I
don't know which version it is. Any idea ?
Which project should be used ?
Thanks,
Mathieu
Hi Sukchan and friends,
the installation instructions recommend changing the permissions of /dev/net/tun,
which can be dangerous as it gives permissions to potentially many other processes.
There are several better alternatives to this:
1) give CAP_NET_ADMIN permission to the pgw binary:
Simply execute "setcap cap_net_admin=ep /usr/local/bin/nextepc-pgwd"
and then you can run the process as 'nextepc' user, like the other processes.
The sad part about this is that nextepc-pgwd has now the power to reconfigure
anything about linux netwowrking. The best approach would be to drop those
capabiligies after creating/configuring the tun devices using
prctl(PR_CAPBSET_DROP, CAP_NET_ADMIN) - this way it is ensured that
after start-up, no capabilities survive, and even if somebody manages
to get code execution in the PGW, it is not a privilege escalation.
2) create the tun devices *before* starting the P-GW, and then start the
PGW as non-root. We offer this method in OsmoGGSN, see Section 8.3
of http://ftp.osmocom.org/docs/latest/osmoggsn-usermanual.pdf
This can even be done with systemd now.
I suggest to first change the documentation to recomend the setcap
approach, and then later to adopt privilege dropping or another
approach.
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,
I'm trying to setup nextepc to provide service for multiple ISPs with
the same core network.
Is there a way to ignore the APN configured in the UE, and rather use
the one configured with the webui ?
On the same topic, is it possible to restrict a UE to the apn configured
with the webui ?
Thanks,
Best regards,
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
Hello guys and @Sukchan Lee <acetcom(a)gmail.com>
I tested with sucess the send and receive SMS in new version of NextEPC
running together with OSMO-MSC/HLR (SGS).
Thanks
Romeu Medeiros
