From zecke at selfish.org Thu Oct 1 02:23:02 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 1 Oct 2009 04:23:02 +0200 Subject: [RFC] Changes to the lchan and BSC/MSC split In-Reply-To: <20090930172513.GD31723@prithivi.gnumonks.org> References: <200909300412.37237.zecke@selfish.org> <20090930172513.GD31723@prithivi.gnumonks.org> Message-ID: <200910010423.02578.zecke@selfish.org> On Wednesday 30 September 2009 19:25:13 Harald Welte wrote: > Hi Zecke, Ni Hao Laforge, > > The lchan is getting released when the transaction is finished, > > in case of the "RSL chan" is going away too early there will be a "clear" > > signal/method called from the BSC and the MSC side is asked to let it go. > > well, what we need to somehow ensure is a situation where multiple > transactions are pending / ongoing for one MS, i.e. a call is already > established (or in the process of being established), while another call > is to be signalled, or while SMS are to be delivered, etc. > > How would this fit into your new concept? I think there is no change to the problem above as it is mostly policy (e.g. two phone MS terminated calls at the same time) or to queue SMS submit and then phone call. What is currently in the tree but unused is the "subscr_get" and "subscr_put" methods that implement queuing on top of the paging layer. The current implementation will close the channel on _put and initiate paging again. This could/should be tweaked to issue a channel modify and then pass on the transaction from one subsystem to another. Once everything has been handled the "CLEAR REQUEST"/transaction end would be signalized and the radio resource would be freed. does this make sense to you? holger From zecke at selfish.org Thu Oct 1 02:14:23 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 1 Oct 2009 04:14:23 +0200 Subject: LAC 0 / paging to all BTS In-Reply-To: <20090930124921.GF27065@prithivi.gnumonks.org> References: <20090930112310.GC24634@prithivi.gnumonks.org> <200909301337.42447.zecke@selfish.org> <20090930124921.GF27065@prithivi.gnumonks.org> Message-ID: <200910010414.23951.zecke@selfish.org> On Wednesday 30 September 2009 14:49:21 Harald Welte wrote: > Hi Zecke, > > On Wed, Sep 30, 2009 at 01:37:42PM +0200, Holger Freyther wrote: > > On Wednesday 30 September 2009 13:23:10 Harald Welte wrote: > > > You are now redefiniing the LAC 0 to something like the opposite case, > > > which I don't particularly like. Is there some alternative solution? > > > > I didn't think about the IMSI DETACH case. One easy alternative is to use > > the other reserved lac value. With the least significant bit set 0 and > > all others to 1 (so 0xfffe... ETSI always makes me unsure about it). > > I think LAC = 0xfffe seems to be the way to go for paging of all BTS, wile > we keep LAC = 0 for the 'user is detached' case. Okay, I have added a change set, please check if you are okay with it. holger From laforge at gnumonks.org Thu Oct 1 06:59:26 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 1 Oct 2009 08:59:26 +0200 Subject: Patch: parsing of Software Activate parameters In-Reply-To: <4AC3B510.7080300@btinternet.com> References: <4AC3B510.7080300@btinternet.com> Message-ID: <20091001065926.GS31723@prithivi.gnumonks.org> On Wed, Sep 30, 2009 at 08:44:16PM +0100, Mike Haben wrote: > Hi all, > Patch-file is attached - addresses a FIXME in abis_nm.c, parsing > the parameters passed by a Software Activate request. I've tested > this on three different IpAccess BTSs (including one which didn't > work with the original code), would be good if someone could check > it on a BS11. Hi Mike, thanks for your message. After I find time for some testing, I will apply it (maybe Holger is faster, as he's working on OpenBSC every day at the moment, it seems) BS11 will very likely be unaffected by this, since it does not send software activate requests to the BSC at all. It will simply activate the software that is installed to its non-volatile memory. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Thu Oct 1 13:01:20 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 1 Oct 2009 15:01:20 +0200 Subject: Patch: parsing of Software Activate parameters In-Reply-To: <20091001065926.GS31723@prithivi.gnumonks.org> References: <4AC3B510.7080300@btinternet.com> <20091001065926.GS31723@prithivi.gnumonks.org> Message-ID: <200910011501.21639.zecke@selfish.org> On Thursday 01 October 2009 08:59:26 Harald Welte wrote: > On Wed, Sep 30, 2009 at 08:44:16PM +0100, Mike Haben wrote: > > Hi all, > > Patch-file is attached - addresses a FIXME in abis_nm.c, parsing > > the parameters passed by a Software Activate request. I've tested > > this on three different IpAccess BTSs (including one which didn't > > work with the original code), would be good if someone could check > > it on a BS11. > > Hi Mike, thanks for your message. After I find time for some testing, I > will apply it (maybe Holger is faster, as he's working on OpenBSC every > day at the moment, it seems) I tested the patch, tweaked the comments, pushed it. thanks z. From zecke at selfish.org Thu Oct 1 01:46:25 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 1 Oct 2009 03:46:25 +0200 Subject: [PATCH] input/ipaccess: Fix segv caused by use of uninitialized var In-Reply-To: <1254342904-15695-1-git-send-email-246tnt@gmail.com> References: <1254342904-15695-1-git-send-email-246tnt@gmail.com> Message-ID: <200910010346.26478.zecke@selfish.org> On Wednesday 30 September 2009 22:35:04 Sylvain Munaut wrote: > From: Sylvain Munaut > > This is a regression coming from the recent split of the > handle_ts1_read method in two. Sorry. > > Signed-off-by: Sylvain Munaut > --- > openbsc/src/input/ipaccess.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/openbsc/src/input/ipaccess.c b/openbsc/src/input/ipaccess.c > index 8a22810..40891ae 100644 > --- a/openbsc/src/input/ipaccess.c > +++ b/openbsc/src/input/ipaccess.c > @@ -319,7 +319,7 @@ static int handle_ts1_read(struct bsc_fd *bfd) > return error; > } > > - DEBUGP(DMI, "RX %u: %s\n", ts_nr, hexdump(msgb_l2(msg), ret)); > + DEBUGP(DMI, "RX %u: %s\n", ts_nr, hexdump(msgb_l2(msg), > msgb_l2len(msg))); > > hh = (struct ipaccess_head *) msg->data; > if (hh->proto == IPAC_PROTO_IPACCESS) { > From michael.haben at btinternet.com Thu Oct 1 20:08:49 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Thu, 01 Oct 2009 21:08:49 +0100 Subject: Another day, another patch... 1900 nanoBTS support Message-ID: <4AC50C51.5080109@btinternet.com> Hello again, attached patch adds support for 1900MHz nanoBTS - use one bts_type GSM_BTS_TYPE_NANOBTS to refer to all variants of nanoBTS, and rely on the band specified in the config file when bounds-checking the specified ARFCN. At last getting the hang of git... Best regards, Mike H. From mike at mike-desktop. Thu Oct 1 19:51:38 2009 From: mike at mike-desktop. (Mike (none)) Date: Thu, 1 Oct 2009 20:51:38 +0100 Subject: [PATCH] Add support for 1900 nanoBTS by using unified GSM_BTS_TYPE_NANOBTS to cover 900, 1800 and 1900 versions Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_data.h | 6 ++---- openbsc/src/abis_nm.c | 3 +-- openbsc/src/bsc_init.c | 23 +++++++++++++---------- openbsc/src/gsm_04_08.c | 3 +-- openbsc/src/gsm_data.c | 3 +-- openbsc/src/ipaccess-config.c | 2 +- 6 files changed, 19 insertions(+), 21 deletions(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index 495f741..a493a69 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -242,8 +242,7 @@ struct gsm_bts_trx { enum gsm_bts_type { GSM_BTS_TYPE_UNKNOWN, GSM_BTS_TYPE_BS11, - GSM_BTS_TYPE_NANOBTS_900, - GSM_BTS_TYPE_NANOBTS_1800, + GSM_BTS_TYPE_NANOBTS, }; /** @@ -445,8 +444,7 @@ extern void *tall_bsc_ctx; static inline int is_ipaccess_bts(struct gsm_bts *bts) { switch (bts->type) { - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: return 1; default: break; diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 35ed8db..9a2fad7 100755 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -1025,8 +1025,7 @@ static int abis_nm_rcvmsg_manuf(struct msgb *mb) int bts_type = mb->trx->bts->type; switch (bts_type) { - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: rc = abis_nm_rx_ipacc(mb); break; default: diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index c626415..3f5df23 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -526,8 +526,7 @@ static void nm_reconfig_trx(struct gsm_bts_trx *trx) sizeof(trx1_attr_radio)); } break; - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: trx->nominal_power = 20; default: break; @@ -594,8 +593,7 @@ static void bootstrap_om(struct gsm_bts *bts) case GSM_BTS_TYPE_BS11: bootstrap_om_bs11(bts); break; - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: bootstrap_om_nanobts(bts); break; default: @@ -985,23 +983,28 @@ void input_event(int event, enum e1inp_sign_type type, struct gsm_bts_trx *trx) static int bootstrap_bts(struct gsm_bts *bts) { - switch (bts->type) { - case GSM_BTS_TYPE_NANOBTS_1800: + switch (bts->band) { + case GSM_BAND_1800: if (bts->c0->arfcn < 512 || bts->c0->arfcn > 885) { fprintf(stderr, "GSM1800 channel must be between 512-885.\n"); return -EINVAL; } break; - case GSM_BTS_TYPE_BS11: - case GSM_BTS_TYPE_NANOBTS_900: + case GSM_BAND_1900: + if (bts->c0->arfcn < 512 || bts->c0->arfcn > 810) { + fprintf(stderr, "GSM1900 channel must be between 512-810.\n"); + return -EINVAL; + } + break; + case GSM_BAND_900: - /* Assume we have a P-GSM900 here */ if (bts->c0->arfcn < 1 || bts->c0->arfcn > 124) { fprintf(stderr, "GSM900 channel must be between 1-124.\n"); return -EINVAL; } break; - case GSM_BTS_TYPE_UNKNOWN: - fprintf(stderr, "Unknown BTS. Please specify\n"); + default: + fprintf(stderr, "Unsupported frequency band.\n"); return -EINVAL; } diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c index bac920e..9ad9e15 100644 --- a/openbsc/src/gsm_04_08.c +++ b/openbsc/src/gsm_04_08.c @@ -1954,8 +1954,7 @@ static int tch_map(struct gsm_lchan *lchan, struct gsm_lchan *remote_lchan) } switch (bts->type) { - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: if (!ipacc_rtp_direct) { /* connect the TCH's to our RTP proxy */ rc = ipacc_connect_proxy_bind(lchan); diff --git a/openbsc/src/gsm_data.c b/openbsc/src/gsm_data.c index a50ba8c..6767c3f 100644 --- a/openbsc/src/gsm_data.c +++ b/openbsc/src/gsm_data.c @@ -232,8 +232,7 @@ char *gsm_ts_name(struct gsm_bts_trx_ts *ts) static const char *bts_types[] = { [GSM_BTS_TYPE_UNKNOWN] = "unknown", [GSM_BTS_TYPE_BS11] = "bs11", - [GSM_BTS_TYPE_NANOBTS_900] = "nanobts900", - [GSM_BTS_TYPE_NANOBTS_1800] = "nanobts1800", + [GSM_BTS_TYPE_NANOBTS] = "nanobts", }; enum gsm_bts_type parse_btstype(const char *arg) diff --git a/openbsc/src/ipaccess-config.c b/openbsc/src/ipaccess-config.c index 7358d64..46043d5 100644 --- a/openbsc/src/ipaccess-config.c +++ b/openbsc/src/ipaccess-config.c @@ -348,7 +348,7 @@ int main(int argc, char **argv) if (!gsmnet) exit(1); - bts = gsm_bts_alloc(gsmnet, GSM_BTS_TYPE_NANOBTS_900, HARDCODED_TSC, + bts = gsm_bts_alloc(gsmnet, GSM_BTS_TYPE_NANOBTS, HARDCODED_TSC, HARDCODED_BSIC); register_signal_handler(SS_NM, nm_sig_cb, NULL); -- 1.6.0.4 --------------020006030004070001070807-- From zecke at selfish.org Fri Oct 2 03:29:59 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 2 Oct 2009 05:29:59 +0200 Subject: Another day, another patch... 1900 nanoBTS support In-Reply-To: <4AC50C51.5080109@btinternet.com> References: <4AC50C51.5080109@btinternet.com> Message-ID: <200910020530.00152.zecke@selfish.org> On Thursday 01 October 2009 22:08:49 Mike Haben wrote: > Hello again, > attached patch adds support for 1900MHz nanoBTS - use one bts_type > GSM_BTS_TYPE_NANOBTS to refer to all variants of nanoBTS, and rely on > the band specified in the config file when bounds-checking the specified > ARFCN. Awesome. From zecke at selfish.org Fri Oct 2 06:42:31 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 2 Oct 2009 08:42:31 +0200 Subject: Another day, another patch... 1900 nanoBTS support In-Reply-To: <200910020530.00152.zecke@selfish.org> References: <4AC50C51.5080109@btinternet.com> <200910020530.00152.zecke@selfish.org> Message-ID: <200910020842.31745.zecke@selfish.org> On Friday 02 October 2009 05:29:59 Holger Freyther wrote: > On Thursday 01 October 2009 22:08:49 Mike Haben wrote: > > Hello again, > > attached patch adds support for 1900MHz nanoBTS - use one bts_type > > GSM_BTS_TYPE_NANOBTS to refer to all variants of nanoBTS, and rely on > > the band specified in the config file when bounds-checking the specified > > ARFCN. > > Awesome. > Okay, git am can not apply the patch and says it is corrupted. Is it my ext4 playing tricks on me? could you help me with sending the patch again? z. From laforge at gnumonks.org Fri Oct 2 07:28:51 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Oct 2009 09:28:51 +0200 Subject: Another day, another patch... 1900 nanoBTS support In-Reply-To: <4AC50C51.5080109@btinternet.com> References: <4AC50C51.5080109@btinternet.com> Message-ID: <20091002072851.GV19548@prithivi.gnumonks.org> Hi Mike, thanks for your patch. On Thu, Oct 01, 2009 at 09:08:49PM +0100, Mike Haben wrote: > attached patch adds support for 1900MHz nanoBTS - use one bts_type > GSM_BTS_TYPE_NANOBTS to refer to all variants of nanoBTS, and rely > on the band specified in the config file when bounds-checking the > specified ARFCN. > At last getting the hang of git... Thanks this makes sense, but.... In fact, we could even go beyond that at some point and inquire the band capabilities from the BTS. I'm quite sure i've once seen something like this in the ip.access protocol while working with the wireshark dissector for it. We will definitely have to differentiate the old 1800/1900 (round like the 850/900 models) and the new 1800/1900 models in some way, as the latter support edge and the former don't. But I suppose that can also be read through OML from the BTS. The hardware type is 178U for the non-edge version and 165AU for the EDGE capable version, at least on all my units. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Fri Oct 2 07:45:35 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Fri, 02 Oct 2009 07:45:35 +0000 Subject: Another day, another patch... 1900 nanoBTS support In-Reply-To: <20091002072851.GV19548@prithivi.gnumonks.org> Message-ID: <00504502ca221182f50474eef3e6@google.com> > But I suppose that can also be read through OML from the BTS. The hardware > type is 178U for the non-edge version and 165AU for the EDGE capable > version, > at least on all my units. fyi, mine is model number 139 (it's a round 1800 version, without EDGE, see internal pictures in the wiki). It would probably be useful to make a complete list of all known version numbers on the wiki. That's 3 version already. Anyone has other versions ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Fri Oct 2 15:41:04 2009 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 02 Oct 2009 17:41:04 +0200 Subject: Another day, another patch... 1900 nanoBTS support In-Reply-To: <00504502ca221182f50474eef3e6@google.com> References: <00504502ca221182f50474eef3e6@google.com> Message-ID: <4AC61F10.4010702@gmail.com> > Anyone has other versions ? Well, I might get a nanoBTS3G to play with! A nice client will borrow me a UMTS version of nanoBTS, also from the same manufactory ip.access. I'll let you know soon ;) From michael.haben at btinternet.com Thu Oct 1 20:14:49 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Thu, 01 Oct 2009 21:14:49 +0100 Subject: Oops... Message-ID: <4AC50DB9.5000206@btinternet.com> Sorry about the message before last - how the hell did git do that? Mike H. From zecke at selfish.org Fri Oct 2 03:26:13 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 2 Oct 2009 05:26:13 +0200 Subject: Oops... In-Reply-To: <4AC50DB9.5000206@btinternet.com> References: <4AC50DB9.5000206@btinternet.com> Message-ID: <200910020526.13807.zecke@selfish.org> On Thursday 01 October 2009 22:14:49 Mike Haben wrote: > Sorry about the message before last - how the hell did git do that? git send-patch? You should consider setting a proper email address with git config... maybe even use --global to set it globally. holger From michael.haben at btinternet.com Fri Oct 2 11:29:36 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Fri, 02 Oct 2009 12:29:36 +0100 Subject: That patch again... Message-ID: <4AC5E420.7080202@btinternet.com> Sorry about that Holger, another lesson learned - I'd manually edited the patch to remove an extra line. Now recreated from scratch. Very much like Harald's idea of reading the model / frequency-band from the unit - may end up with GSM_BTS_TYPE_NANOBTS_OLD and GSM_BTS_TYPE_NANOBTS_NEW or similar? Best regards, Mike H. From mike at mike-desktop. Fri Oct 2 11:19:34 2009 From: mike at mike-desktop. (Mike (none)) Date: Fri, 2 Oct 2009 12:19:34 +0100 Subject: [PATCH] Add support for 1900 nanoBTS by using unified bts_type GSM_BTS_TYPE_NANOBTS for 900, 1800 and 1900 versions Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_data.h | 6 ++---- openbsc/src/abis_nm.c | 3 +-- openbsc/src/bsc_init.c | 24 +++++++++++++----------- openbsc/src/gsm_04_08.c | 3 +-- openbsc/src/gsm_data.c | 3 +-- openbsc/src/ipaccess-config.c | 2 +- 6 files changed, 19 insertions(+), 22 deletions(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index 495f741..a493a69 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -242,8 +242,7 @@ struct gsm_bts_trx { enum gsm_bts_type { GSM_BTS_TYPE_UNKNOWN, GSM_BTS_TYPE_BS11, - GSM_BTS_TYPE_NANOBTS_900, - GSM_BTS_TYPE_NANOBTS_1800, + GSM_BTS_TYPE_NANOBTS, }; /** @@ -445,8 +444,7 @@ extern void *tall_bsc_ctx; static inline int is_ipaccess_bts(struct gsm_bts *bts) { switch (bts->type) { - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: return 1; default: break; diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 35ed8db..9a2fad7 100755 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -1025,8 +1025,7 @@ static int abis_nm_rcvmsg_manuf(struct msgb *mb) int bts_type = mb->trx->bts->type; switch (bts_type) { - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: rc = abis_nm_rx_ipacc(mb); break; default: diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index c626415..78e9861 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -526,8 +526,7 @@ static void nm_reconfig_trx(struct gsm_bts_trx *trx) sizeof(trx1_attr_radio)); } break; - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: trx->nominal_power = 20; default: break; @@ -594,8 +593,7 @@ static void bootstrap_om(struct gsm_bts *bts) case GSM_BTS_TYPE_BS11: bootstrap_om_bs11(bts); break; - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: bootstrap_om_nanobts(bts); break; default: @@ -985,23 +983,27 @@ void input_event(int event, enum e1inp_sign_type type, struct gsm_bts_trx *trx) static int bootstrap_bts(struct gsm_bts *bts) { - switch (bts->type) { - case GSM_BTS_TYPE_NANOBTS_1800: + switch (bts->band) { + case GSM_BAND_1800: if (bts->c0->arfcn < 512 || bts->c0->arfcn > 885) { fprintf(stderr, "GSM1800 channel must be between 512-885.\n"); return -EINVAL; } break; - case GSM_BTS_TYPE_BS11: - case GSM_BTS_TYPE_NANOBTS_900: - /* Assume we have a P-GSM900 here */ + case GSM_BAND_1900: + if (bts->c0->arfcn < 512 || bts->c0->arfcn > 810) { + fprintf(stderr, "GSM1900 channel must be between 512-810.\n"); + return -EINVAL; + } + break; + case GSM_BAND_900: if (bts->c0->arfcn < 1 || bts->c0->arfcn > 124) { fprintf(stderr, "GSM900 channel must be between 1-124.\n"); return -EINVAL; } break; - case GSM_BTS_TYPE_UNKNOWN: - fprintf(stderr, "Unknown BTS. Please specify\n"); + default: + fprintf(stderr, "Unsupported frequency band.\n"); return -EINVAL; } diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c index bac920e..9ad9e15 100644 --- a/openbsc/src/gsm_04_08.c +++ b/openbsc/src/gsm_04_08.c @@ -1954,8 +1954,7 @@ static int tch_map(struct gsm_lchan *lchan, struct gsm_lchan *remote_lchan) } switch (bts->type) { - case GSM_BTS_TYPE_NANOBTS_900: - case GSM_BTS_TYPE_NANOBTS_1800: + case GSM_BTS_TYPE_NANOBTS: if (!ipacc_rtp_direct) { /* connect the TCH's to our RTP proxy */ rc = ipacc_connect_proxy_bind(lchan); diff --git a/openbsc/src/gsm_data.c b/openbsc/src/gsm_data.c index a50ba8c..6767c3f 100644 --- a/openbsc/src/gsm_data.c +++ b/openbsc/src/gsm_data.c @@ -232,8 +232,7 @@ char *gsm_ts_name(struct gsm_bts_trx_ts *ts) static const char *bts_types[] = { [GSM_BTS_TYPE_UNKNOWN] = "unknown", [GSM_BTS_TYPE_BS11] = "bs11", - [GSM_BTS_TYPE_NANOBTS_900] = "nanobts900", - [GSM_BTS_TYPE_NANOBTS_1800] = "nanobts1800", + [GSM_BTS_TYPE_NANOBTS] = "nanobts", }; enum gsm_bts_type parse_btstype(const char *arg) diff --git a/openbsc/src/ipaccess-config.c b/openbsc/src/ipaccess-config.c index 7358d64..46043d5 100644 --- a/openbsc/src/ipaccess-config.c +++ b/openbsc/src/ipaccess-config.c @@ -348,7 +348,7 @@ int main(int argc, char **argv) if (!gsmnet) exit(1); - bts = gsm_bts_alloc(gsmnet, GSM_BTS_TYPE_NANOBTS_900, HARDCODED_TSC, + bts = gsm_bts_alloc(gsmnet, GSM_BTS_TYPE_NANOBTS, HARDCODED_TSC, HARDCODED_BSIC); register_signal_handler(SS_NM, nm_sig_cb, NULL); -- 1.6.0.4 --------------010903070906000806000204-- From philipp at hug.cx Fri Oct 2 15:09:00 2009 From: philipp at hug.cx (philipp at hug.cx) Date: Fri, 2 Oct 2009 17:09:00 +0200 (CEST) Subject: ip.access nanoBTS 140 - GSM1900 Message-ID: <40163.172.16.2.35.1254496140.squirrel@mail.hug.cx> Hi everyone, I'm trying to get an ip.access nanobts 140 working with OpenBSC. Chaning oml ip worked. But when I try to start tests using "-l 64" or start bsc_hack it looks like it doesn't go online. I also applied a similar patch than the one from Mike Haben to handle the GSM1900 nanoBTS. Does anyone have an idea? Philipp Here's the output: ./ipaccess-config -l 64 172.16.19.39 ipaccess-config (C) 2009 by Harald Welte This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Trying to connect to ip.access BTS ... OML link established <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 30 62 31 36 64 30 00 <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:863 Software Activate Request NACKing for GPRS obj_class 0xf0 <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 30 62 31 36 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 30 62 31 36 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) From philipp at hug.cx Fri Oct 2 15:19:54 2009 From: philipp at hug.cx (philipp at hug.cx) Date: Fri, 2 Oct 2009 17:19:54 +0200 (CEST) Subject: ip.access nanoBTS 140 - GSM1900 Message-ID: <42445.172.16.2.35.1254496794.squirrel@mail.hug.cx> Hi everyone, I'm trying to get an ip.access nanobts 140 working with OpenBSC. Chaning oml ip worked. But when I try to start tests using "-l 64" or start bsc_hack it looks like it doesn't go online. I also applied a similar patch than the one from Mike Haben to handle the GSM1900 nanoBTS. Does anyone have an idea? Philipp Here's the output: ./ipaccess-config -l 64 172.16.19.39 ipaccess-config (C) 2009 by Harald Welte This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Trying to connect to ip.access BTS ... OML link established <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 30 62 31 36 64 30 00 <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:863 Software Activate Request NACKing for GPRS obj_class 0xf0 <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 30 62 31 36 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 30 62 31 36 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) From 246tnt at gmail.com Fri Oct 2 16:17:10 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 2 Oct 2009 18:17:10 +0200 Subject: ip.access nanoBTS 140 - GSM1900 In-Reply-To: <42445.172.16.2.35.1254496794.squirrel@mail.hug.cx> References: <42445.172.16.2.35.1254496794.squirrel@mail.hug.cx> Message-ID: <866320f70910020917s55a990d4j89d9e305d511fd81@mail.gmail.com> For reference: Here's my full output : tnt at lain ~/projects/openbsc $ /opt/openbsc/sbin/bsc_hack DB: Database initialized. DB: Database prepared. <8000> input/ipaccess.c:481 accept()ed new OML link from 10.0.0.133 <8000> input/ipaccess.c:221 Identified BTS 1801/0/0 bootstrapping OML for BTS 0 <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0020> abis_nm.c:805 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: <0020> abis_nm.c:859 Software Activate Request ACKing and Activating <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x00 obj_inst=(0xff, 0xff, 0xff) <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0020> abis_nm.c:859 Software Activate Request ACKing and Activating <0020> abis_nm.c:859 Software Activate Request NACKing for GPRS obj_class 0xf0 <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1644 Set BTS Attr (bts=0) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x01 obj_inst=(0x00, 0xff, 0xff) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0020> abis_nm.c:859 Software Activate Request ACKing and Activating <0020> abis_nm.c:859 Software Activate Request ACKing and Activating <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x04 obj_inst=(0x00, 0x00, 0xff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=0) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x00) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=1) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x01) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=2) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x02) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=3) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=4) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x04) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=5) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=6) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x06) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=7) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:1661 Set TRX Attr (bts=0,trx=0) <0020> abis_nm.c:1828 Sending OPSTART obj_class=0x02 obj_inst=(0x00, 0x00, 0xff) <0020> abis_nm.c:2450 IPACCESS(0xe1): RSL CONNECT ACK IP=10.0.0.130 PORT=3003 <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <8000> input/ipaccess.c:542 accept()ed new RSL link from 10.0.0.133 <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <8000> input/ipaccess.c:221 Identified BTS 1801/0/0 <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=failure ceased <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) bootstrapping RSL for BTS/TRX (0/0) using MCC=901 MNC=55 BSIC=63 TSC=7 And my config file : ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! network network country code 901 mobile network code 55 short name OpenBSC long name OpenBSC auth policy accept-all bts 0 type nanobts1800 ip.access unit_id 1801 0 band GSM1800 location_area_code 1 training_sequence_code 7 base_station_id_code 63 oml e1 line 0 timeslot 1 sub-slot full oml e1 tei 25 ! Limit to 12dBm ~ 16 mW ms max power 12 trx 0 arfcn 514 ! Setup a 12dB attenuation (24dBm - 12dBm => 12dBm ~ 16 mW) max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 1 timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 0 timeslot 1 sub-slot full timeslot 1 phys_chan_config SDCCH8 e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 From michael.haben at btinternet.com Fri Oct 2 16:32:10 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Fri, 02 Oct 2009 17:32:10 +0100 Subject: nanoBTS model numbers Message-ID: <4AC62B0A.8040007@btinternet.com> Hi Sylvain, I asked a colleague of mine about nanoBTS model-numbers, he gave me a list of available models that he got from IpAccess when he was looking to buy some BTSs from them a while ago. They seem to use different internal and external model-numbers for the non-EDGE oval models, maybe not for the EDGE models; I've put in the three external->internal number correspondences I know for definite: Model no. IpAccess ref. Description 108B 1800MHz single-TRX BTS GPRS - OLD 108D 1800MHz multi-TRX nanoBTS 139U 108DU 1800MHz multi-TRX nanoBTS 108E 1900MHz multi-TRX nanoBTS 108EF 1900MHz multi-TRX nanoBTS 108ER012 1900MHz multi-TRX nanoBTS 178U 108GU 900MHz BTS RoHS-compliant 108H 850MHz BTS - pre-release product 108HU 850MHz BTS - pre-release product 165AU 165AU 1800MHz EDGE BTS 165B 1900MHz EDGE BTS 165BU 1900MHz EDGE BTS 165CU 900MHz EDGE BTS 165DU 850MHz EDGE BTS 165 E012 1800MHz extended temperature EDGE BTS Pre Custom 165FM 1900MHz temperature-hardened EDGE BTS module I know there are also models 110A and 140, both 1900MHz oval models, but don't know what internal refs they correspond to. HTH, Mike H From 246tnt at gmail.com Fri Oct 2 16:41:06 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 2 Oct 2009 18:41:06 +0200 Subject: nanoBTS model numbers In-Reply-To: <4AC62B0A.8040007@btinternet.com> References: <4AC62B0A.8040007@btinternet.com> Message-ID: <866320f70910020941i4ee4b730r589f272ae0507659@mail.gmail.com> Hi Mike, yes, this is really nice thanks ! I'll put that on the wiki. I didn't even knew the one I had was multi-TRX. OpenBSC doesn't handle that for nanoBTS I think (or does it ?) Sylvain From laforge at gnumonks.org Fri Oct 2 20:37:41 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Oct 2009 22:37:41 +0200 Subject: nanoBTS multi TRX In-Reply-To: <866320f70910020941i4ee4b730r589f272ae0507659@mail.gmail.com> References: <4AC62B0A.8040007@btinternet.com> <866320f70910020941i4ee4b730r589f272ae0507659@mail.gmail.com> Message-ID: <20091002203741.GN19548@prithivi.gnumonks.org> On Fri, Oct 02, 2009 at 06:41:06PM +0200, Sylvain Munaut wrote: > I didn't even knew the one I had was multi-TRX. OpenBSC doesn't handle > that for nanoBTS I think (or does it ?) "multi-TRX" in this context simply means that you can stack multiple unit to behave like one BTS with multiple TRX rather than multiple BTS with one TRX each. We don't have explicit support for it in OpenBSC so far, but I think there should be nothing major missing either, as we already support multiple TRX in the E1 case. All we have is suddenly two TCP connections with RSL rather than one. It probably boils down to somebody testing it and tracing any remaining bug, but there's no fundamental part of the code that needs massive changes to support this. I'm in the process of building one of those custom modified RJ69 cables that you need to stack them. I'm busy with lots of other work, and it is not of very high importance, though. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michael.haben at btinternet.com Sat Oct 3 06:45:26 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Sat, 03 Oct 2009 07:45:26 +0100 Subject: Low-cost engineer / net-monitor handsets Message-ID: <4AC6F306.2010707@btinternet.com> Slightly off-topic, but this may be of use when testing OpenBSC... Some mobiles made by Pantech have an engineering mode built in - displays various parameters of the network like LAC, BSIC, ARFCN and signal-strength (C1 value) of serving and neighbour cells, TMSI assigned to phone, timing advance etc. The two models I've played with are: PG-C3 - very comprehensive data (10 screens of it!), engineer mode persists when power-cycled, but US tri-band, so does not cover 900MHz band. PG-C520 - quad-band, but data not so comprehensive (e.g. no timing advance), engineer mode does not persist I bought mine from an Ebay shop in the USA: http://stores.shop.ebay.co.uk/Khala-Ki-Dukan__W0QQ_armrsZ1 Both models were < 100 Euro, even with postage from the States and import tax. If anyone's interested, email me and I'll post some screenshots. Does anyone know of other phones with built-in net-monitor / engineer functions (other than the old Nokias!)? Thanks, Mike H. From jens.david at jens-david-consulting.com Sat Oct 3 07:02:23 2009 From: jens.david at jens-david-consulting.com (Jens David) Date: Sat, 3 Oct 2009 09:02:23 +0200 Subject: Low-cost engineer / net-monitor handsets In-Reply-To: <4AC6F306.2010707@btinternet.com> References: <4AC6F306.2010707@btinternet.com> Message-ID: Good old Sony-Ericsson T610 has 3-pages persisting GSM network monitor mode and 1 page GPRS. Assigned TMSI is not part of it, unfortunately, but everything else. -j Am 03.10.2009 um 08:45 schrieb Mike Haben: > Slightly off-topic, but this may be of use when testing OpenBSC... > > Some mobiles made by Pantech have an engineering mode built in - > displays various parameters of the network like LAC, BSIC, ARFCN and > signal-strength (C1 value) of serving and neighbour cells, TMSI > assigned to phone, timing advance etc. The two models I've played > with are: > PG-C3 - very comprehensive data (10 screens of it!), engineer mode > persists when power-cycled, but US tri-band, so does not cover > 900MHz band. > PG-C520 - quad-band, but data not so comprehensive (e.g. no timing > advance), engineer mode does not persist > > I bought mine from an Ebay shop in the USA: > http://stores.shop.ebay.co.uk/Khala-Ki-Dukan__W0QQ_armrsZ1 > Both models were < 100 Euro, even with postage from the States and > import tax. If anyone's interested, email me and I'll post some > screenshots. > > Does anyone know of other phones with built-in net-monitor / > engineer functions (other than the old Nokias!)? > > Thanks, Mike H. > > -- Jens David, DG1KJD jens.david at jens-david-consulting.com http://www.jens-david-consulting.com From 246tnt at gmail.com Sat Oct 3 10:17:30 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sat, 03 Oct 2009 10:17:30 +0000 Subject: Low-cost engineer / net-monitor handsets In-Reply-To: Message-ID: <0016364d20a13207cd04750530f1@google.com> On Oct 3, 2009 9:02am, Jens David wrote: > Good old Sony-Ericsson T610 has 3-pages persisting GSM network monitor > mode and 1 page GPRS. Assigned TMSI is not part of it, unfortunately, but > everything else. Really ? Do you have a mean to activate it because I couldn't find one ... They're not really 'low cost' but : * iPhone Dial *3001#12345#* and you'll get to field test mode where you view some info. TMSI is not part of it, but you can also ssh into the phone and with AT commands interrogate the SIM and get TMSI, Kc, ... * Android G2 : Dial *#*#7262626#*#* to get to field test mode then setup button to select page. There is lot of info including TMSI and you can even log to SD card. There is a minor glitch that makes the scroll bar hide part of the values, so the last digit is only half displayed and you have to try and guess it ... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.david at jens-david-consulting.com Sun Oct 4 00:16:27 2009 From: jens.david at jens-david-consulting.com (Jens David) Date: Sun, 4 Oct 2009 02:16:27 +0200 Subject: Low-cost engineer / net-monitor handsets In-Reply-To: <0016364d20a13207cd04750530f1@google.com> References: <0016364d20a13207cd04750530f1@google.com> Message-ID: <098B10A0-981D-4CF6-BE81-5E456A8C14C0@jens-david-consulting.com> A service cable called "terminator dongle" (see ebay) is needed to activate it, and the programming software used with it. I still have the cable, but not the software nor the OS needed (win2k). I could send you the cable if required. --j Am 03.10.2009 um 12:17 schrieb 246tnt at gmail.com: > On Oct 3, 2009 9:02am, Jens David > wrote: > > Good old Sony-Ericsson T610 has 3-pages persisting GSM network > monitor mode and 1 page GPRS. Assigned TMSI is not part of it, > unfortunately, but everything else. > > Really ? Do you have a mean to activate it because I couldn't find > one ... > > > They're not really 'low cost' but : > > * iPhone Dial *3001#12345#* and you'll get to field test mode where > you view some info. TMSI is not part of it, but you can also ssh > into the phone and with AT commands interrogate the SIM and get > TMSI, Kc, ... > > * Android G2 : Dial *#*#7262626#*#* to get to field test mode then > setup button to select page. There is lot of info including TMSI and > you can even log to SD card. There is a minor glitch that makes the > scroll bar hide part of the values, so the last digit is only half > displayed and you have to try and guess it ... > > > Sylvain -- Jens David, DG1KJD jens.david at jens-david-consulting.com http://www.jens-david-consulting.com From 246tnt at gmail.com Sat Oct 3 12:02:48 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 3 Oct 2009 14:02:48 +0200 Subject: [PATCH] abis_nm: Fix ACTIVATE SW parameters Message-ID: <1254571368-19494-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut The previous code only sent the FILE_ID tag data part, but according to the GSM 12.21 spec, section 8.3.6, the full SW Description 'object' must be sent so that includes the NM_ATT_SW_DESCR tag, the whole FILE_ID and the whole FILE_VERSION (including tags & length fields). Note that functionnaly on a nanoBTS 139 I couldn't see any difference ... whatever I send in there it works ... Signed-off-by: Sylvain Munaut --- openbsc/src/abis_nm.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 35ed8db..a450452 100755 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -857,6 +857,7 @@ static int abis_nm_rx_sw_act_req(struct msgb *mb) const u_int8_t *sw_config; int sw_config_len; int file_id_len; + int file_ver_len; int nack = 0; int ret; @@ -889,18 +890,24 @@ static int abis_nm_rx_sw_act_req(struct msgb *mb) if (sw_config[0] != NM_ATT_SW_DESCR) DEBUGP(DNM, "SW_DESCR attribute identifier not found!\n"); + if (sw_config[1] != NM_ATT_FILE_ID) DEBUGP(DNM, "FILE_ID attribute identifier not found!\n"); file_id_len = sw_config[2] * 256 + sw_config[3]; + if (sw_config[4+file_id_len] != NM_ATT_FILE_VERSION) + DEBUGP(DNM, "FILE_VERSION attribute identifier not found!\n"); + file_ver_len = sw_config[5+file_id_len] * 256 + sw_config[6+file_id_len]; + /* Assumes first SW file in list is the one to be activated */ - /* sw_config + 4 to skip over 2 attribute ID bytes and 16-bit length field */ + /* The +7 in length is to account for the 3 tags and 2 length fields */ + /* (see GSM 12.21 - 9.4.{62,18,19} for details */ return ipacc_sw_activate(mb->trx->bts, foh->obj_class, foh->obj_inst.bts_nr, foh->obj_inst.trx_nr, foh->obj_inst.ts_nr, - sw_config + 4, - file_id_len); + sw_config, + 7 + file_id_len + file_ver_len); } /* Receive a CHANGE_ADM_STATE_ACK, parse the TLV and update local state */ -- 1.6.4 From laforge at gnumonks.org Sun Oct 4 11:47:30 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 4 Oct 2009 13:47:30 +0200 Subject: [PATCH] abis_nm: Fix ACTIVATE SW parameters In-Reply-To: <1254571368-19494-1-git-send-email-246tnt@gmail.com> References: <1254571368-19494-1-git-send-email-246tnt@gmail.com> Message-ID: <20091004114730.GA3628@prithivi.gnumonks.org> Hi Sylvain, instead of building more hacks on existing hacks, we should probably consider to use our TLV parser instead of things like: > if (sw_config[0] != NM_ATT_SW_DESCR) > DEBUGP(DNM, "SW_DESCR attribute identifier not found!\n"); > + > if (sw_config[1] != NM_ATT_FILE_ID) > DEBUGP(DNM, "FILE_ID attribute identifier not found!\n"); > file_id_len = sw_config[2] * 256 + sw_config[3]; > > + if (sw_config[4+file_id_len] != NM_ATT_FILE_VERSION) > + DEBUGP(DNM, "FILE_VERSION attribute identifier not found!\n"); > + file_ver_len = sw_config[5+file_id_len] * 256 + sw_config[6+file_id_len]; all that we need is a second 'struct tlv_parsed' on the stack, as well as a 'static const struct tlv_definition' for the nested attributes such as SW_DESCR and FILE_ID, FILE_VERSION (or any others, if they exist). If you have the time, I would appreciate a patch that solves the problem this way, rather than manually calculating lengths and indexing into sw_config[], etc. The existing software activation code probably predates our tlv_parser and thus wasn't written properly in the first place. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun Oct 4 12:46:15 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sun, 04 Oct 2009 12:46:15 +0000 Subject: [PATCH] abis_nm: Fix ACTIVATE SW parameters In-Reply-To: <20091004114730.GA3628@prithivi.gnumonks.org> Message-ID: <0016e6db68530009f604751b62c1@google.com> Hi Harald, > instead of building more hacks on existing hacks, we should probably > consider to use our TLV parser instead [... patch snipped ...] > all that we need is a second 'struct tlv_parsed' on the stack, as well as > a 'static const struct tlv_definition' for the nested attributes such as > SW_DESCR and FILE_ID, FILE_VERSION (or any others, if they exist). Mmmm, I don't really see how to do that without another hack ... * You can view it either as flat (liek the wireshard dissector does) like this : SW_CONFIG FILE_ID len_16 data FILE_VERSION len_16 data SW_CONFIG FILE_ID len_16 data FILE_VERSION len_16 data But then the problem is that the tag will override each other in the tlv_parser, you can't really 'choose' which config you get. * Or you can view the FILE_ID & FILE_VERSION as 'nested into' SW_CONFIG: SW_CONFIG FILE_ID len_16 data FILE_VERSION len_16 data SW_CONFIG FILE_ID len_16 data FILE_VERSION len_16 data But that's not better, because even if I start tlv_parsing a sw_config+1, SW_CONFIG tag doesn't have a 'length' it's just defined as having two child, so I can't really tell the tlv_parser to stop and it will continue past the first FILE_VERSION and into the second SW_CONFIG tag. Or am I missing something obvious here ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Sat Oct 3 19:23:52 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sat, 3 Oct 2009 21:23:52 +0200 Subject: audio support for application interface with nanoBTS Message-ID: hi, here is the patch to support audio exchange between application interface and nanoBTS. the patch changes the audio format from TRAU frame format to RTP payload format on the application interface. also the BS11 TRAU frame is converted to/from RTP payload format (inside trau_mux.c), so an application does not have to care about what BTS is used. here is the format as defined by RFC: (just fyi) first byte has the magic value of 0xd0 plus four upper bits of the LARc[0] element as lower bits. second byte has the lower two bits of the LARc[0] element as upper bits and the upper bits of LARc[1] element as lower bits. third byte has the lower four bits of LARc[1] element as upper bits and so on... this format can directly be transcoded with the open source lossy gsm codec. the rtp_proxy.c now parses RTP frames and generates them. for easier code, i just mirrored the received RTCP frames back to the nanoBTS, mangled of yourse. (oops, maybe i need to change some synchronization source identifiers.) i think there is no problem with that right now. because RFC requires special synchronization source (ssrc) generation, i added md5 code and the (funny) random number generator. (see rtp_proxy.c random32()) as soon as the patch is applied, i will also check in linux-call-router modification for the new audio frame format. note that this code is just quickly tested, it works with both BS11 and nanoBTS and should not crash on corrupt or extended RTP data. the delay of audio data sent to nanoBTS was > 0.5 seconds. i think this is too much. maybe it is because i seamlessly increment the timestamp value in the RTP frame, even if the application dropps (delays) frames. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtp.patch Type: application/octet-stream Size: 21809 bytes Desc: rtp.patch URL: From laforge at gnumonks.org Sun Oct 4 06:30:58 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 4 Oct 2009 08:30:58 +0200 Subject: audio support for application interface with nanoBTS In-Reply-To: References: Message-ID: <20091004063058.GE19548@prithivi.gnumonks.org> Thanks a lot, Andreas. I will review this ASAP, though it might take until tuesday until I can actually play with it and test it, due to travel reasons. One thing I noted immediately: The newly-introduced md5c.c file is missing from your diff. Can you please re-submit with that file? Thanks. (in case you work with git, first 'git add' the file, then 'git diff HEAD', if all your changes are not yet committed) Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Sun Oct 4 09:42:15 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 4 Oct 2009 11:42:15 +0200 Subject: AW: audio support for application interface with nanoBTS Message-ID: > One thing I noted immediately: The newly-introduced md5c.c file is missing from your diff. Can you please re-submit with that file? Thanks. >(in case you work with git, first 'git add' the file, then 'git diff HEAD', if all your changes are not yet committed) ok, again a corrected verion of the rtp.patch (hopefully complete) -------------- next part -------------- A non-text attachment was scrubbed... Name: rtp_3.patch Type: application/octet-stream Size: 35150 bytes Desc: rtp_3.patch URL: From laforge at gnumonks.org Sun Oct 4 11:51:29 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 4 Oct 2009 13:51:29 +0200 Subject: md5 / randomness (Re: audio support for application interface with nanoBTS) In-Reply-To: References: Message-ID: <20091004115129.GB3628@prithivi.gnumonks.org> one further note on the missing md5 file: As it seems it is only used to generate a pseudo-random 32bit value for use in the SSRC: I'd rather not introduce a copy of MD5 for that. There are two options to take: 1) simply use the same [not very random] method as we use for the TMSI 2) introduce a dependency to openssl and use that. Given that nanoBTS also support OML/RSL over SSL/TLS, I think sooner or later we will have to add that dependency anyway. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Sun Oct 4 13:15:26 2009 From: zecke at selfish.org (Holger Freyther) Date: Sun, 4 Oct 2009 15:15:26 +0200 Subject: md5 / randomness (Re: audio support for application interface with nanoBTS) In-Reply-To: <20091004115129.GB3628@prithivi.gnumonks.org> References: <20091004115129.GB3628@prithivi.gnumonks.org> Message-ID: <200910041515.26699.zecke@selfish.org> On Sunday 04 October 2009 13:51:29 Harald Welte wrote: > one further note on the missing md5 file: > > As it seems it is only used to generate a pseudo-random 32bit value > for use in the SSRC: I'd rather not introduce a copy of MD5 for that. > > There are two options to take: > > 1) simply use the same [not very random] method as we use for the TMSI > > 2) introduce a dependency to openssl and use that. Given that nanoBTS > also support OML/RSL over SSL/TLS, I think sooner or later we will > have to add that dependency anyway. Are you sure you want to introduce code that is using SSL? This would mean we have to check if someone from the US sends us a SSL patch and reject it based on the region. The other issue with OpenSSL is that the license is considered to not be GPL compatible and that the GNUtls replacement is not there yet.... z. From laforge at gnumonks.org Sun Oct 4 21:18:50 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 4 Oct 2009 23:18:50 +0200 Subject: md5 / randomness (Re: audio support for application interface with nanoBTS) In-Reply-To: <200910041515.26699.zecke@selfish.org> References: <20091004115129.GB3628@prithivi.gnumonks.org> <200910041515.26699.zecke@selfish.org> Message-ID: <20091004211850.GB3798@prithivi.gnumonks.org> On Sun, Oct 04, 2009 at 03:15:26PM +0200, Holger Freyther wrote: > On Sunday 04 October 2009 13:51:29 Harald Welte wrote: > > one further note on the missing md5 file: > > > > As it seems it is only used to generate a pseudo-random 32bit value > > for use in the SSRC: I'd rather not introduce a copy of MD5 for that. > > > > There are two options to take: > > > > 1) simply use the same [not very random] method as we use for the TMSI > > > > 2) introduce a dependency to openssl and use that. Given that nanoBTS > > also support OML/RSL over SSL/TLS, I think sooner or later we will > > have to add that dependency anyway. > > Are you sure you want to introduce code that is using SSL? sure, SSL is a pretty standard thing. > This would mean we have to check if someone from the US sends us a SSL patch > and reject it based on the region. I think you're living in the past if you think that US crypto export regualtions are still in place... or am I missing something? > The other issue with OpenSSL is that the license is considered > to not be GPL compatible and that the GNUtls replacement is not there yet.... gnutls is not there in what sense? Sure, it tends to behave different than one expected and it appearst to have interesting bugs here and there, but when it comes to the core/key functionality of simply handling a single TLS/SSL stream, I don't think there will be much of a problem with it. Debian is using + shipping it as the standard library for SSL/TLS for quite some time now, and I'm using it heavily on many systems... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Sun Oct 4 09:35:10 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 4 Oct 2009 11:35:10 +0200 Subject: No subject Message-ID: hi there, i found the problem with the delayed audio between application and the nanoBTS. the reason was the timestamp. a delay in openbsc causes packets to be delayed 1/2 seconds, so many packet of 1/2 seconds arrived at nanoBTS after the delay at once, nanoBTS buffers them. the reason for the delay was the "usleep(100000)" hack inside input/ipaccess.c. the patch will use the tx_timer instead, so openbsc and application will not stall. this timer was already used with BS11 messages. (there it uses 50 miliseconds instead of 100 miliseconds.) sending 10 messages to nanoBTS will take almost one second. can we decrease the tx_timer value for nanoBTS? how many packets can handle nanoBTS per second? also i fixed some bugs in the rtp patch. use rtp_2.patch for commission/discussion instead. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: txdelay.patch Type: application/octet-stream Size: 1863 bytes Desc: txdelay.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtp_2.patch Type: application/octet-stream Size: 21867 bytes Desc: rtp_2.patch URL: From laforge at gnumonks.org Fri Oct 30 11:29:14 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 30 Oct 2009 12:29:14 +0100 Subject: OpenBSC RTP / MNCC integration In-Reply-To: References: Message-ID: <20091030112914.GJ1685@prithivi.gnumonks.org> Hi Andreas, sorry for not getting back earlier. I honestly did not realize that there was a second attachment to your mail. We typically use inline patches, and one patch per mail on this list. Once again, sorry for the delay. I'm now looking at the code in detail, I shall be getting back to you at some point during the next days. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: rtp_2.patch Type: application/octet-stream Size: 21867 bytes Desc: rtp_2.patch URL: From Andreas.Eversberg at versatel.de Fri Oct 30 12:29:36 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Fri, 30 Oct 2009 13:29:36 +0100 Subject: AW: OpenBSC RTP / MNCC integration Message-ID: hi harald, > sorry for not getting back earlier. I honestly did not realize that there > was a second attachment to your mail. We typically use inline patches, and one > patch per mail on this list. Once again, sorry for the delay. next time i will send the patches inline... > I'm now looking at the code in detail, I shall be getting back to you at some > point during the next days. in order to remove md5 code, you can use a simple XOR to mix the input data. i think it is good enough to not select the same random number as the base station. regards, andreas From laforge at gnumonks.org Sat Oct 31 09:31:23 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 31 Oct 2009 10:31:23 +0100 Subject: OpenBSC RTP / MNCC integration In-Reply-To: References: Message-ID: <20091031093123.GR1685@prithivi.gnumonks.org> Hi Andreas, On Fri, Oct 30, 2009 at 01:29:36PM +0100, Andreas.Eversberg wrote: > in order to remove md5 code, you can use a simple XOR to mix the input > data. i think it is good enough to not select the same random number as the > base station. I think we could use the random() / srandom() functions, which are standard POSIX API. We could seed it with something like the time it takes us to receive the first location update request after boot, or something unpredictable like that. In the end, we have at least three parts in our system that need a 32bit random value: The TMSI, P-TMSI and the RTP source ID Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Sun Oct 4 18:42:37 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 4 Oct 2009 20:42:37 +0200 Subject: AW: md5 / randomness (Re: audio support for application interfacewith nanoBTS) Message-ID: On Sunday 04 October 2009 13:51:29 Harald Welte wrote: > one further note on the missing md5 file: > > As it seems it is only used to generate a pseudo-random 32bit value > for use in the SSRC: I'd rather not introduce a copy of MD5 for that. > > There are two options to take: > > 1) simply use the same [not very random] method as we use for the TMSI > > 2) introduce a dependency to openssl and use that. Given that nanoBTS > also support OML/RSL over SSL/TLS, I think sooner or later we will > have to add that dependency anyway. hi, i think that very good random is not required. in our case we don't have large scale RTP conferences with thousands of sources. we have to choose a random number that just differs from the one selected by nanoBTS. (the RTP session will fail afer some seconds when using same SSRC.) andreas From philipp at hug.cx Mon Oct 5 09:38:31 2009 From: philipp at hug.cx (Philipp Hug) Date: Mon, 5 Oct 2009 11:38:31 +0200 Subject: nanoBTS 140 is working now Message-ID: <200910051138.31640.philipp@hug.cx> Hi everyone, Thanks to some hints from Sylvain my nanoBTS 140 is working now. We found the following problems: * Software Activation request is not complete ( it needs to contain tag + FILE_ID and FILE_VERSION). See patch sent by Sylvain. * It's relevant which Software is activated, but our logic to always use the first SW Description record works most of the time because the nanoBTS will move the software that was activated the last time to the first position. So maybe we need hard-code which software to prefer for activation or we put some warnings in the wiki. What's left is that after some time the BTRS reports an error and goes to Disabled state, but I have to investigate that more. Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Oct 5 20:09:58 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 5 Oct 2009 22:09:58 +0200 Subject: nanoBTS 140 is working now[ In-Reply-To: <200910051138.31640.philipp@hug.cx> References: <200910051138.31640.philipp@hug.cx> Message-ID: <20091005200958.GD3635@prithivi.gnumonks.org> Hi Philipp, thanks for your feedback. On Mon, Oct 05, 2009 at 11:38:31AM +0200, Philipp Hug wrote: > Thanks to some hints from Sylvain my nanoBTS 140 is working now. > We found the following problems: > * Software Activation request is not complete ( it needs to contain tag + > FILE_ID and FILE_VERSION). See patch sent by Sylvain. Ok, I will look into this patch as soon as I have some time. > * It's relevant which Software is activated, but our logic to always use the > first SW Description record works most of the time because the nanoBTS will > move the software that was activated the last time to the first position. > > So maybe we need hard-code which software to prefer for activation or we put > some warnings in the wiki. why? If you say we are activating the most recently activated software, why is there a need for a warning of any sort? Or why would we need to hardcode? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From philipp at hug.cx Tue Oct 6 11:08:47 2009 From: philipp at hug.cx (Philipp Hug) Date: Tue, 6 Oct 2009 13:08:47 +0200 Subject: nanoBTS 140 is working now In-Reply-To: <20091005200958.GD3635@prithivi.gnumonks.org> References: <200910051138.31640.philipp@hug.cx> <20091005200958.GD3635@prithivi.gnumonks.org> Message-ID: <200910061308.48140.philipp@hug.cx> > > So maybe we need hard-code which software to prefer for activation or we > > put some warnings in the wiki. > > why? If you say we are activating the most recently activated software, > why is there a need for a warning of any sort? Or why would we need to > hardcode? the problem is, that at least on my nanoBTS, the most recently activated software was not the correct one and I had to manually activate the correct one. philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Oct 6 12:02:17 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Oct 2009 14:02:17 +0200 Subject: nanoBTS 140 is working now In-Reply-To: <200910061308.48140.philipp@hug.cx> References: <200910051138.31640.philipp@hug.cx> <20091005200958.GD3635@prithivi.gnumonks.org> <200910061308.48140.philipp@hug.cx> Message-ID: <20091006120217.GF17195@prithivi.gnumonks.org> On Tue, Oct 06, 2009 at 01:08:47PM +0200, Philipp Hug wrote: > > > So maybe we need hard-code which software to prefer for activation or we > > > put some warnings in the wiki. > > > > why? If you say we are activating the most recently activated software, > > why is there a need for a warning of any sort? Or why would we need to > > hardcode? > > the problem is, that at least on my nanoBTS, the most recently activated > software was not the correct one and I had to manually activate the correct > one. the question is: which is the 'correct' one? this is a choice only the administrator can take, based on his information of which versions are installed in the BTS, and his information on what differentiates those software versions. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Oct 7 06:26:13 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 08:26:13 +0200 Subject: nanoBTS 140 is working now In-Reply-To: <20091006120217.GF17195@prithivi.gnumonks.org> References: <200910051138.31640.philipp@hug.cx> <20091005200958.GD3635@prithivi.gnumonks.org> <200910061308.48140.philipp@hug.cx> <20091006120217.GF17195@prithivi.gnumonks.org> Message-ID: <20091007062613.GE25086@prithivi.gnumonks.org> On Tue, Oct 06, 2009 at 02:02:17PM +0200, Harald Welte wrote: > On Tue, Oct 06, 2009 at 01:08:47PM +0200, Philipp Hug wrote: > > > > So maybe we need hard-code which software to prefer for activation or we > > > > put some warnings in the wiki. > > > > > > why? If you say we are activating the most recently activated software, > > > why is there a need for a warning of any sort? Or why would we need to > > > hardcode? > > > > the problem is, that at least on my nanoBTS, the most recently activated > > software was not the correct one and I had to manually activate the correct > > one. > > the question is: which is the 'correct' one? this is a choice only the > administrator can take, based on his information of which versions are > installed in the BTS, and his information on what differentiates those software > versions. To summarize: I think it is good if we simply document the fact that we will activate the default software, and that it is the users responsibility to ensure the default software will work. What we should do, though, is to create a list of known-working ip.access firmware versions on the wiki. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From philipp at hug.cx Wed Oct 7 08:43:34 2009 From: philipp at hug.cx (Philipp Hug) Date: Wed, 7 Oct 2009 10:43:34 +0200 Subject: nanoBTS 140 is working now In-Reply-To: <20091007062613.GE25086@prithivi.gnumonks.org> References: <200910051138.31640.philipp@hug.cx> <20091006120217.GF17195@prithivi.gnumonks.org> <20091007062613.GE25086@prithivi.gnumonks.org> Message-ID: <200910071043.35021.philipp@hug.cx> > To summarize: I think it is good if we simply document the fact that we > will activate the default software, and that it is the users responsibility > to ensure the default software will work. > > What we should do, though, is to create a list of known-working ip.access > firmware versions on the wiki. I agree, and it would be nice if we could add an option to ipaccess-config to switch the active firmware. Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at ibp.de Wed Oct 7 10:04:19 2009 From: lars at ibp.de (Lars Immisch) Date: Wed, 07 Oct 2009 12:04:19 +0200 Subject: Ticket spam In-Reply-To: <200910071043.35021.philipp@hug.cx> References: <200910051138.31640.philipp@hug.cx> <20091006120217.GF17195@prithivi.gnumonks.org> <20091007062613.GE25086@prithivi.gnumonks.org> <200910071043.35021.philipp@hug.cx> Message-ID: <4ACC67A3.5000905@ibp.de> Hi, I'm noticing ticket spam on the Trac instance, for example http://bs11-abis.gnumonks.org/trac/ticket/31 Since I see the spam on me News reader, I wouldn't mind purging it as it see it coming in, but trac doesn't allow to delete tickets natively. There are plugins, however: http://trac-hacks.org/svn/ticketdeleteplugin/0.10/ticketdelete/ I'd suggest to install this or a similar plugin. In the meantime, should I mark them as fixed/invalid? Andreas, is there anything I can help you with for your work with 26c3? - Lars From laforge at gnumonks.org Wed Oct 7 14:59:00 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 16:59:00 +0200 Subject: Ticket spam In-Reply-To: <4ACC67A3.5000905@ibp.de> References: <200910051138.31640.philipp@hug.cx> <20091006120217.GF17195@prithivi.gnumonks.org> <20091007062613.GE25086@prithivi.gnumonks.org> <200910071043.35021.philipp@hug.cx> <4ACC67A3.5000905@ibp.de> Message-ID: <20091007145900.GP25086@prithivi.gnumonks.org> Hi Lars, On Wed, Oct 07, 2009 at 12:04:19PM +0200, Lars Immisch wrote: > I'm noticing ticket spam on the Trac instance, for example > http://bs11-abis.gnumonks.org/trac/ticket/31 > > Since I see the spam on me News reader, I wouldn't mind purging it as it > see it coming in, but trac doesn't allow to delete tickets natively. thanks. > There are plugins, however: > > http://trac-hacks.org/svn/ticketdeleteplugin/0.10/ticketdelete/ > > I'd suggest to install this or a similar plugin. thanks, I will do that and see that you get the apropriate permissions. > In the meantime, should I mark them as fixed/invalid? just wait, i'll try to do it within the hour. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Oct 7 13:14:56 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 15:14:56 +0200 Subject: nanoBTS 140 is working now In-Reply-To: <200910071043.35021.philipp@hug.cx> References: <200910051138.31640.philipp@hug.cx> <20091006120217.GF17195@prithivi.gnumonks.org> <20091007062613.GE25086@prithivi.gnumonks.org> <200910071043.35021.philipp@hug.cx> Message-ID: <20091007131456.GI25086@prithivi.gnumonks.org> On Wed, Oct 07, 2009 at 10:43:34AM +0200, Philipp Hug wrote: > > To summarize: I think it is good if we simply document the fact that we > > will activate the default software, and that it is the users responsibility > > to ensure the default software will work. > > > > What we should do, though, is to create a list of known-working ip.access > > firmware versions on the wiki. > > I agree, and it would be nice if we could add an option to ipaccess-config to > switch the active firmware. All my nanoBTS only have one firmware, so I have no idea how to switch (and how to reproduce/test this). If somebody writes a reasonably good patch for adding this support, I'm willing to merge it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mailinglists at hellercom.de Tue Oct 6 07:29:45 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Tue, 6 Oct 2009 09:29:45 +0200 Subject: Running an licensed experimental GSM network at 26c3 Message-ID: Hello everyone, I just want to ask, if there is a general interest in operating a licensed GSM-Network at the chaos congress. Is there anything planned for 26c3 (openBSC desk etc.)? Maybe there is a good chance to get a temp. license for the 900 GSM band from BNetzA. I had little time in the past year to work on openBSC, but in the coming months there will be more time for fun ;) Best regards Bjoern - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Oct 6 10:19:26 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Oct 2009 12:19:26 +0200 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: References: Message-ID: <20091006101926.GA17195@prithivi.gnumonks.org> On Tue, Oct 06, 2009 at 09:29:45AM +0200, Bjoern Heller wrote: > I just want to ask, if there is a general interest in operating a > licensed GSM-Network at the chaos congress. Is there anything planned for > 26c3 (openBSC desk etc.)? yes, we're planning to operate something like 3 bts with a total of 5 trx in GSM 1800 and connection to the DECT phone network of eventphone. This is why Andreas Eversberg is currently workin on the nanoBTS / RTP integration with lcr. > Maybe there is a good chance to get a temp. license for the 900 GSM > band from BNetzA. impossible for 900MHz. All frequencies are commercially licensed to the GSM operators. I've finally prepared the license application yesterday and will send it off later today. The CCC will be the applicant of that license. Regards. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Tue Oct 6 16:36:04 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 6 Oct 2009 20:36:04 +0400 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <20091006101926.GA17195@prithivi.gnumonks.org> References: <20091006101926.GA17195@prithivi.gnumonks.org> Message-ID: <3d032e5d0910060936t2994e503n4c23605429ded9c3@mail.gmail.com> Hi Harald, We're thinking about bringing one or two USRPs configured to run OpenBTS. We'll be interested in testing the setup in real life and interconnecting them with your OpenBSC setup - I think it should be possible with Asterisk. On Tue, Oct 6, 2009 at 14:19, Harald Welte wrote: > On Tue, Oct 06, 2009 at 09:29:45AM +0200, Bjoern Heller wrote: > >> I just want to ask, if there is a general interest in operating a >> licensed GSM-Network at the chaos congress. Is there anything planned for >> 26c3 (openBSC desk etc.)? > > yes, we're planning to operate something like 3 bts with a total of 5 trx > in GSM 1800 and connection to the DECT phone network of eventphone. > > This is why Andreas Eversberg is currently workin on the nanoBTS / RTP > integration with lcr. > >> Maybe there is a good chance to get a temp. license for the 900 GSM >> band from BNetzA. > > impossible for 900MHz. All frequencies are commercially licensed to > the GSM operators. > > I've finally prepared the license application yesterday and will send it off > later today. ?The CCC will be the applicant of that license. > > Regards. > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) > > -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From laforge at gnumonks.org Wed Oct 7 06:19:49 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 08:19:49 +0200 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <3d032e5d0910060936t2994e503n4c23605429ded9c3@mail.gmail.com> References: <20091006101926.GA17195@prithivi.gnumonks.org> <3d032e5d0910060936t2994e503n4c23605429ded9c3@mail.gmail.com> Message-ID: <20091007061949.GC25086@prithivi.gnumonks.org> Hi Alexander, On Tue, Oct 06, 2009 at 08:36:04PM +0400, Alexander Chemeris wrote: > We're thinking about bringing one or two USRPs configured to run > OpenBTS. We'll be interested in testing the setup in real life and > interconnecting them with your OpenBSC setup - I think it should > be possible with Asterisk. I don't think we have a particular interest in interconnecting those two, as our resources are typically _extremely_ stressed, and we would rather not reconfigure the installation while it is running. It will already be very hard to do what we currently have on the agenda. I don't really see what would be gained from routing voice data over voip between OpenBTS and OpenBSC. What would be an interesting project is to reuse the OpenBTS transceiver code (but not the layer3 protocol stack + sip gateway) and add a BTS-side A-bis implementation, turning OpenBTS into a real BTS that can connect to OpenBSC through A-bis. If there's anyone volunteering to get that work started, I'd be willing to experiment with it at 26C3. But that also not on the actual production/live setup, but on a second OpenBSC instance. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Wed Oct 7 12:21:38 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 7 Oct 2009 16:21:38 +0400 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <20091007061949.GC25086@prithivi.gnumonks.org> References: <20091006101926.GA17195@prithivi.gnumonks.org> <3d032e5d0910060936t2994e503n4c23605429ded9c3@mail.gmail.com> <20091007061949.GC25086@prithivi.gnumonks.org> Message-ID: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> Hi Harald, On Wed, Oct 7, 2009 at 10:19, Harald Welte wrote: > On Tue, Oct 06, 2009 at 08:36:04PM +0400, Alexander Chemeris wrote: >> We're thinking about bringing one or two USRPs configured to run >> OpenBTS. We'll be interested in testing the setup in real life and >> interconnecting them with your OpenBSC setup - I think it should >> be possible with Asterisk. > > I don't think we have a particular interest in interconnecting those two, > as our resources are typically _extremely_ stressed, and we would rather not > reconfigure the installation while it is running. ?It will already be very hard > to do what we currently have on the agenda. ?I don't really see what would be > gained from routing voice data over voip between OpenBTS and OpenBSC. > > What would be an interesting project is to reuse the OpenBTS transceiver code > (but not the layer3 protocol stack + sip gateway) and add a BTS-side A-bis > implementation, turning OpenBTS into a real BTS that can connect to OpenBSC > through A-bis. ?If there's anyone volunteering to get that work started, I'd be > willing to experiment with it at 26C3. ?But that also not on the actual > production/live setup, but on a second OpenBSC instance. We see this from different points of view. :) We're interested to show possible ways of OpenBTS interoperability with more conventional BTSes like ones OpenBSC use and evaluate problems which will arise there. But we want to show this with "flat IP" network instead of burdening OpenBTS with A-bis interface. I believe in the positive impact of OpenBTS and OpenBSC interoperability for the both communities and as encouraging factor for possible future OpenBTS test sites. We're ready to work with you beforehand to minimize on-site efforts. PS Where can we find agenda? Official 26C3 site is nearly empty. -- Regards, Alexander Chemeris. From 246tnt at gmail.com Wed Oct 7 14:09:14 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Wed, 07 Oct 2009 14:09:14 +0000 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> Message-ID: <000e0cdff6f64fd056047558e49a@google.com> > We see this from different points of view. :) We're interested to show > possible > ways of OpenBTS interoperability with more conventional BTSes like ones > OpenBSC use and evaluate problems which will arise there. But we want to > show this with "flat IP" network instead of burdening OpenBTS with > A-bis interface. There is A-bis over IP of course :) Because just connecting them with asterisk just proves asterisk works, you still have two independent GSM network. A better integration would allow roaming between an openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool. Now that can be done either by OpenBTS having a Abis-over-IP IF (much like the nanoBTS), or by implementing inter-msc roaming in both (I think, didn't check deeper). I must admit I don't personally think it's ideal to have the BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's pretty common in opensource to have several project 'doing the same thing' and it usually helps innovation and such but in this case there aren't thousands of developers with good GSM knowledge ... OTOH, OpenBTS and OpenBSC have made some choice that don't make a seamless reuse of code trivial (C vs C++, single vs multi thread). The licenses are compatible that's a start :) (v2 or later vs v3) Anyway, just my 2cents. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Oct 7 15:35:17 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 17:35:17 +0200 Subject: OpenBTS / OpenBSC interaction In-Reply-To: <000e0cdff6f64fd056047558e49a@google.com> References: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> <000e0cdff6f64fd056047558e49a@google.com> Message-ID: <20091007153517.GQ25086@prithivi.gnumonks.org> Hi Sylvain and others, On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt at gmail.com wrote: > >We see this from different points of view. :) We're interested to > >show possible > >ways of OpenBTS interoperability with more conventional BTSes like ones > >OpenBSC use and evaluate problems which will arise there. But we want to > >show this with "flat IP" network instead of burdening OpenBTS with > >A-bis interface. > > There is A-bis over IP of course :) > > Because just connecting them with asterisk just proves asterisk > works, you still have two independent GSM network. I agree. Showing that you can make a call from OpenBTS through asterisk through asterisk (through lcr) through openbsc to a nanobts doesn't really say anything about a GSM level of interaction. you're simply testing whether one asterisk can talk voip to the other asterisk. There is no GSM protocol level interaction between those two networks, so you would have no way for handover, or things like sending sms from one network to the other. > A better integration would allow roaming between an > openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool. Indeed! > Now that can be done either by OpenBTS having a Abis-over-IP IF > (much like the nanoBTS), or by implementing inter-msc roaming in > both (I think, didn't check deeper). yes, both ways should work. To me, Abis-over-IP would make a lot of sense. Why not reuse the existing transceiver code and the code that we already have for the BSC side of A-bis (like TLV parser, lots of utility functions, etc.) to turn the USRP into a true BTS. Having a BTS side A-bis implementation would also help us with my other dream: A virtual/simulated BTS. This BTS would not talk to an actual RF layer, but it would simply use something like mac-blocks or gsm bursts with GSMTAP header over multicase UDP/IP. It would allow us to further work on a MS side layer 2+3 stack, without even having to touch the actual radio interface. That, in turn, would allow us to do 90% of a GSM phone without having a full RF / layer 1 implementation. Also, it would allow us to do regression and load testing of OpenBSC without any real phone or even real BTS. So far my "if I only had the time" plan. > I must admit I don't personally think it's ideal to have the > BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's > pretty common in opensource to have several project 'doing the same > thing' and it usually helps innovation and such but in this case > there aren't thousands of developers with good GSM knowledge ... yes, but I would never have the knowledge (and neither would e.g. Holger have his), if we didn't actually do the implementation. > OTOH, OpenBTS and OpenBSC have made some choice that don't make a > seamless reuse of code trivial (C vs C++, single vs multi thread). Also, the intended purpose is quite different. OpenBSC is about playing with higher level GSM protocols, research and analysis. To some people it also serves as a cheap minimal BSC to work with proprietary BTS, which is fine. OpenBTS is about creating an as thin as possible gateway between the Um interface and SIP. They don't want to run a BTS program, a BSC program, a MSC program, a SIP proxy program, a SMSC program and then configure each of those programs individually. Which is why I think a modular approach makes sense. We're already splitting BSC and MSC functionality inside the OpenBSC project. If somebody finds the time to introduce some kind of API between layer 2 and layer 3 of OpenBTS, then that would be the ideal case. People who want to use OpenBTS standalone can continue to do so, while people who want to put a BTS-Side A-bis on top (and use with proprietary BSC or OpenBSC) can also do that. I haven't spoken about this with David so far, since I didn't have the time to actually do the implementation. But I believe as long as the changes are not intrusive and OpenBTS doesn't loose features / stability or performance, I wouldn't expect much objection to it. > The licenses are compatible that's a start :) (v2 or later vs v3) You may be missing the fact that (I believe) Kestrel might be interested in doing dual licensing on OpenBTS. However, thinking more about this, it seems unlikely since the copyright is now with the FSF. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at kestrelsp.com Wed Oct 7 16:54:53 2009 From: dburgess at kestrelsp.com (David Burgess) Date: Wed, 7 Oct 2009 09:54:53 -0700 Subject: OpenBTS / OpenBSC interaction In-Reply-To: <20091007153517.GQ25086@prithivi.gnumonks.org> References: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> <000e0cdff6f64fd056047558e49a@google.com> <20091007153517.GQ25086@prithivi.gnumonks.org> Message-ID: Harald, Alexander, Sylvain, others - I should probably speak up here at some point. On Oct 7, 2009, at 8:35 AM, Harald Welte wrote: > Hi Sylvain and others, > > On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt at gmail.com wrote: >>> We see this from different points of view. :) We're interested to >>> show possible >>> ways of OpenBTS interoperability with more conventional BTSes >>> like ones >>> OpenBSC use and evaluate problems which will arise there. But we >>> want to >>> show this with "flat IP" network instead of burdening OpenBTS with >>> A-bis interface. >> >> There is A-bis over IP of course :) That doesn't count. >> >> Because just connecting them with asterisk just proves asterisk >> works, you still have two independent GSM network. > > I agree. Showing that you can make a call from OpenBTS through > asterisk > through asterisk (through lcr) through openbsc to a nanobts doesn't > really say > anything about a GSM level of interaction. you're simply testing > whether one > asterisk can talk voip to the other asterisk. > > There is no GSM protocol level interaction between those two > networks, so you > would have no way for handover, or things like sending sms from one > network to > the other. True. If you could just share registration information, you could have mobility among the cells, but OpenBTS does not yet support handovers of active calls. We can send SMS, though, if you support RFC-3428. (We even tested that interface with Voxbone's messaging gateway.) > >> A better integration would allow roaming between an >> openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool. > > Indeed! Yes, and that would not be too hard if we could share an HLR function. > >> Now that can be done either by OpenBTS having a Abis-over-IP IF >> (much like the nanoBTS), or by implementing inter-msc roaming in >> both (I think, didn't check deeper). > > yes, both ways should work. To me, Abis-over-IP would make a lot > of sense. Why > not reuse the existing transceiver code and the code that we > already have for > the BSC side of A-bis (like TLV parser, lots of utility functions, > etc.) to > turn the USRP into a true BTS. > > Having a BTS side A-bis implementation would also help us with my > other dream: > A virtual/simulated BTS. This BTS would not talk to an actual RF > layer, but > it would simply use something like mac-blocks or gsm bursts with > GSMTAP header > over multicase UDP/IP. It would allow us to further work on a MS > side layer 2+3 > stack, without even having to touch the actual radio interface. > > That, in turn, would allow us to do 90% of a GSM phone without > having a full > RF / layer 1 implementation. Also, it would allow us to do > regression and load > testing of OpenBSC without any real phone or even real BTS. > > So far my "if I only had the time" plan. From a testing standpoint, I can see value in putting an Abis interface on OpenBTS, but it's not a high priority for us, either. > >> I must admit I don't personally think it's ideal to have the >> BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's >> pretty common in opensource to have several project 'doing the same >> thing' and it usually helps innovation and such but in this case >> there aren't thousands of developers with good GSM knowledge ... > > yes, but I would never have the knowledge (and neither would e.g. > Holger have > his), if we didn't actually do the implementation. Same here. You don't really understand it until you actually do it. > >> OTOH, OpenBTS and OpenBSC have made some choice that don't make a >> seamless reuse of code trivial (C vs C++, single vs multi thread). > > Also, the intended purpose is quite different. OpenBSC is about > playing with > higher level GSM protocols, research and analysis. To some people > it also > serves as a cheap minimal BSC to work with proprietary BTS, which > is fine. > > OpenBTS is about creating an as thin as possible gateway between > the Um > interface and SIP. They don't want to run a BTS program, a BSC > program, a MSC > program, a SIP proxy program, a SMSC program and then configure > each of those > programs individually. Yes. We can learn a lot from each other and face a lot of similar technical problems, but our goals and implementation styles are very different. However, our design approach *is* to keep everything above L3 in outside applications. Our L3 is just a collection of gateway functions between the ISDN world and the IETF world. Everything else is done with outside applications over IP interfaces. Our SIP-based SMSC replacement is a separate application. Our SIP-based PBX is a separate application. Our HLR replacement is also an outside application, although for now it is just Asterisk's SIP registry. Something I think could be useful, and would allow a lot of interoperability, would be to have a common HLR/VLR replacement. The Asterisk SIP registry doesn't meet our long-term requirements and so we need to develop one anyway. If we can agree on an interface and an implementation, we could do something here. > > Which is why I think a modular approach makes sense. We're already > splitting > BSC and MSC functionality inside the OpenBSC project. If somebody > finds the > time to introduce some kind of API between layer 2 and layer 3 of > OpenBTS, > then that would be the ideal case. People who want to use OpenBTS > standalone > can continue to do so, while people who want to put a BTS-Side A- > bis on top > (and use with proprietary BSC or OpenBSC) can also do that. That kind of API should be easy. OpenBTS follows a data-flow design. At the top of L2, every channel is just a pair of FIFOs (up/ down) of L3 message objects. It should be easy to funnel all of that through some kind of Abis adapter. > > I haven't spoken about this with David so far, since I didn't have > the time to > actually do the implementation. But I believe as long as the > changes are not > intrusive and OpenBTS doesn't loose features / stability or > performance, I > wouldn't expect much objection to it. No objection, but there will be questions about licensing. To date, there are very few outside contributions in the OpenBTS distribution, maybe a few dozen lines out of ~12k. The FSF copyright assignment gives us the flexibility to distribute a non-GPL release if we want. Given GPLv3's treatment of patent licenses, that will be very desirable for some users, even if the actual code is identical to what we release under GPL. It also give us the opportunity to charge licensing fees and royalties for use of OpenBTS in commercial products, a plan for which we make no apology. ("Free as in freedom, not free beer.") We have no problem with sharing royalties with contributors, but our business plan requires that we preserve licensing flexibility, and so we would need to have formal agreements with any significant contributors if we were to actually use their contributions. Admittedly, this creates a tension in the open source project, a tension that we are still learning to manage, especially since the lifting of the injunction has removed the biggest barrier to participation. I would very much look forward to discussing this face to face. Maybe we'll get a chance next month. > >> The licenses are compatible that's a start :) (v2 or later vs v3) > > You may be missing the fact that (I believe) Kestrel might be > interested in > doing dual licensing on OpenBTS. However, thinking more about > this, it seems > unlikely since the copyright is now with the FSF. See above. The FSF granted us back a blanket license. We can do anything we want *except* stop the FSF from distributing it under GPL. The text of the agreement says we can use the code "in any why [we] see fit". Period. Also, since OpenBTS puts different functions in different applications, we can license those components differently, so the final application suite may be used commercially under a mix of GPL and non-GPL licenses. > > -- > - Harald Welte http:// > laforge.gnumonks.org/ > ====================================================================== > ====== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 > 175-7 Ch. A6) David A. Burgess Kestrel Signal Processing, Inc. From alexander.chemeris at gmail.com Wed Oct 7 18:29:15 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 7 Oct 2009 22:29:15 +0400 Subject: OpenBTS / OpenBSC interaction In-Reply-To: References: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> <000e0cdff6f64fd056047558e49a@google.com> <20091007153517.GQ25086@prithivi.gnumonks.org> Message-ID: <3d032e5d0910071129hba87a65v83db3012fd9ee0ed@mail.gmail.com> Hi all, I will answer to David's e-mail, because I'm mostly agree with him on tech questions. On Wed, Oct 7, 2009 at 20:54, David Burgess wrote: > Harald, Alexander, Sylvain, others - > > I should probably speak up here at some point. > > On Oct 7, 2009, at 8:35 AM, Harald Welte wrote: > >> Hi Sylvain and others, >> >> On Wed, Oct 07, 2009 at 02:09:14PM +0000, 246tnt at gmail.com wrote: >>>> >>>> We see this from different points of view. :) We're interested to >>>> show possible >>>> ways of OpenBTS interoperability with more conventional BTSes like ones >>>> OpenBSC use and evaluate problems which will arise there. But we want to >>>> show this with "flat IP" network instead of burdening OpenBTS with >>>> A-bis interface. >>> >>> There is A-bis over IP of course :) > > That doesn't count. Right, that's not what I meant by "flat". A-bis over IP is a tunneling rather then real network. >>> Because just connecting them with asterisk just proves asterisk >>> works, you still have two independent GSM network. >> >> I agree. ?Showing that you can make a call from OpenBTS through asterisk >> through asterisk (through lcr) through openbsc to a nanobts doesn't really >> say >> anything about a GSM level of interaction. ?you're simply testing whether >> one >> asterisk can talk voip to the other asterisk. >> >> There is no GSM protocol level interaction between those two networks, so >> you >> would have no way for handover, or things like sending sms from one >> network to >> the other. > > True. ?If you could just share registration information, you could have > mobility among the cells, but OpenBTS does not yet support handovers of > active calls. > > We can send SMS, though, if you support RFC-3428. ?(We even tested that > interface with Voxbone's messaging gateway.) That was what I had in mind too. 1) We should share the same HLR and then it won't be two separate networks with "roaming". And this makes sense, and is the first target to work on. 2) For SMS we can interoperate if we had a gateway between SIP/SIMPLE and OpenBSC's SMSC (not sure what does OpenBSC use for SMSC? Do you plan to support SMPP or such?). That'll be nice, but that's obviously not the top priority. Could we work on HLR interoperability and try to test it at 26C3? >>> A better integration would allow roaming between an >>> openbsc/nanoBTS|BS11 and a OpenBTS. That would be pretty cool. >> >> Indeed! > > Yes, and that would not be too hard if we could share an HLR function. > >> >>> Now that can be done either by OpenBTS having a Abis-over-IP IF >>> (much like the nanoBTS), or by implementing inter-msc roaming in >>> both (I think, didn't check deeper). >> >> yes, both ways should work. ?To me, Abis-over-IP would make a lot of >> sense. Why >> not reuse the existing transceiver code and the code that we already have >> for >> the BSC side of A-bis (like TLV parser, lots of utility functions, etc.) >> to >> turn the USRP into a true BTS. >> >> Having a BTS side A-bis implementation would also help us with my other >> dream: >> A virtual/simulated BTS. ?This BTS would not talk to an actual RF layer, >> but >> it would simply use something like mac-blocks or gsm bursts with GSMTAP >> header >> over multicase UDP/IP. ?It would allow us to further work on a MS side >> layer 2+3 >> stack, without even having to touch the actual radio interface. >> >> That, in turn, would allow us to do 90% of a GSM phone without having a >> full >> RF / layer 1 implementation. ?Also, it would allow us to do regression and >> load >> testing of OpenBSC without any real phone or even real BTS. >> >> So far my "if I only had the time" plan. > > From a testing standpoint, I can see value in putting an Abis interface on > OpenBTS, but it's not a high priority for us, either. > >> >>> I must admit I don't personally think it's ideal to have the >>> BSC/MSC/HLR... layers duplicated in both OpenBTS/OpenBSC. It's >>> pretty common in opensource to have several project 'doing the same >>> thing' and it usually helps innovation and such but in this case >>> there aren't thousands of developers with good GSM knowledge ... >> >> yes, but I would never have the knowledge (and neither would e.g. Holger >> have >> his), if we didn't actually do the implementation. > > Same here. ?You don't really understand it until you actually do it. > >> >>> OTOH, OpenBTS and OpenBSC have made some choice that don't make a >>> seamless reuse of code trivial (C vs C++, single vs multi thread). >> >> Also, the intended purpose is quite different. OpenBSC is about playing >> with >> higher level GSM protocols, research and analysis. ?To some people it also >> serves as a cheap minimal BSC to work with proprietary BTS, which is fine. >> >> OpenBTS is about creating an as thin as possible gateway between the Um >> interface and SIP. ?They don't want to run a BTS program, a BSC program, a >> MSC >> program, a SIP proxy program, a SMSC program and then configure each of >> those >> programs individually. > > Yes. ?We can learn a lot from each other and face a lot of similar technical > problems, but our goals and implementation styles are very different. > > However, our design approach *is* to keep everything above L3 in outside > applications. ?Our L3 is just a collection of gateway functions between the > ISDN world and the IETF world. ?Everything else is done with outside > applications over IP interfaces. ?Our SIP-based SMSC replacement is a > separate application. ?Our SIP-based PBX is a separate application. ?Our HLR > replacement is also an outside application, although for now it is just > Asterisk's SIP registry. > > Something I think could be useful, and would allow a lot of > interoperability, would be to have a common HLR/VLR replacement. ?The > Asterisk SIP registry doesn't meet our long-term requirements and so we need > to develop one anyway. ?If we can agree on an interface and an > implementation, we could do something here. I second this. See above. >> Which is why I think a modular approach makes sense. ?We're already >> splitting >> BSC and MSC functionality inside the OpenBSC project. ?If somebody finds >> the >> time to introduce some kind of API between layer 2 and layer 3 of OpenBTS, >> then that would be the ideal case. ?People who want to use OpenBTS >> standalone >> can continue to do so, while people who want to put a BTS-Side A-bis on >> top >> (and use with proprietary BSC or OpenBSC) can also do that. > > That kind of API should be easy. ?OpenBTS follows a data-flow design. ?At > the top of L2, every channel is just a pair of FIFOs (up/down) of L3 message > objects. ?It should be easy to funnel all of that through some kind of Abis > adapter. > >> >> I haven't spoken about this with David so far, since I didn't have the >> time to >> actually do the implementation. ?But I believe as long as the changes are >> not >> intrusive and OpenBTS doesn't loose features / stability or performance, I >> wouldn't expect much objection to it. > > No objection, but there will be questions about licensing. ?To date, there > are very few outside contributions in the OpenBTS distribution, maybe a few > dozen lines out of ~12k. ?The FSF copyright assignment gives us the > flexibility to distribute a non-GPL release if we want. ?Given GPLv3's > treatment of patent licenses, that will be very desirable for some users, > even if the actual code is identical to what we release under GPL. ?It also > give us the opportunity to charge licensing fees and royalties for use of > OpenBTS in commercial products, a plan for which we make no apology. ?("Free > as in freedom, not free beer.") ?We have no problem with sharing royalties > with contributors, but our business plan requires that we preserve licensing > flexibility, and so we would need to have formal agreements with any > significant contributors if we were to actually use their contributions. > ?Admittedly, this creates a tension in the open source project, a tension > that we are still learning to manage, especially since the lifting of the > injunction has removed the biggest barrier to participation. > > I would very much look forward to discussing this face to face. ?Maybe we'll > get a chance next month. I strongly believe and has spoken several times, that something there must be changed - current situation is simply discouraging both users and potential developers. My points are: 1) Main svn must be open and all non-funded development should be done there, so everyone will be able to get latest bugfixes and not wait months while David and Harvind have no time and desire to publish them. 2) Funded development may go in a private branch (Mercurial or git helps here a lot) and will be published when needed. Having that OpenBTS architecture will be more and more stable as time passes, changed will be pretty non-intrusive. re: sharing royalties with contributors That's great, but how do you plan to measure how much each contributor should gain? Should one, contributed 120 lines receive 120/12K part of royalties? But what if these 12 lines where a critical fix or an important feature? >>> The licenses are compatible that's a start :) (v2 or later vs v3) >> >> You may be missing the fact that (I believe) Kestrel might be interested >> in >> doing dual licensing on OpenBTS. ?However, thinking more about this, it >> seems >> unlikely since the copyright is now with the FSF. > > See above. ?The FSF granted us back a blanket license. ?We can do anything > we want *except* stop the FSF from distributing it under GPL. ?The text of > the agreement says we can use the code "in any why [we] see fit". ?Period. > > Also, since OpenBTS puts different functions in different applications, we > can license those components differently, so the final application suite may > be used commercially under a mix of GPL and non-GPL licenses. That's an interesting way. But won't this GPL parts have the same problems with the patents as main OpenBTS core? -- Regards, Alexander Chemeris. From laforge at gnumonks.org Wed Oct 7 19:53:51 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 21:53:51 +0200 Subject: OpenBTS / OpenBSC interaction In-Reply-To: References: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> <000e0cdff6f64fd056047558e49a@google.com> <20091007153517.GQ25086@prithivi.gnumonks.org> Message-ID: <20091007195351.GV25086@prithivi.gnumonks.org> Hi David, On Wed, Oct 07, 2009 at 09:54:53AM -0700, David Burgess wrote: > >>There is A-bis over IP of course :) > > That doesn't count. well, that would be what I'd implement if I was to write a BTS-side Abis implementation that would like to OpenBTS' transceiver + LAPDm code. > >That, in turn, would allow us to do 90% of a GSM phone without having a full > >RF / layer 1 implementation. Also, it would allow us to do regression and > >load testing of OpenBSC without any real phone or even real BTS. > > > >So far my "if I only had the time" plan. > > From a testing standpoint, I can see value in putting an Abis > interface on OpenBTS, but it's not a high priority for us, either. of course, I never assumed it was any of your priorities at all.. > However, our design approach *is* to keep everything above L3 in > outside applications. Our L3 is just a collection of gateway > functions between the ISDN world and the IETF world. Everything > else is done with outside applications over IP interfaces. Our > SIP-based SMSC replacement is a separate application. Our SIP-based > PBX is a separate application. Our HLR replacement is also an > outside application, although for now it is just Asterisk's SIP > registry. Well, we at OpenBSC are very interested in the actual GSM layer 3 protocols on the various interfaces (Abis, A, B and others). > Something I think could be useful, and would allow a lot of > interoperability, would be to have a common HLR/VLR replacement. > The Asterisk SIP registry doesn't meet our long-term requirements > and so we need to develop one anyway. If we can agree on an > interface and an implementation, we could do something here. I think I would actually want to have a protocol-compatible HLR, i.e. using the standard interfaces that GSM/3GPP use for the HLR - which I doubt is something that you would want to see :) > >Which is why I think a modular approach makes sense. We're already > >splitting BSC and MSC functionality inside the OpenBSC project. If somebody > >finds the time to introduce some kind of API between layer 2 and layer 3 of > >OpenBTS, then that would be the ideal case. People who want to use OpenBTS > >standalone can continue to do so, while people who want to put a BTS-Side A- > >bis on top (and use with proprietary BSC or OpenBSC) can also do that. > > That kind of API should be easy. OpenBTS follows a data-flow > design. At the top of L2, every channel is just a pair of FIFOs > (up/down) of L3 message objects. It should be easy to funnel all of > that through some kind of Abis adapter. Yes, I've looked at the code before and thought it should be relatively easy. I see one other advantage for this: More and more OpenBTS bits that are currently static (like channel configuration or similar) would have to become configurable in order to support GSM 12.21 (A-bis OML). Initially, having all of this static is fine, of course. > >I haven't spoken about this with David so far, since I didn't have the time > >to actually do the implementation. But I believe as long as the changes are > >not intrusive and OpenBTS doesn't loose features / stability or performance, > >I wouldn't expect much objection to it. > > No objection, but there will be questions about licensing. To date, > there are very few outside contributions in the OpenBTS > distribution, maybe a few dozen lines out of ~12k. The FSF > copyright assignment gives us the flexibility to distribute a > non-GPL release if we want. Given GPLv3's treatment of patent > licenses, that will be very desirable for some users, even if the > actual code is identical to what we release under GPL. It also give > us the opportunity to charge licensing fees and royalties for use of > OpenBTS in commercial products, a plan for which we make no apology. sure. That shouldn't be much of a problem either. If we introduce the API that I've proposed above, then the part 'below' the API stays like it is, with copyright assingments to the FSF, etc. However, the BTS side A-bis code on top would be GPL (v2+) licensed and copyright is with whoever does the implementation. That part would not neccesarrily be a part that is required to be part of the OpenBTS standard distribution. If some alternative licensing is required by one of your customers down the road, arrangements would have to be made with the copyright holder of that A-bis BTS part. > ("Free as in freedom, not free beer.") We have no problem with > sharing royalties with contributors, but our business plan requires > that we preserve licensing flexibility, and so we would need to have > formal agreements with any significant contributors if we were to > actually use their contributions. Admittedly, this creates a > tension in the open source project, a tension that we are still > learning to manage, especially since the lifting of the injunction > has removed the biggest barrier to participation. I don't think it will be a big deal, don't worry too much about it :) > See above. The FSF granted us back a blanket license. We can do > anything we want *except* stop the FSF from distributing it under > GPL. The text of the agreement says we can use the code "in any why > [we] see fit". Period. ok, that's interesting and good to know. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at kestrelsp.com Wed Oct 7 20:42:23 2009 From: dburgess at kestrelsp.com (David Burgess) Date: Wed, 7 Oct 2009 13:42:23 -0700 Subject: OpenBTS / OpenBSC interaction In-Reply-To: <20091007195351.GV25086@prithivi.gnumonks.org> References: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> <000e0cdff6f64fd056047558e49a@google.com> <20091007153517.GQ25086@prithivi.gnumonks.org> <20091007195351.GV25086@prithivi.gnumonks.org> Message-ID: <88ED4B90-23B1-4089-ADCD-7D59CD44EC33@kestrelsp.com> Harald - On Oct 7, 2009, at 12:53 PM, Harald Welte wrote: > >> Something I think could be useful, and would allow a lot of >> interoperability, would be to have a common HLR/VLR replacement. >> The Asterisk SIP registry doesn't meet our long-term requirements >> and so we need to develop one anyway. If we can agree on an >> interface and an implementation, we could do something here. > > I think I would actually want to have a protocol-compatible HLR, > i.e. using the > standard interfaces that GSM/3GPP use for the HLR - which I doubt > is something > that you would want to see :) I'm open minded at this point. We eventually have to interface to standard HLRs anyway and I need some project to force me to learn the MAP stuff. It would also be good if the underlying database can be used to generate configurations for FreeSWITCH or Asterisk, but that should not be hard given any SQL-based system. -- David David A. Burgess Kestrel Signal Processing, Inc. From alexander.chemeris at gmail.com Wed Oct 7 20:50:51 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 8 Oct 2009 00:50:51 +0400 Subject: OpenBTS / OpenBSC interaction In-Reply-To: <88ED4B90-23B1-4089-ADCD-7D59CD44EC33@kestrelsp.com> References: <3d032e5d0910070521h7fcb97d4i4239055f6938cb18@mail.gmail.com> <000e0cdff6f64fd056047558e49a@google.com> <20091007153517.GQ25086@prithivi.gnumonks.org> <20091007195351.GV25086@prithivi.gnumonks.org> <88ED4B90-23B1-4089-ADCD-7D59CD44EC33@kestrelsp.com> Message-ID: <3d032e5d0910071350v283e319rbd8de6f5205851f2@mail.gmail.com> Harald, David, On Thu, Oct 8, 2009 at 00:42, David Burgess wrote: > Harald - > > On Oct 7, 2009, at 12:53 PM, Harald Welte wrote: > >> >>> Something I think could be useful, and would allow a lot of >>> interoperability, would be to have a common HLR/VLR replacement. >>> The Asterisk SIP registry doesn't meet our long-term requirements >>> and so we need to develop one anyway. ?If we can agree on an >>> interface and an implementation, we could do something here. >> >> I think I would actually want to have a protocol-compatible HLR, i.e. >> using the >> standard interfaces that GSM/3GPP use for the HLR - which I doubt is >> something >> that you would want to see :) > > I'm open minded at this point. ?We eventually have to interface to standard > HLRs anyway and I need some project to force me to learn the MAP stuff. ?It > would also be good if the underlying database can be used to generate > configurations for FreeSWITCH or Asterisk, but that should not be hard given > any SQL-based system. Right. At some point we'll need to create an adapter for normal HLRs anyway, so the early we start, the further we get. ;) I wonder - is there already any IETF-based protocol for such kind of interaction? Radius? -- Regards, Alexander Chemeris. From 246tnt at gmail.com Wed Oct 7 22:56:59 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Wed, 07 Oct 2009 22:56:59 +0000 Subject: OpenBTS / OpenBSC interaction In-Reply-To: <20091007195351.GV25086@prithivi.gnumonks.org> Message-ID: <0016e6d7f07ea5e760047560432d@google.com> > > Something I think could be useful, and would allow a lot of > > interoperability, would be to have a common HLR/VLR replacement. > > The Asterisk SIP registry doesn't meet our long-term requirements > > and so we need to develop one anyway. If we can agree on an > > interface and an implementation, we could do something here. > I think I would actually want to have a protocol-compatible HLR, ie using > the > standard interfaces that GSM/3GPP use for the HLR - which I doubt is > something > that you would want to see :) After having a quick look at the specs : - The VLR would stay in each OpenBTS/OpenBSC instance (since it's usually attached 1:1 to a MSC) - The common part needed would group HLR/AuC/EIR If you want 'official' interfaces, that means D interface, F interface & G interface to implement. Each run over SCCP and there are standardized ways to transport SCCP over IP. Most of it seems to be in GSM 09.02 (using ASN.1 notation, enjoy ...) AFAICS. The whole VLR & D/F/G MSC side code can obviously be shared by both project and just expose an very simple internal API. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Thu Oct 8 11:56:44 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 8 Oct 2009 13:56:44 +0200 Subject: AW: Running an licensed experimental GSM network at 26c3 Message-ID: >I believe in the positive impact of OpenBTS and OpenBSC interoperability for >the both communities and as encouraging factor for possible future OpenBTS >test sites. > >We're ready to work with you beforehand to minimize on-site efforts. > >PS Where can we find agenda? Official 26C3 site is nearly empty. hi all, on the congress i use linux-call-router to route isdn traffic from versatel to berlin and vice versa for free as part of versatel sponsoring. i would like to join the POC (phone operation center) in the upper hall again this year. there we sit close to the "eventphone" guys, so we can easier communicate and do cabeling of our hardware. it would be nice to have also the openbsc and openbts projects close to us. we could easier interact and build one test networks. since eventphone uses an own linux-call-router hardware, i can use my test machine without disturbing the external isdn connection to versatel. it is equipped with two E1 cards, one for interconnection with eventphone, the second one can be used for BS11. eventphone has a big DECT pbx running and provides mobile access. what do you think? andreas From alexander.chemeris at gmail.com Sat Oct 10 17:33:31 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 10 Oct 2009 21:33:31 +0400 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: References: Message-ID: <3d032e5d0910101033o760a2f8dtf59bd1127d996622@mail.gmail.com> Hi Andreas, On Thu, Oct 8, 2009 at 15:56, Andreas.Eversberg wrote: > on the congress i use linux-call-router to route isdn traffic from > versatel to berlin and vice versa for free as part of versatel > sponsoring. i would like to join the POC (phone operation center) in the > upper hall again this year. there we sit close to the "eventphone" guys, > so we can easier communicate and do cabeling of our hardware. it would > be nice to have also the openbsc and openbts projects close to us. we > could easier interact and build one test networks. since eventphone uses > an own linux-call-router hardware, i can use my test machine without > disturbing the external isdn connection to versatel. it is equipped with > two E1 cards, one for interconnection with eventphone, the second one > can be used for BS11. eventphone has a big DECT pbx running and provides > mobile access. We'll bring one or two our USRPs for OpenBTS testing even if David Burgess won't be able to come, and we would love to be located near OpenBSC guys and you. But that'll be our first time at 26C3 and we're little bit lost - should we send some request to get the space? Do you have an option for VoIP link rather then E1? -- Regards, Alexander Chemeris. From laforge at gnumonks.org Sun Oct 11 09:19:07 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Oct 2009 11:19:07 +0200 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <3d032e5d0910101033o760a2f8dtf59bd1127d996622@mail.gmail.com> References: <3d032e5d0910101033o760a2f8dtf59bd1127d996622@mail.gmail.com> Message-ID: <20091011091907.GD4000@prithivi.gnumonks.org> Hi Alexander, On Sat, Oct 10, 2009 at 09:33:31PM +0400, Alexander Chemeris wrote: > We'll bring one or two our USRPs for OpenBTS testing even if David Burgess > won't be able to come, and we would love to be located near OpenBSC guys > and you. But that'll be our first time at 26C3 and we're little bit > lost - should we send some request to get the space? I think the process for applying for tablespace in the hackcenter has not yet started. Meanwhile I've created a http://events.ccc.de/congress/2009/wiki/index.php/GSM wiki page where we can add stuff to, similar to the 25C3 and HAR2009. > Do you have an option for VoIP link rather then E1? As indicated, I am really not interested in this. My general interest in any actual voice switching is extremely low. I have two objectives with regard to OpenBSC at the 26C3: * operate a functional network that interconnects with the DECT network of the POC (due to popular demand) * do some more experimentation with security related aspects of GSM related signalling I don't really see the point of having any kind of additional interfaces for voice data at the 26C3 installation. I don't see a technical challenge there, I think it only increases the network complexity in case something needs to be debugged. Playing with the asterisk or lcr integration of OpenBSC and hooking it up to some other VoIP-based or -gatewayed system like OpenBTS is something that can be done at any time, at any place, by anyone who is interested in doing that. Please don't misunderstand me. David knows how friendly I am with regard to OpenBTS, and that there is no sense of "competition" or anything like that. I am very interested in technical discussions of GSM signalling, or at interfacing OpenBSC and OpenBTS on a GSM signalling level. But simply passing around transcoded voice samples in a VoIP protocol between two autonomous GSM networks is about the most boring thing I can imagine. VoIP protocols are well understood, there are dozens of open source projecst in that area, each with their own community. I happily let somebody else do that. So if Andreas and you decide you want to hook up OpenBTS and OpenBSC over VoIP, please go ahead and do so. But this is unrelated to the 26C3 GSM network and I expect you will interfere neither with the 26C3 GSM network, nor with the public networks. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at jcis.net Mon Oct 12 01:49:29 2009 From: dburgess at jcis.net (David A. Burgess) Date: Sun, 11 Oct 2009 18:49:29 -0700 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <20091011091907.GD4000@prithivi.gnumonks.org> References: <3d032e5d0910101033o760a2f8dtf59bd1127d996622@mail.gmail.com> <20091011091907.GD4000@prithivi.gnumonks.org> Message-ID: Harald, Alexander - On Oct 11, 2009, at 2:19 AM, Harald Welte wrote: > > So if Andreas and you decide you want to hook up OpenBTS and > OpenBSC over VoIP, > please go ahead and do so. But this is unrelated to the 26C3 GSM > network and I > expect you will interfere neither with the 26C3 GSM network, nor > with the > public networks. > My personal opinion, for whatever it's worth: Based on our experience trying to coexist with Commnet Wireless at Burning Man, I would say that trying to run two experimental networks in the same place without cross-roaming will be confusing for the test users and a big mess for the operators. OpenBSC has their own agenda for the 26c3 test network, a second network would probably interfere with that agenda. I see the Congress as OpenBSC's "home turf", where they get to set the agenda. I'd very much like to cooperate somehow if there's an advantage from doing so, but I don't see 26c3 as the right opportunity. (BTW - I still don't know if I will be attending, but whether or not there's an OpenBTS network running probably doesn't alter that decision. It's great to meet in person and I miss the smell of Club Mate.) -- David David A. Burgess Kestrel Signal Processing, Inc. From laforge at gnumonks.org Mon Oct 12 08:45:28 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Oct 2009 10:45:28 +0200 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: References: <3d032e5d0910101033o760a2f8dtf59bd1127d996622@mail.gmail.com> <20091011091907.GD4000@prithivi.gnumonks.org> Message-ID: <20091012084528.GR21426@prithivi.gnumonks.org> Hi David, On Sun, Oct 11, 2009 at 06:49:29PM -0700, David A. Burgess wrote: > >So if Andreas and you decide you want to hook up OpenBTS and OpenBSC over > >VoIP, please go ahead and do so. But this is unrelated to the 26C3 GSM > >network and I expect you will interfere neither with the 26C3 GSM network, > >nor with the public networks. > > My personal opinion, for whatever it's worth: Based on our > experience trying to coexist with Commnet Wireless at Burning Man, I > would say that trying to run two experimental networks in the same > place without cross-roaming will be confusing for the test users and > a big mess for the operators. I would not worry all that much as long as it is documented in the wiki. Also, the 26C3 GSM network will be again in 'token auth' mode, i.e. nobody can enter unless he has registered on a website before. Anyone else who intends to operate some GSM network on the 26C3 site: I would kindly ask them to stick to a 'strictly closed' policy, i.e. don't allow anyone to complete the location update procedure, unless the IMSI is part of a pre-registered list. > (BTW - I still don't know if I will be attending, but whether or not > there's an OpenBTS network running probably doesn't alter that > decision. I hope you will be able to make it... > It's great to meet in person and I miss the smell of Club Mate. I'll make sure to have sufficient Club Mate supply when you come to Berlin before depesec :) Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From alexander.chemeris at gmail.com Mon Oct 12 20:18:29 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 13 Oct 2009 00:18:29 +0400 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: <20091011091907.GD4000@prithivi.gnumonks.org> References: <3d032e5d0910101033o760a2f8dtf59bd1127d996622@mail.gmail.com> <20091011091907.GD4000@prithivi.gnumonks.org> Message-ID: <3d032e5d0910121318k4d025517w855c5cf4ad9156ec@mail.gmail.com> Hi Harald, David, Andreas, On Sun, Oct 11, 2009 at 13:19, Harald Welte wrote: > On Sat, Oct 10, 2009 at 09:33:31PM +0400, Alexander Chemeris wrote: >> We'll bring one or two our USRPs for OpenBTS testing even if David Burgess >> won't be able to come, and we would love to be located near OpenBSC guys >> and you. But that'll be our first time at 26C3 and we're little bit >> lost - should we send some request to get the space? > > I think the process for applying for tablespace in the hackcenter has not yet > started. > > Meanwhile I've created a http://events.ccc.de/congress/2009/wiki/index.php/GSM > wiki page where we can add stuff to, similar to the 25C3 and HAR2009. Great, thank you. I'll keep my eye on it. >> Do you have an option for VoIP link rather then E1? > > As indicated, I am really not interested in this. ?My general interest in any > actual voice switching is extremely low. ?I have two objectives with regard to > OpenBSC at the 26C3: Well, question was addressed to Andreas, I know that you're not interested ;) > * operate a functional network that interconnects with the DECT network of > ?the POC (due to popular demand) > * do some more experimentation with security related aspects of GSM related > ?signalling > > I don't really see the point of having any kind of additional interfaces for > voice data at the 26C3 installation. ?I don't see a technical challenge there, > I think it only increases the network complexity in case something needs to be > debugged. > > Playing with the asterisk or lcr integration of OpenBSC and hooking it up to > some other VoIP-based or -gatewayed system like OpenBTS is something that can > be done at any time, at any place, by anyone who is interested in doing that. > > Please don't misunderstand me. ?David knows how friendly I am with regard to > OpenBTS, and that there is no sense of "competition" or anything like that. > I am very interested in technical discussions of GSM signalling, or at > interfacing OpenBSC and OpenBTS on a GSM signalling level. > > But simply passing around transcoded voice samples in a VoIP protocol between > two autonomous GSM networks is about the most boring thing I can imagine. ?VoIP > protocols are well understood, there are dozens of open source projecst in that > area, each with their own community. ?I happily let somebody else do that. > > So if Andreas and you decide you want to hook up OpenBTS and OpenBSC over VoIP, > please go ahead and do so. ?But this is unrelated to the 26C3 GSM network and I > expect you will interfere neither with the 26C3 GSM network, nor with the > public networks. I know that you're very much of a friend to OpenBTS rather then a competitor, and if you understood me that way, I ask for excuse. What I'm trying to achieve is to get the most from the event as I can for OpenBTS. As a first time attendee I may not get a lot of things before hand, but I definitely have no intention to break your agenda. I just think that being connected to the DECT network will give us broader testing then being self-encapsulated. And I see the worth of having integrated HLR and operating a single network rather then two separate networks. But if will render impossible, we'll be happy to be a closed unconnected network or VoIP connected one (which is already more fun for testers). PS And yes, we plan for registered-users-only network. -- Regards, Alexander Chemeris. From Andreas.Eversberg at versatel.de Tue Oct 13 11:27:13 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 13 Oct 2009 13:27:13 +0200 Subject: AW: Running an licensed experimental GSM network at 26c3 Message-ID: hi, i also did my part: http://events.ccc.de/congress/2009/wiki/index.php/Linux-Call-Router harald, you may add yours to the projects category: http://events.ccc.de/congress/2009/wiki/index.php/Category:Projects. if you would like to join with me, then go ahead, link your project to my page and increase the number of seats, and note on both project pages that both projects are together in one area. if anyone requires special equipment, let me know or bring it yourself. e.g. if we like to play with OpenBTS in conjunction with Asterisk, we need another server, since my server is in use for the ISDN/ASTERISK/DECT <-> GSM link. andreas -----Urspr?ngliche Nachricht----- Von: Alexander Chemeris [mailto:alexander.chemeris at gmail.com] Gesendet: Montag, 12. Oktober 2009 22:18 An: Harald Welte Cc: Andreas.Eversberg; openbsc; openbts-discuss at lists.sourceforge.net Betreff: Re: Running an licensed experimental GSM network at 26c3 Hi Harald, David, Andreas, On Sun, Oct 11, 2009 at 13:19, Harald Welte wrote: > On Sat, Oct 10, 2009 at 09:33:31PM +0400, Alexander Chemeris wrote: >> We'll bring one or two our USRPs for OpenBTS testing even if David Burgess >> won't be able to come, and we would love to be located near OpenBSC guys >> and you. But that'll be our first time at 26C3 and we're little bit >> lost - should we send some request to get the space? > > I think the process for applying for tablespace in the hackcenter has not yet > started. > > Meanwhile I've created a http://events.ccc.de/congress/2009/wiki/index.php/GSM > wiki page where we can add stuff to, similar to the 25C3 and HAR2009. Great, thank you. I'll keep my eye on it. From laforge at gnumonks.org Wed Oct 14 14:10:32 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Oct 2009 16:10:32 +0200 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: References: Message-ID: <20091014141032.GA30960@prithivi.gnumonks.org> On Tue, Oct 13, 2009 at 01:27:13PM +0200, Andreas.Eversberg wrote: > i also did my part: > http://events.ccc.de/congress/2009/wiki/index.php/Linux-Call-Router great. > harald, you may add yours to the projects category: > http://events.ccc.de/congress/2009/wiki/index.php/Category:Projects. thanks, I intended to do that but a syntax error prevented it. > if you would like to join with me, then go ahead, link your project to my > page and increase the number of seats, and note on both project pages that > both projects are together in one area. That's fine with me, I'll figure out who is in charge of tablespace allocation at 26C3 and reserve something like 10 seats. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Oct 22 19:39:51 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Oct 2009 21:39:51 +0200 Subject: Running an licensed experimental GSM network at 26c3 In-Reply-To: References: Message-ID: <20091022193951.GV29852@prithivi.gnumonks.org> JFYI: I've spoken with some of the other Berlin CCC folks, and it seems there is no process / responsible person for registering tablespace in the hackcenter yet. I hope I'll notice once that process exists and take care of allocating some of that space. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michael.haben at btinternet.com Tue Oct 6 17:11:52 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Tue, 06 Oct 2009 18:11:52 +0100 Subject: Patches - add support for mobile-originated USSD Message-ID: <4ACB7A58.9040705@btinternet.com> Hello again, More patches - these two (combined) add support for mobile-originated USSD. The demonstration application, implemented in ussd.c, is that sending *#100# to the network will display your 5-digit extension. It's not 100% finished - I've tested it on 6 handsets, 5 of them work perfectly, but the 6th (Samsung i520) doesn't seem to receive the response, so more experimenting to be done... Best regards to all, Mike H. From michael.haben at btinternet.com Sat Oct 3 05:52:51 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Sat, 3 Oct 2009 06:52:51 +0100 Subject: [PATCH] Mobile-originated USSD - first step: receive and decode Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_04_80.h | 10 + openbsc/include/openbsc/ussd.h | 8 + openbsc/src/Makefile.am | 2 +- openbsc/src/gsm_04_08.c | 6 +- openbsc/src/gsm_04_80.c | 349 +++++++++++++++++++++++++++++++++++ openbsc/src/ussd.c | 59 ++++++ 6 files changed, 431 insertions(+), 3 deletions(-) create mode 100755 openbsc/include/openbsc/gsm_04_80.h create mode 100644 openbsc/include/openbsc/ussd.h create mode 100755 openbsc/src/gsm_04_80.c create mode 100644 openbsc/src/ussd.c diff --git a/openbsc/include/openbsc/gsm_04_80.h b/openbsc/include/openbsc/gsm_04_80.h new file mode 100755 index 0000000..d16a876 --- /dev/null +++ b/openbsc/include/openbsc/gsm_04_80.h @@ -0,0 +1,10 @@ +#ifndef _GSM_04_80_H +#define _GSM_04_80_H + +#include + +char* gsm0480_rcv_ussd(struct msgb *msg); +int gsm0480_send_ussd_response(struct msgb *msg, const char* response_text); +int gsm0480_send_ussd_error(struct msgb *msg); + +#endif diff --git a/openbsc/include/openbsc/ussd.h b/openbsc/include/openbsc/ussd.h new file mode 100644 index 0000000..dfd34f3 --- /dev/null +++ b/openbsc/include/openbsc/ussd.h @@ -0,0 +1,8 @@ +#ifndef _USSD_H +#define _USSD_H + +#include + +int handle_rcv_ussd(struct msgb *msg); + +#endif diff --git a/openbsc/src/Makefile.am b/openbsc/src/Makefile.am index 919e075..2f715bb 100644 --- a/openbsc/src/Makefile.am +++ b/openbsc/src/Makefile.am @@ -14,7 +14,7 @@ libbsc_a_SOURCES = abis_rsl.c abis_nm.c gsm_data.c gsm_04_08_utils.c \ libmsc_a_SOURCES = gsm_subscriber.c db.c telnet_interface.c \ mncc.c rtp_proxy.c gsm_04_08.c gsm_04_11.c transaction.c \ - token_auth.c rrlp.c + token_auth.c rrlp.c gsm_04_80.c ussd.c libvty_a_SOURCES = vty/buffer.c vty/command.c vty/vector.c vty/vty.c diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c index 9ad9e15..62f2c18 100644 --- a/openbsc/src/gsm_04_08.c +++ b/openbsc/src/gsm_04_08.c @@ -48,6 +48,7 @@ #include #include #include +#include #define GSM_MAX_FACILITY 128 #define GSM_MAX_SSVERSION 128 @@ -3544,7 +3545,6 @@ static int gsm0408_rcv_cc(struct msgb *msg) return rc; } -/* here we pass in a msgb from the RSL->RLL. We expect the l3 pointer to be set */ int gsm0408_rcvmsg(struct msgb *msg, u_int8_t link_id) { struct gsm48_hdr *gh = msgb_l3(msg); @@ -3566,10 +3566,12 @@ int gsm0408_rcvmsg(struct msgb *msg, u_int8_t link_id) break; case GSM48_PDISC_MM_GPRS: case GSM48_PDISC_SM_GPRS: - case GSM48_PDISC_NC_SS: /* mobile-originated USSD */ fprintf(stderr, "Unimplemented GSM 04.08 discriminator 0x%02x\n", pdisc); break; + case GSM48_PDISC_NC_SS: + rc = handle_rcv_ussd(msg); + break; default: fprintf(stderr, "Unknown GSM 04.08 discriminator 0x%02x\n", pdisc); diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c new file mode 100755 index 0000000..c2c2a86 --- /dev/null +++ b/openbsc/src/gsm_04_80.c @@ -0,0 +1,349 @@ +/* GSM Mobile Radio Interface Layer 3 messages on the A-bis interface + * 3GPP TS 04.08 version 7.21.0 Release 1998 / ETSI TS 100 940 V7.21.0 */ + +/* (C) 2008-2009 by Harald Welte + * (C) 2008, 2009 by Holger Hans Peter Freyther + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* GSM TS 04.80 definitions (Supplementary Services specification, Formats and coding */ + +/* Section 3.4 */ +#define GSM0480_MTYPE_RELEASE_COMPLETE 0x2A +#define GSM0480_MTYPE_FACILITY 0x3A +#define GSM0480_MTYPE_REGISTER 0x3B + +/* Section 3.5 */ +#define GSM0480_IE_FACILITY 0x1C +#define GSM0480_IE_SS_VERSION 0x7F + +/* Section 3.6.2 */ +#define GSM0480_CTYPE_INVOKE 0xA1 +#define GSM0480_CTYPE_RETURN_RESULT 0xA2 +#define GSM0480_CTYPE_RETURN_ERROR 0xA3 +#define GSM0480_CTYPE_REJECT 0xA4 + +/* Section 3.6.3 */ +#define GSM0480_COMPIDTAG_INVOKE_ID 0x02 +#define GSM0480_COMPIDTAG_LINKED_ID 0x80 + +/* Section 3.6.4 */ +#define GSM0480_OPERATION_CODE 0x02 + +/* Section 4.5 */ +#define GSM0480_OP_CODE_REGISTER_SS 0x0A +#define GSM0480_OP_CODE_ERASE_SS 0x0B +#define GSM0480_OP_CODE_ACTIVATE_SS 0x0C +#define GSM0480_OP_CODE_DEACTIVATE_SS 0x0D +#define GSM0480_OP_CODE_INTERROGATE_SS 0x0E +#define GSM0480_OP_CODE_NOTIFY_SS 0x10 +#define GSM0480_OP_CODE_REGISTER_PASSWORD 0x11 +#define GSM0480_OP_CODE_GET_PASSWORD 0x12 +#define GSM0480_OP_CODE_PROCESS_USS_DATA 0x13 +#define GSM0480_OP_CODE_FORWARD_CHECK_SS_IND 0x26 +#define GSM0480_OP_CODE_PROCESS_USS_REQ 0x3B +#define GSM0480_OP_CODE_USS_REQUEST 0x3C +#define GSM0480_OP_CODE_USS_NOTIFY 0x3D +#define GSM0480_OP_CODE_FORWARD_CUG_INFO 0x78 +#define GSM0480_OP_CODE_SPLIT_MPTY 0x79 +#define GSM0480_OP_CODE_RETRIEVE_MPTY 0x7A +#define GSM0480_OP_CODE_HOLD_MPTY 0x7B +#define GSM0480_OP_CODE_BUILD_MPTY 0x7C +#define GSM0480_OP_CODE_FORWARD_CHARGE_ADVICE 0x7D + +#define GSM0480_ERR_CODE_UNKNOWN_SUBSCRIBER 0x01 +#define GSM0480_ERR_CODE_ILLEGAL_SUBSCRIBER 0x09 +#define GSM0480_ERR_CODE_BEARER_SERVICE_NOT_PROVISIONED 0x0A +#define GSM0480_ERR_CODE_TELESERVICE_NOT_PROVISIONED 0x0B +#define GSM0480_ERR_CODE_ILLEGAL_EQUIPMENT 0x0C +#define GSM0480_ERR_CODE_CALL_BARRED 0x0D +#define GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION 0x10 +#define GSM0480_ERR_CODE_SS_ERROR_STATUS 0x11 +#define GSM0480_ERR_CODE_SS_NOT_AVAILABLE 0x12 +#define GSM0480_ERR_CODE_SS_SUBSCRIPTION_VIOLATION 0x13 +#define GSM0480_ERR_CODE_SS_INCOMPATIBILITY 0x14 +#define GSM0480_ERR_CODE_FACILITY_NOT_SUPPORTED 0x15 +#define GSM0480_ERR_CODE_ABSENT_SUBSCRIBER 0x1B +#define GSM0480_ERR_CODE_SYSTEM_FAILURE 0x22 +#define GSM0480_ERR_CODE_DATA_MISSING 0x23 +#define GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE 0x24 +#define GSM0480_ERR_CODE_PW_REGISTRATION_FAILURE 0x25 +#define GSM0480_ERR_CODE_NEGATIVE_PW_CHECK 0x26 +#define GSM0480_ERR_CODE_NUM_PW_ATTEMPTS_VIOLATION 0x2B +#define GSM0480_ERR_CODE_UNKNOWN_ALPHABET 0x47 +#define GSM0480_ERR_CODE_USSD_BUSY 0x48 +#define GSM0480_ERR_CODE_MAX_MPTY_PARTICIPANTS 0x7E +#define GSM0480_ERR_CODE_RESOURCES_NOT_AVAILABLE 0x7F + +static char ussd_string_buff[256]; + +/* Forward declarations */ +static int parse_ussd(u_int8_t *ussd, u_int8_t length); +static int parse_ussd_information_elements(u_int8_t *ussd_ie, u_int8_t length); +static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length); +static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length); +static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length); + +/* Receive a mobile-originated USSD message and return the decoded text */ +char* gsm0480_rcv_ussd(struct msgb *msg) +{ + int rc = 1; + u_int8_t tag; + u_int8_t length; + u_int8_t offset = 2; // don't yet understand the first 2 bytes, so ignore them for now + + DEBUGP(DMM, "USSD %s\n", hexdump(msg->data, msg->len)); // preliminary! Just see what we're receiving... + + memset(ussd_string_buff, 0, sizeof(ussd_string_buff)); + + do + { + tag = msg->data[offset]; + length = msg->data[offset+1]; + if((msg->data[offset+2] & 0x0f) == GSM48_PDISC_NC_SS) // not sure if this is correct??? + rc &= parse_ussd(&(msg->data[offset+3]), length-3); + offset += (length+2); + } + while(offset < msg->len); + + if(rc) + DEBUGP(DMM, "USSD received OK, response not yet implemented\n"); + else + DEBUGP(DMM, "Error occurred while parsing received USSD!\n"); + + return ussd_string_buff; +} + +static int parse_ussd(u_int8_t *ussd, u_int8_t length) +{ + int rc = 1; + u_int8_t msg_type = ussd[0] & 0xBF; // message-type - section 3.4 + + switch(msg_type) { + case GSM0480_MTYPE_RELEASE_COMPLETE: + DEBUGP(DMM, "USS Release Complete\n"); // could also parse out the optional Cause/Facility data + break; + case GSM0480_MTYPE_REGISTER: + case GSM0480_MTYPE_FACILITY: + rc &= parse_ussd_information_elements(ussd+1, length-1); + break; + default: + fprintf(stderr, "Unknown GSM 04.80 message-type field 0x%02x\n", + ussd[0]); + rc = 0; + break; + } + + return rc; +} + +static int parse_ussd_information_elements(u_int8_t *ussd_ie, u_int8_t length) +{ + int rc = 1; + u_int8_t offset = 0; + + do + { + u_int8_t iei = ussd_ie[offset]; // Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 + u_int8_t iei_length = ussd_ie[offset+1]; + switch(iei) { + case GSM48_IE_CAUSE: + break; + case GSM0480_IE_FACILITY: + rc &= parse_facility_ie(ussd_ie+2, iei_length); + break; + case GSM0480_IE_SS_VERSION: + break; + default: + fprintf(stderr, "Unhandled GSM 04.08 or 04.80 Information Element Identifier 0x%02x\n", + iei); + rc = 0; + break; + } + + + offset += (iei_length+2); + } + while(offset < length); + + return rc; +} + +static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) +{ + int rc = 1; + u_int8_t offset = 0; + + do + { + u_int8_t component_type = facility_ie[offset]; // Component Type tag - table 3.7 + u_int8_t component_length = facility_ie[offset+1]; + switch(component_type) { + case GSM0480_CTYPE_INVOKE: + rc &= parse_ss_invoke(facility_ie+2, component_length); + break; + case GSM0480_CTYPE_RETURN_RESULT: + break; + case GSM0480_CTYPE_RETURN_ERROR: + break; + case GSM0480_CTYPE_REJECT: + break; + default: + fprintf(stderr, "Unknown GSM 04.80 Facility Component Type 0x%02x\n", + component_type); + rc = 0; + break; + } + + offset += (component_length+2); + } + while(offset < length); + + return rc; +} + +/* Parse an Invoke component - see table 3.3 */ +static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) +{ + int rc = 1; + + if(invoke_data[0] != GSM0480_COMPIDTAG_INVOKE_ID) // mandatory part + { + fprintf(stderr, "Unexpected GSM 04.80 Component-ID tag 0x%02x (expecting Invoke ID tag)\n", + invoke_data[0]); + } + u_int8_t offset = invoke_data[1] + 2; + + if(invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) // optional part + offset += invoke_data[offset+1] + 2; // skip over it + + if(invoke_data[offset] == GSM0480_OPERATION_CODE) // mandatory part + { + u_int8_t operation_code = invoke_data[offset+2]; + switch(operation_code) { + case GSM0480_OP_CODE_PROCESS_USS_REQ: + rc = parse_process_uss_req(invoke_data + 3, length - 3); + break; + default: + fprintf(stderr, "GSM 04.80 operation code 0x%02x is not yet handled\n", + operation_code); + rc = 0; + break; + } + } + else + { + fprintf(stderr, "Unexpected GSM 04.80 Component-ID tag 0x%02x (expecting Operation Code tag)\n", + invoke_data[0]); + rc = 0; + } + + return rc; +} + +/* Parse the parameters of a Process UnstructuredSS Request */ +static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) +{ + int rc = 1; + u_int8_t dcs; + + /* FIXME: properly parse out the initial tag and length, then the data-coding scheme and finally the text - + following piece of code uses hard-coded offsets into the data */ + dcs = uss_req_data[7]; + DEBUGP(DMM, "Data coding scheme = 0x%2.2X\n", dcs); // temporary + + int num_7_bit_chars = (uss_req_data[9] * 8) / 7; + gsm_7bit_decode(ussd_string_buff, &(uss_req_data[10]), num_7_bit_chars); + + return rc; +} + +/* !!! Not yet complete or even partly working, causes a test phone to reboot! */ +int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) +{ + struct msgb *msg = gsm48_msgb_alloc(); + struct gsm48_hdr *gh; + struct gsm_network *net = in_msg->lchan->ts->trx->bts->network; + u_int8_t *ptr8; + int response_len, response_pad; + + msg->lchan = in_msg->lchan; + + gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); + gh->proto_discr = GSM48_PDISC_NC_SS; + gh->msg_type = GSM0480_MTYPE_FACILITY; + +/* FIXME: Need to add lots of stuff here to build up a valid USSD - + GSM0480_IE_FACILITY, GSM0480_CTYPE_INVOKE(?), GSM0480_COMPIDTAG_INVOKE_ID, + GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ(?) */ + + response_len = (strlen(response_text)*7)/8; + response_pad = (8 - strlen(net->name_long)*7)%8; + if (response_pad > 0) + response_len++; + /* 10.5.3.5a */ + ptr8 = msgb_put(msg, 19); + ptr8[0] = GSM0480_IE_FACILITY; + ptr8[1] = response_len + 17; + ptr8[2] = GSM0480_CTYPE_RETURN_RESULT; + ptr8[3] = response_len + 15; + ptr8[4] = GSM0480_COMPIDTAG_INVOKE_ID; + ptr8[5] = 1; + ptr8[6] = 0x80; // invoke-ID -128 + ptr8[7] = 0x30; // don't yet understand where this comes from + ptr8[8] = response_len + 10; + ptr8[9] = GSM0480_OPERATION_CODE; + ptr8[10] = 1; + ptr8[11] = GSM0480_OP_CODE_PROCESS_USS_REQ; + ptr8[12] = 0x30; // don't yet understand where this comes from + ptr8[13] = response_len + 5; + ptr8[14] = 0x04; // indicates DCS to follow + ptr8[15] = 1; // length of DCS + ptr8[16] = 0x0F; // DCS + ptr8[17] = 0x04; // indicates string to follow + ptr8[18] = response_len; + + ptr8 = msgb_put(msg, response_len); + gsm_7bit_encode(ptr8, response_text); + + DEBUGP(DMM, "USSD response %s\n", hexdump(msg->data, msg->len)); // preliminary! Just see what we're sending... + + return -EINVAL; /* Temporary */ +// return gsm48_sendmsg(msg, NULL); +} + +/* !!! Not yet complete or even partly working */ +int gsm0480_send_ussd_error(struct msgb *in_msg) +{ + return -EINVAL; +} diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c new file mode 100644 index 0000000..26b4686 --- /dev/null +++ b/openbsc/src/ussd.c @@ -0,0 +1,59 @@ +/* Handler for mobile-originated USSDs */ + +/* (C) 2008-2009 by Harald Welte + * (C) 2008, 2009 by Holger Hans Peter Freyther + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + + +#include +#include +#include +#include + +#include +#include +#include + +#define USSD_TEXT_OWN_NUMBER "*#100#" + +static int send_own_number(struct msgb *msg); + +int handle_rcv_ussd(struct msgb *msg) +{ + char* ussd_text_rcvd = gsm0480_rcv_ussd(msg); + DEBUGP(DMM, "Received USSD text %s\n", ussd_text_rcvd); // show text payload entered on MS + + if(strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) + { + DEBUGP(DMM, "USSD: Own number requested\n"); + return send_own_number(msg); + } + else + { + DEBUGP(DMM, "Unhandled USSD %s\n", ussd_text_rcvd); + return gsm0480_send_ussd_error(msg); + } +} + +static int send_own_number(struct msgb *msg) +{ + char* own_number = msg->lchan->subscr->extension; + return gsm0480_send_ussd_response(msg, own_number); +} -- 1.6.0.4 --------------040900030502000202050609 Content-Type: text/x-diff; name="0002-Support-for-mobile-originated-USSD-working-demonst.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="0002-Support-for-mobile-originated-USSD-working-demonst.patc"; filename*1="h" From michael.haben at btinternet.com Tue Oct 6 16:55:26 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Tue, 6 Oct 2009 17:55:26 +0100 Subject: [PATCH] Support for mobile-originated USSD - working demonstration (*#100# to get own number) Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_04_80.h | 19 +++- openbsc/src/gsm_04_80.c | 252 +++++++++++++++++++++-------------- openbsc/src/ussd.c | 15 ++- 3 files changed, 180 insertions(+), 106 deletions(-) mode change 100644 => 100755 openbsc/include/openbsc/ussd.h mode change 100644 => 100755 openbsc/src/gsm_04_08.c mode change 100644 => 100755 openbsc/src/ussd.c diff --git a/openbsc/include/openbsc/gsm_04_80.h b/openbsc/include/openbsc/gsm_04_80.h index d16a876..43b5b74 100755 --- a/openbsc/include/openbsc/gsm_04_80.h +++ b/openbsc/include/openbsc/gsm_04_80.h @@ -3,8 +3,25 @@ #include +/* GSM TS 04.80 definitions (Supplementary Services specification, Formats and coding */ +/* Section 3.6.5 */ +#define GSM_0480_SEQUENCE_TAG 0x30 +#define GSM_0480_SET_TAG 0x31 + +/* ASN.1 type-tags */ +#define ASN1_BOOLEAN_TAG 0x01 +#define ASN1_INTEGER_TAG 0x02 +#define ASN1_BIT_STRING_TAG 0x03 +#define ASN1_OCTET_STRING_TAG 0x04 +#define ASN1_NULL_TYPE_TAG 0x05 +#define ASN1_OBJECT_ID_TAG 0x06 +#define ASN1_UTF8_STRING_TAG 0x0C +#define ASN1_PRINTABLE_STRING_TAG 0x13 +#define ASN1_IA5_STRING_TAG 0x16 +#define ASN1_UNICODE_STRING_TAG 0x1E + char* gsm0480_rcv_ussd(struct msgb *msg); int gsm0480_send_ussd_response(struct msgb *msg, const char* response_text); -int gsm0480_send_ussd_error(struct msgb *msg); +int gsm0480_send_ussd_reject(struct msgb *msg); #endif diff --git a/openbsc/include/openbsc/ussd.h b/openbsc/include/openbsc/ussd.h old mode 100644 new mode 100755 diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c old mode 100644 new mode 100755 diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c index c2c2a86..a6dffa8 100755 --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -39,26 +39,63 @@ /* GSM TS 04.80 definitions (Supplementary Services specification, Formats and coding */ /* Section 3.4 */ -#define GSM0480_MTYPE_RELEASE_COMPLETE 0x2A -#define GSM0480_MTYPE_FACILITY 0x3A -#define GSM0480_MTYPE_REGISTER 0x3B +#define GSM0480_MTYPE_RELEASE_COMPLETE 0x2A +#define GSM0480_MTYPE_FACILITY 0x3A +#define GSM0480_MTYPE_REGISTER 0x3B /* Section 3.5 */ -#define GSM0480_IE_FACILITY 0x1C -#define GSM0480_IE_SS_VERSION 0x7F +#define GSM0480_IE_FACILITY 0x1C +#define GSM0480_IE_SS_VERSION 0x7F /* Section 3.6.2 */ -#define GSM0480_CTYPE_INVOKE 0xA1 -#define GSM0480_CTYPE_RETURN_RESULT 0xA2 -#define GSM0480_CTYPE_RETURN_ERROR 0xA3 -#define GSM0480_CTYPE_REJECT 0xA4 +#define GSM0480_CTYPE_INVOKE 0xA1 +#define GSM0480_CTYPE_RETURN_RESULT 0xA2 +#define GSM0480_CTYPE_RETURN_ERROR 0xA3 +#define GSM0480_CTYPE_REJECT 0xA4 /* Section 3.6.3 */ -#define GSM0480_COMPIDTAG_INVOKE_ID 0x02 -#define GSM0480_COMPIDTAG_LINKED_ID 0x80 +#define GSM0480_COMPIDTAG_INVOKE_ID 0x02 +#define GSM0480_COMPIDTAG_LINKED_ID 0x80 /* Section 3.6.4 */ -#define GSM0480_OPERATION_CODE 0x02 +#define GSM0480_OPERATION_CODE 0x02 + +/* Section 3.6.6 */ +#define GSM_0480_ERROR_CODE_TAG 0x02 + +/* Section 3.6.7 */ +/* Table 3.13 */ +#define GSM_0480_PROBLEM_CODE_TAG_GENERAL 0x80 +#define GSM_0480_PROBLEM_CODE_TAG_INVOKE 0x81 +#define GSM_0480_PROBLEM_CODE_TAG_RETURN_RESULT 0x82 +#define GSM_0480_PROBLEM_CODE_TAG_RETURN_ERROR 0x83 + +/* Table 3.14 */ +#define GSM_0480_GEN_PROB_CODE_UNRECOGNISED 0x00 +#define GSM_0480_GEN_PROB_CODE_MISTYPED 0x01 +#define GSM_0480_GEN_PROB_CODE_BAD_STRUCTURE 0x02 + +/* Table 3.15 */ +#define GSM_0480_INVOKE_PROB_CODE_DUPLICATE_INVOKE_ID 0x00 +#define GSM_0480_INVOKE_PROB_CODE_UNRECOGNISED_OPERATION 0x01 +#define GSM_0480_INVOKE_PROB_CODE_MISTYPED_PARAMETER 0x02 +#define GSM_0480_INVOKE_PROB_CODE_RESOURCE_LIMITATION 0x03 +#define GSM_0480_INVOKE_PROB_CODE_INITIATING_RELEASE 0x04 +#define GSM_0480_INVOKE_PROB_CODE_UNRECOGNISED_LINKED_ID 0x05 +#define GSM_0480_INVOKE_PROB_CODE_UNEXPECTED_LINKED_RESPONSE 0x06 +#define GSM_0480_INVOKE_PROB_CODE_UNEXPECTED_LINKED_OPERATION 0x07 + +/* Table 3.16 */ +#define GSM_0480_RESULT_PROB_CODE_UNRECOGNISED_INVOKE_ID 0x00 +#define GSM_0480_RESULT_PROB_CODE_RETURN_RESULT_UNEXPECTED 0x01 +#define GSM_0480_RESULT_PROB_CODE_MISTYPED_PARAMETER 0x02 + +/* Table 3.17 */ +#define GSM_0480_ERROR_PROB_CODE_UNRECOGNISED_INVOKE_ID 0x00 +#define GSM_0480_ERROR_PROB_CODE_RETURN_ERROR_UNEXPECTED 0x01 +#define GSM_0480_ERROR_PROB_CODE_UNRECOGNISED_ERROR 0x02 +#define GSM_0480_ERROR_PROB_CODE_UNEXPECTED_ERROR 0x03 +#define GSM_0480_ERROR_PROB_CODE_MISTYPED_PARAMETER 0x04 /* Section 4.5 */ #define GSM0480_OP_CODE_REGISTER_SS 0x0A @@ -105,11 +142,13 @@ #define GSM0480_ERR_CODE_MAX_MPTY_PARTICIPANTS 0x7E #define GSM0480_ERR_CODE_RESOURCES_NOT_AVAILABLE 0x7F -static char ussd_string_buff[256]; +static char ussd_string_buff[32]; +static u_int8_t last_transaction_id; +static u_int8_t last_invoke_id; /* Forward declarations */ -static int parse_ussd(u_int8_t *ussd, u_int8_t length); -static int parse_ussd_information_elements(u_int8_t *ussd_ie, u_int8_t length); +static int parse_ussd(u_int8_t *ussd); +static int parse_ussd_information_elements(u_int8_t *ussd_ie); static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length); static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length); static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length); @@ -117,34 +156,26 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length); /* Receive a mobile-originated USSD message and return the decoded text */ char* gsm0480_rcv_ussd(struct msgb *msg) { - int rc = 1; - u_int8_t tag; - u_int8_t length; - u_int8_t offset = 2; // don't yet understand the first 2 bytes, so ignore them for now + int rc = 0; + u_int8_t* parse_ptr = msgb_l3(msg); - DEBUGP(DMM, "USSD %s\n", hexdump(msg->data, msg->len)); // preliminary! Just see what we're receiving... +// DEBUGP(DMM, "USSD %s\n", hexdump(msg->data, msg->len)); // temporary, just see what we're receiving... memset(ussd_string_buff, 0, sizeof(ussd_string_buff)); - do + if((*parse_ptr & 0x0F) == GSM48_PDISC_NC_SS) { - tag = msg->data[offset]; - length = msg->data[offset+1]; - if((msg->data[offset+2] & 0x0f) == GSM48_PDISC_NC_SS) // not sure if this is correct??? - rc &= parse_ussd(&(msg->data[offset+3]), length-3); - offset += (length+2); + last_transaction_id = *parse_ptr & 0xF0; + rc = parse_ussd(parse_ptr + 1); } - while(offset < msg->len); - if(rc) - DEBUGP(DMM, "USSD received OK, response not yet implemented\n"); - else + if(!rc) DEBUGP(DMM, "Error occurred while parsing received USSD!\n"); return ussd_string_buff; } -static int parse_ussd(u_int8_t *ussd, u_int8_t length) +static int parse_ussd(u_int8_t *ussd) { int rc = 1; u_int8_t msg_type = ussd[0] & 0xBF; // message-type - section 3.4 @@ -152,10 +183,11 @@ static int parse_ussd(u_int8_t *ussd, u_int8_t length) switch(msg_type) { case GSM0480_MTYPE_RELEASE_COMPLETE: DEBUGP(DMM, "USS Release Complete\n"); // could also parse out the optional Cause/Facility data + ussd_string_buff[0] = 0xFF; break; case GSM0480_MTYPE_REGISTER: case GSM0480_MTYPE_FACILITY: - rc &= parse_ussd_information_elements(ussd+1, length-1); + rc &= parse_ussd_information_elements(ussd+1); break; default: fprintf(stderr, "Unknown GSM 04.80 message-type field 0x%02x\n", @@ -167,34 +199,26 @@ static int parse_ussd(u_int8_t *ussd, u_int8_t length) return rc; } -static int parse_ussd_information_elements(u_int8_t *ussd_ie, u_int8_t length) +static int parse_ussd_information_elements(u_int8_t *ussd_ie) { - int rc = 1; - u_int8_t offset = 0; + int rc; - do - { - u_int8_t iei = ussd_ie[offset]; // Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 - u_int8_t iei_length = ussd_ie[offset+1]; - switch(iei) { - case GSM48_IE_CAUSE: - break; - case GSM0480_IE_FACILITY: - rc &= parse_facility_ie(ussd_ie+2, iei_length); - break; - case GSM0480_IE_SS_VERSION: - break; - default: - fprintf(stderr, "Unhandled GSM 04.08 or 04.80 Information Element Identifier 0x%02x\n", - iei); - rc = 0; - break; - } - - - offset += (iei_length+2); + u_int8_t iei = ussd_ie[0]; // Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 + u_int8_t iei_length = ussd_ie[1]; + switch(iei) { + case GSM48_IE_CAUSE: + break; + case GSM0480_IE_FACILITY: + rc = parse_facility_ie(ussd_ie+2, iei_length); + break; + case GSM0480_IE_SS_VERSION: + break; + default: + fprintf(stderr, "Unhandled GSM 04.08 or 04.80 Information Element Identifier 0x%02x\n", + iei); + rc = 0; + break; } - while(offset < length); return rc; } @@ -243,6 +267,7 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) invoke_data[0]); } u_int8_t offset = invoke_data[1] + 2; + last_invoke_id = invoke_data[2]; if(invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) // optional part offset += invoke_data[offset+1] + 2; // skip over it @@ -252,7 +277,7 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) u_int8_t operation_code = invoke_data[offset+2]; switch(operation_code) { case GSM0480_OP_CODE_PROCESS_USS_REQ: - rc = parse_process_uss_req(invoke_data + 3, length - 3); + rc = parse_process_uss_req(invoke_data + offset + 3, length - offset - 3); break; default: fprintf(stderr, "GSM 04.80 operation code 0x%02x is not yet handled\n", @@ -275,75 +300,100 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) { int rc = 1; + int num_chars; u_int8_t dcs; - /* FIXME: properly parse out the initial tag and length, then the data-coding scheme and finally the text - - following piece of code uses hard-coded offsets into the data */ - dcs = uss_req_data[7]; - DEBUGP(DMM, "Data coding scheme = 0x%2.2X\n", dcs); // temporary - - int num_7_bit_chars = (uss_req_data[9] * 8) / 7; - gsm_7bit_decode(ussd_string_buff, &(uss_req_data[10]), num_7_bit_chars); +// DEBUGP(DMM, "USSD request params %s\n", hexdump(uss_req_data, length)); + /* FIXME: most phones send USSD text as a 7-bit encoded octet string; the following code + also handles the case of plain ASCII text (IA5String), but other encodings might be used */ + if(uss_req_data[0] == GSM_0480_SEQUENCE_TAG) + { + if(uss_req_data[2] == ASN1_OCTET_STRING_TAG) + { + dcs = uss_req_data[4]; +// DEBUGP(DMM, "Data coding scheme = 0x%2.2X\n", dcs); + if((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) + { + num_chars = (uss_req_data[6] * 8) / 7; + gsm_7bit_decode(ussd_string_buff, &(uss_req_data[7]), num_chars); + } + } + } + else if(uss_req_data[0] == ASN1_IA5_STRING_TAG) + { + num_chars = uss_req_data[1]; + memcpy(ussd_string_buff, &(uss_req_data[2]), num_chars); + } return rc; } -/* !!! Not yet complete or even partly working, causes a test phone to reboot! */ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) { struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - struct gsm_network *net = in_msg->lchan->ts->trx->bts->network; u_int8_t *ptr8; - int response_len, response_pad; + int response_len; + response_len = strlen(response_text); + + msg->bts_link = in_msg->bts_link; msg->lchan = in_msg->lchan; gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); - gh->proto_discr = GSM48_PDISC_NC_SS; - gh->msg_type = GSM0480_MTYPE_FACILITY; - -/* FIXME: Need to add lots of stuff here to build up a valid USSD - - GSM0480_IE_FACILITY, GSM0480_CTYPE_INVOKE(?), GSM0480_COMPIDTAG_INVOKE_ID, - GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ(?) */ - - response_len = (strlen(response_text)*7)/8; - response_pad = (8 - strlen(net->name_long)*7)%8; - if (response_pad > 0) - response_len++; - /* 10.5.3.5a */ - ptr8 = msgb_put(msg, 19); + gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | 0x80; // TI direction = 1 + gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; + + ptr8 = msgb_put(msg, 14); ptr8[0] = GSM0480_IE_FACILITY; - ptr8[1] = response_len + 17; + ptr8[1] = response_len + 12; ptr8[2] = GSM0480_CTYPE_RETURN_RESULT; - ptr8[3] = response_len + 15; + ptr8[3] = response_len + 10; ptr8[4] = GSM0480_COMPIDTAG_INVOKE_ID; ptr8[5] = 1; - ptr8[6] = 0x80; // invoke-ID -128 - ptr8[7] = 0x30; // don't yet understand where this comes from - ptr8[8] = response_len + 10; + ptr8[6] = last_invoke_id; + ptr8[7] = GSM_0480_SEQUENCE_TAG; + ptr8[8] = response_len + 5; ptr8[9] = GSM0480_OPERATION_CODE; ptr8[10] = 1; - ptr8[11] = GSM0480_OP_CODE_PROCESS_USS_REQ; - ptr8[12] = 0x30; // don't yet understand where this comes from - ptr8[13] = response_len + 5; - ptr8[14] = 0x04; // indicates DCS to follow - ptr8[15] = 1; // length of DCS - ptr8[16] = 0x0F; // DCS - ptr8[17] = 0x04; // indicates string to follow - ptr8[18] = response_len; + ptr8[11] = GSM0480_OP_CODE_PROCESS_USS_DATA; + ptr8[12] = ASN1_IA5_STRING_TAG; + ptr8[13] = response_len; ptr8 = msgb_put(msg, response_len); - gsm_7bit_encode(ptr8, response_text); + memcpy(ptr8, response_text, response_len); - DEBUGP(DMM, "USSD response %s\n", hexdump(msg->data, msg->len)); // preliminary! Just see what we're sending... +// DEBUGP(DMM, "USSD response %s\n", hexdump(msg->data, msg->len)); // temporary, just to see what we're sending back - return -EINVAL; /* Temporary */ -// return gsm48_sendmsg(msg, NULL); + return gsm48_sendmsg(msg, NULL); } -/* !!! Not yet complete or even partly working */ -int gsm0480_send_ussd_error(struct msgb *in_msg) +int gsm0480_send_ussd_reject(struct msgb *in_msg) { - return -EINVAL; + struct msgb *msg = gsm48_msgb_alloc(); + struct gsm48_hdr *gh; + u_int8_t *ptr8; + + msg->bts_link = in_msg->bts_link; + msg->lchan = in_msg->lchan; + + gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); + gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | 0x80; // TI direction = 1 + gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; + + ptr8 = msgb_put(msg, 10); + ptr8[0] = GSM0480_IE_FACILITY; + ptr8[1] = 8; + ptr8[2] = GSM0480_CTYPE_REJECT; + ptr8[3] = 6; + ptr8[4] = GSM0480_COMPIDTAG_INVOKE_ID; + ptr8[5] = 1; + ptr8[6] = last_invoke_id; + ptr8[7] = GSM_0480_PROBLEM_CODE_TAG_GENERAL; + ptr8[8] = 1; + ptr8[9] = GSM_0480_GEN_PROB_CODE_UNRECOGNISED; + +// DEBUGP(DMM, "USSD reject %s\n", hexdump(msg->data, msg->len)); // temporary, just to see what we're sending back + + return gsm48_sendmsg(msg, NULL); } diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c old mode 100644 new mode 100755 index 26b4686..761a0e7 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -1,4 +1,4 @@ -/* Handler for mobile-originated USSDs */ +/* Network-specific handling of mobile-originated USSDs. */ /* (C) 2008-2009 by Harald Welte * (C) 2008, 2009 by Holger Hans Peter Freyther @@ -31,13 +31,17 @@ #include #include -#define USSD_TEXT_OWN_NUMBER "*#100#" +const char USSD_TEXT_OWN_NUMBER[] = "*#100#"; static int send_own_number(struct msgb *msg); int handle_rcv_ussd(struct msgb *msg) { char* ussd_text_rcvd = gsm0480_rcv_ussd(msg); + + if(ussd_text_rcvd[0] == 0xFF) // Release-Complete + return 0; + DEBUGP(DMM, "Received USSD text %s\n", ussd_text_rcvd); // show text payload entered on MS if(strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) @@ -48,12 +52,15 @@ int handle_rcv_ussd(struct msgb *msg) else { DEBUGP(DMM, "Unhandled USSD %s\n", ussd_text_rcvd); - return gsm0480_send_ussd_error(msg); + return gsm0480_send_ussd_reject(msg); } } static int send_own_number(struct msgb *msg) { + char response_string[] = "Your extension is xxxxx"; + char* own_number = msg->lchan->subscr->extension; - return gsm0480_send_ussd_response(msg, own_number); + memcpy(response_string + 18, own_number, 5); + return gsm0480_send_ussd_response(msg, response_string); } -- 1.6.0.4 --------------040900030502000202050609-- From zecke at selfish.org Wed Oct 7 01:55:03 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 7 Oct 2009 03:55:03 +0200 Subject: Patches - add support for mobile-originated USSD In-Reply-To: <4ACB7A58.9040705@btinternet.com> References: <4ACB7A58.9040705@btinternet.com> Message-ID: <200910070355.04048.zecke@selfish.org> On Tuesday 06 October 2009 19:11:52 Mike Haben wrote: > Hello again, > More patches - these two (combined) add support for mobile-originated > USSD. The demonstration application, implemented in ussd.c, is that > sending *#100# to the network will display your 5-digit extension. It's > not 100% finished - I've tested it on 6 handsets, 5 of them work > perfectly, but the 6th (Samsung i520) doesn't seem to receive the > response, so more experimenting to be done... nice, please give us some time to review. Why didn't you add your copyright to the new files? holger From michael.haben at btinternet.com Wed Oct 7 05:49:28 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Wed, 07 Oct 2009 06:49:28 +0100 Subject: Patches - add support for mobile-originated USSD In-Reply-To: <4ACB7A58.9040705@btinternet.com> References: <4ACB7A58.9040705@btinternet.com> Message-ID: <4ACC2BE8.9090309@btinternet.com> Holger wrote: > Why didn't you add your copyright to > the new files? Should have done I guess, didn't occur to me - this is the first time I've contributed more than small bugfixes to an open-source project. Thanks for pointing it out! Mike H. From laforge at gnumonks.org Wed Oct 7 06:24:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 08:24:39 +0200 Subject: Patches - add support for mobile-originated USSD In-Reply-To: <4ACB7A58.9040705@btinternet.com> References: <4ACB7A58.9040705@btinternet.com> Message-ID: <20091007062439.GD25086@prithivi.gnumonks.org> Hi Mike, On Tue, Oct 06, 2009 at 06:11:52PM +0100, Mike Haben wrote: > More patches - these two (combined) add support for > mobile-originated USSD. The demonstration application, implemented > in ussd.c, is that sending *#100# to the network will display your > 5-digit extension. It's not 100% finished - I've tested it on 6 > handsets, 5 of them work perfectly, but the 6th (Samsung i520) > doesn't seem to receive the response, so more experimenting to be > done... thanks a lot. some initial review comments * please move the "#define GSM0480_" into the header file * please pay attention to the coding style, we use linux-2.6/Documentation/CodingStyle . This particularly relates to having "do {" on one line and not using // style comments, and space at "if (" * I don't like the ptr8[n] arrays. If there is a common/static header, please define a structure for it. For the variable parts at the end, things like msgb_tv_put() or msgb_tlv_put() should be used. can you please take care of this and re-submit? thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michael.haben at btinternet.com Fri Oct 9 17:52:30 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Fri, 09 Oct 2009 18:52:30 +0100 Subject: Patches - add support for mobile-originated USSD In-Reply-To: <20091007062439.GD25086@prithivi.gnumonks.org> References: <4ACB7A58.9040705@btinternet.com> <20091007062439.GD25086@prithivi.gnumonks.org> Message-ID: <4ACF785E.9070600@btinternet.com> Hi Harald, thanks for the comments - update patch attached. USSD uses TLVs inside TLVs inside other TLVs, so I've defined a couple of msgb_push utility functions, this seemed the most elegant way to express the construction of these messages. Interested (and secretly pleased) to find that most of the Linux-2.6 coding style guidelines directly contradict the coding standard imposed on me at work... Best regards, Mike H. Harald Welte wrote: > Hi Mike, > > On Tue, Oct 06, 2009 at 06:11:52PM +0100, Mike Haben wrote: > > >> More patches - these two (combined) add support for >> mobile-originated USSD. The demonstration application, implemented >> in ussd.c, is that sending *#100# to the network will display your >> 5-digit extension. It's not 100% finished - I've tested it on 6 >> handsets, 5 of them work perfectly, but the 6th (Samsung i520) >> doesn't seem to receive the response, so more experimenting to be >> done... >> > > thanks a lot. > > some initial review comments > * please move the "#define GSM0480_" into the header file > * please pay attention to the coding style, we use > linux-2.6/Documentation/CodingStyle . This particularly relates to having > "do {" on one line and not using // style comments, and space at "if (" > * I don't like the ptr8[n] arrays. If there is a common/static header, > please define a structure for it. For the variable parts at the end, > things like msgb_tv_put() or msgb_tlv_put() should be used. > > can you please take care of this and re-submit? thanks. > From michael.haben at btinternet.com Fri Oct 9 17:53:43 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Fri, 09 Oct 2009 18:53:43 +0100 Subject: Patches - add support for mobile-originated USSD - D'oh! In-Reply-To: <20091007062439.GD25086@prithivi.gnumonks.org> References: <4ACB7A58.9040705@btinternet.com> <20091007062439.GD25086@prithivi.gnumonks.org> Message-ID: <4ACF78A7.4060707@btinternet.com> Now with patch... Harald Welte wrote: > Hi Mike, > > On Tue, Oct 06, 2009 at 06:11:52PM +0100, Mike Haben wrote: > > >> More patches - these two (combined) add support for >> mobile-originated USSD. The demonstration application, implemented >> in ussd.c, is that sending *#100# to the network will display your >> 5-digit extension. It's not 100% finished - I've tested it on 6 >> handsets, 5 of them work perfectly, but the 6th (Samsung i520) >> doesn't seem to receive the response, so more experimenting to be >> done... >> > > thanks a lot. > > some initial review comments > * please move the "#define GSM0480_" into the header file > * please pay attention to the coding style, we use > linux-2.6/Documentation/CodingStyle . This particularly relates to having > "do {" on one line and not using // style comments, and space at "if (" > * I don't like the ptr8[n] arrays. If there is a common/static header, > please define a structure for it. For the variable parts at the end, > things like msgb_tv_put() or msgb_tlv_put() should be used. > > can you please take care of this and re-submit? thanks. > From michael.haben at btinternet.com Fri Oct 9 17:24:21 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Fri, 9 Oct 2009 18:24:21 +0100 Subject: [PATCH] Changes to USSD support modules following initial review Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_04_80.h | 129 +++++++++++++++++-- openbsc/include/openbsc/ussd.h | 2 + openbsc/src/gsm_04_80.c | 246 ++++++++++------------------------ openbsc/src/ussd.c | 16 ++- 4 files changed, 201 insertions(+), 192 deletions(-) diff --git a/openbsc/include/openbsc/gsm_04_80.h b/openbsc/include/openbsc/gsm_04_80.h index 43b5b74..11962d8 100755 --- a/openbsc/include/openbsc/gsm_04_80.h +++ b/openbsc/include/openbsc/gsm_04_80.h @@ -1,24 +1,129 @@ #ifndef _GSM_04_80_H #define _GSM_04_80_H -#include +/* GSM TS 04.80 definitions (Supplementary Services Specification, Formats and Coding) */ + +/* Section 3.4 */ +#define GSM0480_MTYPE_RELEASE_COMPLETE 0x2A +#define GSM0480_MTYPE_FACILITY 0x3A +#define GSM0480_MTYPE_REGISTER 0x3B + +/* Section 3.5 */ +#define GSM0480_IE_FACILITY 0x1C +#define GSM0480_IE_SS_VERSION 0x7F + +/* Section 3.6.2 */ +#define GSM0480_CTYPE_INVOKE 0xA1 +#define GSM0480_CTYPE_RETURN_RESULT 0xA2 +#define GSM0480_CTYPE_RETURN_ERROR 0xA3 +#define GSM0480_CTYPE_REJECT 0xA4 + +/* Section 3.6.3 */ +#define GSM0480_COMPIDTAG_INVOKE_ID 0x02 +#define GSM0480_COMPIDTAG_LINKED_ID 0x80 + +/* Section 3.6.4 */ +#define GSM0480_OPERATION_CODE 0x02 -/* GSM TS 04.80 definitions (Supplementary Services specification, Formats and coding */ /* Section 3.6.5 */ #define GSM_0480_SEQUENCE_TAG 0x30 #define GSM_0480_SET_TAG 0x31 +/* Section 3.6.6 */ +#define GSM_0480_ERROR_CODE_TAG 0x02 + +/* Section 3.6.7 */ +/* Table 3.13 */ +#define GSM_0480_PROBLEM_CODE_TAG_GENERAL 0x80 +#define GSM_0480_PROBLEM_CODE_TAG_INVOKE 0x81 +#define GSM_0480_PROBLEM_CODE_TAG_RETURN_RESULT 0x82 +#define GSM_0480_PROBLEM_CODE_TAG_RETURN_ERROR 0x83 + +/* Table 3.14 */ +#define GSM_0480_GEN_PROB_CODE_UNRECOGNISED 0x00 +#define GSM_0480_GEN_PROB_CODE_MISTYPED 0x01 +#define GSM_0480_GEN_PROB_CODE_BAD_STRUCTURE 0x02 + +/* Table 3.15 */ +#define GSM_0480_INVOKE_PROB_CODE_DUPLICATE_INVOKE_ID 0x00 +#define GSM_0480_INVOKE_PROB_CODE_UNRECOGNISED_OPERATION 0x01 +#define GSM_0480_INVOKE_PROB_CODE_MISTYPED_PARAMETER 0x02 +#define GSM_0480_INVOKE_PROB_CODE_RESOURCE_LIMITATION 0x03 +#define GSM_0480_INVOKE_PROB_CODE_INITIATING_RELEASE 0x04 +#define GSM_0480_INVOKE_PROB_CODE_UNRECOGNISED_LINKED_ID 0x05 +#define GSM_0480_INVOKE_PROB_CODE_UNEXPECTED_LINKED_RESPONSE 0x06 +#define GSM_0480_INVOKE_PROB_CODE_UNEXPECTED_LINKED_OPERATION 0x07 + +/* Table 3.16 */ +#define GSM_0480_RESULT_PROB_CODE_UNRECOGNISED_INVOKE_ID 0x00 +#define GSM_0480_RESULT_PROB_CODE_RETURN_RESULT_UNEXPECTED 0x01 +#define GSM_0480_RESULT_PROB_CODE_MISTYPED_PARAMETER 0x02 + +/* Table 3.17 */ +#define GSM_0480_ERROR_PROB_CODE_UNRECOGNISED_INVOKE_ID 0x00 +#define GSM_0480_ERROR_PROB_CODE_RETURN_ERROR_UNEXPECTED 0x01 +#define GSM_0480_ERROR_PROB_CODE_UNRECOGNISED_ERROR 0x02 +#define GSM_0480_ERROR_PROB_CODE_UNEXPECTED_ERROR 0x03 +#define GSM_0480_ERROR_PROB_CODE_MISTYPED_PARAMETER 0x04 + +/* Section 4.5 */ +#define GSM0480_OP_CODE_REGISTER_SS 0x0A +#define GSM0480_OP_CODE_ERASE_SS 0x0B +#define GSM0480_OP_CODE_ACTIVATE_SS 0x0C +#define GSM0480_OP_CODE_DEACTIVATE_SS 0x0D +#define GSM0480_OP_CODE_INTERROGATE_SS 0x0E +#define GSM0480_OP_CODE_NOTIFY_SS 0x10 +#define GSM0480_OP_CODE_REGISTER_PASSWORD 0x11 +#define GSM0480_OP_CODE_GET_PASSWORD 0x12 +#define GSM0480_OP_CODE_PROCESS_USS_DATA 0x13 +#define GSM0480_OP_CODE_FORWARD_CHECK_SS_IND 0x26 +#define GSM0480_OP_CODE_PROCESS_USS_REQ 0x3B +#define GSM0480_OP_CODE_USS_REQUEST 0x3C +#define GSM0480_OP_CODE_USS_NOTIFY 0x3D +#define GSM0480_OP_CODE_FORWARD_CUG_INFO 0x78 +#define GSM0480_OP_CODE_SPLIT_MPTY 0x79 +#define GSM0480_OP_CODE_RETRIEVE_MPTY 0x7A +#define GSM0480_OP_CODE_HOLD_MPTY 0x7B +#define GSM0480_OP_CODE_BUILD_MPTY 0x7C +#define GSM0480_OP_CODE_FORWARD_CHARGE_ADVICE 0x7D + +#define GSM0480_ERR_CODE_UNKNOWN_SUBSCRIBER 0x01 +#define GSM0480_ERR_CODE_ILLEGAL_SUBSCRIBER 0x09 +#define GSM0480_ERR_CODE_BEARER_SERVICE_NOT_PROVISIONED 0x0A +#define GSM0480_ERR_CODE_TELESERVICE_NOT_PROVISIONED 0x0B +#define GSM0480_ERR_CODE_ILLEGAL_EQUIPMENT 0x0C +#define GSM0480_ERR_CODE_CALL_BARRED 0x0D +#define GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION 0x10 +#define GSM0480_ERR_CODE_SS_ERROR_STATUS 0x11 +#define GSM0480_ERR_CODE_SS_NOT_AVAILABLE 0x12 +#define GSM0480_ERR_CODE_SS_SUBSCRIPTION_VIOLATION 0x13 +#define GSM0480_ERR_CODE_SS_INCOMPATIBILITY 0x14 +#define GSM0480_ERR_CODE_FACILITY_NOT_SUPPORTED 0x15 +#define GSM0480_ERR_CODE_ABSENT_SUBSCRIBER 0x1B +#define GSM0480_ERR_CODE_SYSTEM_FAILURE 0x22 +#define GSM0480_ERR_CODE_DATA_MISSING 0x23 +#define GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE 0x24 +#define GSM0480_ERR_CODE_PW_REGISTRATION_FAILURE 0x25 +#define GSM0480_ERR_CODE_NEGATIVE_PW_CHECK 0x26 +#define GSM0480_ERR_CODE_NUM_PW_ATTEMPTS_VIOLATION 0x2B +#define GSM0480_ERR_CODE_UNKNOWN_ALPHABET 0x47 +#define GSM0480_ERR_CODE_USSD_BUSY 0x48 +#define GSM0480_ERR_CODE_MAX_MPTY_PARTICIPANTS 0x7E +#define GSM0480_ERR_CODE_RESOURCES_NOT_AVAILABLE 0x7F + /* ASN.1 type-tags */ -#define ASN1_BOOLEAN_TAG 0x01 -#define ASN1_INTEGER_TAG 0x02 -#define ASN1_BIT_STRING_TAG 0x03 -#define ASN1_OCTET_STRING_TAG 0x04 -#define ASN1_NULL_TYPE_TAG 0x05 -#define ASN1_OBJECT_ID_TAG 0x06 -#define ASN1_UTF8_STRING_TAG 0x0C -#define ASN1_PRINTABLE_STRING_TAG 0x13 -#define ASN1_IA5_STRING_TAG 0x16 -#define ASN1_UNICODE_STRING_TAG 0x1E +#define ASN1_BOOLEAN_TAG 0x01 +#define ASN1_INTEGER_TAG 0x02 +#define ASN1_BIT_STRING_TAG 0x03 +#define ASN1_OCTET_STRING_TAG 0x04 +#define ASN1_NULL_TYPE_TAG 0x05 +#define ASN1_OBJECT_ID_TAG 0x06 +#define ASN1_UTF8_STRING_TAG 0x0C +#define ASN1_PRINTABLE_STRING_TAG 0x13 +#define ASN1_IA5_STRING_TAG 0x16 +#define ASN1_UNICODE_STRING_TAG 0x1E + +#include char* gsm0480_rcv_ussd(struct msgb *msg); int gsm0480_send_ussd_response(struct msgb *msg, const char* response_text); diff --git a/openbsc/include/openbsc/ussd.h b/openbsc/include/openbsc/ussd.h index dfd34f3..e7bd6d6 100755 --- a/openbsc/include/openbsc/ussd.h +++ b/openbsc/include/openbsc/ussd.h @@ -1,6 +1,8 @@ #ifndef _USSD_H #define _USSD_H +/* Handler function for mobile-originated USSD messages */ + #include int handle_rcv_ussd(struct msgb *msg); diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c index a6dffa8..d922ae5 100755 --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -3,6 +3,7 @@ /* (C) 2008-2009 by Harald Welte * (C) 2008, 2009 by Holger Hans Peter Freyther + * (C) 2009 by Mike Haben * * All Rights Reserved * @@ -36,112 +37,6 @@ #include #include -/* GSM TS 04.80 definitions (Supplementary Services specification, Formats and coding */ - -/* Section 3.4 */ -#define GSM0480_MTYPE_RELEASE_COMPLETE 0x2A -#define GSM0480_MTYPE_FACILITY 0x3A -#define GSM0480_MTYPE_REGISTER 0x3B - -/* Section 3.5 */ -#define GSM0480_IE_FACILITY 0x1C -#define GSM0480_IE_SS_VERSION 0x7F - -/* Section 3.6.2 */ -#define GSM0480_CTYPE_INVOKE 0xA1 -#define GSM0480_CTYPE_RETURN_RESULT 0xA2 -#define GSM0480_CTYPE_RETURN_ERROR 0xA3 -#define GSM0480_CTYPE_REJECT 0xA4 - -/* Section 3.6.3 */ -#define GSM0480_COMPIDTAG_INVOKE_ID 0x02 -#define GSM0480_COMPIDTAG_LINKED_ID 0x80 - -/* Section 3.6.4 */ -#define GSM0480_OPERATION_CODE 0x02 - -/* Section 3.6.6 */ -#define GSM_0480_ERROR_CODE_TAG 0x02 - -/* Section 3.6.7 */ -/* Table 3.13 */ -#define GSM_0480_PROBLEM_CODE_TAG_GENERAL 0x80 -#define GSM_0480_PROBLEM_CODE_TAG_INVOKE 0x81 -#define GSM_0480_PROBLEM_CODE_TAG_RETURN_RESULT 0x82 -#define GSM_0480_PROBLEM_CODE_TAG_RETURN_ERROR 0x83 - -/* Table 3.14 */ -#define GSM_0480_GEN_PROB_CODE_UNRECOGNISED 0x00 -#define GSM_0480_GEN_PROB_CODE_MISTYPED 0x01 -#define GSM_0480_GEN_PROB_CODE_BAD_STRUCTURE 0x02 - -/* Table 3.15 */ -#define GSM_0480_INVOKE_PROB_CODE_DUPLICATE_INVOKE_ID 0x00 -#define GSM_0480_INVOKE_PROB_CODE_UNRECOGNISED_OPERATION 0x01 -#define GSM_0480_INVOKE_PROB_CODE_MISTYPED_PARAMETER 0x02 -#define GSM_0480_INVOKE_PROB_CODE_RESOURCE_LIMITATION 0x03 -#define GSM_0480_INVOKE_PROB_CODE_INITIATING_RELEASE 0x04 -#define GSM_0480_INVOKE_PROB_CODE_UNRECOGNISED_LINKED_ID 0x05 -#define GSM_0480_INVOKE_PROB_CODE_UNEXPECTED_LINKED_RESPONSE 0x06 -#define GSM_0480_INVOKE_PROB_CODE_UNEXPECTED_LINKED_OPERATION 0x07 - -/* Table 3.16 */ -#define GSM_0480_RESULT_PROB_CODE_UNRECOGNISED_INVOKE_ID 0x00 -#define GSM_0480_RESULT_PROB_CODE_RETURN_RESULT_UNEXPECTED 0x01 -#define GSM_0480_RESULT_PROB_CODE_MISTYPED_PARAMETER 0x02 - -/* Table 3.17 */ -#define GSM_0480_ERROR_PROB_CODE_UNRECOGNISED_INVOKE_ID 0x00 -#define GSM_0480_ERROR_PROB_CODE_RETURN_ERROR_UNEXPECTED 0x01 -#define GSM_0480_ERROR_PROB_CODE_UNRECOGNISED_ERROR 0x02 -#define GSM_0480_ERROR_PROB_CODE_UNEXPECTED_ERROR 0x03 -#define GSM_0480_ERROR_PROB_CODE_MISTYPED_PARAMETER 0x04 - -/* Section 4.5 */ -#define GSM0480_OP_CODE_REGISTER_SS 0x0A -#define GSM0480_OP_CODE_ERASE_SS 0x0B -#define GSM0480_OP_CODE_ACTIVATE_SS 0x0C -#define GSM0480_OP_CODE_DEACTIVATE_SS 0x0D -#define GSM0480_OP_CODE_INTERROGATE_SS 0x0E -#define GSM0480_OP_CODE_NOTIFY_SS 0x10 -#define GSM0480_OP_CODE_REGISTER_PASSWORD 0x11 -#define GSM0480_OP_CODE_GET_PASSWORD 0x12 -#define GSM0480_OP_CODE_PROCESS_USS_DATA 0x13 -#define GSM0480_OP_CODE_FORWARD_CHECK_SS_IND 0x26 -#define GSM0480_OP_CODE_PROCESS_USS_REQ 0x3B -#define GSM0480_OP_CODE_USS_REQUEST 0x3C -#define GSM0480_OP_CODE_USS_NOTIFY 0x3D -#define GSM0480_OP_CODE_FORWARD_CUG_INFO 0x78 -#define GSM0480_OP_CODE_SPLIT_MPTY 0x79 -#define GSM0480_OP_CODE_RETRIEVE_MPTY 0x7A -#define GSM0480_OP_CODE_HOLD_MPTY 0x7B -#define GSM0480_OP_CODE_BUILD_MPTY 0x7C -#define GSM0480_OP_CODE_FORWARD_CHARGE_ADVICE 0x7D - -#define GSM0480_ERR_CODE_UNKNOWN_SUBSCRIBER 0x01 -#define GSM0480_ERR_CODE_ILLEGAL_SUBSCRIBER 0x09 -#define GSM0480_ERR_CODE_BEARER_SERVICE_NOT_PROVISIONED 0x0A -#define GSM0480_ERR_CODE_TELESERVICE_NOT_PROVISIONED 0x0B -#define GSM0480_ERR_CODE_ILLEGAL_EQUIPMENT 0x0C -#define GSM0480_ERR_CODE_CALL_BARRED 0x0D -#define GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION 0x10 -#define GSM0480_ERR_CODE_SS_ERROR_STATUS 0x11 -#define GSM0480_ERR_CODE_SS_NOT_AVAILABLE 0x12 -#define GSM0480_ERR_CODE_SS_SUBSCRIPTION_VIOLATION 0x13 -#define GSM0480_ERR_CODE_SS_INCOMPATIBILITY 0x14 -#define GSM0480_ERR_CODE_FACILITY_NOT_SUPPORTED 0x15 -#define GSM0480_ERR_CODE_ABSENT_SUBSCRIBER 0x1B -#define GSM0480_ERR_CODE_SYSTEM_FAILURE 0x22 -#define GSM0480_ERR_CODE_DATA_MISSING 0x23 -#define GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE 0x24 -#define GSM0480_ERR_CODE_PW_REGISTRATION_FAILURE 0x25 -#define GSM0480_ERR_CODE_NEGATIVE_PW_CHECK 0x26 -#define GSM0480_ERR_CODE_NUM_PW_ATTEMPTS_VIOLATION 0x2B -#define GSM0480_ERR_CODE_UNKNOWN_ALPHABET 0x47 -#define GSM0480_ERR_CODE_USSD_BUSY 0x48 -#define GSM0480_ERR_CODE_MAX_MPTY_PARTICIPANTS 0x7E -#define GSM0480_ERR_CODE_RESOURCES_NOT_AVAILABLE 0x7F - static char ussd_string_buff[32]; static u_int8_t last_transaction_id; static u_int8_t last_invoke_id; @@ -153,23 +48,40 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length); static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length); static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length); +static inline unsigned char *msgb_wrap_with_TL(struct msgb *msgb, u_int8_t tag) +{ + msgb->data -= 2; + msgb->data[0] = tag; + msgb->data[1] = msgb->len; + msgb->len += 2; + return msgb->data; +} + +static inline unsigned char *msgb_push_TLV1(struct msgb *msgb, u_int8_t tag, u_int8_t value) +{ + msgb->data -= 3; + msgb->len += 3; + msgb->data[0] = tag; + msgb->data[1] = 1; + msgb->data[2] = value; + return msgb->data; +} + + /* Receive a mobile-originated USSD message and return the decoded text */ char* gsm0480_rcv_ussd(struct msgb *msg) { int rc = 0; u_int8_t* parse_ptr = msgb_l3(msg); -// DEBUGP(DMM, "USSD %s\n", hexdump(msg->data, msg->len)); // temporary, just see what we're receiving... - memset(ussd_string_buff, 0, sizeof(ussd_string_buff)); - if((*parse_ptr & 0x0F) == GSM48_PDISC_NC_SS) - { - last_transaction_id = *parse_ptr & 0xF0; + if ((*parse_ptr & 0x0F) == GSM48_PDISC_NC_SS) { + last_transaction_id = *parse_ptr & 0x70; rc = parse_ussd(parse_ptr + 1); } - if(!rc) + if (!rc) DEBUGP(DMM, "Error occurred while parsing received USSD!\n"); return ussd_string_buff; @@ -228,8 +140,7 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) int rc = 1; u_int8_t offset = 0; - do - { + do { u_int8_t component_type = facility_ie[offset]; // Component Type tag - table 3.7 u_int8_t component_length = facility_ie[offset+1]; switch(component_type) { @@ -248,10 +159,8 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) rc = 0; break; } - offset += (component_length+2); - } - while(offset < length); + } while(offset < length); return rc; } @@ -261,19 +170,17 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) { int rc = 1; - if(invoke_data[0] != GSM0480_COMPIDTAG_INVOKE_ID) // mandatory part - { + if (invoke_data[0] != GSM0480_COMPIDTAG_INVOKE_ID) { /* mandatory part */ fprintf(stderr, "Unexpected GSM 04.80 Component-ID tag 0x%02x (expecting Invoke ID tag)\n", invoke_data[0]); } u_int8_t offset = invoke_data[1] + 2; last_invoke_id = invoke_data[2]; - if(invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) // optional part + if (invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) /* optional part */ offset += invoke_data[offset+1] + 2; // skip over it - if(invoke_data[offset] == GSM0480_OPERATION_CODE) // mandatory part - { + if (invoke_data[offset] == GSM0480_OPERATION_CODE) { /* mandatory part */ u_int8_t operation_code = invoke_data[offset+2]; switch(operation_code) { case GSM0480_OP_CODE_PROCESS_USS_REQ: @@ -285,11 +192,9 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) rc = 0; break; } - } - else - { + } else { fprintf(stderr, "Unexpected GSM 04.80 Component-ID tag 0x%02x (expecting Operation Code tag)\n", - invoke_data[0]); + invoke_data[0]); rc = 0; } @@ -306,21 +211,16 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) // DEBUGP(DMM, "USSD request params %s\n", hexdump(uss_req_data, length)); /* FIXME: most phones send USSD text as a 7-bit encoded octet string; the following code also handles the case of plain ASCII text (IA5String), but other encodings might be used */ - if(uss_req_data[0] == GSM_0480_SEQUENCE_TAG) - { - if(uss_req_data[2] == ASN1_OCTET_STRING_TAG) - { + if (uss_req_data[0] == GSM_0480_SEQUENCE_TAG) { + if (uss_req_data[2] == ASN1_OCTET_STRING_TAG) { dcs = uss_req_data[4]; // DEBUGP(DMM, "Data coding scheme = 0x%2.2X\n", dcs); - if((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) - { + if ((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) { num_chars = (uss_req_data[6] * 8) / 7; gsm_7bit_decode(ussd_string_buff, &(uss_req_data[7]), num_chars); } } - } - else if(uss_req_data[0] == ASN1_IA5_STRING_TAG) - { + } else if (uss_req_data[0] == ASN1_IA5_STRING_TAG) { num_chars = uss_req_data[1]; memcpy(ussd_string_buff, &(uss_req_data[2]), num_chars); } @@ -340,30 +240,32 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) msg->bts_link = in_msg->bts_link; msg->lchan = in_msg->lchan; - gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); - gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | 0x80; // TI direction = 1 - gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; - - ptr8 = msgb_put(msg, 14); - ptr8[0] = GSM0480_IE_FACILITY; - ptr8[1] = response_len + 12; - ptr8[2] = GSM0480_CTYPE_RETURN_RESULT; - ptr8[3] = response_len + 10; - ptr8[4] = GSM0480_COMPIDTAG_INVOKE_ID; - ptr8[5] = 1; - ptr8[6] = last_invoke_id; - ptr8[7] = GSM_0480_SEQUENCE_TAG; - ptr8[8] = response_len + 5; - ptr8[9] = GSM0480_OPERATION_CODE; - ptr8[10] = 1; - ptr8[11] = GSM0480_OP_CODE_PROCESS_USS_DATA; - ptr8[12] = ASN1_IA5_STRING_TAG; - ptr8[13] = response_len; - + /* First put the payload text into the message */ ptr8 = msgb_put(msg, response_len); memcpy(ptr8, response_text, response_len); -// DEBUGP(DMM, "USSD response %s\n", hexdump(msg->data, msg->len)); // temporary, just to see what we're sending back + /* Then wrap it as an IA5 String */ + msgb_wrap_with_TL(msg, ASN1_IA5_STRING_TAG); + + /* Pre-pend the operation code */ + msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_DATA); + + /* Wrap the operation code and IA5 string as a sequence */ + msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); + + /* Pre-pend the invoke ID */ + msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, last_invoke_id); + + /* Wrap this up as a Return Result component */ + msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); + + /* Wrap the component in a Facility message */ + msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY); + + /* And finally pre-pend the L3 header */ + gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh)); + gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | (1<<7); /* TI direction = 1 */ + gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; return gsm48_sendmsg(msg, NULL); } @@ -372,28 +274,26 @@ int gsm0480_send_ussd_reject(struct msgb *in_msg) { struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - u_int8_t *ptr8; msg->bts_link = in_msg->bts_link; msg->lchan = in_msg->lchan; - gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); - gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | 0x80; // TI direction = 1 - gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; + /* First insert the problem code */ + msgb_push_TLV1(msg, GSM_0480_PROBLEM_CODE_TAG_GENERAL, GSM_0480_GEN_PROB_CODE_UNRECOGNISED); + + /* Before it insert the invoke ID */ + msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, last_invoke_id); - ptr8 = msgb_put(msg, 10); - ptr8[0] = GSM0480_IE_FACILITY; - ptr8[1] = 8; - ptr8[2] = GSM0480_CTYPE_REJECT; - ptr8[3] = 6; - ptr8[4] = GSM0480_COMPIDTAG_INVOKE_ID; - ptr8[5] = 1; - ptr8[6] = last_invoke_id; - ptr8[7] = GSM_0480_PROBLEM_CODE_TAG_GENERAL; - ptr8[8] = 1; - ptr8[9] = GSM_0480_GEN_PROB_CODE_UNRECOGNISED; - -// DEBUGP(DMM, "USSD reject %s\n", hexdump(msg->data, msg->len)); // temporary, just to see what we're sending back + /* Wrap this up as a Reject component */ + msgb_wrap_with_TL(msg, GSM0480_CTYPE_REJECT); + + /* Wrap the component in a Facility message */ + msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY); + + /* And finally pre-pend the L3 header */ + gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh)); + gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | (1<<7); /* TI direction = 1 */ + gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; return gsm48_sendmsg(msg, NULL); } diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c index 761a0e7..ba2f045 100755 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -2,6 +2,7 @@ /* (C) 2008-2009 by Harald Welte * (C) 2008, 2009 by Holger Hans Peter Freyther + * (C) 2009 by Mike Haben * * All Rights Reserved * @@ -21,6 +22,7 @@ * */ +/* This module defines the network-specific handling of mobile-originated USSD messages. */ #include #include @@ -31,10 +33,14 @@ #include #include +/* Declarations of USSD strings to be recognised */ const char USSD_TEXT_OWN_NUMBER[] = "*#100#"; +/* Forward declarations of network-specific handler functions */ static int send_own_number(struct msgb *msg); + +/* Entrypoint - handler function common to all mobile-originated USSDs */ int handle_rcv_ussd(struct msgb *msg) { char* ussd_text_rcvd = gsm0480_rcv_ussd(msg); @@ -42,20 +48,16 @@ int handle_rcv_ussd(struct msgb *msg) if(ussd_text_rcvd[0] == 0xFF) // Release-Complete return 0; - DEBUGP(DMM, "Received USSD text %s\n", ussd_text_rcvd); // show text payload entered on MS - - if(strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) - { + if(strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) { DEBUGP(DMM, "USSD: Own number requested\n"); return send_own_number(msg); - } - else - { + } else { DEBUGP(DMM, "Unhandled USSD %s\n", ussd_text_rcvd); return gsm0480_send_ussd_reject(msg); } } +/* A network-specific handler function */ static int send_own_number(struct msgb *msg) { char response_string[] = "Your extension is xxxxx"; -- 1.6.0.4 --------------090900090905050500050904-- From zecke at selfish.org Wed Oct 7 08:38:04 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 7 Oct 2009 10:38:04 +0200 Subject: RFC: Establishing logging standards Message-ID: <200910071038.05122.zecke@selfish.org> Hey, I think in the next days I will go around the sourcecode and change a couple of logging messages. My two primary goals are increase the usefulness to figure out what was going wrong and the second to be able to put some of these into the syslog. Should we use DEBUG* to also log to syslog or introduce a new set of macros? Log Levels: I think Harald has expressed the wish to introduce log levels. Should we follow the log levels of syslog(3)? Messages: I would like to collect formats for various actions. Currently I'm thinking of the following but would like to have more input. subscriber: When talking about a subscriber use TMSI, IMSI and Extension. lchan: Include refcount, channel type, link_id, subscriber sccp: Talk about SCCP source local reference and pointer transaction: Print the transaction? gsm0408: Print the lchan which prints the subscriber? comments? holger From laforge at gnumonks.org Wed Oct 7 14:56:47 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 16:56:47 +0200 Subject: RFC: Establishing logging standards In-Reply-To: <200910071038.05122.zecke@selfish.org> References: <200910071038.05122.zecke@selfish.org> Message-ID: <20091007145647.GO25086@prithivi.gnumonks.org> Hi Zecke, On Wed, Oct 07, 2009 at 10:38:04AM +0200, Holger Freyther wrote: > I think in the next days I will go around the sourcecode and change a couple > of logging messages. My two primary goals are increase the usefulness to figure > out what was going wrong and the second to be able to put some of these into > the syslog. Thanks for addressing this. I always wanted to get around to do it, but didn't find time so far. > Should we use DEBUG* to also log to syslog or introduce a new set of macros? I think it would be best to introduce a new logging macro, and turn DEBUGP into a backwards compatibility macro that then calls/uses the new logging macro to print a DEBUG level message There is some code for log file handling in ulogd (http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2), see ulogd_log() and __ulog_log() in ulogd.h as well as __ulogd_log() in ulogd.c. It already handles logging to a runtime choice of either syslog or a dedicated text file. This is a feature that I'd like to see in openbsc, too. In addition to that, we should support enabling of certain log levels and log 'groups' (like syslog facility, but more fine grained) to print to the telnet interface. So from the telnet interface, I want to be able to use vty commands to do things like * enable "WARNING" level messages on this telnet vty for all groups (MM, CC, ...) * enable "DEBUG" level messages on this telnet vty for one specific group (SMS) * change the log level and log groups for the logfile > Log Levels: > > I think Harald has expressed the wish to introduce log levels. Should we > follow the log levels of syslog(3)? yes. > I would like to collect formats for various actions. Currently I'm thinking of > the following but would like to have more input. all of those, plus abis_nm needs formats for * object class and object instance * nm_state since we probably need more and more of these, it might be interesting to think of adding a new format character instead of %... % is already heavily used especially in glibc.g Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Wed Oct 7 15:18:41 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 7 Oct 2009 17:18:41 +0200 Subject: RFC: Establishing logging standards In-Reply-To: <20091007145647.GO25086@prithivi.gnumonks.org> References: <200910071038.05122.zecke@selfish.org> <20091007145647.GO25086@prithivi.gnumonks.org> Message-ID: <200910071718.41795.zecke@selfish.org> On Wednesday 07 October 2009 16:56:47 Harald Welte wrote: > Hi Zecke, > > since we probably need more and more of these, it might be interesting to > think of adding a new format character instead of %... % is already > heavily used especially in glibc.g Do we mind GNUism? If not we could register special handlers for lchan, subscriber and such. holger From laforge at gnumonks.org Wed Oct 7 15:36:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Oct 2009 17:36:39 +0200 Subject: RFC: Establishing logging standards In-Reply-To: <200910071718.41795.zecke@selfish.org> References: <200910071038.05122.zecke@selfish.org> <20091007145647.GO25086@prithivi.gnumonks.org> <200910071718.41795.zecke@selfish.org> Message-ID: <20091007153639.GR25086@prithivi.gnumonks.org> On Wed, Oct 07, 2009 at 05:18:41PM +0200, Holger Freyther wrote: > > > since we probably need more and more of these, it might be interesting to > > think of adding a new format character instead of %... % is already > > heavily used especially in glibc.g > > Do we mind GNUism? If not we could register special handlers for lchan, > subscriber and such. I think we can make the assumption that we need gcc for compilation, but we should not introduce arbitrary dependencies on things like the libc we're using (which would make it impossible to build on BSD, windows, solaris or macos, I guess). Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zero-kelvin at gmx.de Wed Oct 7 18:22:00 2009 From: zero-kelvin at gmx.de (dexter) Date: Wed, 07 Oct 2009 20:22:00 +0200 Subject: BS11 does not work, but everything looks normal. Message-ID: <4ACCDC48.20505@gmx.de> Hi folks. I can't get my setup working. Everything works, the BS11 boots up well, openBSC loads well. At the software side, everything looks perfect. But the setup does not work. I have testet my BSC now with 3 different BS11. One of the BS11 is brandnew (Has been set in standalone directly after installing the firmware.)! I found this and i think that this is an explaination of the problem: http://lists.gnumonks.org/pipermail/openbsc/2009-August/000783.html Finally my question is if anone of you ever observed a semilar effect. regards. Philipp From laforge at gnumonks.org Thu Oct 8 08:04:07 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Oct 2009 10:04:07 +0200 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <4ACCDC48.20505@gmx.de> References: <4ACCDC48.20505@gmx.de> Message-ID: <20091008080407.GI25086@prithivi.gnumonks.org> Hi Dexter, On Wed, Oct 07, 2009 at 08:22:00PM +0200, dexter wrote: > I can't get my setup working. Everything works, the BS11 boots up > well, openBSC loads well. At the software side, everything looks > perfect. > > But the setup does not work. I have testet my BSC now with 3 > different BS11. One of the BS11 is brandnew (Has been set in > standalone directly after installing the firmware.)! With what result? All three BS-11 do not work? > I found this and i think that this is an explaination of the problem: > http://lists.gnumonks.org/pipermail/openbsc/2009-August/000783.html Sergey, can you comment on this? What solved your propblem? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From risky at mail.ru Thu Oct 8 11:31:07 2009 From: risky at mail.ru (Sergey V. Efimoff) Date: Thu, 8 Oct 2009 15:31:07 +0400 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <20091008080407.GI25086@prithivi.gnumonks.org> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> Message-ID: Hmm, in my case the solution consisted of 3 steps: 1. Full BS-11 firmware re-flash. 2. Accurate calibration of internal oscillator. 3. Update of mISDN stack to the latest version. On Oct 8, 2009, at 12:04 PM, Harald Welte wrote: > Hi Dexter, > > On Wed, Oct 07, 2009 at 08:22:00PM +0200, dexter wrote: > >> I can't get my setup working. Everything works, the BS11 boots up >> well, openBSC loads well. At the software side, everything looks >> perfect. >> >> But the setup does not work. I have testet my BSC now with 3 >> different BS11. One of the BS11 is brandnew (Has been set in >> standalone directly after installing the firmware.)! > > With what result? All three BS-11 do not work? > >> I found this and i think that this is an explaination of the problem: >> http://lists.gnumonks.org/pipermail/openbsc/2009-August/000783.html > > Sergey, can you comment on this? What solved your propblem? > > -- > - Harald Welte http://laforge.gnumonks.org/ > = > = > = > = > = > = > ====================================================================== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 > Ch. A6) > From mailinglists at hellercom.de Thu Oct 8 11:37:17 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 8 Oct 2009 13:37:17 +0200 Subject: BS11 does not work, but everything looks normal. In-Reply-To: References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> Message-ID: <62F5E5D2-DCEB-4007-902F-79FEBF301103@hellercom.de> Thats really the way to go! Works. Had the same problem. Best Regards Bj?rn Heller Am 08.10.2009 um 13:31 schrieb "Sergey V. Efimoff" : > Hmm, in my case the solution consisted of 3 steps: > > 1. Full BS-11 firmware re-flash. > 2. Accurate calibration of internal oscillator. > 3. Update of mISDN stack to the latest version. > > On Oct 8, 2009, at 12:04 PM, Harald Welte wrote: > >> Hi Dexter, >> >> On Wed, Oct 07, 2009 at 08:22:00PM +0200, dexter wrote: >> >>> I can't get my setup working. Everything works, the BS11 boots up >>> well, openBSC loads well. At the software side, everything looks >>> perfect. >>> >>> But the setup does not work. I have testet my BSC now with 3 >>> different BS11. One of the BS11 is brandnew (Has been set in >>> standalone directly after installing the firmware.)! >> >> With what result? All three BS-11 do not work? >> >>> I found this and i think that this is an explaination of the >>> problem: >>> http://lists.gnumonks.org/pipermail/openbsc/2009-August/000783.html >> >> Sergey, can you comment on this? What solved your propblem? >> >> -- - Harald Welte http://laforge.gnumonks.org/ >> = >> = >> = >> = >> = >> = >> === >> =================================================================== >> "Privacy in residential applications is a desirable marketing >> option." >> (ETSI EN 300 175-7 >> Ch. A6) >> > > From squ at tent.at Thu Oct 8 12:05:02 2009 From: squ at tent.at (Kai =?iso-8859-1?Q?M=FCnz?=) Date: Thu, 8 Oct 2009 14:05:02 +0200 (CEST) Subject: BS11 does not work, but everything looks normal. In-Reply-To: References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> Message-ID: <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> How can i reflash the firmware of the BS-11? Mine sometimes "scrambles" the audio signal which seems to be a software bug in my BS-11? > Hmm, in my case the solution consisted of 3 steps: > > 1. Full BS-11 firmware re-flash. > 2. Accurate calibration of internal oscillator. > 3. Update of mISDN stack to the latest version. From risky at mail.ru Thu Oct 8 14:47:28 2009 From: risky at mail.ru (Sergey V. Efimoff) Date: Thu, 8 Oct 2009 18:47:28 +0400 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> Message-ID: <2B0E6B35-65E1-454D-9584-9C58285346B4@mail.ru> See http://openbsc.gnumonks.org/trac/wiki/bs11_config Though have not seen any audio problems on BS-11. On Oct 8, 2009, at 4:05 PM, Kai M?nz wrote: > How can i reflash the firmware of the BS-11? Mine sometimes > "scrambles" > the audio signal which seems to be a software bug in my BS-11? > >> Hmm, in my case the solution consisted of 3 steps: >> >> 1. Full BS-11 firmware re-flash. >> 2. Accurate calibration of internal oscillator. >> 3. Update of mISDN stack to the latest version. > > From squ at tent.at Thu Oct 8 15:24:32 2009 From: squ at tent.at (=?ISO-8859-1?Q?Kai_M=FCnz?=) Date: Thu, 08 Oct 2009 17:24:32 +0200 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <2B0E6B35-65E1-454D-9584-9C58285346B4@mail.ru> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> <2B0E6B35-65E1-454D-9584-9C58285346B4@mail.ru> Message-ID: <4ACE0430.5070002@tent.at> Actually I'm missing the firmware files. Could anyone give me a hint where I can find them? Regards, Kai Sergey V. Efimoff wrote: > See http://openbsc.gnumonks.org/trac/wiki/bs11_config > > Though have not seen any audio problems on BS-11. > > On Oct 8, 2009, at 4:05 PM, Kai M?nz wrote: > >> How can i reflash the firmware of the BS-11? Mine sometimes "scrambles" >> the audio signal which seems to be a software bug in my BS-11? >> >>> Hmm, in my case the solution consisted of 3 steps: >>> >>> 1. Full BS-11 firmware re-flash. >>> 2. Accurate calibration of internal oscillator. >>> 3. Update of mISDN stack to the latest version. From laforge at gnumonks.org Thu Oct 8 15:41:24 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Oct 2009 17:41:24 +0200 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> Message-ID: <20091008154124.GI26619@prithivi.gnumonks.org> On Thu, Oct 08, 2009 at 02:05:02PM +0200, Kai M?nz wrote: > How can i reflash the firmware of the BS-11? Mine sometimes "scrambles" > the audio signal which seems to be a software bug in my BS-11? i doubt that it is the BTS, and even if it was, I doubt that it was some erroneously flashed software... maybe you can give a more detailed report when the problem occurs and in which particular setup. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From philipp.maier at runningserver.com Fri Oct 9 09:10:38 2009 From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier) Date: Fri, 09 Oct 2009 11:10:38 +0200 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <20091008154124.GI26619@prithivi.gnumonks.org> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> <20091008154124.GI26619@prithivi.gnumonks.org> Message-ID: <4ACEFE0E.10902@runningserver.com> Hi Folks. Thank you for your replies. Now I know I am not alone with that Problem. I will build a vanilla 2.6.31 - that should contain the latest mISDN drivers. I hope that will fix it. From one BS11 i definitly know that it is out of sync. This problem will be fixed with a rubidium frequency source soon. (I will write down a howto when i done it successfull). I will keep you posted. regards. Philipp From zero-kelvin at gmx.de Fri Oct 9 14:46:29 2009 From: zero-kelvin at gmx.de (dexter) Date: Fri, 09 Oct 2009 16:46:29 +0200 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <20091008154124.GI26619@prithivi.gnumonks.org> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> <20091008154124.GI26619@prithivi.gnumonks.org> Message-ID: <4ACF4CC5.4080202@gmx.de> Hi to all. I successfully installed 2.6.31 and the problem seems to be solved. I left a note in at Troublesooting [1] in the Wiki. [1] http://bs11-abis.gnumonks.org/trac/wiki/BS11_Troubleshooting Thank you very much! regards. Philipp From Andreas.Eversberg at versatel.de Thu Oct 8 05:55:37 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 8 Oct 2009 07:55:37 +0200 Subject: No subject Message-ID: hi, i am no shure if i already sent this mail, but i can't find it anywhere. this fixes the delay of audio caused by stalling of the openbsc process. the use of 'usleep(100000)' for slowing down transmission to nanoBTS is replaced by the tx-delay timer. i did this on bs11 code, so i did it the same way. it actually queues frames for transmission not nanoBTS. on transmission a timer is started and when this timer expires, the next frame in the queue is transmitted (timer restarted) until the queue is empty. regards andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: txdelay.patch Type: application/octet-stream Size: 1863 bytes Desc: txdelay.patch URL: From laforge at gnumonks.org Thu Oct 8 10:54:30 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Oct 2009 12:54:30 +0200 Subject: tx timer instead of usleep in ip.access input plugin In-Reply-To: References: Message-ID: <20091008105430.GC26619@prithivi.gnumonks.org> On Thu, Oct 08, 2009 at 07:55:37AM +0200, Andreas.Eversberg wrote: > hi, > > i am no shure if i already sent this mail, but i can't find it anywhere. thanks, I have applied your patch to the git tree. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Oct 8 17:25:27 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Oct 2009 19:25:27 +0200 Subject: nanoBTS Multi-TRX configuration? Message-ID: <20091008172527.GL26619@prithivi.gnumonks.org> Hi! Does anyone on this list have experience with nanoBTS Multi-TRX configurations? I've built a TIB cable (10pin RJ69 to 10pin, 1:1 wiring, i.e. pin1 is pin1 on the other plug, pin2 is pin 2, etc.) and connected the two BTS. When I power them up simultaneously, they still come up as two individual BTS with each their own unit ID. I've tried to set the unit ID to something like 1801/0/0 on the first one, and 1801/1/0 on the second. However, any non-zero TRX ID of the unit ID is rejected by the BTS. Any hint how I can make them behave like one BTS with two TRX is appreciated. I'm expecting only one OML Link but of course two RSL links (one for each TRX). Thanks in advance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Oct 9 14:15:34 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Oct 2009 16:15:34 +0200 Subject: official ip.access wireshark Abis/IP dissector Message-ID: <20091009141534.GH17611@prithivi.gnumonks.org> Hi! Quite some time ago (must be 2-3 months ago), I have officially inquired at ip.access about the source code of their wireshark modifications, as per the GNU GPL. It took them some time, but they eventually responded recently. Today I finally received a CD-ROM with the source code. I've uploaded it to the OpenBSC wiki, and it is now available from http://openbsc.gnumonks.org/trac/attachment/wiki/nanoBTS/wireshark-1.0.6ipa27.tar.gz Had I known earlier that ip.access has actually written a GPL licensed dissector, many hours (rather days/weeks) of reverse engineering time would have been saved. I have not yet had time to review it thoroughly, though I plan to merge/port the interesting bits of it with my dissectors for A-bis OML and ip.access RSL extensions and eventually submit it to wireshark mainline. If you use this source code, please don't just simply take it and push it to upstream wireshark, as that would conflict with the patches that we have in openbsc git at the moment. Have fun with it, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Oct 13 08:52:23 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Oct 2009 10:52:23 +0200 Subject: [ANNOUNCE] Report on OpenBSC powered GSM network at HAR2009 Message-ID: <20091013085223.GA3664@prithivi.gnumonks.org> Hi! I finally finished the report from the GSM test network that we operated at HAR2009 using OpenBSC and two BS-11. The report is available for download from http://openbsc.gnumonks.org/trac/attachment/wiki/HAR2009/har2009-gsm-report.pdf Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From 246tnt at gmail.com Tue Oct 13 11:57:47 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 13 Oct 2009 13:57:47 +0200 Subject: [Openbts-discuss] [Fwd: [FOSDEM] News : Call For Participation] In-Reply-To: <866320f70910121138n16a5a908y1df73220a326fcae@mail.gmail.com> References: <4AD3655C.5030709@gmail.com> <866320f70910121138n16a5a908y1df73220a326fcae@mail.gmail.com> Message-ID: <866320f70910130457n4703fec4h62baed3d0892fdf1@mail.gmail.com> For info: Ok, I called the IBPT and I got the procedure to follow to request frequencies. The 900 MHz is entirely allocated to commercial operators but in the 1800 spectrum there are possibilities to get experimental licenses for a small fee so I'm filling up the paper work ASAP. For OpenBTS to work in the 1800 band we may need more stable clock source (which I don't have yet). For OpenBSC, I have a 1800 nanoBTS. Sylvain On Mon, Oct 12, 2009 at 8:38 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > On Mon, Oct 12, 2009 at 7:20 PM, Michel Daggelinckx <03taxi at gmail.com> wrote: >> >> >> FOSDEM [1], the most developer-oriented Free and Opensource conference in >> Europe, is taking place in Brussels, Belgium [2] on *Saturday 6 and Sunday 7 >> February 2010*. Apart from having many invited speakers, the conference >> offers developer rooms, stands and lightning talks to projects from the Free >> and Opensource community. This results in a staggering number of 250+ >> lectures! >> >> We hereby welcome proposals from speakers and projects to talk in a main >> track, man a stand, or hold a lightning talk. /Information on developer >> rooms >> will become available later, as we are slightly reworking the concept/. > > In relation to that, I'm trying to get an experimental license from the IBPT to > operate on the GSM spectrum during the conference. I didn't find much in the > legislation about this kind of licence in Belgium, but I must call > back the guy tomorrow ... > > I didn't take any contact with the fosdem yet to have a spot or > anything, I wanted to > hear back from the ibpt first. > > If other people are motivated, there is definitely something to do there. > I have equipment to run both OpenBTS and OpenBSC and I'm located in Belgium, > so I'll definitely be there. > > > ? ?Sylvain > From dburgess at jcis.net Tue Oct 13 16:45:11 2009 From: dburgess at jcis.net (David A. Burgess) Date: Tue, 13 Oct 2009 09:45:11 -0700 Subject: [Openbts-discuss] [Fwd: [FOSDEM] News : Call For Participation] In-Reply-To: <866320f70910130457n4703fec4h62baed3d0892fdf1@mail.gmail.com> References: <4AD3655C.5030709@gmail.com> <866320f70910121138n16a5a908y1df73220a326fcae@mail.gmail.com> <866320f70910130457n4703fec4h62baed3d0892fdf1@mail.gmail.com> Message-ID: <8B05188F-8D22-488C-ABE1-BB8B408FA5C2@jcis.net> You will most definitely need an improved clock to operate in the 1800 band. On Oct 13, 2009, at 4:57 AM, Sylvain Munaut wrote: > For info: > > Ok, I called the IBPT and I got the procedure to follow to request > frequencies. > > The 900 MHz is entirely allocated to commercial operators but in the > 1800 spectrum there are possibilities to get experimental licenses for > a small fee so I'm filling up the paper work ASAP. > > For OpenBTS to work in the 1800 band we may need more stable clock > source (which I don't have yet). > For OpenBSC, I have a 1800 nanoBTS. > > Sylvain > David A. Burgess Kestrel Signal Processing, Inc. From jl at thre.at Tue Oct 13 20:16:24 2009 From: jl at thre.at (Joshua Lackey) Date: Tue, 13 Oct 2009 16:16:24 -0400 Subject: [Openbts-discuss] [Fwd: [FOSDEM] News : Call For Participation] In-Reply-To: <8B05188F-8D22-488C-ABE1-BB8B408FA5C2@jcis.net> References: <4AD3655C.5030709@gmail.com> <866320f70910121138n16a5a908y1df73220a326fcae@mail.gmail.com> <866320f70910130457n4703fec4h62baed3d0892fdf1@mail.gmail.com> <8B05188F-8D22-488C-ABE1-BB8B408FA5C2@jcis.net> Message-ID: <20091013201624.GA69914@thre.at> Sylvain -- try the FA-SY 1. It's cheap and fairly easy to install. (It's not something that you could calibrate and leave on a tower for any length of time though. It is strictly an "experimental" type clock.) Quoting David A. Burgess (dburgess at jcis.net): > > You will most definitely need an improved clock to operate in the > 1800 band. > > On Oct 13, 2009, at 4:57 AM, Sylvain Munaut wrote: > > > For info: > > > > Ok, I called the IBPT and I got the procedure to follow to request > > frequencies. > > > > The 900 MHz is entirely allocated to commercial operators but in the > > 1800 spectrum there are possibilities to get experimental licenses for > > a small fee so I'm filling up the paper work ASAP. > > > > For OpenBTS to work in the 1800 band we may need more stable clock > > source (which I don't have yet). > > For OpenBSC, I have a 1800 nanoBTS. > > > > Sylvain > > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Openbts-discuss mailing list > Openbts-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbts-discuss From michael.haben at btinternet.com Tue Oct 13 16:26:32 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Tue, 13 Oct 2009 17:26:32 +0100 Subject: Mobile-originated USSD - corrected, now works 100% Message-ID: <4AD4AA38.8010705@btinternet.com> (Hopefully) last patch attached - now sends the correct op-code in response, works with all 6 phones I have tried. Interesting that 5 out of 6 were happy with a completely different op-code and payload... Mike H. From michael.haben at btinternet.com Tue Oct 13 16:28:19 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Tue, 13 Oct 2009 17:28:19 +0100 Subject: Mobile-originated USSD - double D'oh! In-Reply-To: <4AD4AA38.8010705@btinternet.com> References: <4AD4AA38.8010705@btinternet.com> Message-ID: <4AD4AAA3.6090902@btinternet.com> It's been a long day... Mike Haben wrote: > (Hopefully) last patch attached - now sends the correct op-code in > response, works with all 6 phones I have tried. Interesting that 5 > out of 6 were happy with a completely different op-code and payload... > > Mike H. > > From michael.haben at btinternet.com Tue Oct 13 16:20:19 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Tue, 13 Oct 2009 17:20:19 +0100 Subject: [PATCH] Corrected response to mobile-originated USSD ProcessUnstructuredSS Request - return same op code Signed-off-by: Mike Haben Message-ID: --- openbsc/src/gsm_04_80.c | 31 +++++++++++++++++++------------ openbsc/src/ussd.c | 4 ++-- 2 files changed, 21 insertions(+), 14 deletions(-) diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c index d922ae5..d0dcbc2 100755 --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -90,11 +90,11 @@ char* gsm0480_rcv_ussd(struct msgb *msg) static int parse_ussd(u_int8_t *ussd) { int rc = 1; - u_int8_t msg_type = ussd[0] & 0xBF; // message-type - section 3.4 + u_int8_t msg_type = ussd[0] & 0xBF; /* message-type - section 3.4 */ switch(msg_type) { case GSM0480_MTYPE_RELEASE_COMPLETE: - DEBUGP(DMM, "USS Release Complete\n"); // could also parse out the optional Cause/Facility data + DEBUGP(DMM, "USS Release Complete\n"); /* could also parse out the optional Cause/Facility data */ ussd_string_buff[0] = 0xFF; break; case GSM0480_MTYPE_REGISTER: @@ -115,7 +115,7 @@ static int parse_ussd_information_elements(u_int8_t *ussd_ie) { int rc; - u_int8_t iei = ussd_ie[0]; // Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 + u_int8_t iei = ussd_ie[0]; /* Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 */ u_int8_t iei_length = ussd_ie[1]; switch(iei) { case GSM48_IE_CAUSE: @@ -141,7 +141,7 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) u_int8_t offset = 0; do { - u_int8_t component_type = facility_ie[offset]; // Component Type tag - table 3.7 + u_int8_t component_type = facility_ie[offset]; /* Component Type tag - table 3.7 */ u_int8_t component_length = facility_ie[offset+1]; switch(component_type) { case GSM0480_CTYPE_INVOKE: @@ -178,7 +178,7 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) last_invoke_id = invoke_data[2]; if (invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) /* optional part */ - offset += invoke_data[offset+1] + 2; // skip over it + offset += invoke_data[offset+1] + 2; /* skip over it */ if (invoke_data[offset] == GSM0480_OPERATION_CODE) { /* mandatory part */ u_int8_t operation_code = invoke_data[offset+2]; @@ -208,13 +208,11 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) int num_chars; u_int8_t dcs; -// DEBUGP(DMM, "USSD request params %s\n", hexdump(uss_req_data, length)); /* FIXME: most phones send USSD text as a 7-bit encoded octet string; the following code also handles the case of plain ASCII text (IA5String), but other encodings might be used */ if (uss_req_data[0] == GSM_0480_SEQUENCE_TAG) { if (uss_req_data[2] == ASN1_OCTET_STRING_TAG) { dcs = uss_req_data[4]; -// DEBUGP(DMM, "Data coding scheme = 0x%2.2X\n", dcs); if ((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) { num_chars = (uss_req_data[6] * 8) / 7; gsm_7bit_decode(ussd_string_buff, &(uss_req_data[7]), num_chars); @@ -228,6 +226,7 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) return rc; } +/* Send response to a mobile-originated ProcessUnstructuredSS-Request */ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) { struct msgb *msg = gsm48_msgb_alloc(); @@ -235,20 +234,28 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) u_int8_t *ptr8; int response_len; - response_len = strlen(response_text); + response_len = (strlen(response_text) * 7) / 8; + if (((strlen(response_text) * 7) % 8) != 0) + response_len += 1; msg->bts_link = in_msg->bts_link; msg->lchan = in_msg->lchan; /* First put the payload text into the message */ ptr8 = msgb_put(msg, response_len); - memcpy(ptr8, response_text, response_len); + gsm_7bit_encode(ptr8, response_text); - /* Then wrap it as an IA5 String */ - msgb_wrap_with_TL(msg, ASN1_IA5_STRING_TAG); + /* Then wrap it as an Octet String */ + msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG); + + /* Pre-pend the DCS octet string */ + msgb_push_TLV1(msg, ASN1_OCTET_STRING_TAG, 0x0F); + + /* Then wrap these as a Sequence */ + msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); /* Pre-pend the operation code */ - msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_DATA); + msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ); /* Wrap the operation code and IA5 string as a sequence */ msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c index ba2f045..5f9a457 100755 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -45,7 +45,7 @@ int handle_rcv_ussd(struct msgb *msg) { char* ussd_text_rcvd = gsm0480_rcv_ussd(msg); - if(ussd_text_rcvd[0] == 0xFF) // Release-Complete + if(ussd_text_rcvd[0] == 0xFF) /* Release-Complete */ return 0; if(strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) { @@ -60,7 +60,7 @@ int handle_rcv_ussd(struct msgb *msg) /* A network-specific handler function */ static int send_own_number(struct msgb *msg) { - char response_string[] = "Your extension is xxxxx"; + char response_string[] = "Your extension is xxxxx\r"; /* Need trailing CR as EOT character */ char* own_number = msg->lchan->subscr->extension; memcpy(response_string + 18, own_number, 5); -- 1.6.0.4 --------------050801040303060009020404-- From laforge at gnumonks.org Wed Oct 14 15:33:04 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Oct 2009 17:33:04 +0200 Subject: Mobile-originated USSD - double D'oh! In-Reply-To: <4AD4AAA3.6090902@btinternet.com> References: <4AD4AA38.8010705@btinternet.com> <4AD4AAA3.6090902@btinternet.com> Message-ID: <20091014153304.GG30960@prithivi.gnumonks.org> Dear Mike, it would be useful if you can send one patch against the git master of openbsc, that way I could apply your patch. The incremental patches are not really helpful because I need to find all of them on the list, look at them, figure out what has changed in which order, ... a simple git diff sha1_start..sha1_end (where sha1_start and sha1_end are the versions you can se in 'git log') is sufficient. On Tue, Oct 13, 2009 at 05:28:19PM +0100, Mike Haben wrote: > Mike Haben wrote: > >(Hopefully) last patch attached - now sends the correct op-code in > >response, works with all 6 phones I have tried. Interesting that > >5 out of 6 were happy with a completely different op-code and > >payload... It tells a lot about the protocol parser, and I'm not surprised. Be conservative in what you send and tolerant in what you accept is a very useful strategy in network protocols -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Oct 16 06:53:31 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Oct 2009 08:53:31 +0200 Subject: Mobile-originated USSD - double D'oh! In-Reply-To: <4AD62E42.90804@btinternet.com> References: <4AD4AA38.8010705@btinternet.com> <4AD4AAA3.6090902@btinternet.com> <20091014153304.GG30960@prithivi.gnumonks.org> <4AD62E42.90804@btinternet.com> Message-ID: <20091016065331.GM6173@prithivi.gnumonks.org> Hi Mike! Some comments: * it would have been good to Cc the mailinglist when you re-posted the patch, this way more eyes are on the code * I've looked at it but unfortunately there's a number of issues. That's why I've committed it to a new 'ussd' branch in git. * I've pushed an incremental patch as commit that cleans up the coding style issues that I had seen with the code There are also issues with the actual code that I'd like to see addressed, preferrably by incremental patches to my ussd branch: * the use of static global variables like ussd_string_buf in gsm_04_80.c Code like this will prove very difficult to ever use concurrently at some later point. global variables in the main program (or similar) are fine, but in actual 'library' style code, we should not keep code in static global variables across multiple calls. In such a case, the state needs to be associated with some of the data structures we have in memory anyway. ussd_string_buff looks like something the caller should allocate and pass into gsm0480_rcv_ussd(). Also, since rcv_ussd() only decodes, it should probably be called gsm0480_decode_ussd(). Things like the static last_transaction_id also will cause race conditions once multiple people send USSD requests at the same time. This data needs to be per subscriber, or per lchan, I presume. * the assumption that extension numbers are not longer than 5 characters in ussd.c is really not good. Please check the specs what is the maximum length of the phone number in this context, add a #define and then make sure the string buffer is large enough for it. Also, I prefer snprintf() to having XXXX that then get overwritten by memcopy :) If you could send patches for those two issues (one patch for each logical change), I would appreciate that and in the end merge the ussd branch into master. Thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From oystein at homelien.no Thu Oct 15 16:41:28 2009 From: oystein at homelien.no (Oystein Homelien) Date: Thu, 15 Oct 2009 18:41:28 +0200 (CEST) Subject: ip.access nanobts 1800 model 139, get "disabled" states Message-ID: Hello, I am trying to get my nanobts 1800 model 139 working. It is set up for dhcp and correctly contacts my openbsc instance. I get lots of "disabled" states and I am curious if you have any hints for me. I suspect there may be a bts firmware version problem. Any help is appreciated! See log below. ipaccess_find: MAC Address='00:02:95:00:xx:xx' IP Address='xxxx' Unit ID='1801/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='111_029_21' Software Version='120a002_v149b32d0' Unit Name='nbts-00-02-95-x' Serial Number='x' config: ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! network network country code 242 mobile network code 99 short name analyzer long name AnaLyzer auth policy accept-all encryption a5 0 bts 0 type nanobts band 1800 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 12 channel allocator ascending ip.access unit_id 1801 0 trx 0 arfcn 576 max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 1 timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 0 timeslot 1 sub-slot full timeslot 1 phys_chan_config SDCCH8 e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 log: <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: <0020> abis_nm.c:805 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 33 32 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 33 32 64 30 00 <0020> abis_nm.c:863 Software Activate Request NACKing for GPRS obj_class 0xf0 <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1671 Set BTS Attr (bts=0) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x01 obj_inst=(0x00, 0xff, 0xff) <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 33 32 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 33 32 64 30 00 <0020> abis_nm.c:863 Software Activate Request ACKing and Activating <0020> abis_nm.c:887 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 34 34 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 31 34 39 62 33 32 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 31 34 39 62 33 32 64 30 00 <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x04 obj_inst=(0x00, 0x00, 0xff) <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=0) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x00) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=1) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x01) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=2) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x02) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=3) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x03) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=4) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x04) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=5) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=6) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x06) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:1768 Set Chan Attr (bts=0,trx=0,ts=7) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x03 obj_inst=(0x00, 0x00, 0x07) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0020> abis_nm.c:1688 Set TRX Attr (bts=0,trx=0) <0020> abis_nm.c:1855 Sending OPSTART obj_class=0x02 obj_inst=(0x00, 0x00, 0xff) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:2477 IPACCESS(0xe1): RSL CONNECT ACK IP=123.234.10.101 PORT=3003 <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0020> abis_nm.c:805 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked yours, oystein From laforge at gnumonks.org Fri Oct 16 06:26:16 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Oct 2009 08:26:16 +0200 Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: References: Message-ID: <20091016062616.GL6173@prithivi.gnumonks.org> On Thu, Oct 15, 2009 at 06:41:28PM +0200, Oystein Homelien wrote: > Hello, I am trying to get my nanobts 1800 model 139 working. It is > set up for dhcp and correctly contacts my openbsc instance. I get > lots of "disabled" states and I am curious if you have any hints for > me. I suspect there may be a bts firmware version problem. Any > help is appreciated! See log below. I think it would be useful to get a full pcap from the time yoy start OpenBSC so we can do a more detailed protocol analysis of what fails.. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From oystein at homelien.no Fri Oct 16 14:39:39 2009 From: oystein at homelien.no (Oystein Homelien) Date: Fri, 16 Oct 2009 16:39:39 +0200 (CEST) Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: <20091016062616.GL6173@prithivi.gnumonks.org> References: <20091016062616.GL6173@prithivi.gnumonks.org> Message-ID: On Fri, 16 Oct 2009, Harald Welte wrote: > I think it would be useful to get a full pcap from the time yoy start OpenBSC > so we can do a more detailed protocol analysis of what fails.. Attached is a pcap file captured with bsc_hack -p. I let it run until there was no more 'action. yours, oystein -------------- next part -------------- A non-text attachment was scrubbed... Name: bsc.pcap Type: application/cap Size: 2978 bytes Desc: URL: From 246tnt at gmail.com Fri Oct 16 14:43:25 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Fri, 16 Oct 2009 14:43:25 +0000 Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: Message-ID: <001517401dd0240e6304760e6b0b@google.com> > I think it would be useful to get a full pcap from the time yoy start > OpenBSC > so we can do a more detailed protocol analysis of what fails.. > Attached is a pcap file captured with bsc_hack -p. I let it run until > there was no more 'action. Capture it with tcpdump please. There isn't much info in what you sent. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From oystein at homelien.no Fri Oct 16 14:52:30 2009 From: oystein at homelien.no (Oystein Homelien) Date: Fri, 16 Oct 2009 16:52:30 +0200 (CEST) Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: <001517401dd0240e6304760e6b0b@google.com> References: <001517401dd0240e6304760e6b0b@google.com> Message-ID: On Fri, 16 Oct 2009, 246tnt at gmail.com wrote: > Capture it with tcpdump please. > There isn't much info in what you sent. Sure. I put it here: http://home.powertech.no/oystein/bsc-tcpdump.pcap yours, oystein From 246tnt at gmail.com Fri Oct 16 15:17:31 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Fri, 16 Oct 2009 15:17:31 +0000 Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: Message-ID: <001636c5bc3f0b231804760ee510@google.com> You need to use the -s 1500 option of tcpdump. Because as it is, you capture only the first 90 bytes of each packet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oystein at homelien.no Fri Oct 16 15:26:24 2009 From: oystein at homelien.no (Oystein Homelien) Date: Fri, 16 Oct 2009 17:26:24 +0200 (CEST) Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: <001636c5bc3f0b231804760ee510@google.com> References: <001636c5bc3f0b231804760ee510@google.com> Message-ID: On Fri, 16 Oct 2009, 246tnt at gmail.com wrote: > You need to use the -s 1500 option of tcpdump. Because as it is, you capture only the first 90 bytes of each packet. Wow, this is really not my best day. Sorry for the inconvenience. New file here: http://home.powertech.no/oystein/bsc-tcpdump-2.pcap yours, oystein From laforge at gnumonks.org Sat Oct 17 08:55:29 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 17 Oct 2009 10:55:29 +0200 Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: References: <001636c5bc3f0b231804760ee510@google.com> Message-ID: <20091017085529.GX6173@prithivi.gnumonks.org> Hi! On Fri, Oct 16, 2009 at 05:26:24PM +0200, Oystein Homelien wrote: > On Fri, 16 Oct 2009, 246tnt at gmail.com wrote: > > >You need to use the -s 1500 option of tcpdump. Because as it is, you capture only the first 90 bytes of each packet. > > Wow, this is really not my best day. Sorry for the inconvenience. > New file here: > > http://home.powertech.no/oystein/bsc-tcpdump-2.pcap ok, everything looks fine, i.e. there are no NACKs (apart from the one intended NACK of GPRS) and no unknown messages or error messages. What is interesting is that the individual timeslots all look like: operational state: disabled availability state: dependency administrative state: unlocked the first part "opstate == disabled" is strange, since we have issued the OPSTART command to change that. Maybe the old unit/firmware is more picky with regard to the ordering of the commands. It might well be that we have to obey the following sequence of things: 1) we set the object attributes 2) we wait for the ack 3) we change the administrative state to unlocked 4) we wait for the ack 5) we now send the OPSTART command 6) we receive an ack. Right now, we have the order "1,2,5,6,3,4" which is not quite logical. How can something start operating if it is still in locked state. The 'locked' state is intended to lock an object for OML configuration such as setting channel attributes. While an object is locked, it is not available to the regular network (and thus RSL). If you want to play with the sequence of things, bsc_init.c:nm_state_event() is where you have to start. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From oystein at homelien.no Sun Oct 25 17:47:47 2009 From: oystein at homelien.no (Oystein Homelien) Date: Sun, 25 Oct 2009 18:47:47 +0100 (CET) Subject: ip.access nanobts 1800 model 139, get "disabled" states In-Reply-To: <20091017085529.GX6173@prithivi.gnumonks.org> References: <001636c5bc3f0b231804760ee510@google.com> <20091017085529.GX6173@prithivi.gnumonks.org> Message-ID: On Sat, 17 Oct 2009, Harald Welte wrote: > Right now, we have the order "1,2,5,6,3,4" which is not quite logical. How can > something start operating if it is still in locked state. I have managed to get my nanobts to go operational (confirmed with gsm terminal), by changing the order of things and sending some messages several times. Indeed I think a cleanup in this area is warranted; I will post (hopefully) non-intrusive patches when I get the time - for now I just report interim success. yours, oystein From 246tnt at gmail.com Thu Oct 15 18:33:36 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 15 Oct 2009 20:33:36 +0200 Subject: FOSDEM: Who's coming ? Message-ID: <866320f70910151133m75b3e52dn4a8fcc48b313ad52@mail.gmail.com> Hi everyone, As I mentionned in the earlier post, I think it'd be great if we could use FOSDEM to get known more. These projects covers a wide area, from quite low level RF stuff, signal processing to higher level GSM protocols ...so the work is certainly not missing :) So what I'd like to know is who's planning on coming (yes/no/maybe) to FOSDEM and if you'd be ready to help out or have equipment you could bring. Exactly _what_ we could do will most likely depend on the number of answer to this mail :) I've included OpenBTS, OpenBSC and airprobe here because they're the three projects I know that deal with the 'network' part of GSM (as opposed to the MS side for things like OpenMoko, Android, ...). And even if they currently don't share that much code, the GSM knowledge you gain by contributing to one of these can be directly applicable to help out in the others. Cheers ! Sylvain From laforge at gnumonks.org Mon Oct 19 18:48:49 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Oct 2009 20:48:49 +0200 Subject: progress: nanoBTS multi-TRX configuration Message-ID: <20091019184848.GU32489@prithivi.gnumonks.org> Hi all, JFYI: There's some progress on the nanoBTS multi-TRX configuration. It seems it was my mistake. Setting the TRX0 unit ID to 1801/0/0 and the TRX1 unit ID to 1801/0/1 works using ipaccess-config. If you then connect the TIB cable (TRX0 TIB out -> TRX1 TIB in) and reboot both nanoBTS, you will get a single A-bis OML connection from 1801/0/0 where you get software activate requests for both transceivers. Somehow we're not handling them correctly yet from our abis_nm code, but that should be easy to solve. I'm working at it. So Dieter and others: No need to worry about this at the moment, we're very close now and I think it is no problem for the 26C3. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Oct 19 23:02:54 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 20 Oct 2009 01:02:54 +0200 Subject: progress: nanoBTS multi-TRX configuration In-Reply-To: <20091019184848.GU32489@prithivi.gnumonks.org> References: <20091019184848.GU32489@prithivi.gnumonks.org> Message-ID: <20091019230254.GA32489@prithivi.gnumonks.org> On Mon, Oct 19, 2009 at 08:48:48PM +0200, Harald Welte wrote: > Somehow we're not handling them correctly yet from our abis_nm code, but that > should be easy to solve. I'm working at it. I've now fixed a number of bugs, and the input/ipaccess.c code can now deal with multiple RSL connections with each their own stream identifier. There's also vty support to configure the stream identifiers. The OML for both transceivers is coming up quite nicely, and the BTS also ACK the connection of the second RSL link. However, I never actually see any packets from that second OML link, and the state of all the TRX1 baseband transceiver, radio carrier and channel objects still remains in "dependency" I'll leave it at this for now. If somebody is able to provide an OML trace for a nanoBTS multi-TRX configuration, I would be extremely interested. I'm sure there's just some minor detail that I didn't know. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Oct 21 13:03:19 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 21 Oct 2009 15:03:19 +0200 Subject: Progress on the GPRS side Message-ID: <20091021130319.GB29852@prithivi.gnumonks.org> Hi all! With the current code in the 'gprs' branch, I am able to get the NS (08.16) and BSSGP (08.18) layers up and running with the nanoBTS. The NS RESET and TEST procedures are running fine, as well as the BSSGP RESET and BLOCK procedures. I now need to work on patching the system information to indicate GPRS support and add a SI13 message. Hopefully at that point, it is possible to receive LLC frames that are being sent by the MS. Ignoring Mobility Management for now and considering only single-BTS operation of GPRS, the biggest remaining items are: * understand LLC better and implement it * implement SNDCP * how to interface the actual network (using pty's with pppd on top) * make things more dynamic rather than static at compile time Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michael.haben at btinternet.com Wed Oct 21 19:10:14 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Wed, 21 Oct 2009 20:10:14 +0100 Subject: Patch to USSD branch - eliminates static variables Message-ID: <4ADF5C96.9030802@btinternet.com> Hi Harald, thanks for the review comments. Patch (attached) for the USSD branch addresses the first issue you highlighted - static variables have been eliminated. Best regards, Mike H. From michael.haben at btinternet.com Wed Oct 21 19:01:22 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Wed, 21 Oct 2009 20:01:22 +0100 Subject: [PATCH] USSD code - eliminate static variables, as per Harald's review Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_04_80.h | 15 +++++- openbsc/src/gsm_04_80.c | 90 ++++++++++++++++++----------------- openbsc/src/ussd.c | 19 ++++---- 3 files changed, 68 insertions(+), 56 deletions(-) diff --git a/openbsc/include/openbsc/gsm_04_80.h b/openbsc/include/openbsc/gsm_04_80.h index 11962d8..9bdf2c2 100644 --- a/openbsc/include/openbsc/gsm_04_80.h +++ b/openbsc/include/openbsc/gsm_04_80.h @@ -125,8 +125,17 @@ #include -char* gsm0480_rcv_ussd(struct msgb *msg); -int gsm0480_send_ussd_response(struct msgb *msg, const char* response_text); -int gsm0480_send_ussd_reject(struct msgb *msg); +struct ussd_request { + char text[32]; + u_int8_t transaction_id; + u_int8_t invoke_id; +}; + +int gsm0480_decode_ussd_request(struct msgb *msg, + struct ussd_request *request); +int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, + const struct ussd_request *req); +int gsm0480_send_ussd_reject(struct msgb *msg, + const struct ussd_request *request); #endif diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c index 052b0a7..5d85c82 100644 --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -37,16 +37,16 @@ #include #include -static char ussd_string_buff[32]; -static u_int8_t last_transaction_id; -static u_int8_t last_invoke_id; - /* Forward declarations */ -static int parse_ussd(u_int8_t *ussd); -static int parse_ussd_information_elements(u_int8_t *ussd_ie); -static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length); -static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length); -static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length); +static int parse_ussd(u_int8_t *ussd, struct ussd_request *req); +static int parse_ussd_info_elements(u_int8_t *ussd_ie, + struct ussd_request *req); +static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length, + struct ussd_request *req); +static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length, + struct ussd_request *req); +static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length, + struct ussd_request *req); static inline unsigned char *msgb_wrap_with_TL(struct msgb *msgb, u_int8_t tag) { @@ -69,26 +69,24 @@ static inline unsigned char *msgb_push_TLV1(struct msgb *msgb, u_int8_t tag, } -/* Receive a mobile-originated USSD message and return the decoded text */ -char *gsm0480_rcv_ussd(struct msgb *msg) +/* Decode a mobile-originated USSD-request message */ +int gsm0480_decode_ussd_request(struct msgb *msg, struct ussd_request *req) { int rc = 0; u_int8_t *parse_ptr = msgb_l3(msg); - memset(ussd_string_buff, 0, sizeof(ussd_string_buff)); - if ((*parse_ptr & 0x0F) == GSM48_PDISC_NC_SS) { - last_transaction_id = *parse_ptr & 0x70; - rc = parse_ussd(parse_ptr + 1); + req->transaction_id = *parse_ptr & 0x70; + rc = parse_ussd(parse_ptr+1, req); } if (!rc) DEBUGP(DMM, "Error occurred while parsing received USSD!\n"); - return ussd_string_buff; + return rc; } -static int parse_ussd(u_int8_t *ussd) +static int parse_ussd(u_int8_t *ussd, struct ussd_request *req) { int rc = 1; u_int8_t msg_type = ussd[0] & 0xBF; /* message-type - section 3.4 */ @@ -97,11 +95,11 @@ static int parse_ussd(u_int8_t *ussd) case GSM0480_MTYPE_RELEASE_COMPLETE: DEBUGP(DMM, "USS Release Complete\n"); /* could also parse out the optional Cause/Facility data */ - ussd_string_buff[0] = 0xFF; + req->text[0] = 0xFF; break; case GSM0480_MTYPE_REGISTER: case GSM0480_MTYPE_FACILITY: - rc &= parse_ussd_information_elements(ussd+1); + rc &= parse_ussd_info_elements(ussd+1, req); break; default: fprintf(stderr, "Unknown GSM 04.80 message-type field 0x%02x\n", @@ -113,7 +111,7 @@ static int parse_ussd(u_int8_t *ussd) return rc; } -static int parse_ussd_information_elements(u_int8_t *ussd_ie) +static int parse_ussd_info_elements(u_int8_t *ussd_ie, struct ussd_request *req) { int rc; /* Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 */ @@ -124,7 +122,7 @@ static int parse_ussd_information_elements(u_int8_t *ussd_ie) case GSM48_IE_CAUSE: break; case GSM0480_IE_FACILITY: - rc = parse_facility_ie(ussd_ie+2, iei_length); + rc = parse_facility_ie(ussd_ie+2, iei_length, req); break; case GSM0480_IE_SS_VERSION: break; @@ -138,7 +136,8 @@ static int parse_ussd_information_elements(u_int8_t *ussd_ie) return rc; } -static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) +static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length, + struct ussd_request *req) { int rc = 1; u_int8_t offset = 0; @@ -150,7 +149,9 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) switch (component_type) { case GSM0480_CTYPE_INVOKE: - rc &= parse_ss_invoke(facility_ie+2, component_length); + rc &= parse_ss_invoke(facility_ie+2, + component_length, + req); break; case GSM0480_CTYPE_RETURN_RESULT: break; @@ -171,7 +172,8 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) } /* Parse an Invoke component - see table 3.3 */ -static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) +static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length, + struct ussd_request *req) { int rc = 1; u_int8_t offset; @@ -183,7 +185,7 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) } offset = invoke_data[1] + 2; - last_invoke_id = invoke_data[2]; + req->invoke_id = invoke_data[2]; /* optional part */ if (invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) @@ -195,7 +197,8 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) switch (operation_code) { case GSM0480_OP_CODE_PROCESS_USS_REQ: rc = parse_process_uss_req(invoke_data + offset + 3, - length - offset - 3); + length - offset - 3, + req); break; default: fprintf(stderr, "GSM 04.80 operation code 0x%02x " @@ -214,36 +217,33 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) } /* Parse the parameters of a Process UnstructuredSS Request */ -static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) +static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length, + struct ussd_request *req) { - int rc = 1; + int rc = 0; int num_chars; u_int8_t dcs; - /* FIXME: most phones send USSD text as a 7-bit encoded octet string; - * the following code also handles the case of plain ASCII text - * (IA5String), but other encodings might be used */ - if (uss_req_data[0] == GSM_0480_SEQUENCE_TAG) { if (uss_req_data[2] == ASN1_OCTET_STRING_TAG) { dcs = uss_req_data[4]; if ((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) { num_chars = (uss_req_data[6] * 8) / 7; - gsm_7bit_decode(ussd_string_buff, + gsm_7bit_decode(req->text, &(uss_req_data[7]), num_chars); + /* append null-terminator */ + req->text[num_chars+1] = 0; + rc = 1; } } - } else if (uss_req_data[0] == ASN1_IA5_STRING_TAG) { - num_chars = uss_req_data[1]; - memcpy(ussd_string_buff, &(uss_req_data[2]), num_chars); - } - + } return rc; } /* Send response to a mobile-originated ProcessUnstructuredSS-Request */ -int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) +int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, + const struct ussd_request *req) { struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; @@ -278,7 +278,7 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); /* Pre-pend the invoke ID */ - msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, last_invoke_id); + msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, req->invoke_id); /* Wrap this up as a Return Result component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); @@ -288,13 +288,15 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) /* And finally pre-pend the L3 header */ gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh)); - gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | (1<<7); /* TI direction = 1 */ + gh->proto_discr = GSM48_PDISC_NC_SS | req->transaction_id + | (1<<7); /* TI direction = 1 */ gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; return gsm48_sendmsg(msg, NULL); } -int gsm0480_send_ussd_reject(struct msgb *in_msg) +int gsm0480_send_ussd_reject(struct msgb *in_msg, + const struct ussd_request *req) { struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; @@ -307,7 +309,7 @@ int gsm0480_send_ussd_reject(struct msgb *in_msg) GSM_0480_GEN_PROB_CODE_UNRECOGNISED); /* Before it insert the invoke ID */ - msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, last_invoke_id); + msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, req->invoke_id); /* Wrap this up as a Reject component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_REJECT); @@ -318,7 +320,7 @@ int gsm0480_send_ussd_reject(struct msgb *in_msg) /* And finally pre-pend the L3 header */ gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh)); gh->proto_discr = GSM48_PDISC_NC_SS; - gh->proto_discr |= last_transaction_id | (1<<7); /* TI direction = 1 */ + gh->proto_discr |= req->transaction_id | (1<<7); /* TI direction = 1 */ gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; return gsm48_sendmsg(msg, NULL); diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c index 9dc2205..e414b1c 100644 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -38,33 +38,34 @@ const char USSD_TEXT_OWN_NUMBER[] = "*#100#"; /* Forward declarations of network-specific handler functions */ -static int send_own_number(struct msgb *msg); +static int send_own_number(const struct msgb *msg, const struct ussd_request *req); /* Entrypoint - handler function common to all mobile-originated USSDs */ int handle_rcv_ussd(struct msgb *msg) { - char *ussd_text_rcvd = gsm0480_rcv_ussd(msg); + struct ussd_request req; - if (ussd_text_rcvd[0] == 0xFF) /* Release-Complete */ + gsm0480_decode_ussd_request(msg, &req); + if (req.text[0] == 0xFF) /* Release-Complete */ return 0; - if (strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) { + if (strstr(USSD_TEXT_OWN_NUMBER, req.text) != NULL) { DEBUGP(DMM, "USSD: Own number requested\n"); - return send_own_number(msg); + return send_own_number(msg, &req); } else { - DEBUGP(DMM, "Unhandled USSD %s\n", ussd_text_rcvd); - return gsm0480_send_ussd_reject(msg); + DEBUGP(DMM, "Unhandled USSD %s\n", req.text); + return gsm0480_send_ussd_reject(msg, &req); } } /* A network-specific handler function */ -static int send_own_number(struct msgb *msg) +static int send_own_number(const struct msgb *msg, const struct ussd_request *req) { char *own_number = msg->lchan->subscr->extension; /* Need trailing CR as EOT character */ char response_string[] = "Your extension is xxxxx\r"; memcpy(response_string + 18, own_number, 5); - return gsm0480_send_ussd_response(msg, response_string); + return gsm0480_send_ussd_response(msg, response_string, req); } -- 1.6.0.4 --------------080700070202040005090208-- From laforge at gnumonks.org Thu Oct 22 07:57:55 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Oct 2009 09:57:55 +0200 Subject: Patch to USSD branch - eliminates static variables In-Reply-To: <4ADF5C96.9030802@btinternet.com> References: <4ADF5C96.9030802@btinternet.com> Message-ID: <20091022075755.GK29852@prithivi.gnumonks.org> Hi Mike, On Wed, Oct 21, 2009 at 08:10:14PM +0100, Mike Haben wrote: > Hi Harald, thanks for the review comments. Patch (attached) for the > USSD branch addresses the first issue you highlighted - static > variables have been eliminated. thanks for taking care of this, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Oct 22 09:18:09 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Oct 2009 11:18:09 +0200 Subject: OpenBSC system_information branch Message-ID: <20091022091809.GL29852@prithivi.gnumonks.org> Hi! I've updated the system_information branch. The purpose of this branch is to move away from static u_int8_t arrays that are used as templates for the SYSTEM INFORMATION messages. Thise arrays are reminiscent of the old days of bs11_init, where everything had been done this way. The current head of system_information is now managing to actually do that. The full SI1-SI4 on the BCCH as well as the SI5/SI6 on the SACCH are now created from scratch (see code in system_information.c) The content of the SI is "phase 1" content, i.e. before rest octets were introduced I've also written some code to generate the rest octets, as well as a some "rest octet encoding aware" bit vector routines that understand the meaning of 0/1/L/H. However, those rest octet routines are not yet used. They need some careful testing before use. Testing is actually quite hard, as not even wireshark has dissector for the system information messages (anyone interested in contributing on this? It's needed for airprobe, too) One interesting bit that stalled development for quite some time: If you send a SACCH FILLing with length > 18 bytes, then the nanoBTS will actually crash somewhere in the layer 2, sending you long error strings with addresses (stack?) as error reports before rebooting :) Feel free to start testing the system_information branch if you're interested. I'd be happy to hear any "master works for my phone, but system_information branch confuses my phone" kind of reports. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun Oct 25 17:13:22 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 25 Oct 2009 18:13:22 +0100 Subject: OpenBSC system_information branch In-Reply-To: <20091022091809.GL29852@prithivi.gnumonks.org> References: <20091022091809.GL29852@prithivi.gnumonks.org> Message-ID: <866320f70910251013g672212a5g9cde83156b623c07@mail.gmail.com> Hi, I've just run that branch and tested with : * iPhone 2G * HTC Magic * Cheap nokia 1661 And I didn't notice any weird behaviors. Each was able to register and place call/send sms without trouble ... > Feel free to start testing the system_information branch if you're interested. > I'd be happy to hear any "master works for my phone, but system_information > branch confuses my phone" kind of reports. Nope sorry, it works fine here ... Sylvain From laforge at gnumonks.org Mon Oct 26 19:23:21 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Oct 2009 20:23:21 +0100 Subject: OpenBSC system_information branch In-Reply-To: <866320f70910251013g672212a5g9cde83156b623c07@mail.gmail.com> References: <20091022091809.GL29852@prithivi.gnumonks.org> <866320f70910251013g672212a5g9cde83156b623c07@mail.gmail.com> Message-ID: <20091026192320.GR29852@prithivi.gnumonks.org> Hi! Thanks for testing... On Sun, Oct 25, 2009 at 06:13:22PM +0100, Sylvain Munaut wrote: > I've just run that branch and tested with : > * iPhone 2G > * HTC Magic > * Cheap nokia 1661 > > And I didn't notice any weird behaviors. Each was able to register and > place call/send sms without trouble ... > > > Feel free to start testing the system_information branch if you're interested. > > I'd be happy to hear any "master works for my phone, but system_information > > branch confuses my phone" kind of reports. > > Nope sorry, it works fine here ... ok, this is good news. Which particular git version did you test? I've activated the code to generate the rest octets now, which might make quite some difference. I've been testing only a merged gprs + system_information branch, which uses the SI13 [rest octet] generation. That part is definitely broken, I need to research this. If anyone has some spare time, writing a full System Information dissector for wireshark would be a really cool thing to do. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Tue Oct 27 21:43:38 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Tue, 27 Oct 2009 21:43:38 +0000 Subject: OpenBSC system_information branch In-Reply-To: <20091026192320.GR29852@prithivi.gnumonks.org> Message-ID: <0016e6dab6c32cac490476f19263@google.com> Ok, I tested : * "main branch": A merge of : - master:ba92587cd5789d74ffa8675179f680232682edf1 - SW activate patch - 16bits len patch * "SI branch": A merge of - system_information:6a6d4f6361827bad5ab3005520ef47133def51ec - master:ba92587cd5789d74ffa8675179f680232682edf1 - SW activate patch - 16bits len patch The results : * iPhone 2G : OK on both * Android HTC Magic: OK on both * Nokia 3310: OK on both * Cheap nokia 1661: OK on both * SE T610: Weird behavior on both branch but repeatably worse on SI. - On the main branch: All is more or less ok except the active call period can only last 15-20 sec, after, it just closes. - On the SI branch, after two rings the call fails, and it seems each RF channel 'collapse' quickly (with no error ... on the MS side, it goes back to the default screen then a few second later, openbsc realize the rf channel is dead ...) The T610 behavior is really weird ... but I tested and the MS works fine when connected on the 'true' network ... I never tested that MS on openbsc before so I have no other reference point. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at hellercom.de Thu Oct 22 14:21:00 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 22 Oct 2009 16:21:00 +0200 Subject: cheap ip.access nano BTS on ebay Message-ID: Hello, yesterday I got a ip.access nano BTS MODEL 165B V33 PCS 1900 for 133 Euro (incl. shipping) on Ebay. The seller has maybe more in stock... I know, that it`s only 1900 band but maybe interesting for some people. regards Bjoern - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at hellercom.de Thu Oct 22 21:39:13 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 22 Oct 2009 23:39:13 +0200 Subject: cheap ip.access nano BTS on ebay In-Reply-To: <20091022213316.GR4861@elxsi.de> References: <20091022213316.GR4861@elxsi.de> Message-ID: <7B7BC8D4-2939-4328-9AA5-44C4FAF03CFF@hellercom.de> Hallo, ich bitte dich/alle aber da nicht zu viel Wirbel drum zu machen, damit die nicht bei ihrem eventuell vorhandenem restlichen Bestand die Preise hoch ziehen... http://stores.ebay.de/BLLCORP Gruss Bjoern Am 22.10.2009 um 23:33 schrieb Martin Kluge: > Hi Bjoern, > > k?nntest Du mit evtl. mal den Namen/Kontaktdaten des H?ndlers > schicken? > > > Vielen Dank, > Martin > > On Thu, Oct 22, 2009 at 04:21:00PM +0200, Bjoern Heller wrote: >> Hello, >> >> yesterday I got a ip.access nano BTS >> MODEL 165B V33 PCS 1900 >> for 133 Euro (incl. shipping) on Ebay. >> >> The seller has maybe more in stock... >> >> I know, that it`s only 1900 band but maybe interesting for some >> people. >> >> regards >> Bjoern >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> Bj?rn Heller >> Jabber: tec at jabber.hellercom.de >> > > -- > Dipl. Inf. (FH) Martin Kluge > > Email : mk at elxsi.de > Phone : +49 (700) 00101000 > Fax : +49 (941) 599267834 > Website : http://www.elxsi.de > GPG Key : http://www.elxsi.de/key.pub > RIPE : KLM-RIPE / AS35292 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.haben at btinternet.com Sat Oct 24 07:16:12 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Sat, 24 Oct 2009 08:16:12 +0100 Subject: Final (?) USSD-branch patch Message-ID: <4AE2A9BC.6040204@btinternet.com> - Improved handling of extension-number string (as per review) - Guard against a buffer-overflow if mobile sends a too-long USSD - declare some function-parameters const - fix gsm_ts_name function to display the right BTS number (bts->nr rather than bts->bts_nr) Hope this all looks OK... Best regards, Mike H. From michael.haben at btinternet.com Sat Oct 24 07:04:49 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Sat, 24 Oct 2009 08:04:49 +0100 Subject: [PATCH] USSD - address remaining review points, and guard against buffer overflow Signed-off-by: Mike Haben Message-ID: --- openbsc/include/openbsc/gsm_04_80.h | 10 ++++++---- openbsc/include/openbsc/gsm_subscriber.h | 7 ++++--- openbsc/src/gsm_04_80.c | 9 ++++++--- openbsc/src/gsm_data.c | 2 +- openbsc/src/ussd.c | 6 +++--- 5 files changed, 20 insertions(+), 14 deletions(-) mode change 100644 => 100755 openbsc/include/openbsc/gsm_04_80.h mode change 100644 => 100755 openbsc/include/openbsc/gsm_subscriber.h mode change 100644 => 100755 openbsc/src/gsm_04_80.c mode change 100644 => 100755 openbsc/src/gsm_data.c mode change 100644 => 100755 openbsc/src/ussd.c diff --git a/openbsc/include/openbsc/gsm_04_80.h b/openbsc/include/openbsc/gsm_04_80.h old mode 100644 new mode 100755 index 9bdf2c2..c240bbe --- a/openbsc/include/openbsc/gsm_04_80.h +++ b/openbsc/include/openbsc/gsm_04_80.h @@ -125,17 +125,19 @@ #include +#define MAX_LEN_USSD_STRING 31 + struct ussd_request { - char text[32]; + char text[MAX_LEN_USSD_STRING + 1]; u_int8_t transaction_id; u_int8_t invoke_id; }; -int gsm0480_decode_ussd_request(struct msgb *msg, +int gsm0480_decode_ussd_request(const struct msgb *msg, struct ussd_request *request); -int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, +int gsm0480_send_ussd_response(const struct msgb *in_msg, const char* response_text, const struct ussd_request *req); -int gsm0480_send_ussd_reject(struct msgb *msg, +int gsm0480_send_ussd_reject(const struct msgb *msg, const struct ussd_request *request); #endif diff --git a/openbsc/include/openbsc/gsm_subscriber.h b/openbsc/include/openbsc/gsm_subscriber.h old mode 100644 new mode 100755 index ea70c3a..b181917 --- a/openbsc/include/openbsc/gsm_subscriber.h +++ b/openbsc/include/openbsc/gsm_subscriber.h @@ -8,13 +8,14 @@ #define GSM_IMEI_LENGTH 17 #define GSM_IMSI_LENGTH 17 #define GSM_NAME_LENGTH 128 -#define GSM_EXTENSION_LENGTH 128 + +#define GSM_EXTENSION_LENGTH 6 +#define GSM_MIN_EXTEN 20000 +#define GSM_MAX_EXTEN 49999 /* reserved according to GSM 03.03 ?? 2.4 */ #define GSM_RESERVED_TMSI 0xFFFFFFFF -#define GSM_MIN_EXTEN 20000 -#define GSM_MAX_EXTEN 49999 #define GSM_SUBSCRIBER_FIRST_CONTACT 0x00000001 #define tmsi_from_string(str) strtoul(str, NULL, 10) diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c old mode 100644 new mode 100755 index 5d85c82..7f5089d --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -70,7 +70,7 @@ static inline unsigned char *msgb_push_TLV1(struct msgb *msgb, u_int8_t tag, /* Decode a mobile-originated USSD-request message */ -int gsm0480_decode_ussd_request(struct msgb *msg, struct ussd_request *req) +int gsm0480_decode_ussd_request(const struct msgb *msg, struct ussd_request *req) { int rc = 0; u_int8_t *parse_ptr = msgb_l3(msg); @@ -230,6 +230,9 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length, if ((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) { num_chars = (uss_req_data[6] * 8) / 7; + /* Prevent a mobile-originated buffer-overrun! */ + if (num_chars > MAX_LEN_USSD_STRING) + num_chars = MAX_LEN_USSD_STRING; gsm_7bit_decode(req->text, &(uss_req_data[7]), num_chars); /* append null-terminator */ @@ -242,7 +245,7 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length, } /* Send response to a mobile-originated ProcessUnstructuredSS-Request */ -int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, +int gsm0480_send_ussd_response(const struct msgb *in_msg, const char* response_text, const struct ussd_request *req) { struct msgb *msg = gsm48_msgb_alloc(); @@ -295,7 +298,7 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, return gsm48_sendmsg(msg, NULL); } -int gsm0480_send_ussd_reject(struct msgb *in_msg, +int gsm0480_send_ussd_reject(const struct msgb *in_msg, const struct ussd_request *req) { struct msgb *msg = gsm48_msgb_alloc(); diff --git a/openbsc/src/gsm_data.c b/openbsc/src/gsm_data.c old mode 100644 new mode 100755 index 6767c3f..2344d96 --- a/openbsc/src/gsm_data.c +++ b/openbsc/src/gsm_data.c @@ -224,7 +224,7 @@ static char ts2str[255]; char *gsm_ts_name(struct gsm_bts_trx_ts *ts) { snprintf(ts2str, sizeof(ts2str), "(bts=%d,trx=%d,ts=%d)", - ts->trx->bts->bts_nr, ts->trx->nr, ts->nr); + ts->trx->bts->nr, ts->trx->nr, ts->nr); return ts2str; } diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c old mode 100644 new mode 100755 index e414b1c..a3d11f0 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -63,9 +63,9 @@ int handle_rcv_ussd(struct msgb *msg) static int send_own_number(const struct msgb *msg, const struct ussd_request *req) { char *own_number = msg->lchan->subscr->extension; - /* Need trailing CR as EOT character */ - char response_string[] = "Your extension is xxxxx\r"; + char response_string[GSM_EXTENSION_LENGTH + 20]; - memcpy(response_string + 18, own_number, 5); + /* Need trailing CR as EOT character */ + snprintf(response_string, sizeof(response_string), "Your extension is %s\r", own_number); return gsm0480_send_ussd_response(msg, response_string, req); } -- 1.6.0.4 --------------090904070701030605040309-- From 246tnt at gmail.com Sun Oct 25 16:56:41 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 25 Oct 2009 17:56:41 +0100 Subject: [PATCH 1/4] ip.access: Fix bad call to patch_nm_tables when configuring channel Message-ID: <1256489804-9165-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut The bts variable isn't even defined at that point causing crashes. The patch_nm_tables is called for BTS object class. Signed-off-by: Sylvain Munaut --- openbsc/src/bsc_init.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 1394dd8..0adc656 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -378,7 +378,6 @@ int nm_state_event(enum nm_evt evt, u_int8_t obj_class, void *obj, trx = ts->trx; if (new_state->operational == 1 && new_state->availability == NM_AVSTATE_DEPENDENCY) { - patch_nm_tables(bts); enum abis_nm_chan_comb ccomb = abis_nm_chcomb4pchan(ts->pchan); abis_nm_set_channel_attr(ts, ccomb); -- 1.6.4 From 246tnt at gmail.com Sun Oct 25 16:56:42 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 25 Oct 2009 17:56:42 +0100 Subject: [PATCH 2/4] ip.access: Add a configuration file example for nanoBTS In-Reply-To: <1256489804-9165-1-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> Message-ID: <1256489804-9165-2-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Signed-off-by: Sylvain Munaut --- openbsc/src/openbsc.cfg.nanobts | 38 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 openbsc/src/openbsc.cfg.nanobts diff --git a/openbsc/src/openbsc.cfg.nanobts b/openbsc/src/openbsc.cfg.nanobts new file mode 100644 index 0000000..a12794f --- /dev/null +++ b/openbsc/src/openbsc.cfg.nanobts @@ -0,0 +1,38 @@ +! +! OpenBSC configuration saved from vty +! +password foo +! +line vty + no login +! +network + network country code 1 + mobile network code 1 + short name OpenBSC + long name OpenBSC + bts 0 + type nanobts + ip.access unit_id 1801 0 + band GSM1800 + location_area_code 1 + training_sequence_code 7 + base_station_id_code 63 + trx 0 + arfcn 514 + timeslot 0 + phys_chan_config CCCH+SDCCH4 + timeslot 1 + phys_chan_config SDCCH8 + timeslot 2 + phys_chan_config TCH/F + timeslot 3 + phys_chan_config TCH/F + timeslot 4 + phys_chan_config TCH/F + timeslot 5 + phys_chan_config TCH/F + timeslot 6 + phys_chan_config TCH/F + timeslot 7 + phys_chan_config TCH/F -- 1.6.4 From 246tnt at gmail.com Sun Oct 25 16:56:43 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 25 Oct 2009 17:56:43 +0100 Subject: [PATCH 3/4] tlv_parser: Split the tlv into 'parse loop' and 'parse single value' In-Reply-To: <1256489804-9165-2-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> <1256489804-9165-2-git-send-email-246tnt@gmail.com> Message-ID: <1256489804-9165-3-git-send-email-246tnt@gmail.com> From: Sylvain Munaut This is needed when you need to manually parse TLV blocks that don't follow the logic supported by tlv_parse but you still want to rely on working code and not fiddle with details. Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/tlv.h | 3 + openbsc/src/tlv_parser.c | 173 ++++++++++++++++++++++++----------------- 2 files changed, 104 insertions(+), 72 deletions(-) diff --git a/openbsc/include/openbsc/tlv.h b/openbsc/include/openbsc/tlv.h index 6da4fb1..0cf4388 100644 --- a/openbsc/include/openbsc/tlv.h +++ b/openbsc/include/openbsc/tlv.h @@ -207,6 +207,9 @@ struct tlv_parsed { extern struct tlv_definition tvlv_att_def; +int tlv_parse_one(u_int8_t *o_tag, u_int16_t *o_len, const u_int8_t **o_val, + const struct tlv_definition *def, + const u_int8_t *buf, int buf_len); int tlv_parse(struct tlv_parsed *dec, const struct tlv_definition *def, const u_int8_t *buf, int buf_len, u_int8_t lv_tag, u_int8_t lv_tag2); diff --git a/openbsc/src/tlv_parser.c b/openbsc/src/tlv_parser.c index 8321b88..fd0045f 100644 --- a/openbsc/src/tlv_parser.c +++ b/openbsc/src/tlv_parser.c @@ -16,6 +16,82 @@ int tlv_dump(struct tlv_parsed *dec) return 0; } +/* o_tag: output: tag found + * o_len: output: length of the data + * o_val: output: pointer to the data + * def: input: a structure defining the valid TLV tags / configurations + * buf: input: the input data buffer to be parsed + * buf_len: input: the length of the input data buffer + * + * Also, returns the number of bytes consumed by the TLV entry + */ +int tlv_parse_one(u_int8_t *o_tag, u_int16_t *o_len, const u_int8_t **o_val, + const struct tlv_definition *def, + const u_int8_t *buf, int buf_len) +{ + u_int8_t tag; + int len; + + tag = *buf; + *o_tag = tag; + + /* FIXME: use tables for knwon IEI */ + switch (def->def[tag].type) { + case TLV_TYPE_T: + /* GSM TS 04.07 11.2.4: Type 1 TV or Type 2 T */ + *o_val = buf; + *o_len = 0; + len = 1; + break; + case TLV_TYPE_TV: + *o_val = buf+1; + *o_len = 1; + len = 2; + break; + case TLV_TYPE_FIXED: + *o_val = buf+1; + *o_len = def->def[tag].fixed_len; + len = def->def[tag].fixed_len + 1; + break; + case TLV_TYPE_TLV: + /* GSM TS 04.07 11.2.4: Type 4 TLV */ + if (buf + 1 > buf + buf_len) + return -1; + *o_val = buf+2; + *o_len = *(buf+1); + len = *o_len + 2; + if (len > buf_len) + return -2; + break; + case TLV_TYPE_TvLV: + if (*(buf+1) & 0x80) { + /* like TLV, but without highest bit of len */ + if (buf + 1 > buf + buf_len) + return -1; + *o_val = buf+2; + *o_len = *(buf+1) & 0x7f; + len = *o_len + 2; + if (len > buf_len) + return -2; + break; + } + /* like TL16V, fallthrough */ + case TLV_TYPE_TL16V: + if (2 > buf_len) + return -1; + *o_val = buf+3; + *o_len = *(buf+1) << 8 | *(buf+2); + len = *o_len + 3; + if (len > buf_len) + return -2; + break; + default: + return -3; + } + + return len; +} + /* dec: output: a caller-allocated pointer to a struct tlv_parsed, * def: input: a structure defining the valid TLV tags / configurations * buf: input: the input data buffer to be parsed @@ -27,94 +103,47 @@ int tlv_parse(struct tlv_parsed *dec, const struct tlv_definition *def, const u_int8_t *buf, int buf_len, u_int8_t lv_tag, u_int8_t lv_tag2) { - u_int8_t tag, len = 1; - const u_int8_t *pos = buf; - int num_parsed = 0; + int ofs = 0, num_parsed = 0; + u_int16_t len; memset(dec, 0, sizeof(*dec)); if (lv_tag) { - if (pos > buf + buf_len) + if (ofs > buf_len) return -1; - dec->lv[lv_tag].val = pos+1; - dec->lv[lv_tag].len = *pos; + dec->lv[lv_tag].val = &buf[ofs+1]; + dec->lv[lv_tag].len = buf[ofs]; len = dec->lv[lv_tag].len + 1; - if (pos + len > buf + buf_len) + if (ofs + len > buf_len) return -2; num_parsed++; - pos += len; + ofs += len; } if (lv_tag2) { - if (pos > buf + buf_len) + if (ofs > buf_len) return -1; - dec->lv[lv_tag2].val = pos+1; - dec->lv[lv_tag2].len = *pos; + dec->lv[lv_tag2].val = &buf[ofs+1]; + dec->lv[lv_tag2].len = buf[ofs]; len = dec->lv[lv_tag2].len + 1; - if (pos + len > buf + buf_len) + if (ofs + len > buf_len) return -2; num_parsed++; - pos += len; + ofs += len; } - for (; pos < buf+buf_len; pos += len) { - tag = *pos; - /* FIXME: use tables for knwon IEI */ - switch (def->def[tag].type) { - case TLV_TYPE_T: - /* GSM TS 04.07 11.2.4: Type 1 TV or Type 2 T */ - dec->lv[tag].val = pos; - dec->lv[tag].len = 0; - len = 1; - num_parsed++; - break; - case TLV_TYPE_TV: - dec->lv[tag].val = pos+1; - dec->lv[tag].len = 1; - len = 2; - num_parsed++; - break; - case TLV_TYPE_FIXED: - dec->lv[tag].val = pos+1; - dec->lv[tag].len = def->def[tag].fixed_len; - len = def->def[tag].fixed_len + 1; - num_parsed++; - break; - case TLV_TYPE_TLV: - /* GSM TS 04.07 11.2.4: Type 4 TLV */ - if (pos + 1 > buf + buf_len) - return -1; - dec->lv[tag].val = pos+2; - dec->lv[tag].len = *(pos+1); - len = dec->lv[tag].len + 2; - if (pos + len > buf + buf_len) - return -2; - num_parsed++; - break; - case TLV_TYPE_TvLV: - if (*(pos+1) & 0x80) { - /* like TLV, but without highest bit of len */ - if (pos + 1 > buf + buf_len) - return -1; - dec->lv[tag].val = pos+2; - dec->lv[tag].len = *(pos+1) & 0x7f; - len = dec->lv[tag].len + 2; - if (pos + len > buf + buf_len) - return -2; - num_parsed++; - break; - } - /* like TL16V, fallthrough */ - case TLV_TYPE_TL16V: - if (pos + 2 > buf + buf_len) - return -1; - dec->lv[tag].val = pos+3; - dec->lv[tag].len = *(pos+1) << 8 | *(pos+2); - len = dec->lv[tag].len + 3; - if (pos + len > buf + buf_len) - return -2; - num_parsed++; - break; - } + while (ofs < buf_len) { + int rv; + u_int8_t tag; + const u_int8_t *val; + + rv = tlv_parse_one(&tag, &len, &val, def, + &buf[ofs], buf_len-ofs); + if (rv < 0) + return rv; + dec->lv[tag].val = val; + dec->lv[tag].len = len; + ofs += rv; + num_parsed++; } //tlv_dump(dec); return num_parsed; -- 1.6.4 From 246tnt at gmail.com Sun Oct 25 16:56:44 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 25 Oct 2009 17:56:44 +0100 Subject: [PATCH 4/4] abis_nm: Fix ACTIVATE SW parameters In-Reply-To: <1256489804-9165-3-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> <1256489804-9165-2-git-send-email-246tnt@gmail.com> <1256489804-9165-3-git-send-email-246tnt@gmail.com> Message-ID: <1256489804-9165-4-git-send-email-246tnt@gmail.com> From: Sylvain Munaut The previous code only sent the FILE_ID tag data part, but according to the GSM 12.21 spec, section 8.3.6, the full SW Description 'object' must be sent so that includes the NM_ATT_SW_DESCR tag, the whole FILE_ID and the whole FILE_VERSION (including tags & length fields). Note that functionnaly on a nanoBTS 139 I couldn't see any difference ... whatever I send in there it works ... Signed-off-by: Sylvain Munaut --- openbsc/src/abis_nm.c | 61 +++++++++++++++++++++++++++++++++++++++--------- 1 files changed, 49 insertions(+), 12 deletions(-) diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 03d9def..c2641c4 100755 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -878,16 +878,57 @@ static int ipacc_sw_activate(struct gsm_bts *bts, u_int8_t obj_class, u_int8_t i return abis_nm_sendmsg(bts, msg); } +static int abis_nm_parse_sw_descr(const u_int8_t *sw_descr, int sw_descr_len) +{ + static const struct tlv_definition sw_descr_def = { + .def = { + [NM_ATT_FILE_ID] = { TLV_TYPE_TL16V, }, + [NM_ATT_FILE_VERSION] = { TLV_TYPE_TL16V, }, + }, + }; + + u_int8_t tag; + u_int16_t tag_len; + const u_int8_t *val; + int ofs = 0, len; + + /* Classic TLV parsing doesn't work well with SW_DESCR because of it's + * nested nature and the fact you have to assume it contains only two sub + * tags NM_ATT_FILE_VERSION & NM_ATT_FILE_ID to parse it */ + + if (sw_descr[0] != NM_ATT_SW_DESCR) { + DEBUGP(DNM, "SW_DESCR attribute identifier not found!\n"); + return -1; + } + ofs += 1; + + len = tlv_parse_one(&tag, &tag_len, &val, + &sw_descr_def, &sw_descr[ofs], sw_descr_len-ofs); + if (len < 0 || (tag != NM_ATT_FILE_ID)) { + DEBUGP(DNM, "FILE_ID attribute identifier not found!\n"); + return -2; + } + ofs += len; + + len = tlv_parse_one(&tag, &tag_len, &val, + &sw_descr_def, &sw_descr[ofs], sw_descr_len-ofs); + if (len < 0 || (tag != NM_ATT_FILE_VERSION)) { + DEBUGP(DNM, "FILE_VERSION attribute identifier not found!\n"); + return -3; + } + ofs += len; + + return ofs; +} + static int abis_nm_rx_sw_act_req(struct msgb *mb) { struct abis_om_hdr *oh = msgb_l2(mb); struct abis_om_fom_hdr *foh = msgb_l3(mb); struct tlv_parsed tp; const u_int8_t *sw_config; - int sw_config_len; - int file_id_len; int nack = 0; - int ret; + int ret, sw_config_len, sw_descr_len; debugp_foh(foh); @@ -918,20 +959,16 @@ static int abis_nm_rx_sw_act_req(struct msgb *mb) DEBUGP(DNM, "Found SW config: %s\n", hexdump(sw_config, sw_config_len)); } - if (sw_config[0] != NM_ATT_SW_DESCR) - DEBUGP(DNM, "SW_DESCR attribute identifier not found!\n"); - if (sw_config[1] != NM_ATT_FILE_ID) - DEBUGP(DNM, "FILE_ID attribute identifier not found!\n"); - file_id_len = sw_config[2] * 256 + sw_config[3]; + /* Use the first SW_DESCR present in SW config */ + sw_descr_len = abis_nm_parse_sw_descr(sw_config, sw_config_len); + if (sw_descr_len < 0) + return -EINVAL; - /* Assumes first SW file in list is the one to be activated */ - /* sw_config + 4 to skip over 2 attribute ID bytes and 16-bit length field */ return ipacc_sw_activate(mb->trx->bts, foh->obj_class, foh->obj_inst.bts_nr, foh->obj_inst.trx_nr, foh->obj_inst.ts_nr, - sw_config + 4, - file_id_len); + sw_config, sw_descr_len); } /* Receive a CHANGE_ADM_STATE_ACK, parse the TLV and update local state */ -- 1.6.4 From laforge at gnumonks.org Mon Oct 26 19:18:42 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Oct 2009 20:18:42 +0100 Subject: [PATCH 4/4] abis_nm: Fix ACTIVATE SW parameters In-Reply-To: <1256489804-9165-4-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> <1256489804-9165-2-git-send-email-246tnt@gmail.com> <1256489804-9165-3-git-send-email-246tnt@gmail.com> <1256489804-9165-4-git-send-email-246tnt@gmail.com> Message-ID: <20091026191842.GP29852@prithivi.gnumonks.org> Hi Sylvain, thanks for your patch. On Sun, Oct 25, 2009 at 05:56:44PM +0100, Sylvain Munaut wrote: > The previous code only sent the FILE_ID tag data part, > but according to the GSM 12.21 spec, section 8.3.6, the > full SW Description 'object' must be sent so that includes > the NM_ATT_SW_DESCR tag, the whole FILE_ID and the whole > FILE_VERSION (including tags & length fields). Can somebody test this with a BS11? I want to make sure we don't introduce regressions here. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Oct 26 19:21:31 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Oct 2009 20:21:31 +0100 Subject: [PATCH 3/4] tlv_parser: Split the tlv into 'parse loop' and 'parse single value' In-Reply-To: <1256489804-9165-3-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> <1256489804-9165-2-git-send-email-246tnt@gmail.com> <1256489804-9165-3-git-send-email-246tnt@gmail.com> Message-ID: <20091026192131.GQ29852@prithivi.gnumonks.org> Thanks, applied. For the future, please don't mix two things in one patch. In addition to splitting the function, you have also changed the variables, i.e. no longer using 'pos' but the offset. That should have been a separate patch and made review much easier. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Oct 26 19:16:57 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Oct 2009 20:16:57 +0100 Subject: [PATCH 2/4] ip.access: Add a configuration file example for nanoBTS In-Reply-To: <1256489804-9165-2-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> <1256489804-9165-2-git-send-email-246tnt@gmail.com> Message-ID: <20091026191657.GO29852@prithivi.gnumonks.org> Thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Oct 26 19:14:28 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Oct 2009 20:14:28 +0100 Subject: [PATCH 1/4] ip.access: Fix bad call to patch_nm_tables when configuring channel In-Reply-To: <1256489804-9165-1-git-send-email-246tnt@gmail.com> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> Message-ID: <20091026191428.GN29852@prithivi.gnumonks.org> Thanks, I had already fixed this, but apparently not in the master branch yet. The correct fix is to use trx->bts, rather than bts. Skipping/removing patch_nm_tables() can cause erroneous data from the templates to leak into the live system without reflecting the configuration file. I'll fix it in master right now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun Oct 25 18:50:53 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 25 Oct 2009 19:50:53 +0100 Subject: RRLP Message-ID: <866320f70910251150x21b14fbfu141ace6fbf26cdef@mail.gmail.com> Hi, I've been working on improving RRLP support lately. Most precisely, providing real assistance data sourced directly from a GPS receiver attached to the control PC. My problem right now is that the generated APDU is about 1500 bytes and obviously there is no way that fits in a single L3 frame. GSM 04.08 9.1.53 describes the format of the APDU and there is a 4 bits flag fields, which from what I understand occupies the 4 upper fields of the first octet and that allows fragmentation. From reading the IE description in 10.5.2.49 I should set : 0x10 for the first segment 0x30 for the intermediate segments 0x20 for the last segment Which is what I tried, by modifying the gsm48_send_rr_app_info function like this : http://yourpaste.net/3558/ Unfortunately, I couldn't make it work. When I set the segment size to try and have L3 frame of 251 bytes, I get some RSL error back and when I use a smaller size, the MS seems to interpret each segment separately and not reconstituting them ... Does anyone have a clue ? Sylvain Here's a log, where you see the MS answering independently to the 3 segments (with errors since you can't just decode partial data ...): <0002> gsm_04_08.c:280 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to: 0 <0004> gsm_04_08.c:901 -> LOCATION UPDATE ACCEPT <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. l3_len = 14 <0004> gsm_04_08.c:1222 -> MM INFO <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. l3_len = 22 <0008> gsm_04_08.c:1651 TX APPLICATION INFO id=0x00, len=688 <0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=0 len=230 id=10 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. l3_len = 234 <0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=230 len=230 id=30 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. l3_len = 234 <0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=460 len=228 id=20 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. l3_len = 232 <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0004> gsm_04_08.c:1438 TMSI Reallocation Completed. Subscriber: 206205003327508 <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=48 20 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING. <0010> abis_rsl.c:720 RF Channel Release CMD channel=(bts=0,trx=0,ts=0) chan_nr=0x28 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 RF CHANNEL RELEASE ACK <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=88 10 <0010> abis_rsl.c:720 RF Channel Release CMD channel=(bts=0,trx=0,ts=0) chan_nr=0x28 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 RF CHANNEL RELEASE ACK <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=c8 00 <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 RELEASE INDICATION <0010> abis_rsl.c:720 RF Channel Release CMD channel=(bts=0,trx=0,ts=0) chan_nr=0x20 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 RF CHANNEL RELEASE ACK <0002> gsm_subscriber_base.c:150 subscr 201 usage decreased usage to: 0 From spaar at mirider.augusta.de Sun Oct 25 20:57:11 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 25 Oct 2009 20:57:11 Subject: RRLP Message-ID: <4ae4bba7.mirider@mirider.augusta.de> Hello Sylvain, On Sun, 25 Oct 2009 19:50:53 +0100, "Sylvain Munaut" <246tnt at gmail.com> wrote: > Does anyone have a clue ? You already had a look at TS 44.031 ? It describes the RRLP procedures in detail. It also mentiones that the RRLP maximum PDU size is 242 bytes and that you have to use RRLP pseudo-segmentation to deliver larger PDUs, however it also mentiones that "legacy" MS and SMLC may exceed this PDU size. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From spaar at mirider.augusta.de Mon Oct 26 09:03:42 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 26 Oct 2009 09:03:42 Subject: RRLP Message-ID: <4ae565ee.mirider@mirider.augusta.de> Hello, here is a summary of the RRLP requests from HAR2009. It is the summary from a time periode of about 10 hours near the end of the event. Total number of RRLP responses: 2179 "methodNotSupported" response: 122 "notEnoughSats" response: 667 "gpsAssDataMissing" response: 1368 Successful positions returned: 22 Number of different phones: 86 Phones which returned "methodNotSupported": 5 Phones which returned a position: 7 Requested assitance data for the "gpsAssDataMissing" response: 530 Navigation Model, Reference Location, Reference Time 468 Navigation Model, Reference Location 141 Navigation Model 123 Almanac, Navigation Model, Reference Location, Reference Time 58 Almanac, Navigation Model, Reference Location, Reference Time, Real-Time Integrity 27 Almanac, Navigation Model, Reference Location 13 Almanac, UTC Model, Ionospheric Model, Navigation Model, Reference Location, Reference Time, Real-Time Integrity 5 Reference Location 3 Navigation Model, Reference Time And this was the request sent to the phones: PDU: 40 01 78 A8 referenceNumber 2 msrPositionReq methodType msBased Accuracy 60 positionMethod gps measureResponseTime 2 useMultipleSets oneSet Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Mon Oct 26 09:19:55 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 26 Oct 2009 10:19:55 +0100 Subject: RRLP In-Reply-To: <4ae565ee.mirider@mirider.augusta.de> References: <4ae565ee.mirider@mirider.augusta.de> Message-ID: <866320f70910260219t7dd9f1bcw8f13803be0ed5995@mail.gmail.com> > ? Total number of RRLP responses: ? ? ? ? ? ? 2179 > ? "methodNotSupported" response: ? ? ? ? ? ? ? 122 > ? "notEnoughSats" response: ? ? ? ? ? ? ? ? ? ?667 > ? "gpsAssDataMissing" response: ? ? ? ? ? ? ? 1368 > ? Successful positions returned: ? ? ? ? ? ? ? ?22 > > ? Number of different phones: ? ? ? ? ? ? ? ? ? 86 > ? Phones which returned "methodNotSupported": ? ?5 > ? Phones which returned a position: ? ? ? ? ? ? ?7 So a lot of phones seem to support this and with assistance data could maybe provide a location. Did you try to correlate IMEI manufacturer part with the messages ? > ? Requested assitance data for the "gpsAssDataMissing" response: > > ? ? 530 Navigation Model, Reference Location, Reference Time > ? ? 468 Navigation Model, Reference Location > ? ? 141 Navigation Model > ? ? 123 Almanac, Navigation Model, Reference Location, Reference Time > ? ? ?58 Almanac, Navigation Model, Reference Location, Reference Time, > ? ? ? ? Real-Time Integrity > ? ? ?27 Almanac, Navigation Model, Reference Location > ? ? ?13 Almanac, UTC Model, Ionospheric Model, Navigation Model, > ? ? ? ? Reference Location, Reference Time, Real-Time Integrity > ? ? ? 5 Reference Location > ? ? ? 3 Navigation Model, Reference Time I can provide all of this, except for "Real-Time Integrity". But as I said, it doesn't seem to accept my 'reference location'. Do you have any log of a successful response ? Maybe I screw up the encoding of the position somehow. Sylvain From spaar at mirider.augusta.de Mon Oct 26 10:55:58 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 26 Oct 2009 10:55:58 Subject: RRLP Message-ID: <4ae5803e.mirider@mirider.augusta.de> Hello Sylvain, On Mon, 26 Oct 2009 10:19:55 +0100, "Sylvain Munaut" <246tnt at gmail.com> wrote: > > So a lot of phones seem to support this and with assistance data could > maybe provide a location. > Did you try to correlate IMEI manufacturer part with the messages ? No, not yet. > Do you have any log of a successful response ? Maybe I screw up the > encoding of the position somehow. Yes, here is an example. This is the response from the phone 42 11 00 00 6A 57 9F B6 41 29 B1 B0 10 8D 84 00 6C 9C 9C 01 B1 0C This is decoded PDU (asn1c was used): PDU ::= { referenceNumber: 2 component: MsrPosition-Rsp ::= { locationInfo: LocationInfo ::= { refFrame: 0 gpsTOW: 6969247 fixType: 1 posEstimate: 90 4A 6C 6C 04 23 61 00 1B 27 27 00 6C 43 } } } And those are the coordinates from "posEstimate" (I did not care about the height): 52.329040 - 52 19'44" N 5.819342 - 5 49' 9" E Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From zecke at selfish.org Tue Oct 27 09:06:56 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 27 Oct 2009 10:06:56 +0100 Subject: Errors reports by clang --analyze in abis_nm.c Message-ID: <200910271006.56796.zecke@selfish.org> Hey, the clang C frontend has found some issues in our OpenBSC code. I think we will need to have a table for BS11 and one for ipaccess with the shared/speced elements being in both tables. Here is the list of things I can resolve myself right now: [NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_FIXED, 2 } [NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_TV, }, these vendor specific commands have the same value: [NM_ATT_IPACC_NS_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_BIT_ERR_THESH] = { TLV_TYPE_FIXED, 2 }, [NM_ATT_IPACC_BSSGP_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_BOOT_SW_VERS] = { TLV_TYPE_TLV }, ^~~~~~~~~~~~ [NM_ATT_IPACC_RLC_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_CCLK_ACCURACY] = { TLV_TYPE_TV }, ^~~~~~~~~~~ [NM_ATT_IPACC_ALM_THRESH_LIST]= { TLV_TYPE_TL16V }, [NM_ATT_BS11_CCLK_TYPE] = { TLV_TYPE_TV }, ^~~~~~~~~~~ [NM_ATT_IPACC_CODING_SCHEMES] = { TLV_TYPE_TL16V }, [0xa8] = { TLV_TYPE_TLV }, [NM_ATT_IPACC_UPTIME] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_L1_PROT_TYPE] = { TLV_TYPE_TV }, [NM_ATT_IPACC_RLC_CFG_3] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_LINE_CFG] = { TLV_TYPE_TV }, [0x85] = { TLV_TYPE_TV }, [NM_ATT_IPACC_STREAM_ID] = { TLV_TYPE_TV, }, From laforge at gnumonks.org Tue Oct 27 12:46:41 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 27 Oct 2009 13:46:41 +0100 Subject: Errors reports by clang --analyze in abis_nm.c In-Reply-To: <200910271006.56796.zecke@selfish.org> References: <200910271006.56796.zecke@selfish.org> Message-ID: <20091027124641.GE29852@prithivi.gnumonks.org> On Tue, Oct 27, 2009 at 10:06:56AM +0100, Holger Freyther wrote: > Hey, > > the clang C frontend has found some issues in our OpenBSC code. I think we > will need to have a table for BS11 and one for ipaccess with the shared/speced > elements being in both tables. yes, that has been on my 'wishlist' for quite some time. so it's at least to me a 'known issue', and also the reason the abis_oml plugin for wireshark (using the same tables) has not yet been submitted to wireshark. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Tue Oct 27 11:57:55 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 27 Oct 2009 12:57:55 +0100 Subject: [RFC] Subscriber Reference Counting Message-ID: <200910271257.56268.zecke@selfish.org> Hi, IIRC Harald et all. were seeing GSM subscriber leakage at HAR2009 and we have not yet explored the cause of this problem. I would like to have no subscriber leaks for the congress and propose the following changes. I have pushed the "holger/subscr-ref-handling" branch to our repository and would be happy if people could give it a spin. My testing here is pretty limited. Currently I have two commits. The second is removing a leak in the vty console for SMS sending and subscriber usage and the other patch is trying to stop borrowing someone else's gsm_subscriber reference. More details below. Currently we do lchan->subscr = new_subscr and then we have two flavors of checking if the channel is already used. I have changed this to use a new assignment function that will do the check consistently and updated call sites. I would establish the following guideline for gsm_subscriber handling: In every method where subscr_get* is called the subscriber must be released at the exit with subscr_put unless the referenced provider is assigned to a struct that is created in the same method, then the subscriber must be released next to the talloc_free. More details: - paging.c seems fine - gsm_subscriber_chan seems fine - gsm_04_08_utils.c seems fine - gsm_04_08.c seems fine now as well. subscr_get/_put should be balanced - gsm_04_11.c if we leak a subscriber we also leak a sms I have not checked all SMS paths to be sure we don't leak there. I would be very happy if people could test this. z, From Andreas.Eversberg at versatel.de Tue Oct 27 14:26:08 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 27 Oct 2009 15:26:08 +0100 Subject: AW: [RFC] Subscriber Reference Counting Message-ID: hi holger, i would like to test it. but before i can do that, i need to know what ressource are actually counted. for example: a transaction holds one ressource, paging holds one ressource, as well as a channel that is associated to that subscriber's transaction. what about sms? shold an object of "struct gsm_sms" be counted as one ressource, or each sender/receiver within this structure, or all together (one for the sms, one for the sender and one for the receiver)? i need a list of all subscriber ressources for gsm_04_11.c regards, andreas From zecke at selfish.org Wed Oct 28 01:27:48 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 28 Oct 2009 02:27:48 +0100 Subject: [RFC] Subscriber Reference Counting In-Reply-To: References: Message-ID: <200910280227.48381.zecke@selfish.org> On Tuesday 27 October 2009 15:26:08 Andreas.Eversberg wrote: > hi holger, > > i would like to test it. but before i can do that, i need to know what > ressource are actually counted. The first step is to only count gsm_subscriber instances. E.g. start with a fresh BSC. - Do Location Updating Request procedure and see if "show subscriber cache" on the telnet console is empty. - Use "sms send EXTENSION TEXT" and see if subscriber cache is empty afterwards - Call one phone from another, hang up, see the subscriber cache. Currently the called party (Mobile Terminated) will leak the gsm_subscriber due the mncc_send implementation and the paging down there. > > for example: a transaction holds one ressource, paging holds one > ressource, as well as a channel that is associated to that subscriber's > transaction. > what about sms? shold an object of "struct gsm_sms" be counted as one > ressource, or each sender/receiver within this structure, or all > together (one for the sms, one for the sender and one for the receiver)? Currently it is just about getting subscr_get and subscr_put balanced, finding out more "live leaks" later is the next thing. Currently the branch is doing: - Stops borrowing the gsm_subscriber to the lchan - Fixes leaks in the vty_interface_layer3.c code for subscriber action - Fixes a subscriber leak (actually two) in mncc_send. if wanted I can attach the patches to this mail to ease reviewing. z. From Andreas.Eversberg at versatel.de Wed Oct 28 14:04:19 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 28 Oct 2009 15:04:19 +0100 Subject: AW: [RFC] Subscriber Reference Counting Message-ID: > Currently the branch is doing: > - Stops borrowing the gsm_subscriber to the lchan > - Fixes leaks in the vty_interface_layer3.c code for subscriber action > - Fixes a subscriber leak (actually two) in mncc_send. > > if wanted I can attach the patches to this mail to ease reviewing. what branch is it? do i need additional patches? i use the master with the RTP patch applied. From zecke at selfish.org Wed Oct 28 14:47:25 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 28 Oct 2009 15:47:25 +0100 Subject: [RFC] Subscriber Reference Counting In-Reply-To: References: Message-ID: <200910281547.25914.zecke@selfish.org> On Wednesday 28 October 2009 15:04:19 Andreas.Eversberg wrote: > what branch is it? do i need additional patches? i use the master with > the RTP patch applied. This information was in the initial mail the branch is called "holger/subscr- ref-handling". This branch is fixing a real life subscriber leak in the mncc_send routine. I would do the following to switch the branches. 1.) Check the name $ git branch -a ... origin/holger/subscr-ref-handling 2.) save my current work $ git stash 3.) create a local branch that tracks the other branch $ git checkout -b holger/subscr-ref-handling origin/holger/subscr-ref-handling 4.) apply my current work on top of it $ git stash apply 5.) resolve conflicts $ git mergetool I hope this information is helpful z. From laforge at gpl-violations.org Tue Oct 27 13:51:58 2009 From: laforge at gpl-violations.org (Harald Welte) Date: Tue, 27 Oct 2009 14:51:58 +0100 Subject: Status of wireshark patches Message-ID: <20091027135158.GA24126@prithivi.gnumonks.org> Hi! Holger has asked me to send an update on the status of the wireshark patches that we have in git: gsm_a_rr-rrlp.patch and abisip.patch are mainline wireshark, they can be removed from our git tree. abis_oml.patch: * does not yet dissect all the different 12.21 IEs, especially not all of the standard IEs * does not yet differentiate between BTS types. We need a preference where we can select the BTS model in order to really pars all the messages, plus vendor dependent IE tables * might possibly use non-standard C language syntax and thus not be portable to micrsofot compilers on windows. not sure what the wireshark requirements are in that regard rsli-ipaccess.patch: * does not support all of the ip.access RSL extensions yet * no major reason why it should nt be merged to wireshark * additional ip.access RSL extensions can be sent as incremental patches lucent-hmb.patch * this is just a minimal stub, should be completed more before submitting anywhere -- - Harald Welte http://gpl-violations.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Tue Oct 27 19:56:45 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 27 Oct 2009 20:56:45 +0100 Subject: [PATCH] ip.access: Header has a 16bit length in network byte order Message-ID: <1256673405-20705-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut This is confirmed by looking at the source of their dissector. The length can go up to 273 bytes apparently (again, according to the source of their dissector). Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/ipaccess.h | 3 +-- openbsc/src/input/ipaccess.c | 10 +++++----- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index eb17167..3956877 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -4,8 +4,7 @@ #include "e1_input.h" struct ipaccess_head { - u_int8_t zero; - u_int8_t len; + u_int16_t len; /* network byte order */ u_int8_t proto; u_int8_t data[0]; } __attribute__ ((packed)); diff --git a/openbsc/src/input/ipaccess.c b/openbsc/src/input/ipaccess.c index 1265982..ea44f1e 100644 --- a/openbsc/src/input/ipaccess.c +++ b/openbsc/src/input/ipaccess.c @@ -259,7 +259,7 @@ struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) { struct msgb *msg = msgb_alloc(TS1_ALLOC_SIZE, "Abis/IP"); struct ipaccess_head *hh; - int ret = 0; + int len, ret = 0; if (!msg) { *error = -ENOMEM; @@ -284,8 +284,9 @@ struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) /* then read te length as specified in header */ msg->l2h = msg->data + sizeof(*hh); - ret = recv(bfd->fd, msg->l2h, hh->len, 0); - if (ret < hh->len) { + len = ntohs(hh->len); + ret = recv(bfd->fd, msg->l2h, len, 0); + if (ret < len) { fprintf(stderr, "short read!\n"); msgb_free(msg); *error = -EIO; @@ -374,8 +375,7 @@ void ipaccess_prepend_header(struct msgb *msg, int proto) /* prepend the ip.access header */ hh = (struct ipaccess_head *) msgb_push(msg, sizeof(*hh)); - hh->zero = 0; - hh->len = msg->len - sizeof(*hh); + hh->len = htons(msg->len - sizeof(*hh)); hh->proto = proto; } -- 1.6.5.1 From laforge at gnumonks.org Thu Oct 29 15:36:04 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Oct 2009 16:36:04 +0100 Subject: [PATCH] ip.access: Header has a 16bit length in network byte order In-Reply-To: <1256673405-20705-1-git-send-email-246tnt@gmail.com> References: <1256673405-20705-1-git-send-email-246tnt@gmail.com> Message-ID: <20091029153604.GB1685@prithivi.gnumonks.org> On Tue, Oct 27, 2009 at 08:56:45PM +0100, Sylvain Munaut wrote: > From: Sylvain Munaut > > This is confirmed by looking at the source of their dissector. > The length can go up to 273 bytes apparently (again, according > to the source of their dissector). Thanks, I've always suspected it, but now after having their dissector we can be certain. I've committed your patch. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stefreak at stefreak.de Wed Oct 28 15:02:59 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Wed, 28 Oct 2009 16:02:59 +0100 Subject: [PATCH] implemented GSM340_TP_VPF_ABSOLUTE Message-ID: <20091028160259.77c7e4b5@stefreak.de> From: Steffen Neubauer - Added function "gsm340_scts" to decode the service center time stamp into a UTC/GMT timestamp - in function gsm340_validity_period: can now decode validity period format absolute. I hope it's good ;) Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 2661 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From marcjc at gmail.com Thu Oct 29 19:33:16 2009 From: marcjc at gmail.com (Marc Juul) Date: Thu, 29 Oct 2009 20:33:16 +0100 Subject: UMTS BTS for sale on ebay Message-ID: <65e44f2f0910291233j6b386bbaodcf114779dbadf99@mail.gmail.com> Hi. Just wanted to let you know about a $500 UMTS BTS for sale on ebay: http://cgi.ebay.com/ALCATEL-LUCENT-ANDREW-UMTS-BTS-1120-BASE-STATION_W0QQitemZ260395856814QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item3ca0cd73ae In case you were looking for one. -- Juul juul at labitat.dk From laforge at gnumonks.org Fri Oct 30 08:39:20 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 30 Oct 2009 09:39:20 +0100 Subject: UMTS BTS for sale on ebay In-Reply-To: <65e44f2f0910291233j6b386bbaodcf114779dbadf99@mail.gmail.com> References: <65e44f2f0910291233j6b386bbaodcf114779dbadf99@mail.gmail.com> Message-ID: <20091030083920.GF1685@prithivi.gnumonks.org> On Thu, Oct 29, 2009 at 08:33:16PM +0100, Marc Juul wrote: > Hi. > > Just wanted to let you know about a $500 UMTS BTS for sale on ebay: > > http://cgi.ebay.com/ALCATEL-LUCENT-ANDREW-UMTS-BTS-1120-BASE-STATION_W0QQitemZ260395856814QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item3ca0cd73ae Indeed very interesting. According to a press release from Nortel, this is a "zero-footprint microBTS", so something similar like the BS-11 that we've been using for quite some time. However, I could not find any more details such as frequency bands, the UMTS capabilities, etc. Also, without getting a-bis protocol traces, it will be very hard to use. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mailman-bounces at lists.gnumonks.org Sat Oct 31 08:00:02 2009 From: mailman-bounces at lists.gnumonks.org (mailman-bounces at lists.gnumonks.org) Date: Sat, 31 Oct 2009 09:00:02 +0100 Subject: OpenBSC unsubscribe notification Message-ID: xavier.carcelle at openpattern.org has been removed from OpenBSC. From laforge at gnumonks.org Sat Oct 31 18:05:49 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 31 Oct 2009 19:05:49 +0100 Subject: GPRS branch status updates Message-ID: <20091031180549.GB16562@prithivi.gnumonks.org> Hi all! I've pushed the current state of GPRS support into the 'gprs' branch. All the 'core' changes related to GPRS are already in master, so it mainly really adds the GPRS protocols (gprs_{ns,bssgp,llc}.[ch]) as well as the handling of the most importnat 04.08 GMM messages (gsm_04_08_gprs.[ch]) as well as the state management for the SGSN MM context (gprs_sgsn.[ch]). The status of the code is as follows: * NS link and BSSGP link are established between OpenBSC and the nanoBTS * LLC frames from the MS get delivered to the OpenBSC LLC code * GMM messages sent over LLC are delivered to the GMM code * The GMM code tries to respond with useful answers, permitting GPRS attach as well as routing area update What's missing: * any kind of GGSN functionality, i.e. gatewaying to PPP daemon for actual user payloads * persistant storage of SGSN MM context information, especially the attach/detach status, routing area and P-TMSI of a subscriber * PDP context activation/deactivation * flow control for the BTS as well as for each MS (BSSGP level) * retransmissions and things like acknowledged mode of LLC * support for multiple BTS There's really only one extremely ugly hack in the code right now, and that is that the IP address of the BTS is hard-coded in the ipac_gprs_send() function. You will have to enter the IP address of your BTS there to make packets in the SGSN->BTS direction delivered. Apart from that, I think the code is at a state where other interested developers can start playing with it. I am leaving to Korea on a customer assingment tomorrow and will unlikely have time to work on any GPRS code throughout the next two weeks. To get the code going, you should do the following things: * chceck out the gprs branch * hard-code your ip address into ipac_gprs_send() as indicated above * change your openbsc.cfg to use the last timeslot (TS 7) as "TCH/F_PDCH" instead of just "TCH/F" Patches / Bug reports / ... welcome Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sat Oct 31 23:38:48 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 1 Nov 2009 00:38:48 +0100 Subject: GPRS branch status updates In-Reply-To: <20091031180549.GB16562@prithivi.gnumonks.org> References: <20091031180549.GB16562@prithivi.gnumonks.org> Message-ID: <866320f70910311638q2b2f2604o520ac15d920ca9e2@mail.gmail.com> I'm getting this which I'm pretty sure is bad : <0020> abis_nm.c:594 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) IPACCESS(0xf6): SET ATTR ACK <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked bootstrapping RSL for BTS/TRX (0/0) using MCC=901 MNC=55 BSIC=63 TSC=7 <0010> abis_rsl.c:1449 channel=(bts=0,trx=0,ts=7) chan_nr=0x0f IPAC_PDCH_ACT <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=7) chan_nr=0x0f IPAC PDCH ACT ACK <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=critical failure <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Failed(01) It should go further than that shouldn't it ? Sylvain From 246tnt at gmail.com Sat Oct 31 23:48:43 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 1 Nov 2009 00:48:43 +0100 Subject: GPRS branch status updates In-Reply-To: <866320f70910311638q2b2f2604o520ac15d920ca9e2@mail.gmail.com> References: <20091031180549.GB16562@prithivi.gnumonks.org> <866320f70910311638q2b2f2604o520ac15d920ca9e2@mail.gmail.com> Message-ID: <866320f70910311648w1586398bi1ec33cc6186ebea4@mail.gmail.com> Ah, there is another hardcoded ip in nanobts_attr_nsvc0 in bsc_init.c You need to put the OpenBSC ip in there. On Sun, Nov 1, 2009 at 12:38 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > I'm getting this which I'm pretty sure is bad : > > <0020> abis_nm.c:594 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) IPACCESS(0xf6): > SET ATTR ACK > <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked > bootstrapping RSL for BTS/TRX (0/0) using MCC=901 MNC=55 BSIC=63 TSC=7 > <0010> abis_rsl.c:1449 channel=(bts=0,trx=0,ts=7) chan_nr=0x0f IPAC_PDCH_ACT > <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=7) chan_nr=0x0f IPAC PDCH ACT ACK > <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) Failure Event > Report Type=communication failure Severity=critical failure > <0020> abis_nm.c:594 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Failed(01) > > It should go further than that shouldn't it ? > > ? ?Sylvain >