These patches for openbsc
* fix some implicit declarations of functions
* fix a non-critical mismatch in fprintf format specifiers
If the patches seem useful, please merge them to master.
I've noticed in the osmo-bts project a lot of references to this
'sysmobts' product and I'm /really/ curious. Now, I know that not a
lot will probably be able to be discussed for a bit of time, but for
those involved, what can we know /right now/ about it? Any ideal
target price? Availability? What it can handle? What it can do?
I've also wondered how the 'experimental' work of using OsmocomBB
phones as a BTS was ever going - did that ever work?
Cheers,
-from the desk of Dakota C
Support technology in education - because Stone Age administrators never will.
These patches for libosmocore do a trivial update of .gitignore
and correct a function declaration that caused an implicit declaration
in openbsc.
If the patches seem useful, please merge them to master.
These patches for openbsc
* introduce a similar directory structure for the header files as
are used for the source files
* fix some implicit declarations of functions
* fix a non-critical mismatch in fprintf format specifiers
If the patches seem useful, please merge them to master.
Dear openbsc folks,
I am trying to use "auth token" policy for registration of new imsi subscribing
with : src/libmsc/token_auth.c and hrlsync.py (used at har2009)
Missing the "web token" db schema and the web-cgi used at har2009 to fully
understand the "auth token", i am trying to do it from the hlr db by updating
the "authorized" field to 1 but MS can receive calls but not calling.
Does anyone remember the web-db/cgi from har2009 or could head to a hack from
hlrsync.py to do it manually ?
Many thanks. Cheers.
Xavier.
Hello List,
I've noticed that In-Call Handover doesn't work on my Nokia InSites.
OpenBSC attempts the handover but as far as I can tell the device
never moves to the new channel. E.g.
<000d> handover_decision.c:203 (bts=2,trx=0,ts=1): Cell on ARFCN XXX is better:
<000d> handover_logic.c:97 (old_lchan on BTS 2, new BTS 1) Starting handover
<0004> abis_rsl.c:1059 (bts=1,trx=0,ts=1,ss=0) CHANNEL ACTIVATE ACK
<000d> handover_logic.c:206 handover activate ack, send HO Command
<0004> abis_rsl.c:1032 (bts=1,trx=0,ts=1,ss=0) HANDOVER DETECT access delay = 0
<0000> abis_rsl.c:1481 (bts=1,trx=0,ts=1,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> abis_rsl.c:1481 (bts=1,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
<0003> gsm_04_08.c:1196 HANDOVER COMPLETE cause = Normal event
<000d> handover_logic.c:263 Subscriber AAABBBC00000ZZZZ HO from BTS
2->1 on ARFCN YYY->XXX
<0000> chan_alloc.c:421 (bts=2,trx=0,ts=1,ss=0) starting release sequence
Here it seems to get measurement results, because the device is still
on BTS2 (never moved?)
<0004> abis_rsl.c:967 (bts=2,trx=0,ts=1,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:967 (bts=2,trx=0,ts=1,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:967 (bts=2,trx=0,ts=1,ss=0): MEAS RES for inactive channel
After sometime things start to go crazy and the log fills up with messages like:
illegal trau (C1-C5) 00 00 01 01 00
Thanks,
Gus