> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester.
I have run a tcpdump on the ntp port for the past days, and nothing is doing
ntp besides the actual ntp service.
Today I started ntp while an osmo-bts-trx run was active and what do you know,
the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx
shouldn't use wall clock time for precise timing needs.
Besides that, I have no idea what could cause the clock skews, except maybe
that the CPU or the USB are not fast enough?? I'm wondering, is there still
such a thing as a separate linux realtime kernel?
We will soon take to productive use another main unit which will be a cleanly
installed OS. If we see the same problems on that system and can't find a
software fix, we may need to reconsider the tester for osmo-bts-trx...
~N
I'd like to share a VTY config error analysis that has a tricky solution:
I started osmo-bsc -c osmo-bsc.cfg with, according to
openbsc/doc/examples/osmo-bsc:
net
[...]
bts 0
[...]
periodic location update 30
trx 0
[...]
and get this error:
There is no such command.
Error occurred during reading below line:
trx 0
what? 'net / bts / trx' is no command??
Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on
this branch, I've actually moved the 'periodic location update N' command a
level up, from net / bts / periodic to net / periodic (background: assuming
that OsmoMSC does not have individual BTS info, we moved some settings up to
network level; whether this makes sense for osmo-bsc is a different question,
it's just what happens to be on the vlr_3G branch now).
So there is no net / bts / periodic command.
Why do I get an error for net / bts / trx instead?
two reasons:
1. 'trx 0' was the line following the 'periodic' command,
2. since 'periodic' exists one level above, the vty code goes to the parent
node automatically.
About 2: we tend to indent our VTY config files, but in fact the indentation
has no effect whatsoever, it is just eye candy (very useful eye candy).
The code in question: If a command does not exist, try 'vty_go_parent()' and
see if the command exists there. That's what allows us to omit 'exit' in our
config files to go to the parent node explicitly:
libosmocore/src/vty/command.c:
int config_from_file(struct vty *vty, FILE * fp)
{
int ret;
vector vline;
while (fgets(vty->buf, VTY_BUFSIZ, fp)) {
vline = cmd_make_strvec(vty->buf);
/* In case of comment line */
if (vline == NULL)
continue;
/* Execute configuration command : this is strict match */
ret = cmd_execute_command_strict(vline, vty, NULL);
/* Try again with setting node to CONFIG_NODE */
while (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO
&& is_config_child(vty)) {
HERE -----> vty_go_parent(vty);
ret = cmd_execute_command_strict(vline, vty, NULL);
}
cmd_free_strvec(vline);
if (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO)
return ret;
}
return CMD_SUCCESS;
}
In this case the 'periodic...' command does in fact now exist one level above,
so the vty_go_parent() is successful and running that command works. But, the
vty config parsing then sits above on the 'network' level, is no longer in 'bts
0' and hence refuses to accept the following bts-level command, in this case
'trx 0'. Confusing!
So it's not a bug, it's a feature. But it's a feature we might see quite often
if we move the 'periodic' command up to network level and users attempt to use
their old config files.
Same goes for the 'timezone' command, BTW, so we might want to rename commands,
or re-consider moving commands one level up in the first place. Maybe we should
leave backward compat catchers in place that print a warning.
~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 FreeCalypso and Osmocom communities,
I am in the process of creating an informal organisation representing
the interests of those members of the GSM universe whose interests are
not represented by GSMA etc, and I am inviting you to join me in this
venture. I propose that we name our informal organisation GSMUA,
standing for GSM Users Association, and my vision for this GSMUA is to
be a counter-body (antibody?) to the official GSMA. I just registered
the gsmua.org domain name, but there is no website or mailing list set
up yet. If someone from the Osmocom camp would like to host the
server infrastructure for gsmua.org, I will happily point the DNS to
you, otherwise the FreeCalypso family can host it on our server.
My vision for GSMUA is to represent the interests of GSM end users
(empowered end users who wish to fully own and control all aspects of
their user equipment while operating on public mobile networks in a
fully spec-compliant manner), small boutique manufacturers of GSM
devices (both MS/user equipment and network infrastructure), small
community network operators and others whose interests are not
represented by GSMA etc, especially in cases where our interests are
in direct conflict with the interests of big players such as giant
device manufacturers, giant commercial network operators and
governments.
A key goal of GSMUA is to be project-neutral, that is, every person
and every small company belonging to any of the categories listed
above (empowered end user, small boutique device manufacturer, small
community network operator etc) should be fully welcome regardless of
which specific project they are associated with. As of today there
are at least two different projects offering GSM MS implementations
(OsmocomBB and FreeCalypso) and at least two different projects
offering network-side GSM implementations (Osmocom and OpenBTS), and I
hope that this number of available alternatives will continue to grow:
freedom of choice is always a good thing. But at the present time
there exists no neutral soil on which members of different projects
with a common interest (GSM networks and devices serving the interests
of end users rather than big corporations and governments) and a
common enemy (just named) can meet, and this lack of neutral meeting
ground is the problem which GSMUA is meant to solve.
I also have one practical application for GSMUA in mind already: to
manage and legitimize recycling of wasted IMEI number ranges. By the
official rules of GSMA etc each different *type* of GSM mobile
equipment requires a different TAC, i.e., a range of at least 1 million
IMEI numbers. So if a small boutique GSM device manufacturer makes a
boutique MS device of which no more than 100 units will ever be made,
999900 IMEI numbers have to be wasted by the official rules. While I
don't know of any manufacturer who got a range of 1 million IMEIs and
only made 100 devices, we do have examples like Openmoko GTA01/02 and
Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that
about 15 thousand units were made in total; in the case of Pirelli
DP-L10 it appears that the total number produced was somewhere under
100 thousand. In each case a full range of 1 million IMEIs was
allocated, and at least 900 thousand numbers out of each range are
currently unused and wasted.
If a small boutique manufacturer wishes to offer a boutique GSM MS
product to the general public and wishes to ship each unit with a
world-unique IMEI that stands a good chance of being accepted as valid
by common GSM networks, and the product in question does not qualify
for IMEI allocation by the official rules (e.g., the product is a
development board specifically intended for users to run their own
firmware and connect to live public networks with it, taking full
personal responsibility for their actions) - the situation I found
myself in with my GSM MS development board - I feel that the small
boutique manuf in question should be empowered to squat on a small
subrange of someone else's IMEI range if it is known beyond reasonable
doubt to be wasted and unused.
However, this recycling of wasted IMEI number ranges could be better
organized and given at least some aura of semi-legitimacy if there
were a community body set up to manage it, and this is where my
proposed GSMUA can come in. Once we get our GSMUA up and running and
assign a group of volunteers to be IMEI recycling managers, any small
GSM or 3G+ device manufacturer who needs a small range of IMEI numbers
will be able to request one from GSMUA, and we will allocate and
assign these small subranges out of whatever wasted range we decide to
squat on, ensuring that each requestor gets a different subrange.
So these are my ideas, and I would like to see them turn into reality.
We are going to need a simple website and a community mailing list at
gsmua.org, and for the IMEI recycling service we will need a small
group of volunteers to serve as its managers - I and Das Signal from
FreeCalypso will be happy to serve on that panel, but it would be nice
to also have someone from the Osmocom camp for better neutrality.
Bright Blessings,
Mychaela Falconia,
Mother of FreeCalypso
Hi,
Till now I have always worked with simcards without knowing their ki so I was not using any encryption. I have recently bought some programmable simcards and gave them an IMSI and KI and tried to have them working with ‘encryption a5 1’ and ‘encryption a5 3’ and I faced some problems. First if I choose 'a5 3' the phone cannot connect to the BTS and nothing can be done, while if I set the encryption to 'a5 1’, the phone connects normally and can make and receive calls but sometimes the call fails for a reason that I don’t know. I have then tried the following setup:
I have connected 3 phones A, B and C. A and B have no KI related to them so no encryption is applied while C was given a KI.
If I call from A to B or from B to A, the call is done successfully every time, while if I call from either A or B to C or from C to A or B the call might work and might not. Is there something in the configuration that should be changed when adding the encryption support ? And how to enable the a5 3 encryption ?
Best regards,
We need to decide which way to go with point codes, sccp- and ss7-instances.
pmaier and I have reached different conclusions and wrote patches going in
opposite directions, now we need to decide and cosolidate:
The MSC has various connections over SCCP: it serves BSSAP for several BSCs,
and RANAP for several HNBGWs.
BSC - A MSC:
BSC -}----------> BSSAP
BSC - -----> RANAP
/
HNBGW -}-/ IuCS
HNBGW -
1)
I went for exactly one point code at the MSC (say PC=1). There is exactly
one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate
sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to
the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up().
When comparing to the TCP/IP model, the paradigm here is that a PC is like an
IP address and the SSN like a port number. At the server, the MSC, I have one
PC (IP address) and listen on one SSN (port) per protocol served, and clients
all connect to the same PC+SSN, receiving separate connection IDs. I can also
use the calling address to know which client I'm talking to.
Hence I moved the osmo_sccp_instance creation up to "the top" and created two
sccp_user_bind()s, one for BSSAP and one for RANAP. This works in practice.
I can tear down and set up individual sccp_users (i.e. disable/enable IuCS or A
separately), and handling different clients is done by the conn_ids and
possibly keeping distinct osmo_sccp_addresses.
An pseudocode MSC VTY config for this scenario could look something like this:
msc
sccp local-pc 0.0.1
ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb
ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb
remote-bsc 1
pc 1.0.1
remote-bsc 2
pc 1.0.2
remote-hnbgw 1
pc 2.0.2
i.e. one local PC is configured, each protocol has its separate SSN, each
sccp_user_bind() serves all clients for that SSN.
This is the direction I took to add IuCS to AoIP.
2)
pmaier added VTY configuration for various point codes, and went the other way:
the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is
told the addresses of all known BSCs and) every time a BSC is configured via
VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a
distinct local PC for each BSC, and for each HNBGW.
In this model there still is a code problem I noticed while adding IuCS to AoIP
in OsmoMSC: if I call osmo_sccp_simple_client() a second time with a different
PC, the osmo_ss7_instance used is still the same (still id=1), and notes this
second PC as its global local PC. The messages received for the first client's
PC are then seen as remote and routed back out -> infinite message loop. A
solution here would be to either a) use a separate osmo_ss7_instance per
osmo_sccp_simpe_client() (simply add an ss7 instance id parameter to
osmo_sccp_simpe_client() and increment by one each time) or b) implement the
routing algorithm so that it notices the local PCs of several local SCCP
clients.
A VTY config for this scenario so far looks like this:
! define some addresses, referenced below
cs7 instance 1
sccp-address msc_local
subsystem-number 254
point-code 0.0.1
routing-indicator PC
sccp-address bsc_remote
subsystem-number 254
point-code 0.0.2
routing-indicator PC
sccp-address bsc_remote2
subsystem-number 254
point-code 0.0.3
routing-indicator PC
msc
bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote
bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote2
(I'm not sure whether it is possible to have several sccp_instances with the
same msc_local address, but we would find solutions for these petty issues once
we've decided which way to go.)
(I also think 'calling-addr' and 'called-addr' should rather be named
'local-addr' and 'remote-addr': depending on who calls who, the calling-addr
can be the remote or the local one. That's also besides the point for now.)
My personal idea is that 1) is simpler: we have one ss7 instance per program,
no matter how many clients are served. I can still tear down and set up
individual sccp_users (i.e. disable/enable IuCS or A separately), and handling
different clients per SSN is done by the conn_ids and possibly keeping distinct
osmo_sccp_addresses of the clients. 2) seems to me easier to misconfigure and
it sounds to me like a paradigm of creating a whole new server for each client
that connects, so instead of using an ss7_instance's routing, we create
separate instances, each sending to only one counterpart.
But is 2) maybe the correct way to go for reasons I'm not aware of?
I notice that what I wrote is biased towards 1) because that's my POV, but this
is indended to be a neutral question.
We need a choice for 1) or 2) so that pmaier and I can adjust and merge our
patches accordingly. Can you help us decide, hopefully with some background
knowledge on how an SCCP network is intended to be set up?
Thanks!
~N
I successfully tested some new patches on the AoIP branch locally and pushed
them to the openbsc.git/aoip branch. They allow using 3G with AoIP.
@pespin: if aoip tester runs fail now, that's probably the cause.
@pmaier: I tried to apply all patches found on the pmaier/aoip branch, but
excluded the commits started with "MSC side reset" because of build failure.
The failure is the same I saw a few days ago, still unchanged:
CCLD osmo-bsc_nat
../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_go_parent':
/n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:130: undefined reference to `osmo_ss7_vty_go_parent'
../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_is_config_node':
/n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:140: undefined reference to `osmo_ss7_is_config_node'
collect2: error: ld returned 1 exit status
I suspect you still have some of your work not pushed to libosmo-sccp?
I can't find a private branch or patches on gerrit about osmo_ss7_vty.
In general I think it would be good to always keep your work on a private
branch and push it frequently (doing anything you like on it, amending and so
forth). For collaboration, but also to have a backup of your patches...?
If you like, we can have a call soon to figure out a rebase of your work onto
aoip. A merge conflict is solved on the neels/pmaier_aoip branch ('git fetch'
first), but I get above build failure.
~N
Hi.
In a light of https://projects.osmocom.org/issues/2340 I'd like to add .deb build as
an additional step for jenkins jobs triggered by gerrit push.
It'll mean longer build times but it'll prevent breaking changes from reaching
master. It won't guarantee that we won't see occasional arch/version specific
breakage in https://build.opensuse.org/project/monitor/network:osmocom:nightly but it
should make nightly builds more stable and easier to maintain.
What do you think?
--
Max Suraev <msuraev(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
