There has been some face-to-face discussion about Osmocom's code review
process within sysmocom recently. I am posting to this list now with the
consent of everyone involved so far, in order to involve the Osmocom
community at large in this discussion as well.
There has been a lack of code review from people who don't have "+2"
super powers in Gerrit. This applies to anyone among us, independently
of any individual's relationship with sysmocom. The bulk of the work
involved in reviewing code falls on Harald's shoulders, with Pau and
Neels sharing most of the rest between themselves.
At present, while people who add a +1 have their voices heard, their
input does not formally affect the decision to merge a change.
A change still has to pass by the pre-selected +2 gatekeepers in order
to be merged, no matter how many other people have provided input.
The implication for developers without +2 powers is that their time
is more effectively spent on advancing their own changes towards
a +2 vote, rather than spending time on whatever else is waiting
in Gerrit. This may not apply to everyone, of course. But at least
for me, this is certainly the case; I have only been reviewing other
people's patches when I was explicitly asked to do so.
Myself and several other developers hope that with a change to our review
process we can fix this inertia, spread code review across more shoulders
and encourage more collaborative code review in Osmocom.
The basic idea is that everyone's input should count for something.
If those among us with +1 powers were given a partial say on the fate
of every change, our decisions will carry more weight and our influence
within the project will slightly increase. We'd also be encouraged to step
out of our own corners of expertise every now and then, and look at what
other developers are working on. On the flip side, this means we'd carry
more responsibility than we do now. We wouldn't always be relying on our
+2 gate keepers and would have to apply our own judgement more carefully.
The concrete proposal is to make votes in Gerrit accumulative.
Each change would require a total score of +3 to be merged. This score can
consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes.
Also, +2 developers would keep their ability to unilaterally block or revert
changes under this new model. They'd keep their existing role as arbiters
in case of disputes.
Max figured out how Gerrit could be configured for this behaviour.
It involves Prolog code, but since we're all quite smart we should be able
to figure that out, right?
https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_…
We'd be interested to hear what the community thinks about this proposal.
Thanks,
Stefan
Hi to everyone!
I'm a new member and I really appreciate the work done here!
I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw,
but I'm still blocked at the IPSEC tunnel step.
I've created an IPSEC server with EAP support, but I suspect there is a
problem with my self signed certificate.
Probably the femtocell has an internal trusted CA which validates server
certs.
I din't find the console pins on the board also, so I cannot simply connect
to it and have a look at the system level.
Has anyone any experience with this kind of HW or just an idea about a
possible work around?
Thank you and best regards
Alex
The adocs and vty reference content from osmo-gsm-manuals.git has been "moved"
to the individual project repositories. That means if you apply more .adoc
changes to osmo-gsm-manuals.git, we have to port that to the new location.
(The content is not yet removed from osmo-gsm-manuals.git, so you might run into
believing the move hasn't happened yet.)
You can already edit in the individual osmo-bsc,-msc,... repositories,
and build with 'configure --enable-manuals'.
The jenkins publishing job isn't updated yet, should follow soon.
right, osmith?
~N
Hi Oliver,
so I merged the stuff to add the manuals to the individual git repositories,
since you said that it works. But when I do --enable-manuals I don't see any
PDF files generated. Also a manual 'make pdf' says "nothing to be done".
(I probably should have tried it before merging after all)
So what am I doing wrong? Alternatively, can you fix it please?
~N
With the newest git repo version of osmo-bsc, my nanoBTS fails to start.
I can confirm that they work normally with ip.access softBSC.
I thought osmocom Redmine issue #3063 might be relevant and tried
setting/unsetting force-combined-si but I am still getting the same
result. Attached are the packet capture and bsc config file
The following is the log from osmo-bsc:
<0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002
<0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK
<0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message.
<0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
ARI reported sw[0/5]: 168a004 is v136d0
<0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
ARI reported sw[1/5]: 168a002 is v136d0
<0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
ARI reported sw[2/5]: 168a002 is v136d0
<0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
ARI reported sw[3/5]: 168a001 is v136d0
<0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
ARI reported sw[4/5]: 168a001 is v136d0
<0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is
unreported
<0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003
STREAM=0x00
<0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003
<0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN
600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63
BTS 0: Failure Event Report: Type=processing failure, Severity=critical
failure, Probable cause=Manufacturer specific values: Fatal software
error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical
failure, Probable cause=Manufacturer specific values: Fatal software
error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1149 (325).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning
level failure, Probable cause=Manufacturer specific values: Software
warning, Additional
Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error:
.
BTS 0: Failure Event Report: Type=processing failure, Severity=warning
level failure, Probable cause=Manufacturer specific values: Software
warning, Additional
Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX
Proc:L2_BCH:l2_bch.c#1149 (325)
Hi all,
I started looking at this failure and found out code in this repository
is really old, with nobody maintain it (13 months since last commits?).
I started by updating the contrib/jenkins.sh to use osmo-build-dep.sh
and osmo-clean-workspace.sh like we do in other repos, because i felt it
was not building up to date stuff.
After updating that script, indeed it seems cellmgr-ng cannot be built
against new libosmo-sccp due to some M3UA headers /API changes. There's
even a tag during that commit in libosmo-sccp called "old_sua". After
that commit, cellmgr-ng fails to build.
If I try to build it against "old_sua", still cannot build fine with
updated contrib/jenkins.sh script due to missing LIBOSMOSCCP_CFLAGS in
tests/Makefile.am, and then still other headers are not found in other
places, etc.
I stopped at this point because I'm starting to spent too muhch time on
this and it seems nobody is using it anyway.
Can we disable the build of this project? Does somebody want to take
care of it?
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
Hi all,
I noticed that SMS with emoticons on the boundary of the concatenated
segments are not displaying correctly on the destination handset.
* - imagine the disaster when that kiss-blowing smiley face thing at the
end of your SMS turns out as a diamond with a ? for the recpipient! OMG,
the potential butterfly effect is too much to think about... :))
So... This is my analysis:
We have 140 bytes for the message, less the 6 bytes for the user header
data in the case of concatenated SMS , leaving 134 bytes.
It's well know that this means 67 characters per segment for an SMS
using UCS-2 encoding.
But, it we fill the message with emoticons that are using 4 bytes per
'character', then we have space for 134/4 = 33 and a half. Ooops.
Still, the destination handset should reassemble the message and stick
the two "halves" of the emoticon together, right? - except I'm not
observing this.
To rule out us doing something wrong in osmo, I wonder might somebody
else (who has an unlimited SMS package) from a commercial provider try
sending some crafted SM from one emoji-enabled phone to another,
something like this:
😱abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123😱56789
That's likely going to get mangled by mailing list or your mua, so it is:
[4 byte
emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[4
byte emoji]56789
You could also try various messages filled with emojis. Of course, if
you bring up your osmo network with SMPP-mirror you can watch the trace
in wireshark, you'll see when the last emoji gets chopped in two. You
could try the same message on osmo and your commerical network.
If it's actually a problem of the phones, you should get
[4 byte
emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[two
diamonds with ?]56789
Thanks!
Keith.
Hello, I'm setting up an Asterisk connection with osmo-sip-connector.
Initiation of calls works fine, but no sound is getting through.
My setup is as follows:
Local computer is running all osmo software plus asterisk
interface has IP address 192.168.27.49 plus 192.168.27.47 as alias
femtocell is at 192.168.27.41
osmo-mgw.cfg
mgcp
bind ip 192.168.27.49
rtp port-range 4002 16000
rtp bind-ip 192.168.27.47
osmo-sip-connector.cfg
sip
local 192.168.27.47 5069
remote 192.168.27.49 5060
osmo-msc.cfg
msc
mgw remote-ip 192.168.27.49
mgw remote-port 2427
mgw local-port 2728
When I start wireshark it only shows packets flowing between
192.168.27.41(femtocell) and 192.168.27.47(osmo-mgw).
No packets to/from Asterisk server, how can I fix this problem? Current
documentation on osmo-mgw is quite difficult to understand.
(cross-posting so it doesn't get lost)
reading Vadim's patches, I just now invented:
https://osmocom.org/issues/3700
"Idea: have a separate GSUP manual"
Provide feedback at that issue if you have an opinion...
~N