Hello guys,
I was studying the sourcecode of OpenBSC to get a good understanding of
how things work.
But due to my lack of experience in Linux programming I have some
difficulties to understand the source.
I understand that the way bsc_hack works is based on event-queue
concept, am I right?
Anyway, in select.c I don't understand what's going on when it comes to
registering and unregistering fd's in combination with linuxlist.c.
Can someone please give me some links where such concepts are being
explained, so I can study it?
Thanks in advance.
Hello guys,
While I'm still busy with understanding the OpenBSC sourcecodes and GSM
protocols, I wonder if it's possible to control the nanoBTS's
transmissionpower. If some additional code is needed, I'd like to give a
try with some hints or directions to look at.
Thank you.
correction: patch 12 (not 13) uses dynamic transactions.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg
Gesendet: Samstag, 23. Mai 2009 10:21
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: AW: patch: 8_paging
here is the problem: we don't know about the called bts, if
- the subscriber detaches after paging was started and the current_bts pointer inside subscriber is NULL.
- the lchan is not set because paging expires.
we can use the network pointer instead of the bts pointer for paging callback function. the gsm_network is required when paging result is received. all transactions (call instances) are linked in a list in gsm_network. (see patch 13) even if paging expires, the transactions in this list with the same subscriber must be released. (MO out of order)
but it is more complex: the subscriber will not be NULL, because it is "used" by the transactions. the use-counter of subscriber is increased for every transaction created and decreased on release of that transaction. if there is a call process for the paged subscriber, the subscr is set when paging response is received. we need at least a pointer to the network to access the transactions.
we can keep paging callback function without bts (or network) pointer, but then we need a network pointer in gsm_subscriber to process the network's paging result.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg
Gesendet: Samstag, 23. Mai 2009 09:47
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: AW: patch: 8_paging
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 08:30
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
> On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
> > Paging refers to a BTS. To page a mobile phone, the current location
> > is required. If paging succeeds or expires, the BTS structure is
> > also given to the callback function (cbfn).
> >
> > Because paging refers to a BTS, the cbfn (callback function) must
> > include a pointer to bts.
>
> The paging response includes a lchan pointer, which can be resolved to
> the physical channel / timeslot and to the trx and finally to the BTS.
> Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the
BTS of the calling party rather than the called party). So this parameter
is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request()
to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that
is passed back as a reference when calling the call-back function. So
if the bts of the calling or called party needs to be known, it should
probably be referenced from that data structure.
Or am I missing something?
--
- 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)
hi,
finally my patch is documented (almost). you will find the documentation
of the patch:
http://home.eversberg.eu/stage1.html
the patch in plain text fromat:
http://home.eversberg.eu/stage1.patch
it also includes the changes i posted here before. if you have
questions, ask.
regards,
andreas
Hi,
I am having difficulty compiling openbsc and the error message is as
follows. Does anyone know why?
1; fi
db.c:30:21: error: dbi/dbi.h: No such file or directory
db.c:34: error: expected ?? ?? ?? �sm?or �_attribute__?before �onn?
db.c:91: error: expected ??before �onn?
db.c: In function �b_init?
db.c:98: warning: implicit declaration of function �bi_initialize?
db.c:99: error: �onn?undeclared (first use in this function)
db.c:99: error: (Each undeclared identifier is reported only once
db.c:99: error: for each function it appears in.)
db.c:99: warning: implicit declaration of function �bi_conn_new?
db.c:105: warning: implicit declaration of function �bi_conn_error_handler?
db.c:105: error: �b_error_func?undeclared (first use in this function)
db.c:118: warning: implicit declaration of function �bi_conn_set_option?
db.c:121: warning: implicit declaration of function �bi_conn_connect?
db.c: In function �b_prepare?
db.c:133: error: �bi_result?undeclared (first use in this function)
db.c:133: error: expected ??before �esult?
db.c:137: error: �esult?undeclared (first use in this function)
db.c:137: warning: implicit declaration of function �bi_conn_query?
db.c:137: error: �onn?undeclared (first use in this function)
db.c:142: warning: implicit declaration of function �bi_result_free?
db.c: In function �b_fini?
db.c:149: warning: implicit declaration of function �bi_conn_close?
db.c:149: error: �onn?undeclared (first use in this function)
db.c:150: warning: implicit declaration of function �bi_shutdown?
db.c: In function �b_create_subscriber?
db.c:160: error: �bi_result?undeclared (first use in this function)
db.c:160: error: expected ??before �esult?
db.c:166: error: �esult?undeclared (first use in this function)
db.c:166: warning: implicit declaration of function �bi_conn_queryf?
db.c:166: error: �onn?undeclared (first use in this function)
db.c:190: warning: implicit declaration of function �bi_conn_sequence_last?
db.c:193: warning: format ?llu?expects type �ong long unsigned int? but
argument 2 has type �ong unsigned int?
db.c: In function �b_get_subscriber?
db.c:198: error: �bi_result?undeclared (first use in this function)
db.c:198: error: expected ??before �esult?
db.c:205: warning: implicit declaration of function
�bi_conn_quote_string_copy?
db.c:205: error: �onn?undeclared (first use in this function)
db.c:206: error: �esult?undeclared (first use in this function)
db.c:239: warning: implicit declaration of function �bi_result_next_row?
db.c:247: warning: implicit declaration of function
�bi_result_get_ulonglong?
db.c:248: warning: implicit declaration of function �bi_result_get_string?
db.c:248: warning: assignment makes pointer from integer without a cast
db.c:252: warning: assignment makes pointer from integer without a cast
db.c:256: warning: assignment makes pointer from integer without a cast
db.c:260: warning: assignment makes pointer from integer without a cast
db.c:264: warning: implicit declaration of function �bi_result_get_uint?
db.c:268: warning: format ?llu?expects type �ong long unsigned int? but
argument 2 has type �ong unsigned int?
db.c: In function �b_sync_subscriber?
db.c:274: error: �bi_result?undeclared (first use in this function)
db.c:274: error: expected ??before �esult?
db.c:275: error: �esult?undeclared (first use in this function)
db.c:275: error: �onn?undeclared (first use in this function)
db.c: In function �b_subscriber_alloc_tmsi?
db.c:294: error: �bi_result?undeclared (first use in this function)
db.c:294: error: expected ??before �esult?
db.c:298: error: �onn?undeclared (first use in this function)
db.c:299: error: �esult?undeclared (first use in this function)
db.c:309: warning: implicit declaration of function �bi_result_get_numrows?
db.c: In function �b_subscriber_assoc_imei?
db.c:325: error: �bi_result?undeclared (first use in this function)
db.c:325: error: expected ??before �esult?
db.c:327: error: �esult?undeclared (first use in this function)
db.c:327: error: �onn?undeclared (first use in this function)
db.c:339: warning: implicit declaration of function
�bi_result_get_numrows_affected?
db.c:344: warning: format ?llu?expects type �ong long unsigned int? but
argument 2 has type �_int64_t?
db.c:382: warning: format ?llu?expects type �ong long unsigned int? but
argument 2 has type �_int64_t?
db.c:396: warning: format ?llu?expects type �ong long unsigned int? but
argument 2 has type �_int64_t?
db.c: In function �b_sms_store?
db.c:405: error: �bi_result?undeclared (first use in this function)
db.c:405: error: expected ??before �esult?
db.c:408: error: �onn?undeclared (first use in this function)
db.c:409: error: �esult?undeclared (first use in this function)
db.c: In function �b_sms_get_unsent?
db.c:428: error: �bi_result?undeclared (first use in this function)
db.c:428: error: expected ??before �esult?
db.c:436: error: �esult?undeclared (first use in this function)
db.c:436: error: �onn?undeclared (first use in this function)
db.c: In function �b_sms_mark_sent?
db.c:453: error: �bi_result?undeclared (first use in this function)
db.c:453: error: expected ??before �esult?
db.c:455: error: �esult?undeclared (first use in this function)
db.c:455: error: �onn?undeclared (first use in this function)
db.c:460: warning: format ?llu?expects type �ong long unsigned int? but
argument 2 has type �_int64_t?
make[1]: *** [db.o] Error 1
make[1]: Leaving directory `/usr/src/openbsc/src'
make: *** [all-recursive] Error 1
Thank you for your help.
JB
> In my menuconfig I put an * for :
> <*> Modular ISDN driver ---> <*>Digital Audio Processing of
transparent data
> <*>ISDN over IP tunnel
> <*>Support for HFC PCI
cards
> <*>Support for HFC
multiport cards (HFC-4S/8S/E1)
try compile as module then load after boot
modprobe mISDN_core
modprobe hfcmulti dslot=1
> Is there something more to do for mISDN? I saw on mISDN.org that
mISDNv2 is already in the kernel >= 2.6.27 so I were thinking it should
work directly.
no it doesn't! it works for ISDN, but not for openbsc. openbsc requires
differen SAPI values and multiple layer 2 processes on the d-channel.
it will work with the latest mISDN from git repository:
git clone git://git.misdn.org/git/mISDN.git
cd mISDN
sh checkout-branch.sh socket <- change to socket branch (mISDNv2)
make force <- delete all mISDN includes from kernel.
make
make install
be sure to disable mISDN support from kernel. the modules from git will
be installed under /lib/modules/xxxx/extra. the "extra" modules have
lower priority than the kernel modules, so disable mISDN in kernel
config and reinstall modules (make modules && make modules_install).
unused modules will then be removed. then install the git modules as
described above.
Hello,
Now I can configure the bs11 using the bs11_config. Everything worked fine
and I obtained this on bs11_config query :
LMT LOGON: ACK
PHASE: 3 Normal MBCCU0: Load MBCCU1: No Load
Abis-link: Restoring
BS11 ATTRIBUTES:
BS-11 ESN PCB Serial Number: 001073
BS-11 ESN Hardware Code Number: 135-2044/03.03
BS-11 ESN Firmware Code Number: 135-2044/03.03
PLL Set Value=1053, Work Value=1053
SITE MANAGER ATTRIBUTES:
E1 Channel: Port=0 Timeslot=1 (Full Slot)
TEI: 25
BS11 Line Interface ATTRIBUTES:
PLL Mode: Standalone
BS11 Power Amplifier 0 ATTRIBUTES:
TRX Power: 30mW (GSM)
Mon May 25 16:01:12 2009 <0020> abis_nm.c:811 GET ATTRIBUTE NACK
LMT LOGOFF: ACK
I didn't doanwload:
-the SAFETY LOAD software
-the BTS software
Is it necessary since I can reach Phase 3 and since I can see the Firmware
Code Number?
I continued to follow the "getting started" tutorial untill the E1 Link and
I have the following problem when launching bsc_hack :
./bsc_hack -f 123 --debug=DRLL:DCC:DMM:DRR:DRSL:DNM:DMI:DMUX:DPAG:DRLL:DSMS
DB: Database initialized.
DB: Database prepared.
1 device found
id: 0
Dprotocols: 00000018
Bprotocols: 0000006e
protocol: 4
nrbchan: 30
name: hfc-e1.1
activate bchan
activate bchan
Mon May 25 16:07:39 2009 <1000> input/misdn.c:125 alen =6, dev(0) channel(0)
sapi(63) tei(127)
Mon May 25 16:07:39 2009 <1000> input/misdn.c:128 <= len = 12, prim(0x8)
id(0x7f3f): DL_INFORMATION_IND
Mon May 25 16:07:39 2009 <1000> input/misdn.c:135 DL_INFORMATION_IND: use
channel(0) sapi(63) tei(127) for now
mISDN message for unknown sign_link
May be it's coming from my BN1E1 card from Beronet. I only changed the Dip
switches for 120 ohms.
I can see 2 steady red led (which means i am in NT mode, TE mode
deactivate). Both green leds are off (is it normal?).
/* HFC-E1 OEM */
+ /* 2 red blinking: NT mode deactivate
+ * 2 red steady: TE mode deactivate
+ * left green: L1 active
+ * left red: frame sync, but no L1
+ * right green: L2 active
+ */
Anyone?
Thanks in advance!
Best regards
Eric Cathelinaud
Hi,
I wrote a small howto for the setup of OpenBSC, LCR and Asterisk.
I'll add it to the wiki within the next days.
https://brezn.muc.ccc.de/~codec/openbsc/howto.txt
Sorry for the broken english. ;P
cheers,
--
codec
"All children are artists. The problem is
how to remain an artist as one grows up." -- Picasso
did you load hfcmulti.ko with dslot=1 parameter? this is required to
move dchannel slot from 16 to 1.
> Mon May 25 16:07:39 2009 <1000> input/misdn.c:125 alen =6, dev(0)
channel(0) sapi(63) tei(127)
> Mon May 25 16:07:39 2009 <1000> input/misdn.c:128 <= len = 12,
prim(0x8) id(0x7f3f): DL_INFORMATION_IND
> Mon May 25 16:07:39 2009 <1000> input/misdn.c:135 DL_INFORMATION_IND:
use channel(0) sapi(63) tei(127) for now
> ISDN message for unknown sign_link
>
This patch in conjunction with patch 15 (paging lac) makes patch 8
(paging) obsolete.
> The patch will store the current LAC in the HLC when the subscriber
successfully attaches. If the subscriber detaches, the LAC will be set
to 0.
> This patch is required to make patch 15 (paging) work. This patch
does not depend on any other patch i made.
a minor fix of DMM debugging. now MM debugging is shown, if given by
debug option, not only by default debugging. the color of DNM debugging
changes to cyan as it is supposed to be.
This patch will resolve all BTS with the LAC of the subscriber and page
every BTS with this LAC. If the subscriber is not currently attached,
the LAC is not set, so the caller will get cleared with cause 27 (MO out
of order).
This patch must be applied AFTER patch 12 (application interface) has
been applied.
The patch will store the current LAC in the HLC when the subscriber
successfully attaches. If the subscriber detaches, the LAC will be set
to 0.
This patch is required to make patch 15 (paging) work. This patch does
not depend on any other patch i made.
I improved trau_mux.c. Now it supports not just bridging only. A new
function "trau_recv_lchan" is used to link a channel to a call reference
of a transaction. (Transactions are used in later patches.) TRAU frames
will then be forwarded to the application with the given call reference
(in later patches). Also the application can send TRAU frames by using
"trau_send_lchan".
A new list is introduced in trau_mux.c. (upqueue_entry) All subslots
that must be sent to application are listed here.
Received TRAU frames are written in the upqueue of application
interface, if a call reference is found in the upqueue-list. If an entry
is found the ss_entry list, the TRAU frames are bridged as before. The
frames have a message type (msg_type), a call reference (callref) and a
trau frame (data). The length of trau frame is defined by the content of
the c-bits inside the frame.
There is no support for ip-access yet. Harald must add this in order to
use application interface with ip-access. The bridging with ip-access
works as before.
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 08:30
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
> On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
> > Paging refers to a BTS. To page a mobile phone, the current location
> > is required. If paging succeeds or expires, the BTS structure is
> > also given to the callback function (cbfn).
> >
> > Because paging refers to a BTS, the cbfn (callback function) must
> > include a pointer to bts.
>
> The paging response includes a lchan pointer, which can be resolved to
> the physical channel / timeslot and to the trx and finally to the BTS.
> Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the
BTS of the calling party rather than the called party). So this parameter
is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request()
to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that
is passed back as a reference when calling the call-back function. So
if the bts of the calling or called party needs to be known, it should
probably be referenced from that data structure.
Or am I missing something?
--
- 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)
i don't know if it works with the latest mISDN. have you tested it? if it doesn't work, we need to fix it. do you have any idea why it does not work with mISDN?
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 07:43
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 6_datalink
On Thu, May 21, 2009 at 02:27:35PM +0200, Andreas.Eversberg wrote:
> This patch corrects the handling of data link status change.
thanks, applied - with the exception of the last hunk removing the 'kernel doesnt support sapi' comment. As far as I know, we still need to claim that we use SAPI0, despite in reality using a different one, since the kernel will refuse any non-sapi-0 request from userspace.
Regards,
--
- 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)
here is the problem: we don't know about the called bts, if
- the subscriber detaches after paging was started and the current_bts pointer inside subscriber is NULL.
- the lchan is not set because paging expires.
we can use the network pointer instead of the bts pointer for paging callback function. the gsm_network is required when paging result is received. all transactions (call instances) are linked in a list in gsm_network. (see patch 13) even if paging expires, the transactions in this list with the same subscriber must be released. (MO out of order)
but it is more complex: the subscriber will not be NULL, because it is "used" by the transactions. the use-counter of subscriber is increased for every transaction created and decreased on release of that transaction. if there is a call process for the paged subscriber, the subscr is set when paging response is received. we need at least a pointer to the network to access the transactions.
we can keep paging callback function without bts (or network) pointer, but then we need a network pointer in gsm_subscriber to process the network's paging result.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg
Gesendet: Samstag, 23. Mai 2009 09:47
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: AW: patch: 8_paging
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 08:30
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
> On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
> > Paging refers to a BTS. To page a mobile phone, the current location
> > is required. If paging succeeds or expires, the BTS structure is
> > also given to the callback function (cbfn).
> >
> > Because paging refers to a BTS, the cbfn (callback function) must
> > include a pointer to bts.
>
> The paging response includes a lchan pointer, which can be resolved to
> the physical channel / timeslot and to the trx and finally to the BTS.
> Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the
BTS of the calling party rather than the called party). So this parameter
is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request()
to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that
is passed back as a reference when calling the call-back function. So
if the bts of the calling or called party needs to be known, it should
probably be referenced from that data structure.
Or am I missing something?
--
- 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)
you can copy compat_af_isdn.h from mISDNuser package, as you did with mISDNif.h. (socket branch) then you don't need the user package. i think i forgot to copy it to the include/openbsc/ directory.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 07:24
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 2_misdn
On Thu, May 21, 2009 at 02:27:34PM +0200, Andreas.Eversberg wrote:
> This patch corrects the inclusion of mISDN headers. Also the mISDNif.h
> is updated.
compat_af_isdn.h is not in our source tree. As the current socket-based mISDN headers cannot yet be expected to be present on most linux distributions, I would rather not create any additional external dependencies.
I have no problem with updating our header files, but they should not create additional dependencies.
--
- 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)
A new debug flag is introduced: "DMNCC". MNCC is the Mobile Network Call
Control. This is required for later patches, that extract the call
control from gsm_04_08.c
Some messages have one or two length-value information elements. The is
no IE type included in the message. These information elements are
mandatory, so their actual IE type is known. The improved parse_tlv()
function allows to parse zero, one, or two length-value elements.
Paging refers to a BTS. To page a mobile phone, the current location is
required. If paging succeeds or expires, the BTS structure is also given
to the callback function (cbfn).
Because paging refers to a BTS, the cbfn (callback function) must
include a pointer to bts.
There is no implementation yet for the paging of the actual BTS where
the subscriber is located. gsm_04_08.c always uses BTS 0 (in later
patches) The database requires improvement to store the current BTS
number.
To slow down transmission of many ABIS frames at a time, a delay timer
is used for the E1's time slot. This timer replaces the "usleep()"
function, so the process will not block the execution of libbsc. The
timer is started after a frame is transmitted. If another frame is in
the transmit queue, the frame will only be queued until the timer times
out. If the timer is not running or times out, the frame is transmitted
and the timer is restarted.
The problem with partly provisioned TRX (locks show on LMT) is solved.
The adjustment for the inter frame delay of 50 miliseconds is for
further study.
An application that has own events and file descriptors, must poll
select function ob libbsc. A "polling" flag is used to enable polling.
In this case select() will not sleep until file descriptor events occurr
or nearest timer expires. Also a return value will indicate if there was
an event that has been handled. If there was an event, the application
decides to poll again and don't wait.
In case for bsc_hack, the polling flag is not set. select will sleep as
usual.
this patch renames the timer functions to avoid name collisions with
libmisdn.
the return value of bsc_update_timers() is required for applications to
find out if a timer was fired. (this is required for later patches).
This patch chnages the variable "new" to "_new" in order to include it
in C++ code.
The define "container_of" will cast pointer before assigning. Compiler
with stricter options require this.
This patch moves telnet interface from bsc_hack to libbsc, so it can be
used by applications also. If this makes sense, must be decided by you.
This patch also includes the quick and dirty installation hook. This
must be changed also.
Hi,
I am now trying to configure the bs11 using bs11_config and I had a problem
connecting via serial port.
I tried then to use an USB adaptator as you did but I don't have any ttyUSB
in my /dev/
I only have /dev/usbdev*.*_ep** (2 per USB port and 6 new ones appeared
after connecting the USB adaptator).
lsusb give me the following result:
# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 413c:3012 Dell Computer Corp. Optical Wheel Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 013: ID 9710:7715 MosChip Semiconductor Printer cable
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
where "MosChip Semiconductor Printer cable" is my adaptator (for printer and
DB9)
#lsmod
...
usbserial 26348 1 visor
usbcore 118068 7
visor,usbserial,usb_storage,usbhid,uhci_hcd,ehci_hcd
...
Does anyone know why I can't see any ttyUSB?
Best regards,
Eric Cathelinaud
This interface is introduced to allow other applications than bsc_hack
to be used with libbsc. The built-in application for call forwarding
from mobile to mobile calls has been moved out of gsm_04_08.c to mncc.c
and stays part of libbsc.
The most messages on this interface begin with MNCC_ and end with _REQ
(layer 4 requests) _CNF (layer 3 reply) _IND (layer 3 requests) _RSP
(layer 4 replies). Other messages are used to control TRAU traffic or
channel modification. More commands may be added in the future.
The handling of messages from the mobile side (MMCC) and from the
application (MNCC) is done by a state machine. (See Fig. 5.1b TS 04.08)
The "datastate" list handles messages from the mobile side. The
"downstate" list handles messages from the application. The timers are
handled by a special timeout function. When a message is received, the
downstate list or datastate list is checked for the current state and
the message. If there is a match, for a current state and a message,
it's handler called. Inside this handler, timers can be started and
stopped, states can be changed, messages can be forwarded and replied,
and so on.
All information elements are parsed or created in gsm_04_08.c.
A special "upqueue" is used to forward messages from gsm_04_08.c to the
application. The dequeue function is called by the application in the
main loop (before select function). If the application sends a message
to BSC, it calls the "mncc_send" function of gsm_04_08.c. The process of
this maessage in gsm_04_08.c may result in messages back to the
application. The queue prevents libbsc from calling the application's
"mncc_recv" function, while the application calls the "mncc_send"
function. The upqueue makes sure that messages created by gsm_04_08.c
during "mncc_send" is processed AFTER the application has finished it's
processing.
The call instance of the application is called "gsm_call". This has
moved out of gsm_04_08.c into mncc.c. The gsm_04_08.c uses a "llist" of
transactions: "struct gsm_trans". The transaction can be associated with
a logical channel: "lchan". The use-counter of lchan is increased for
every transaction assoicated to. After freeing of transaction, the
use-counter is decremented. If lchan breaks down, all transactions are
released. The application receives a "released indication" message.
Multiple transactions for an lchan provide the ability to hold a call
and receive/make another call. This has been successfully tested on LCR
application and is not yet implemented in mncc.c, but very easy todo.
A message between libbsc and application consists of a message type
(mgs_type), a call reference (callref), and information elements within
the same structure. Each information element has an additional flag, to
indicati if it exists in the message. The message is defined in mncc.h
The A transaction can have a logical channel (lchan) or not. At least it
has a subscriber (subscr). If a transaction is created, the subscriber
is checked. If no transaction with this subscriber exists, paging is
started. If another transaction exists with an lchan, this lchan is also
used for the transaction (already established). If another transaction
of this subscriber exists, but no lchan, the paging is already stated,
nothing is done until paging response. After a paging response, the
transactions with the same subscribers are associated to the lchan. If
paging failed, all transactions associated with the subscriber are
released. (no user responding).
>At least at that point, applications using libbsc (in your context,
i.e. lcr
>like applications) don't need to know any details, agreed.
>The applications that I have in mind in fact need to know a lot more
about the
>details, on the other hand...
hi harald,
if libbsc is a toolbox not only for MSC applilcations, but applications
that e.g. trigger paging or send O&M messages, it makes sense to export
most internal functions and data structures. in this case it does not
make sense to create a header file "openbsc/openbsc.h" for all
applications. instead it makes sense to create a header file especially
for the application interface "openbsc/mncc.h". only MSC application and
MNCC interface require to include this header file. other applications
include other header files.
i would like to keep include files as is and add openbsc/mncc.h instead.
what do you think?
andreas
Hey Harald, Andreas,
I just tried to come up with a patch to prefix the timer functions with bsc_
and started to think about public API. The thing is we only need to properly
prefix symbols we intend to export. I don't think we will export timers.
So the questions I think of are: what are we going to export? how are we going
to export it?
On the what question it mostly depends on Andreas and what he needs for his
application, from what I understand that is the MNCC stuff that will come as
one of his patches.
For the other question of how we are going to export it we have at least two
approaches, symbol filter and visibility attributes of the gcc. I prefer the
later and have cooked up an example patch...
comments welcome
z.
PS: I'm sorry to use libtool... the GNU documentation tries to hide other ways
PPS: With the 2nd patch in place I don't think we need to rename the timer
symbols (we still can as a matter of cleaning it up)
PPS: With the 2nd patch we have everything in place for installable API...
dear holger, dear harald,
don't worry about little communication problems. the difference between
being offensive and being contructive is only determined by the sound of
voice, i think. we can't hear the "tone" in emails, so we try to imagine
the tone when we read mails. so your constructive arguments can be
easily understand wrong.
let's get back to the patches. first, i decided to use one big patch,
because the application interface requires almost all other parts to
work. what i can do is to provide single patches that will work
stand-allone, but some are dependant of earlier patches.
harald already did a list of parts in it's order:
* timer rename throughout the existing code
* llist header changes (why were they made? c++?)
* the transmit delay timer
* introduction of trau interface
* bsc_select_main(polling)
* paging extension with cbfn BTS pointer
* the actual MNCC interface
* installation of libbsc (this should be last, since before the other
changes it is of no use)
i will start this week to apply the changes to the latest SVN snapshot,
one by one. i will test it by calling from one mobile station to another
station. (i think that is enough.) i will create a diff and announce it
on the mailing list. (i can also put it on home.eversberg.eu or on the
wiki, if you whish). after that i will continue with the next step, test
it and provide the next diff.
also, i need to know about "openbsc/openbsc.h" include file, i would
like to add. it shall only include functions and definitions relevant
for the application to use libbsc. because the application does not need
to know about libbsc internals, the pointer to the "struct gsm_net" is
of type "void". example in the first parameter of mncc_send():
int mncc_send(void *net, int msg_type, void *arg);
this header file contains structures that are used by application and
libbsc also, like:
enum gsm_bts_type
currently i copied the bootstrap code from bsc_hack.c into my LCR
application, so i need to incude more than openbsc.h there. in my case i
use a file called "bootstrap.c" which takes all the parameters to
initiate gsm network an controls bootstrapping. i think this should be
part ob libbsc in the future. if bootstrapping would be part of libbsc,
there is no need to include more than openbsc.h to use the MNCC
interface. what do you think?
best regards,
andreas
hi holger,
these patches are not the "final" patch. some things must be discussed before of yourse. i removed the out commented code from the patch. some comments like "// todo ..." are not removed. when you look at the file http://home.eversberg.eu/stage1.html, you will see the new version. whenever there is something to complain about, i will change it, until we have patches that all of us agree.
please ask if you don't fully understand the patch. especially for the BSC<->application interface, i was too lazy to describe all details. you will find mncc.c usefull to see how the interface is handled.
regards,
andres
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Sonntag, 17. Mai 2009 09:35
An: openbsc(a)lists.gnumonks.org
Betreff: Re: patches for openbsc
On Friday 15 May 2009 12:37:50 Andreas.Eversberg wrote:
> hi,
>
> finally my patch is documented (almost). you will find the
> documentation of the patch:
>
> http://home.eversberg.eu/stage1.html
>
> the patch in plain text fromat:
>
> http://home.eversberg.eu/stage1.patch
>
> it also includes the changes i posted here before. if you have
> questions, ask.
Hi Andreas,
thank you for the patches. Let me start to review the patches one by one as replies to this one. One general thing with this and the previous patch. I'm quite picky when it comes to commented out code, and left overs from debugging.... please try to avoid leaving that in.
z.
Hello Andreas,
On Fri, 15 May 2009 16:11:06 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i like to use TRX 2. to create objects, i need a password. any idea?
The original password set by the manufacturer depends on the serial
number of the BS-11. However "bs11_config" contains everything needed
to set a new password and create TRX2. If you want to use LMT, you
should run "bs11_config" first and than use LMT, the new password
is in the source code of "bs11_config".
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
i like to use TRX 2. to create objects, i need a password. any idea?
i think that openbsc requires more changes than adding more timeslots.
also the bootstrap process must be improved, i think.
for multiple trx i would suggest to use an array of frequencies for each
trx when calling boostrap_network()
for multiple bts i would suggest to call bootstrap_network() again to
configure the second bts.
for multiple bts on the same E1 interface, is for further study.
andreas
Hi,
I just saw you added to the wiki a "step by step" guide to build the RJ45.
I was wondering why you are saying you use green white / green cables for
pin1&2. I actually pluged in my twinax orange white / orange cables.
Are you using a crossed cable?
Best regards
Eric Cathelinaud
Hello Nordin,
On Thu, 14 May 2009 17:26:22 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> Than I executed the bsc_hack for the nanoBTS (thus I give the
> appropriate parameters as described on the webpage), and I get the
> following error:
> DB: Database initialized.
> DB: Database prepared.
> mi_setup could not open socket Address family not supported by protocol
Do you really provide the correct parameters to bsc_hack ? The
current version of bsc_hack requires the parameter "-t nanobts900"
or "-t nanobts1800", depending on the type of the nanoBTS you have.
If you don't specify the type, the BS-11 is used.
Additionally be sure to specify the ARFCN for a nanoBTS 1800 because
otherwise the default GSM900 channel 123 will be used which does not
work for DCS1800.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
i know that there is an SMS application interface to come. but currently
i like to send SMS via vty interface. i don't know much about the
interface structure of the vty interface.
here is what i actually want:
a daemon checks the hlr for unauthorized subscribers. for the first
entry found, a subscriber extension is assign. additionally an SMS is
sent to the subscriber, to inform about the assigned number, the
network, and dial plan. the subscriber will sen be authorized in the
hlr. this daemon shall run every minute.
regards,
andreas
p.s. the application interface patch is on its way. maybe this weekend.
On Thu, May 14, 2009 at 04:20:49PM +0200, Nordin wrote:
> Than I executed the bsc_hack for the nanoBTS (thus I give the
> appropriate parameters as described on the webpage), and I get the
> following error:
> DB: Database initialized.
> DB: Database prepared.
> mi_setup could not open socket Address family not supported by protocol
you need to start it with '-t nanobts1800' or '-t nanobts900' depending on your
type. if you don't specify any, it will attempt to use a bs11 via E1 / mISDN
(which you did not have compiled into your kernel).
regards,
--
- 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)
I created an #openbsc irc channel into freenode, feel free to
stop by if you're an irc user.
irc://irc.freenode.net/openbsc
Tuju
--
Better to have one, and not need it, than to need one and not have it.
Hi
I'm new dude in this community. I'm a finn, live in Estonia.
I've a background of military radios and their electronic repair,
not that much of civilian stuff, nor GSM systems.
Also studied some RF stuff in technical institute, but i guess
never was the sharpest tool in the shed in this area, spent more
time in unix machine room than in RF lab.
My plan to be a tester/hangaround here, do some minor hacking but
I think my coding skills and limited time leaves it there. If at
some stage packaging in Fedora camp is needed, I am already pkg
maintainer and could help there.
Anyway, your project is very intresting and wish you success in
it.
Tuju
--
Better to have one, and not need it, than to need one and not have it.
Hello friends,
I've tried to get openbsc running on CentOS, but because of a missing
driver (which interfaces between libdbi and sqlite3) it was not a
succes. So I removed CentOS and installed Debian Lenny, as I kinda
noticed most of you work with Debian.
Anyway I managed to install and configure the openbsc with some
exceptions. Because I don't use BS-11, but a nanoBTS instead, so I
didn't patched the kernel for the mISDN card.
I tried the ipaccess-find first, which worked (after I modified my ip
hardcoded in the source).
Than I tried to configure the nanoBTS using the ipaccess-config as
described in this site http://bs11-abis.gnumonks.org/trac/wiki/nanoBTS,
but with our ip addresses ofcrouse.
That seems to work, but the program doesn't return, I don't know if that
is the case. I assume I get response if the nanoBTS gets connected with
the OpenBSC.
Than I executed the bsc_hack for the nanoBTS (thus I give the
appropriate parameters as described on the webpage), and I get the
following error:
DB: Database initialized.
DB: Database prepared.
mi_setup could not open socket Address family not supported by protocol
Can someone please tell me where to look at?
If it's a simple error, just tell me which source does something with
mi_setup, otherwise more info would be fine.
Thank you.
P.S.: I'm a bit new to Linux, so please be patient with me.
Hi,
I followed Debian_Getting_Started chapter in the wiki. There wasn't any
error but, after rebooting, the kernel crashed:
Booting 'Debian GNU/Linux, kernel 2.6.27.4'
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-2.6.27.4 root=/dev/hda1 ro quiet hfcmulti.dslot=1
[Linux-bzImage, setup=0x3000, size=0x1796901]
[0.000000] Unknown boot option 'hfcmulti.dslot=1': ignoring
[0.796125] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
I tried first to delete "hfcmulti.dslot=1" at the kernel line but still have
the second line.
After checking the /boot/grub/menu.lst file, I saw that the line initdr was
missing for the kernel 2.6.27.4:
title 2.6.27.4
root
kernel
title 2.6.26.2
root
kernel
initdr
In /boot directory, I have initdr files only for 2.6.26.2 and 2.6.26.1.
Sorry I am quite weak concerning the kernel.
Can anyone help me?
Thanks a lot
Eric Cathelinaud
hi,
finally the layer 4 interface of openbsc is done. also LCR
(linux-call-router) talks to libbsc. this turns both into a complete
network. libgsm (compiled to LCR) provides audio transcoding. even
asterisk can use it via "chan_lcr" driver.
today i got my first call to a friend from mobile via fixed network.
(because harald did not answer on the first try, he could not receive
the previledge of the first call.)
before i begin providing patches and documentation, i will make some
stability tests.
have a nice weekend..
jolly
Hello Andreas,
On Sat, 9 May 2009 21:14:48 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> finally the layer 4 interface of openbsc is done. also LCR
> (linux-call-router) talks to libbsc. this turns both into a complete
> network. libgsm (compiled to LCR) provides audio transcoding. even
> asterisk can use it via "chan_lcr" driver.
>
> today i got my first call to a friend from mobile via fixed network.
> (because harald did not answer on the first try, he could not receive
> the previledge of the first call.)
>
> before i begin providing patches and documentation, i will make some
> stability tests.
Sounds great, congratulation :-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello,
I have an Issue related to my Debian OpenBSC.
Every time I fire up openbsc everything goes well like the btse
alignement/db alignement on lmt and there are no errors on lmt.
Only openBSC tells me after the initial state were the net should be
up, that the oc or some module(ill add more details later on today) is
"in test".
So this looks like the issue to me why the net wont come up.
But sometimes it works (sometimes it helps to restart the bts but it
wont help everytime).
Im a bit curious why the In test is appearing while lmt (the gui app)
tells me that everything is as it should be...
As far as I know this normally tells me that the object is in Test
mode and is checked because requested on lmt.
May this also be a timing issue on the abis link?
Im writing from iPhone in bed so enough for now.
I would be glad if someone could help/ has an idea.
By the way Ill be at SIGINT09 in Cologne helping out at the GSM
Workshop.
Who will be there too?
Best Regards
Björn Heller
Hello Christian,
On Thu, 30 Apr 2009 03:13:33 +0200, "hotshot" <hotshot(a)koeln.ccc.de> wrote:
>
> Unfortunately I see the same behavior (even with restarting the
> BS-11) as in E1-locked ('hfcmulti' and 'hfcmulti port=0x200) - a
> network scan shows either your BS-11 or the other networks and only
> sometimes you see all networks
In the latest OpenBSC version there is support to show the "Set Value"
and the "Work Value" of the PLL setting. The "Set Value" is the
configuration value from the factory. The "Work Value" is not 100%
clear yet but most certainly it is the value the PLL is actually
using. In "Locked" mode the PLL follows the E1 clock and the
"Work Value" can change quite a lot. Switching to "Standalone"
mode seems to freeze the current "Work Value". The question now
is if the PLL still used this "Work Value" in "Standalone" mode.
If yes and the "Work Value" is off by a large amount the clock is
not accurate (although its most certainly stable) and you still
won't the test network and the other networks at once.
If the "Work Value" of your BS-11 is off by a large amount from
the "Set Value" you can try to switch to "Locked" mode and watch
if the "Work Value" follows the E1 clock. If its close to the
"Set Value", switch back to "Standalone" mode.
I have not tested this and I don't know a better way yet (I don't
think the "Work Value" can be set from the outside) but you can
give it a try.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
