Hi Peter,
> It means that some real programming is needed. It's not a small
> change. It might work as-is with one phone camping to only one of the
> two BTSes at a time, but you will likely have corruptions if you have
> a bunch of phones on both BTSes at once.
I was able to start two InSite units at the same time, probably
because these units has only one TRX per BTS. I was even able to
establish an inter-BTS voice call. Cell reselection and SMS was
working fine also.
But when I tried to enable handover, I got this strange message that I
have to enable RTP proxy. If I do so, my voice calls are failing
completely (not a surprise, these units are connecting through E1). I
could really use a straight answer from any developer, that OpenBSC has
handover support for non-IP (E1 based) units or not, because I am not
trying to get this done if it is completely missing.
> When using nitb with a multi-TRX MetroSite there is a similar pattern
> to what you describe - after the BTS is reset using the Nokia BTS
> Manager, nitb only ever manages to correctly initialize the first
> TRX. An error occurs and nitb exits. Restarting nitb sometimes allows
> it to initialize the second TRX, sometimes no. My guess is that
> failure or success depends on what phones are sending to the BTS
> meanwhile, but it could also be only a matter of timing.
Today I was able to setup our MetroSite (2 GSM1800 TRXs) unit and encountered the very
same problem: only the first TRX was initialized, though both TRXs are
set up in the openbsc config file. For the start and stop process you
absolutely right. Out of ten tries, usually 2-3 are successful if I
try to start both InSite units, but the chances are better if I
previously start openbsc with a single BTS config file, then hit
Ctrl+C and start the mutli BTS config file. It is also interesting,
that both TRXSIG lapd connections are ON according to the BTS manager
with MetroSite, but the second TRX is just not working.
> The nokia_site code can definitily be improved when it comes to
> startup/shutdown, but I don't know how well known the Nokia OML is.
> It would also be nice to listen to the BTS Manager serial port
> communication. If I understand correctly, many (all?) things that
> BTS Manager can do over serial are also possible over E1.
I can do these traces if you let me know what commands are you
interested in. For example I can tell you for sure, that the site
reset request command sent by OpenBSC (bts_nokia_site.c to be
specific) is doing exactly the same, when I hit "Enable Abis" in Nokia
BTS Manager.
BTW do you have Nokia units too?
I am still open to give access to our MetroSite (or
the InSite) units if a developer is interested in it.
I also have a fine selection of Nokia BTS managers that includes
almost all Nokia BTS types (InSite, MetroSite, UltraSite, Flexi HUB,
MetroHUB, Flexi EDGE, Metro Hopper etc.) I am happy to share this with any developer,
just PM me with an FTP server account and remember: the whole package
is 2.2GB.
Br,
Csaba
Dear Members,
As I previously mentioned, I have two Nokia InSite BTS units that I
want to set up for my university. One GSM900 and one GSM1800 unit, and
I want to share some findings that can be useful for other users too.
First, the informations about the DAHDI configuration at the end of
the building page:
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
It sais the following for system.conf:
dchan=1
bchan=2-30
I wanted to point out that it is not necessary to define a dchan,
because with BTSes this is not a traditional E1 line configuration
where you share timeslots and you have to signal it
via the traditional E1 signaling channel (dchan), because for every
BTS there are dedicated timeslots for OMUSIG, TRXSIG and TCHs etc,
that cannot be used by anybody else. And
because we are not using that dchan, it is a waste of capacity to
allocate it. My DAHDI system.conf looks like this:
span=1,0,0,ccs,hdb3,crc4
bchan=1-31
and it works perfectly without a configured dchan (well its far from
perfect but at least the problem is not with the E1 configuration).
Because every BTS works like this, it would be wise the update that
information. For T1 lines and other framing configurations (cas, ami
etc.) it is the same.
The second thing is that Nokia InSite units (probably others too) can
be daisy chained. It is possible to share the first BTS units E1
connection for the daisy chained units with the integrated HDSL
cross-connection interface. With this technique it is possible to
share one E1 connection between 5 BTSes.
But there is a slight problem. I figured out if the BTS is not
connecting to the E1 directly, but via this HDSL interface, it needs
more time before it can be configured via OML,RSL. So in
bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the
current 15 seconds to at least 25 seconds, otherwise the unit is not
going to came up. With this modification I was able to use the unity
via this HDSL cross-connection interface.
The third thing is multiple BTS operation. As I mentioned I want to
use two InSite units with OpenBSC. But at the beginning of
bts_nokie_site.c there is a big warning: I most certainly going to
have problems with multi BTS operation. Despite the warning I tried with two units, and
found an interesting thing: if I try to start the two units, only one
of the two units are going to came up. But if I start
the daisy chained unit first, then stop openbsc and immediately start
openbsc again but now with the two unit config file, both BTSes are
came up just fine, the phones can camp on both units. I don't know the
real reason behind this behavior, but I have log and PCAP traces
about the working and non-working scenarios. If someone interested in
it I can share the results. Although a possible reason is that in
bts_nokia_insite.c the shutdown routine is completely missing. It is
not a good solution, but at least we should reset the BTS(es) and
all the signalling channels in the shutdown state (like with BS11),
until we figure out some proper way of shutting Nokia BTSes down.
BR,
Csaba
Dear Osmocom community,
I'm currently looking for one or multiple volunteers who are willing to
tend to the mailman 'moderator queue' of the various osmocom mailing
lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...)
Our lists are 'member posting only' to protect them from spam. This
means that spammers will be caught in the list moderation queue together
with the occasional legitimate message from a non-subscriber.
You need to manually look over that queue in the mailman web interface,
select those legitimate posts as 'approve' and 'defer' all others.
The task requires very few minutes, but it requires them every day or
second day. It is a perfect opportunity how non-developers can
contribute to the project :)
Please let me know if anyone is willing to take care of this. Thanks!
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)
To the MetroSIte topic:
I think we have a MetroSite unit with PSU, E1 card, TRE and 2 TRX.
Nobody tried it out because we dont have a BSC, but I will try to hook
it up to the E1 card and see if it works, I hope I can find a -48V DC
supply :-) If it works I will happily set up access for developers if
someone interested in it.
In the mean time, I will going to do some multi unit tests with the
two insite units and figure it out why sometimes both units came up,
and the other time why only the first unit came up only. I think it is
important to find why is this happening, because InSIte and MetroSite
units can both be daisy chained, and due to the extensive network
upgrades (in Europe) a lot of these units will be available on the
markets (Vodafone and Telenor already dropped these units after the
RAN upgrades in Hungary).
But it is also true, that maybe a good development direction would be
to support femto cells, that are easily and cheaply accessible to
anyone, uses IP technology and In general it is easy to work with.
BR,
Csaba
Dear Mailinglist
I am having a spot of bother with setting up asterisk with openbsc. I have gone with a basic setup from scratch LCR/ASTERISK/SIP minus mISDN as I dont require it and it would not compile it to my current kernel version in ubuntu 12.04 without downgrading it.
Anyway my problem is that I don't know how to prevent OpenBSC from using its own HLR and instead forward all phones that want to register to my nanoBTS to do so via Asterisk.
This is causing me grief because asterisk is its verbose logs is providing me this error when I try to make a call:
> -- Executing [8690 <at> phones:1] Dial("SIP/IMSI466974600011287-00000000",
> "SIP/IMSI466974104638690") in new stack
> [Dec 18 16:00:49] WARNING[2934]: app_dial.c:2218 dial_exec_full:
> Unable to create channel of type 'SIP' (cause 20 - Unknown)
> == Everyone is busy/congested at this time (1:0/0/1)
> -- Auto fallthrough, channel 'SIP/IMSI466974600011287-00000000'
> status is 'CHANUNAVAIL'
when I do show sip peers they are all offline because OpenBSC is registering my handsets and not passing on registration to Asterisk. I believe once OpenBSC is passing on registration all will be healthy with asterisk.
I don't have my configurations with me at the moment snipit above is from a google search, hopefully some helpful soul will know my blunders without my configs
Thank you all .
Regards
Adam
Dear Andreas,
the coverity prevent utility has found three inconsistencies in the
lapd_core.c and the gsm_04_08.c and I think you are suited the best
to comment on how to resolve them.
src/gsm/lapd_core.c
static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx)
...
1943 LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n",
1944 msg->len);
...
CID 1040665 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1956 if (msg && msg->len)
so we already dereferenced msg to print the length. So at this point,
is it legetimate to a have NULL msgb or shall the null check be removed?
src/libmsc/gsm_04_08.c
static int gsm48_cc_rx_connect(struct gsm_trans *trans, struct msgb *msg)
...
2090 if (trans->subscr) {
2091 connect.fields |= MNCC_F_CONNECTED;
2092 strncpy(connect.connected.number, trans->subscr->extension,
2093 sizeof(connect.connected.number)-1);
2094 strncpy(connect.imsi, trans->subscr->imsi,
2095 sizeof(connect.imsi)-1);
2096 }
...
CID 1040740 (#1 of 1): Dereference after null check (FORWARD_NULL)
6. var_deref_op: Dereferencing null pointer "trans->subscr".
2117 osmo_counter_inc(trans->subscr->net->stats.call.mt_connect);
2118
2119 return mncc_recvmsg(trans->subscr->net, trans, MNCC_SETUP_CNF, &connect);
trans->subscr is conditionally dereferenced and then unconditionally,
what is correct?
static int gsm48_cc_rx_setup(struct gsm_trans *trans, struct msgb *msg)
...
1761 if (trans->subscr) {
1762 setup.fields |= MNCC_F_CALLING;
1763 strncpy(setup.calling.number, trans->subscr->extension,
1764 sizeof(setup.calling.number)-1);
1765 strncpy(setup.imsi, trans->subscr->imsi,
1766 sizeof(setup.imsi)-1);
1767 }
...
CID 1040739 (#1 of 1): Dereference after null check (FORWARD_NULL)
14. var_deref_model: Passing null pointer "trans->subscr" to function "subscr_name(struct gsm_subscriber *)", which dereferences it. [show details]
1813 LOGP(DCC, LOGL_INFO, "Subscriber %s (%s) sends SETUP to %s\n",
1814 subscr_name(trans->subscr), trans->subscr->extension,
1815 setup.called.number);
1816
1817 osmo_counter_inc(trans->subscr->net->stats.call.mo_setup);
Same thing as above. Can the null check be removed? Would you have the
time to do that?
Hi all,
Attached patch fixes lengths of MS Network Capability and MS Radio
Access Capability elements.
Original code was inconsistent about lengths and could lead to out of
bounds write. Lengths were also inconsistent with the TS 24.008.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
