6 Jul
2016
6 Jul
'16
6:58 p.m.
Hi 3G folks,
I would like to make our osmocom jenkins build openbsc with --enable-iu, which
still requires use of non-master branches in aper-prefix, libosmo-sccp and
libosmo-netif.
I will at first make the jenkins build use these branches to build 3G, but
since we'd like them to be merged to master anyway, let's try to push this
forward.
Here are the remaining tasks again, as from the openbsc@ mail on Feb 19, 2016:
http://lists.osmocom.org/pipermail/openbsc/2016-February/007906.html
( <20160219083519.GA4570@nataraja> )
First the good news for libosmo-sccp:
On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote:
This boils down to a mere rename of opaque structs osmo_sua_link and
osmo_sua_user, which I've started to submit.
https://gerrit.osmocom.org/477
d484b0593112222cef3f106da654df07c3d40919 (hash changed after rebases)
libosmo-sccp: * laforge/wip
My main problem with this patch set is naming. We are creating an 'SCCP
User SAP' which should look the same no matter what the underlying
transport protocol stacking is. [...] > asn1c: * aper-prefix
First of all, it looks like we imported from svn, but Lev Walkin later did
another migration to git, which we fetched as well. So our master is on our old
svn import, while the upstream master has different hashes in its history. Our
aper-prefix branch is based on the upstream history, not our "stale" master,
which made a rebase a bit easier.
Furthermore, on https://github.com/vlm/asn1c/commits/master there are scores of
new commits we don't have in our asn1c. our last commit from Lev Walkin is
from 2015-04-28, "?= was confusing some environments", 62913d8b8e1eb96d74315ff
I have thus:
* fetched upstream master from github's vlm/asn1c,
pushed as new branch vlm/master to our git.osmocom.org/asn1c
* rebased our aper-prefix branch to that master (with minor conflicts),
pushed as new branch aper-prefix-onto-upstream
We should probably:
* reset --hard our master to vlm/master
* reset --hard our aper-prefix to aper-prefix-onto-upstream (after testing)
Agreed?
Then follows:
On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote:
If you look at the aper code I took from OpenAirInterface and re-based,
For the record:
https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/S1AP/MESSAGES/ASN1
https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1…
https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1…
you will see that it does not look 100% complete and
would
probably not yet qualify for submitting it to the upstream asn1c
project. The situation is not made better by my hackish way to
implement the type prefixing on top of it by means of an environment
variable.
Specifically, it
* contains commented-out code which might just have been a work-around
of some buggy code, rather than fit for removal in general
* contains TODO comments like "/* TODO: act upon NOTE in #18.7 for
canonical PER */" which hints that it is not properly implementing
parts of the PER specification
* contrary to the rest of asn1c, it does not come with a comprehensive
test suiet for the APER encoding and decoding routines of all types
Any help in cleaning this code up (it could be done for the type
prefixing independent of the APER support) would be much appreciated.
The goal is to get this merged in asn1c, after all.
It might also be worth to contact the OpenAirInterface guys about their
thoughts on moving this code forward. I fear there might be none, as
they are using an ancient version of asn1c to begin with. But they are
a much larger project and might be convinced to put some resources on
doing this properly?
I've written to the openair-cn-devel list.
https://lists.eurecom.fr/sympa/arc/openaircn-devel/2016-07/msg00001.html
Unless we think something is ready for pushing to
upstream asn1c, we
should keep it out of our local master, too.
libosmo-netif: * sysmocom/sctp
commit basically just
prints some messages to the log file in case there are association state
changes like UP and LOST. This is clearly not the intended behavior.
The application should be notified accordintly in such events,
particularly in 'connection lost' events that can be communicated in the
same way as they can for e.g. TCP sockets.
Only after that is resolved, we can merge it to master.
This doesn't look like a lot of work, though I'm not familiar with how exactly
this should be done.
ret = sctp_recvmsg(conn->ofd.fd, msgb_data(msg), msgb_tailroom(msg),
NULL, NULL, &sinfo, &flags);
if (flags & MSG_NOTIFICATION) {
union sctp_notification *notif = (union sctp_notification *) msgb_data(msg);
LOGP(DLINP, LOGL_DEBUG, "NOTIFICATION %u flags=0x%x\n",
notif->sn_header.sn_type,
switch (notif->sn_header.sn_type) {
case SCTP_ASSOC_CHANGE:
LOGP(DLINP, LOGL_DEBUG, "===> ASSOC CHANGE:");
switch (notif->sn_assoc_change.sac_state) {
case SCTP_COMM_UP:
LOGPC(DLINP, LOGL_DEBUG, " UP\n");
call accept_cb?
break;
case SCTP_COMM_LOST:
LOGPC(DLINP, LOGL_DEBUG, " LOST\n");
osmo_stream_srv_destroy() ?
break;
case SCTP_RESTART:
LOGPC(DLINP, LOGL_DEBUG, " RESTART\n");
break;
case SCTP_SHUTDOWN_COMP:
LOGPC(DLINP, LOGL_DEBUG, " SHUTDOWN COMP\n");
break;
case SCTP_CANT_STR_ASSOC:
LOGPC(DLINP, LOGL_DEBUG, " CANT STR ASSOC\n");
break;
}
break;
case SCTP_PEER_ADDR_CHANGE:
LOGP(DLINP, LOGL_DEBUG, "===> PEER ADDR CHANGE\n");
break;
case SCTP_SHUTDOWN_EVENT:
LOGP(DLINP, LOGL_DEBUG, "===> SHUTDOWN EVT\n");
/* Handle this like a regular disconnect */
osmo_stream_srv_destroy() ?
return 0;
break;
}
return -EAGAIN;
Thanks for any thoughts or even help :)
~Neels
--
- 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