Hi.
I've noticed that we do not use check_PROGRAMS in any of our Makefile.am (happy to be
corrected :) so all the tests/ binaries are built during "make" step instead of "make
check".
Is this intentional? If so - why? Is this smth we'd rather fix?
--
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
I am currently setting up separate repositories to replace openbsc.git.
Aspects:
- choice how to separate
- apply 3G and AoIP changes to do code review
My plan is to separate openbsc.git into these parts:
osmo-msc.git = OsmoMSC
osmo-bsc.git = OsmoBSC, OsmoBSCNAT
osmo-sgsn.git = OsmoSGSN, OsmoGTPHUB
osmo-mgw.git = new OsmoMGW, at first plain renamed from osmo-bsc_mgcp
+ libosmo-mgcp
Each of these will contain the full openbsc.git history to be able to follow
changes back in the log easily.
The libmgcp has so far been internal to openbsc.git. I intend to make it an
installed library from osmo-mgw.git (similar to libosmo-ranap from
osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate
with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not
been aware of until now.
libiu, shared between MSC and SGSN, has already moved to osmo-iuh.
The other thing the MSC and SGSN still share is the GSUP client. The GSUP
protocol code has already moved to libosmocore, but the gsup_client is still in
openbsc. I believe it is appropriate to move the gsup_client along to
libosmocore, even though the notion so far has been to keep it out of there.
Otherwise we either duplicate the gsup_client or need another separate
libosmo-gsupclient.
Possibly other code needs to be moved around similarly, but AFAICT "decreasing
in importance".
Code review:
We can review in various ways. I believe the least troublesome would be this:
- create osmo-msc git from the current openbsc.
- remove the top level 'openbsc' dir.
- go through all of the patches in gerrit to apply to 'master', which will
apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW,
all of these in osmo-msc.git.
- the state thus reached is the basis for the split. Copy this to osmo-*.git
- in each separate git, remove the files not needed for that particular project.
Remove possible remaining code duplication as we go.
openbsc.git
|
| copy
v
osmo-msc.git
|
| - `mv openbsc/* .`
v
| gerrit code review:
| +VLR
| +3G
| +AoIP
|
+-------------------------------
| |
v |
----------copy-------- |
| | | |
v v v |
osmo-bsc osmo-sgsn osmo-mgw osmo-msc
| | | |
| | | | clean unrelated files
v v v v
continue ongoing development from these new master HEADs
I'm currently playing through the separation, osmo-msc with top-level openbsc
removed is done, osmo-mgw and osmo-bsc pending. This means that I will need to
apply commits merged to openbsc from now on to the new separate gits until we
move over for good. That's fairly similar to keeping the 3G,AoIP branch rebased
onto openbsc master as we did previously. It may make sense to focus AoIP
development onto the new repositories soon.
So far I'm keeping the gits privately on a sysmocom office machine. We could
also open up new osmo-* repositories on gerrit and git.osmocom.org now.
~N
Hi all,
During experimenting with RACH requests in my virtual Um-interface
environment, I found an interesting issue in OpenBSC. According to
the specifications, every RACH request should contain BSIC value of
target base station, and if I understand correctly BSC (or BTS?)
should ignore such requests, where rach_bsic != bts_bsic (Ghost RACH).
Meanwhile, when I send all-zero sequence (just for testing) on RACH
lchan, BSC allocates me a channel despite bts_bsic != 0x00. It probably
also explains the reason, why sometimes in a real OpenBSC + OsmoBTS
setup I see channel requests, followed by channel allocation without
any further response from MS side.
So, do we have any BSIC matching functionality implemented somewhere?
If not, I could try to open an issue and implement it.
With best regards,
Vadim Yanitskiy.
Hey Osmocom,
I am trying to understand how to interact with the SGSN via the control
interface and do a few things that I can't find documentation for.
Hoping you can help explain how to:
1) Query(or push) CDRs for active data sessions
2) Terminate active PDP context (network initiated detach)
3) Manage the ACL for the PS domain (assuming via HLR?)
Thanks,
Omar
Hello Neels,
> (any reason to not discuss this on openbsc@?)
I put it on CC.
> Still missing in this proposal: how do you tell e.g. the MSC's A and
IuCS code
> to use a given SCCP instance, local SSN and remote SCCP address?
I would add a VTY command where the user has to tell on which ss7 instance
the A or IuCS interface should bind. When the IDs for both match up, we know
that we use the same SCCP instance, but I think we do not even have to check
that. Its implicit by the pointers. If the numbers are the same we will end
up with the same sccp instance pointer for both.
The SCCP-Addresses are defined by the addressbook. Which one is used will be
configured via a VTY command seperately. The SSNs are hardcoded, so this is
not a problem currently. If someone wants configurable SSNs and wants two
users with different SSNs but same local point codes (which is mandatory in
this case), then the user would have to define two addressbook entries where
only the SSN is different. Logically this is then a different address
and look
at postal addresses, there its the same. Two different houses next to each
other will have different addresses. The only difference is the number
(SSN).
At some point we have to make the cut.
We could think about unifying the osmo_sccp_user_bind() function as
well, so we
would get pointers for ready-to-go sccp-users as well, but I think this
is out
of scope right now. The solution would be similar to the addressbook. We
would
just define nodes which hold the parameters. The results end up in a
list and
after parsing is done. The user can call a function that only gets the
ID that
references the parameter set, the pointer to the sscp instance and the
function pointer for the SAP. e.g.:
osmo_sccp_user_bind_id(sscp,2,sccp_sap_up)
> A much simpler soultion to the problem would be to pack the configuration
> options into struct osmo_ss7_instance. Then when the config file parsing
> is done, the user must call a function e.g. "osmo_sscp_init()" or so to
> trigger the call to osmo_sccp_simple_client().
In struct osmo_ss7_instance we already have the .cfg sub struct. I think we
should add the items there instead of introducing something new. Also if
we do
so we would have to change it for the existing code too to have it
consistent.
Lets do some practical examples:
1) A and IuCS use the same sscp/ss7 instance
cs7 instance 1
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs_and_a
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
cs7-inst-a 1
cs7-inst-iucs 1
local-addr msc_local
1) A and IuCS use separate sscp/ss7 instances
cs7 instance 1
sccp-address msc_local
point-code 0.0.1
routing-indicator PC
sccp
name a
pc msc_local
prot M3UA
local-port 1230
remote-port 5670
local-ip 1.1.1.4
remote-ip 2.2.2.4
cs7 instance 2
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
cs7-inst-a 1
cs7-inst-iucs 2
local-addr msc_local
regards.
Philipp
--
Philipp Maier <pmaier(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
I have a problem with VTY validation. When there is wrong command formatting,
we exit VTY parsing in error, which leads to a program exit in error.
However, if the format matches but the value is wrong in a way that the VTY
format description is unable to detect, the way to escalate an error up
the VTY call chain is a bit weird.
The concrete item in question is the SCCP address point code. The format is
like A.B.C, while ranges are variable depending on configuration.
point-code 0.0.1
If I write 'point-code 0.0.99', it exceeds the range and I want to immediately
abort the program, indicating the VTY config error.
If I return CMD_WARNING, it is merely ignored.
There are various CMD_ERR_* values to return, but there is no plain error like
CMD_ERR_INVALID_VALUE.
I can for example return CMD_ERR_AMBIGUOUS; then the code will try to parse the
same line a second time, to see whether the command succeeds on a child of the
parent node (we had this before, about implicit node 'exit').
DLSS7 <002d> ../../src/osmo_ss7.c:244 1: Error parsing Pointcode '0.42.99'
DLSS7 <002d> ../../src/osmo_ss7.c:244 1: Error parsing Pointcode '0.42.99'
There is no such command.
Error occurred during reading below line:
point-code 0.42.99
% Power 21 dB is not an even value
Invalid point code (0.42.99)
Invalid point code (0.42.99)
This result is rather curious.
I would like to have a CMD_ERROR return value that immediately exits VTY
parsing with a clear error return code.
(We can't abort with an assertion, because that would cause the program to exit
in case someone enters a wrong value on the telnet VTY.)
This is the function in question:
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);
// I would insert something like this:
// if (ret == CMD_ERROR)
// return ret;
/* Try again with setting node to CONFIG_NODE */
while (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO
&& is_config_child(vty)) {
vty_go_parent(vty);
ret = cmd_execute_command_strict(vline, vty, NULL);
// same here
}
cmd_free_strvec(vline);
if (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO)
return ret;
}
return CMD_SUCCESS;
}
Am I on the right track here, have I missed something?
~N
HI.
While working on smoothing out our release process (see
https://projects.osmocom.org/issues/1861 and gerrit 3130, 3131, 3143) I've noticed
that some of Osmocom projects follow semver [1] spec (OsmoBTS) while others don't
(Osmo-PCU).
Is this just "it happened this way" or there're other reasons for that? Shall we
enforce semver for all projects?
[1] http://semver.org/
--
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
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
