From openbsc at wehrle.it Thu Jul 7 17:16:51 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Thu, 07 Jul 2011 19:16:51 +0200 Subject: sms bugfix In-Reply-To: <4D83D64B.30500@wehrle.it> References: <4D83D64B.30500@wehrle.it> Message-ID: <4E15EA03.5040200@wehrle.it> Hello Here it is. After some delay (sorry!) i've finished the sms-patch. As already mentioned, i have changed the database-format for the SMS-table. If you already have a database, you have to _drop_ the SMS-table! If you have questions, please feel free to ask me. Best Regards Dennis Wehrle On 18.03.2011 23:01, Dennis Wehrle wrote: > Hello > > Our goal was to send status sms via the vty interface. But all of our > sms were cropped. In contrast sms from one MS to another MS are > displayed correctly (despite the fact, that the text at the database > contains several '@' at the end / the user_data contains several > zero-octets). Therefore i have inspect the code and found several bugs. > > The main problem is that the "user_data_len" is not correctly used. As > per GSM 03.40, 9.2.3.16 TP?User?Data?Length (TP?UDL): > "If the TP?User?Data is coded using the GSM 7 bit default alphabet, > the TP?User?Data?Length field gives an integer representation of the > number of septets within the TP?User?Data field to follow." > > Currently the "user_data_len" contains the number of octets (returned > from gsm_7bit_encode(...) at gsm_utils.c (libosmocore)). > The big problem here is that this information is not unique, e.g.: > 1.) 46 non-extension characters + 1 extension character => (46 * 7 bit > + (1 * (2 * 7 bit))) / 8 bit = 42 octets > 2.) 47 non-extension characters => (47 * 7 bit) / 8 bit = 41,125 = 42 > octets > 3.) 48 non-extension characters => (48 * 7 bit) / 8 bit = 42 octects > > But the MS has to know the correct "user_data_len" to decode the > correct number of characters. > For this reason i updated the gsm_7bit_encode() function to return the > correct number of septets. However sometimes it is needed to know the > correct number of octets (e.g. at gsm_04_11.c: gsm340_gen_tpdu(...)) > => i added a function to gsm_utils.c named: > uint8_t get_octet_len(const uint8_t sept_len) > > > I have also fixed the problem, that the sms are wrongly stored / > displayed on the database. But the solution on the function > *sms_from_result(...) (at db.c) is not really "beautiful". This is > because there exists no "user_data_len" field at the database. To > store the right value for "user_data_len" (which is further needed) i > have to get the length from the "text" field. Unfortunately this is > not enough. If the text contains extension characters like {[]} etc. > then the "user_data_len" has to be bigger because these characters > needs two septets. Therefore i use a switch statement so search for > these characters. A better solution for that is to store the right > "user_data_len" to the database (on the encoding / decoding > procedure). But i don't know if this is a suitable solution for all of > you (because you have to change your database structure etc.). > > > Best Regards > Dennis Wehrle > > -------------- next part -------------- A non-text attachment was scrubbed... Name: sms_libosmocore.patch Type: text/x-patch Size: 18678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sms_openbsc.patch Type: text/x-patch Size: 18944 bytes Desc: not available URL: From holger at freyther.de Sat Jul 23 06:54:31 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 23 Jul 2011 08:54:31 +0200 Subject: sms bugfix In-Reply-To: <4E15EA03.5040200@wehrle.it> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> Message-ID: <4E2A7027.3010504@freyther.de> On 07/07/2011 07:16 PM, Dennis Wehrle wrote: > Hello hi, I thought you sent this last week, I try to look at it today. From holger at freyther.de Sun Jul 24 13:01:00 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 24 Jul 2011 15:01:00 +0200 Subject: sms bugfix In-Reply-To: <4E15EA03.5040200@wehrle.it> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> Message-ID: <4E2C178C.1070309@freyther.de> On 07/07/2011 07:16 PM, Dennis Wehrle wrote: > Hello > > Here it is. After some delay (sorry!) i've finished the sms-patch. As already > mentioned, i have changed the database-format for the SMS-table. > If you already have a database, you have to _drop_ the SMS-table! > > If you have questions, please feel free to ask me. Hi Dennis, the biggest issue I see is the change of signatures in libosmocore (e.g. adding a parameter). We will need to introduce a method with another name. The next issue is with coding style (yeah, we are picky...). Would you have time to work on it? Do you need a hand with it? holger From holger at freyther.de Sun Jul 24 18:20:53 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 24 Jul 2011 20:20:53 +0200 Subject: sms bugfix In-Reply-To: <4E2C178C.1070309@freyther.de> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> Message-ID: <4E2C6285.1020101@freyther.de> On 07/24/2011 03:01 PM, Holger Hans Peter Freyther wrote: > Would you have time to work on it? Do you need a hand with it? Hi Dennis, I pushed zecke/sms-fixes-by-dennis-wehrle to libosmocore, do you agree with the change? I have moved the VTY change to a new patch (if you want to I can use you as author), I left the 'normal' _decode message like it was and added a new method to it, I also had some cosmetic changes (formation). I would also like to see a rewording of the commit message. I am now moving to the OpenBSC part of your patch. thanks holger From holger at freyther.de Sun Jul 24 18:30:26 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 24 Jul 2011 20:30:26 +0200 Subject: sms bugfix In-Reply-To: <4E2C6285.1020101@freyther.de> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> <4E2C6285.1020101@freyther.de> Message-ID: <4E2C64C2.1040504@freyther.de> On 07/24/2011 08:20 PM, Holger Hans Peter Freyther wrote: > On 07/24/2011 03:01 PM, Holger Hans Peter Freyther wrote: > >> Would you have time to work on it? Do you need a hand with it? > > I am now moving to the OpenBSC part of your patch. Hi Dennis, do you think you could split the work into multiple patches? E.g. 1.) Fix the truncation of the message when sent from the VTY 2.) Move from id to number in the SMS Table (also bump the db version) 3.) Implement multipart SMS? I will try to start with 1st, it would be very kind of you could work on the other parts. holger From holger at freyther.de Sun Jul 24 20:18:56 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 24 Jul 2011 22:18:56 +0200 Subject: sms bugfix In-Reply-To: <4E2C64C2.1040504@freyther.de> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> <4E2C6285.1020101@freyther.de> <4E2C64C2.1040504@freyther.de> Message-ID: <4E2C7E30.4010006@freyther.de> On 07/24/2011 08:30 PM, Holger Hans Peter Freyther wrote: > > I will try to start with 1st, it would be very kind of you could work on the > other parts. E.g. I think this will fix the truncation issue from the VTY. From zecke at selfish.org Sun Jul 24 19:57:56 2011 From: zecke at selfish.org (Holger Hans Peter Freyther) Date: Sun, 24 Jul 2011 21:57:56 +0200 Subject: [PATCH] sms: Kill the text field, fix the size and truncation Message-ID: Patches from Dennis Wehrle, fix the truncation of SMS from the VTY --- openbsc/src/libmsc/db.c | 34 +++++++++++++++------------------- openbsc/src/libmsc/gsm_04_11.c | 2 +- openbsc/src/libmsc/gsm_04_80.c | 4 +++- 3 files changed, 19 insertions(+), 21 deletions(-) diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index 53675f7..d1dd749 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -51,7 +51,7 @@ static char *create_stmts[] = { "INSERT OR IGNORE INTO Meta " "(key, value) " "VALUES " - "('revision', '2')", + "('revision', '3')", "CREATE TABLE IF NOT EXISTS Subscriber (" "id INTEGER PRIMARY KEY AUTOINCREMENT, " "created TIMESTAMP NOT NULL, " @@ -108,9 +108,7 @@ static char *create_stmts[] = { "ud_hdr_ind INTEGER NOT NULL, " "dest_addr TEXT, " "user_data BLOB, " /* TP-UD */ - /* additional data, interpreted from SMS */ - "header BLOB, " /* UD Header */ - "text TEXT " /* decoded UD after UDH */ + "ud_length INTEGER NOT NULL " ")", "CREATE TABLE IF NOT EXISTS VLR (" "id INTEGER PRIMARY KEY AUTOINCREMENT, " @@ -177,7 +175,7 @@ static int check_db_revision(void) return -EINVAL; } rev = dbi_result_get_string(result, "value"); - if (!rev || atoi(rev) != 2) { + if (!rev || atoi(rev) != 3) { dbi_result_free(result); return -EINVAL; } @@ -990,15 +988,16 @@ int db_subscriber_assoc_imei(struct gsm_subscriber *subscriber, char imei[GSM_IM int db_sms_store(struct gsm_sms *sms) { dbi_result result; - char *q_text, *q_daddr; + char *q_daddr; unsigned char *q_udata; char *validity_timestamp = "2222-2-2"; + uint8_t octet_len = 0; /* FIXME: generate validity timestamp based on validity_minutes */ - dbi_conn_quote_string_copy(conn, (char *)sms->text, &q_text); dbi_conn_quote_string_copy(conn, (char *)sms->dest_addr, &q_daddr); - dbi_conn_quote_binary_copy(conn, sms->user_data, sms->user_data_len, + octet_len = gsm_get_octet_len(sms->user_data_len); + dbi_conn_quote_binary_copy(conn, sms->user_data, octet_len, &q_udata); /* FIXME: correct validity period */ result = dbi_conn_queryf(conn, @@ -1006,15 +1005,14 @@ int db_sms_store(struct gsm_sms *sms) "(created, sender_id, receiver_id, valid_until, " "reply_path_req, status_rep_req, protocol_id, " "data_coding_scheme, ud_hdr_ind, dest_addr, " - "user_data, text) VALUES " + "user_data, ud_length) VALUES " "(datetime('now'), %llu, %llu, %u, " - "%u, %u, %u, %u, %u, %s, %s, %s)", + "%u, %u, %u, %u, %u, %s, %s, %u)", sms->sender->id, sms->receiver ? sms->receiver->id : 0, validity_timestamp, sms->reply_path_req, sms->status_rep_req, sms->protocol_id, sms->data_coding_scheme, sms->ud_hdr_ind, - q_daddr, q_udata, q_text); - free(q_text); + q_daddr, q_udata, sms->user_data_len); free(q_daddr); free(q_udata); @@ -1029,8 +1027,9 @@ static struct gsm_sms *sms_from_result(struct gsm_network *net, dbi_result resul { struct gsm_sms *sms = sms_alloc(); long long unsigned int sender_id, receiver_id; - const char *text, *daddr; + const char *daddr; const unsigned char *user_data; + int octet_len; if (!sms) return NULL; @@ -1059,17 +1058,14 @@ static struct gsm_sms *sms_from_result(struct gsm_network *net, dbi_result resul sms->dest_addr[sizeof(sms->dest_addr)-1] = '\0'; } - sms->user_data_len = dbi_result_get_field_length(result, "user_data"); + sms->user_data_len = dbi_result_get_uint(result, "ud_length"); user_data = dbi_result_get_binary(result, "user_data"); + if (sms->user_data_len > sizeof(sms->user_data)) sms->user_data_len = (uint8_t) sizeof(sms->user_data); + octet_len = gsm_get_octet_len(sms->user_data_len); memcpy(sms->user_data, user_data, sms->user_data_len); - text = dbi_result_get_string(result, "text"); - if (text) { - strncpy(sms->text, text, sizeof(sms->text)); - sms->text[sizeof(sms->text)-1] = '\0'; - } return sms; } diff --git a/openbsc/src/libmsc/gsm_04_11.c b/openbsc/src/libmsc/gsm_04_11.c index ee7f577..ad3b300 100644 --- a/openbsc/src/libmsc/gsm_04_11.c +++ b/openbsc/src/libmsc/gsm_04_11.c @@ -628,7 +628,7 @@ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *m switch (sms_alphabet) { case DCS_7BIT_DEFAULT: - gsm_7bit_decode(gsms->text, smsp, gsms->user_data_len); + gsm_7bit_decode_hdr(gsms->text, smsp, gsms->user_data_len, gsms->ud_hdr_ind); break; case DCS_8BIT_DATA: case DCS_UCS2: diff --git a/openbsc/src/libmsc/gsm_04_80.c b/openbsc/src/libmsc/gsm_04_80.c index 39738a5..c7dad43 100644 --- a/openbsc/src/libmsc/gsm_04_80.c +++ b/openbsc/src/libmsc/gsm_04_80.c @@ -68,12 +68,14 @@ int gsm0480_send_ussd_response(struct gsm_subscriber_connection *conn, struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; uint8_t *ptr8; + uint8_t octet_len; int response_len; /* First put the payload text into the message */ ptr8 = msgb_put(msg, 0); response_len = gsm_7bit_encode(ptr8, response_text); - msgb_put(msg, response_len); + octet_len = gsm_get_octet_len(response_len); + msgb_put(msg, octet_len); /* Then wrap it as an Octet String */ msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG); -- 1.7.4.1 --------------090106040904000308080203-- From openbsc at wehrle.it Wed Jul 27 15:25:24 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Wed, 27 Jul 2011 17:25:24 +0200 Subject: sms bugfix In-Reply-To: <4E2C64C2.1040504@freyther.de> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> <4E2C6285.1020101@freyther.de> <4E2C64C2.1040504@freyther.de> Message-ID: <4E302DE4.5090208@wehrle.it> Hello Holger Here are the patches. It was necessary to rewrite your patch for task 1 because some code was missing. Best Regards Dennis On 24.07.2011 20:30, Holger Hans Peter Freyther wrote: > On 07/24/2011 08:20 PM, Holger Hans Peter Freyther wrote: >> On 07/24/2011 03:01 PM, Holger Hans Peter Freyther wrote: >> >>> Would you have time to work on it? Do you need a hand with it? > >> >> I am now moving to the OpenBSC part of your patch. > > Hi Dennis, > > do you think you could split the work into multiple patches? E.g. > > 1.) Fix the truncation of the message when sent from the VTY > 2.) Move from id to number in the SMS Table (also bump the db version) > 3.) Implement multipart SMS? > > I will try to start with 1st, it would be very kind of you could work on the > other parts. > > holger > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sms-Kill-the-text-field-fix-the-size-and-truncation.patch Type: text/x-patch Size: 6907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-change-sms-table-ids-to-extensions.patch Type: text/x-patch Size: 6613 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-multipart-sms-from-vty.patch Type: text/x-patch Size: 10082 bytes Desc: not available URL: From openbsc at wehrle.it Mon Jul 25 15:46:06 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Mon, 25 Jul 2011 17:46:06 +0200 Subject: sms bugfix In-Reply-To: <4E2C178C.1070309@freyther.de> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> Message-ID: <4E2D8FBE.4040505@wehrle.it> Hi Holger On 24.07.2011 20:20, Holger Hans Peter Freyther wrote: > > Hi Dennis, > > I pushed zecke/sms-fixes-by-dennis-wehrle to libosmocore, do you agree with > the change? Sure, i agree with your changes. > I have moved the VTY change to a new patch (if you want to I can > use you as author), I think, it's not necessary :) > I left the 'normal' _decode message like it was and added > a new method to it, I also had some cosmetic changes (formation). I would also > like to see a rewording of the commit message. I think there are some typos in my commit message. For instance, in the first sentence, i think it should be 'were' instead of 'where'. On 24.07.2011 20:30, Holger Hans Peter Freyther wrote: > Hi Dennis, > > do you think you could split the work into multiple patches? E.g. > > 1.) Fix the truncation of the message when sent from the VTY > 2.) Move from id to number in the SMS Table (also bump the db version) > 3.) Implement multipart SMS? > > I will try to start with 1st, it would be very kind of you could work on the > other parts. Sure, i can split it up. My understanding is that the patch for task 2.) depends on task 1.) and the patch for task 3.) depends on task 2.). (create a patch between the commits) Right? On 24.07.2011 22:18, Holger Hans Peter Freyther wrote: > On 07/24/2011 08:30 PM, Holger Hans Peter Freyther wrote: > >> >> I will try to start with 1st, it would be very kind of you could work on the >> other parts. > > E.g. I think this will fix the truncation issue from the VTY. Ok, i can work on the missing two parts. I will also have a look at your patch. Best Regards Dennis From holger at freyther.de Mon Jul 25 16:13:54 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 25 Jul 2011 18:13:54 +0200 Subject: sms bugfix In-Reply-To: <4E2D8FBE.4040505@wehrle.it> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> <4E2D8FBE.4040505@wehrle.it> Message-ID: <4E2D9642.90404@freyther.de> On 07/25/2011 05:46 PM, Dennis Wehrle wrote: > Hi Holger >> I have moved the VTY change to a new patch (if you want to I can >> use you as author), > > I think, it's not necessary :) hehe, we are picky, one change, one (atomic) reason. > I think there are some typos in my commit message. For instance, in the first > sentence, i think it should be 'were' instead of 'where'. Yes, and in general 72/80 chars per line limit. (also try to follow it in the code) > > Sure, i can split it up. My understanding is that the patch for task 2.) > depends on task 1.) and the patch for task 3.) depends on task 2.). (create a > patch between the commits) Right? exactly, it should be commits depending on each other. > Ok, i can work on the missing two parts. I will also have a look at your patch. > thanks. From openbsc at wehrle.it Mon Jul 25 16:39:05 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Mon, 25 Jul 2011 18:39:05 +0200 Subject: sms bugfix In-Reply-To: <4E2D9642.90404@freyther.de> References: <4D83D64B.30500@wehrle.it> <4E15EA03.5040200@wehrle.it> <4E2C178C.1070309@freyther.de> <4E2D8FBE.4040505@wehrle.it> <4E2D9642.90404@freyther.de> Message-ID: <4E2D9C29.3080408@wehrle.it> Hi Holger On 25.07.2011 18:13, Holger Hans Peter Freyther wrote: > On 07/25/2011 05:46 PM, Dennis Wehrle wrote: >> Hi Holger > >>> I have moved the VTY change to a new patch (if you want to I can >>> use you as author), >> >> I think, it's not necessary :) > > hehe, we are picky, one change, one (atomic) reason. I meant: it's not necessary to write me as the author :) > > >> I think there are some typos in my commit message. For instance, in the first >> sentence, i think it should be 'were' instead of 'where'. > > Yes, and in general 72/80 chars per line limit. (also try to follow it in the > code) > Ok, i will pay attention to only use 72/80 chars per line. I will also pay attention to make a space before and after brackets. Best Regards Dennis From holger at freyther.de Tue Jul 12 21:40:06 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 12 Jul 2011 23:40:06 +0200 Subject: Licensing of the wiki In-Reply-To: <000e0ce0b65624622504a1e5f699@google.com> References: <000e0ce0b65624622504a1e5f699@google.com> Message-ID: <4E1CBF36.8030607@freyther.de> On 04/27/2011 02:55 PM, 246tnt at gmail.com wrote: >> If the major contributors to the wiki would agree to a license, I would >> update the wiki accordingly. > > FWIW, CC-BY-SA is fine for me. I also don't really see the need for NC here. > CC-BY-SA is fine for me as well, how did you plan to update the wiki? add the license next to the impressum? holger From laforge at gnumonks.org Wed Jul 13 09:55:29 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 13 Jul 2011 11:55:29 +0200 Subject: Licensing of the wiki In-Reply-To: <4E1CBF36.8030607@freyther.de> References: <000e0ce0b65624622504a1e5f699@google.com> <4E1CBF36.8030607@freyther.de> Message-ID: <20110713095529.GI17260@prithivi.gnumonks.org> On Tue, Jul 12, 2011 at 11:40:06PM +0200, Holger Hans Peter Freyther wrote: > On 04/27/2011 02:55 PM, 246tnt at gmail.com wrote: > >> If the major contributors to the wiki would agree to a license, I would > >> update the wiki accordingly. > > > > FWIW, CC-BY-SA is fine for me. I also don't really see the need for NC here. > > > > CC-BY-SA is fine for me as well, how did you plan to update the wiki? add the > license next to the impressum? I've added the CC icon/link to the bottom of the page Contact/Impressum is now in the 'metanav' bar on the top rigtht of the site. I've also added a main navigation bar on top, with links to all of the *.osmocom.org sites. The layout/design is crap, I'm happy to accept patches against http://osmocom.org/osmocom/style.css ;) 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 Sat Jul 16 13:51:44 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Jul 2011 15:51:44 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <4DEBCEB5.70106@informatik.uni-freiburg.de> References: <20110604190601.GN21708@prithivi.gnumonks.org> <4DEBCEB5.70106@informatik.uni-freiburg.de> Message-ID: <20110716135144.GT10557@prithivi.gnumonks.org> Hi Konrad, On Sun, Jun 05, 2011 at 08:45:09PM +0200, Konrad Meier wrote: > We have two nanoBTS-Booster 1800 here at the university. If for some > reason the Ericsson RBS is not working it should be possible to lend > you the two bossters for the time of the camp. We also have a > splitter and combiner. I will test the splitter/combiner in > combination with a booster at the GPN end of this month. As it turns out, I have not yet managed to get the Motorola BTSs working, despite putting lots of time into it. There are many reasons, but basically the Motorola BSS is _extremely_ different from normal GSM BSS So while I might still get it to work, I doubt it, and it would be better to pursue different plans now. We can certainly bring together a sufficient number of nanoBTS units to fill all our ARFCN. The problem now is the coverage <-> capacity problem, i.e. I don't want 6 BTSs with small coverage area, but rather something like 2 or 3 sites (max) with each 2 or 3 BTSs. Have you meanwhile tested your splitter/combiner/booster setup? does it work? What I can really easily re-use from the Motorola BTS are 2x hybrid combiner/duplexer units, i.e. something that has the following ports: * 1 antenna output, bidirectional, 7/16" socket * 2 PA Tx inputs, SMA * 1 Rx antenna output, N-type So if you don't have a similar setup, we could use those together with two nanoBTS with a Rx LNA and a Rx splitter. I have six of those hybrid combiner/duplexers. I _might_ also get the Rx LNA + splitter of the Motorola BTSs to work, but those are less stand-alone and I'm not certain about it. What do you have in terms of antennas? Also, when would you be able to provide the equipment to me? I would want to put everything together + test it well ahead of the camp, probably around August 1st. Does anyone else on this list have any 1800 MHz PA, Mixer, Duplexer, etc. that he would be able to borrow for the Camp GSM network? 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 meierk at informatik.uni-freiburg.de Mon Jul 18 14:22:19 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Mon, 18 Jul 2011 16:22:19 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <20110716135144.GT10557@prithivi.gnumonks.org> References: <20110604190601.GN21708@prithivi.gnumonks.org> <4DEBCEB5.70106@informatik.uni-freiburg.de> <20110716135144.GT10557@prithivi.gnumonks.org> Message-ID: <4E24419B.5070005@informatik.uni-freiburg.de> Hi Harald, On 16.07.2011 15:51, Harald Welte wrote: >> We have two nanoBTS-Booster 1800 here at the university. If for some >> reason the Ericsson RBS is not working it should be possible to lend >> you the two bossters for the time of the camp. We also have a >> splitter and combiner. I will test the splitter/combiner in >> combination with a booster at the GPN end of this month. > > As it turns out, I have not yet managed to get the Motorola BTSs > working, despite putting lots of time into it. There are many reasons, > but basically the Motorola BSS is _extremely_ different from normal GSM BSS > > So while I might still get it to work, I doubt it, and it would be > better to pursue different plans now. > > We can certainly bring together a sufficient number of nanoBTS units to > fill all our ARFCN. The problem now is the coverage<-> capacity > problem, i.e. I don't want 6 BTSs with small coverage area, but rather > something like 2 or 3 sites (max) with each 2 or 3 BTSs. > > Have you meanwhile tested your splitter/combiner/booster setup? does it > work? The original plan was to test the setup at the GPN. But stupid me forgot to order the RJ69 connectors :-( Last week I was finally able to try the multi TRX setup with two nanoBTS, but without success. TRX 0 worked well but TRX 1 was not working for some reason. I think the problem is the initialization of TRX 1. The nanoBTS are pretty new: Equipment_Version='165g029_73' Software_Version='168a352_v142b30d0' Unfortunately I didn't had the time to investigate the issue further. Maybe tomorrow I have some time. > What I can really easily re-use from the Motorola BTS are 2x hybrid > combiner/duplexer units, i.e. something that has the following ports: > > * 1 antenna output, bidirectional, 7/16" socket > * 2 PA Tx inputs, SMA > * 1 Rx antenna output, N-type > > So if you don't have a similar setup, we could use those together with > two nanoBTS with a Rx LNA and a Rx splitter. > > I have six of those hybrid combiner/duplexers. I have two "SPLIT2P-SMA" from "Global Professional" [1]. My Idea was to use these two units with one naoBTS-Booster like shown here: [2] Your idea sounds good too, but would require some RX LNA. > I _might_ also get the Rx LNA + splitter of the Motorola BTSs to work, > but those are less stand-alone and I'm not certain about it. > > What do you have in terms of antennas? We have two omnidirectional antennas from PROCOM: CXL 1800-3 More information: [3] > Also, when would you be able to provide the equipment to me? I would > want to put everything together + test it well ahead of the camp, > probably around August 1st. Ok, I will see what I can do. Best regards Konrad Meier [1] http://www.globalprofessional.co.uk/acatalog/Splitter_mod.html [2] http://lab.ks.uni-freiburg.de/attachments/download/260/setup.png [3] http://www.procom.dk/eng/Page_menu/Products/Base_Station_Antennas/1.3_-_2.0_GHz/Omnidirectional_Antennas/CXL_1800-3 From laforge at gnumonks.org Mon Jul 18 16:26:49 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 18 Jul 2011 18:26:49 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <4E24419B.5070005@informatik.uni-freiburg.de> References: <20110604190601.GN21708@prithivi.gnumonks.org> <4DEBCEB5.70106@informatik.uni-freiburg.de> <20110716135144.GT10557@prithivi.gnumonks.org> <4E24419B.5070005@informatik.uni-freiburg.de> Message-ID: <20110718162649.GG29859@prithivi.gnumonks.org> Hi Konrad, On Mon, Jul 18, 2011 at 04:22:19PM +0200, Konrad Meier wrote: > The original plan was to test the setup at the GPN. But stupid me > forgot to order the RJ69 connectors :-( > Last week I was finally able to try the multi TRX setup with two > nanoBTS, but without success. TRX 0 worked well but TRX 1 was not > working for some reason. I think the problem is the initialization > of TRX 1. no problem. I have plenty of multi-trx setup experience, I doubt we would have any problem setting that part up at the camp. > I have two "SPLIT2P-SMA" from "Global Professional" [1]. My Idea was > to use these two units with one naoBTS-Booster like shown here: [2] unfortnately this url fails to load: [2] http://lab.ks.uni-freiburg.de/attachments/download/260/setup.png I can ping the server, and I can connect to port 80, but it never responds to a GET request. > Your idea sounds good too, but would require some RX LNA. Sylvain seems to have built some uplink LNAs. > We have two omnidirectional antennas from PROCOM: CXL 1800-3 > More information: [3] Ok. I have just ordered a couple of 1.4m long 8dBi gain omni antennas, just in case. I also ordered 50m low-loss cable (20dB on 100m) and 20 matching N plugs. A 500m roll of CAT6 cable for the abis/ip back-haul is here already > Ok, I will see what I can do. thanks in advance. -- - 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 Jul 21 20:27:06 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Jul 2011 22:27:06 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <4E24419B.5070005@informatik.uni-freiburg.de> References: <20110604190601.GN21708@prithivi.gnumonks.org> <4DEBCEB5.70106@informatik.uni-freiburg.de> <20110716135144.GT10557@prithivi.gnumonks.org> <4E24419B.5070005@informatik.uni-freiburg.de> Message-ID: <20110721202706.GC11553@prithivi.gnumonks.org> Hi Konrad, On Mon, Jul 18, 2011 at 04:22:19PM +0200, Konrad Meier wrote: > I have two "SPLIT2P-SMA" from "Global Professional" [1]. My Idea was > to use these two units with one naoBTS-Booster like shown here: [2] > [2] http://lab.ks.uni-freiburg.de/attachments/download/260/setup.png Reading that diagram: What ist the "combiner" ? Are you suggesting to use a "SPLIT2P-SMA" for that purpose? I'd strongly discourage, as you would still get a lot of Tx power leakage from nanoBTS1 into the amplifier of nanoBTS2. I doubt that they would like that. The alternative here really would be to use one of my hybrid combiner/duplexers in place. We simply ignore the Rx path and use it to combine the Tx path of the two BTS before feeding into the amplifier. > We have two omnidirectional antennas from PROCOM: CXL 1800-3 > More information: [3] > > >Also, when would you be able to provide the equipment to me? I would > >want to put everything together + test it well ahead of the camp, > >probably around August 1st. > > Ok, I will see what I can do. Has there been any news on this? I think we would definitely like to make use of your 2 nanoBTS boosters, even if we can only use each of them with a single TRX setup. 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 meierk at informatik.uni-freiburg.de Fri Jul 22 23:22:08 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Sat, 23 Jul 2011 01:22:08 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <20110721202706.GC11553@prithivi.gnumonks.org> References: <20110604190601.GN21708@prithivi.gnumonks.org> <4DEBCEB5.70106@informatik.uni-freiburg.de> <20110716135144.GT10557@prithivi.gnumonks.org> <4E24419B.5070005@informatik.uni-freiburg.de> <20110721202706.GC11553@prithivi.gnumonks.org> Message-ID: <4E2A0620.7010802@informatik.uni-freiburg.de> Hi, >>> Also, when would you be able to provide the equipment to me? I would >>> want to put everything together + test it well ahead of the camp, >>> probably around August 1st. >> >> Ok, I will see what I can do. > > Has there been any news on this? I think we would definitely like to > make use of your 2 nanoBTS boosters, even if we can only use each of > them with a single TRX setup. I can send you the two boosters end of next week. Regards Konrad From laforge at gnumonks.org Fri Jul 22 21:44:15 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 22 Jul 2011 23:44:15 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <20110604190601.GN21708@prithivi.gnumonks.org> References: <20110604190601.GN21708@prithivi.gnumonks.org> Message-ID: <20110722214415.GL11553@prithivi.gnumonks.org> Hi all! The camp is getting closer and closer. In the past weeks, folks like Sylvain, Dieter and I were trying desparately to find a good technical solution for running the GSM network at the CCC Camp. The original intention of using the Motorola Horizon macro BTSs has unfortunately not worked out, despite spending man-weeks of time in exploring and reverse engineering the highly proprietary Motorola variant of GSM. While it has been a fascinating journey in distributed systems, it has not come anywhere close to using the equipment for actual network operation. The nanoBTSs that we use during the 26C3, 27C3 and other events are too low-power / low-range for the area we want to cover. There are some boosters and LNAs, but we don't have them in the quantity that we anticipate to require (ideally 6TRX). The BS-11 units we have are higher power but all GSM 900 only, for which we cannot get a license from the regulatory authority. The Ericsson RBS2308 are higher power and 4TRX, but they are 1900 MHz :/ Luckily, Dieter has recentl done some work for a university of applied sciences in Bavaria. They have obtained some Nokia Metrosite equipment (from O2 Germany, I believe), and Dieter is helping them with OpenBSC support for it. So just in time, Dieter has managed to get them working _plus_ the university thankfully has agreed to borrow them the two units for the camp. One of them is 2TRX, the other is 3TRX. They have integrated duplexers but no combiners, i.e. we need one Antenna for each TRX. Each of the TRX has 5W output power. I have ordered some nice 140cm long omnidirectional 8dBi gain antennas as well as cable that will only produce 2dB loss over the estimated 10m that we have to cover. The back-haul to the BSC will be classic E1 based. All equipment should be at my place around August 1st. I'm planning to slowly build the network starting from August 3rd onwards. This depends a bit on when we will have electrical power in the shelters where the units are to be located, and when the museum will have the telescope antenna poles ready for us. The license permits us operating from August 3rd onwards, so we can do coverage testing and the like as soon as the BTSs (or even only one of them) is operational. It would be great to know who will be able to give me a hand with the build-up starting from which day/time on. 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 Fri Jul 22 22:09:55 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 23 Jul 2011 00:09:55 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: <20110722214415.GL11553@prithivi.gnumonks.org> References: <20110604190601.GN21708@prithivi.gnumonks.org> <20110722214415.GL11553@prithivi.gnumonks.org> Message-ID: Hi, > It would be great to know who will be able to give me a hand with the > build-up starting from which day/time on. I'm should be there on the 9th, mid afternoon. (landing at TXL at 13h20). A bit late I guess, I should have booked a flight a couple of days earlier ... But if there is anything left to do then, I'm happy to help. Cheers, Sylvain From laforge at gnumonks.org Fri Jul 22 22:45:47 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 23 Jul 2011 00:45:47 +0200 Subject: GSM @ Camp 2011 preparations In-Reply-To: References: <20110604190601.GN21708@prithivi.gnumonks.org> <20110722214415.GL11553@prithivi.gnumonks.org> Message-ID: <20110722224547.GR11553@prithivi.gnumonks.org> Hi Sylvain, On Sat, Jul 23, 2011 at 12:09:55AM +0200, Sylvain Munaut wrote: > > It would be great to know who will be able to give me a hand with the > > build-up starting from which day/time on. > > I'm should be there on the 9th, mid afternoon. (landing at TXL at 13h20). ok. > A bit late I guess, I should have booked a flight a couple of days > earlier don't worry. Peter is in Berlin and is available to help even from the 3rd onwards. Depending on factors like power, pole availability, ... we might even delay the start to the 5th. I think our biggest challenges will not really be GSM related but mechanical, like cabling, plugs, safely putting the units to the side of the shelters, mechanically mounting the antennas, etc. Also, as we don't use any external LNA, PA, Duplexer, Combiner, the setup is extremely simple on the RF side, too... > ... But if there is anything left to do then, I'm happy to help. I think there will be quite a bit of operations + maintenance and possibly bugfixing during the camp... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pablo at gnumonks.org Tue Jul 5 18:25:23 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 05 Jul 2011 20:25:23 +0200 Subject: [PATCH 0/4] use standalone libtalloc instead of own copy In-Reply-To: <1308071692-6041-1-git-send-email-pablo@gnumonks.org> References: <1308071692-6041-1-git-send-email-pablo@gnumonks.org> Message-ID: <4E135713.5010803@gnumonks.org> On 14/06/11 19:14, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > Hi! > > With these patches, libosmocore, libosmo-sccp, openbsc and osmo-tetra > does not use anymore our own copy of talloc and they rely on the > standalone library that is provided by major distributors. > > The osmocom-bb part is still missing, my idea is to include a copy > of libtalloc in the tree in the shared/ directory via rsync. This > patch will follow later since we can still rely on the outdated > copy of libosmocore. > > Please, apply. I have rebased these patches, they live under pablo/talloc in libosmocore, libosmo-sccp, openbsc and osmo-tetra. Please, merge them. From gugod at gugod.org Sat Jul 2 13:35:19 2011 From: gugod at gugod.org (Kang-min Liu) Date: Sat, 2 Jul 2011 21:35:19 +0800 Subject: Question about how to read / send SMS from an external program Message-ID: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> Hi all, I have been working on a project involved using osmo-nitb and trying to read / send SMS by doing SQL queries directly hlr.sqlite3 in a perl program, but I cannot figure out the encode/decode process on the "user_data" field. From "sms_from_text" function in libmsc/gsm_04_11.c, it appears to me that the content of user_data is a gsm_7bit_encode-ed of text if the SMS is sent with VTY interface. I then tried to port gsm_7bit_decode to perl and the implementation successfully decoded two test strings in libosmocore/tests/sms/sms_test.c. However it does not successfully decode any SMS user_data record in hlr.sqlite3 to the original text. The result looks like just a piece of garbled text, not even close to any human-readable text at all. I also tried briefly to include gsm0338 decoding process, or some other perl-based implementation from CPAN, no success at all. I am currently out of ideas to try. It will be really appreciated if anyone with similar experience can offer insight to my issue here. From holger at freyther.de Sat Jul 2 14:19:29 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 02 Jul 2011 16:19:29 +0200 Subject: Question about how to read / send SMS from an external program In-Reply-To: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> References: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> Message-ID: <4E0F28F1.30404@freyther.de> On 07/02/2011 03:35 PM, Kang-min Liu wrote: > Hi all, Hi Kang-min, Our gsm_7bit_encode has some issues (e.g. see the archive of this mailinglist), from a quick look at the sms_from_text routine you mention, and the store inside the db.c i would assume your perl code is doing something wrong. Can you share your perl code? Alternatively the following debug hint might be useful: 1.) send a SMS through the telnet interface.. 2.) osmo_hexdump the sms->user_data in the sms_from_text 3.) also directly decode the string there... (in C) 4.) dump the BLOB for the database in db_sms_store good luck holger From 246tnt at gmail.com Sat Jul 2 14:19:33 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 2 Jul 2011 16:19:33 +0200 Subject: Question about how to read / send SMS from an external program In-Reply-To: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> References: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> Message-ID: Hi > It will be really appreciated if anyone with similar experience can offer insight to my issue here. No idea if that's the problem but one known issue with external interaction to hlr.sqlite3 is that the binary coding/decoding routinge (to store binary data inside sqlite) are not standard. The DBI interface we use has it's own routines and if you try a 'native' sqlite3 driver, you may not get the right data. When accessing binary data fields from a auto-provisionning app for 27c3 from a python script, I actually had to write my own 'dbi-equivalent' binary coding routine ... See the dbi source code for more info about the algorithm itself. Cheers, Sylvain From gugod at gugod.org Sun Jul 3 03:54:23 2011 From: gugod at gugod.org (Kang-min Liu) Date: Sun, 3 Jul 2011 11:54:23 +0800 Subject: Question about how to read / send SMS from an external program In-Reply-To: References: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> Message-ID: On 2011/7/2, at ??10:19, Sylvain Munaut wrote: > Hi > >> It will be really appreciated if anyone with similar experience can offer insight to my issue here. > > No idea if that's the problem but one known issue with external > interaction to hlr.sqlite3 is that the binary coding/decoding routinge > (to store binary data inside sqlite) are not standard. > > The DBI interface we use has it's own routines and if you try a > 'native' sqlite3 driver, you may not get the right data. When > accessing binary data fields from a auto-provisionning app for 27c3 > from a python script, I actually had to write my own 'dbi-equivalent' > binary coding routine ... > > See the dbi source code for more info about the algorithm itself. Sylvian, thanks a lot for the great hint! I also ported the dbd_decode_binary routine to perl an it correctly decoded the sms text from user_data. The overall logic looks like: my $dbh = DBI->connect("dbi:SQLite:dbname=hlr.sqlite3"); $dbh->{sqlite_unicode} = 0; my $sth = $dbh->prepare("SELECT * FROM SMS;"); $sth->execute(); my $row = $sth->fetchrow_hashref(); say gsm_7bit_decode( dbd_decode_binary($row->{user_data}) ); The implementation of gsm_7bit_decode and dbd_decode_binary in perl is posted there: https://gist.github.com/1061933 This really surprise me. I briefly looked the libdbi implementation and turns out it can only perform SQL INSERT or UPDATE with only full SQL statements, and the dbd_encode_binary basically turns any BLOB into TEXT (by escaping \0) so it can be part of the SQL statement. From laforge at gnumonks.org Sun Jul 3 08:27:50 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Jul 2011 10:27:50 +0200 Subject: libdbi / libdbd-sqlite3 In-Reply-To: References: <7A221A10-9861-4A3A-BC8B-0514FC894507@gugod.org> Message-ID: <20110703082750.GC21407@prithivi.gnumonks.org> Hi, On Sun, Jul 03, 2011 at 11:54:23AM +0800, Kang-min Liu wrote: > This really surprise me. I briefly looked the libdbi implementation > and turns out it can only perform SQL INSERT or UPDATE with only full > SQL statements, and the dbd_encode_binary basically turns any BLOB > into TEXT (by escaping \0) so it can be part of the SQL statement. yes, had I ever read the source code of (c language) libdbi and libdbd-sqlite3, I would have never used it for the OpenBSC project. It's ridiculous how they deal with databases, giving away any performance that the underlying DB might have. Once we move the SQL + HLR/VLR out of the main OpenBSC process, I guess we will have to use 'native' database APIs. 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 pablo at gnumonks.org Sat Jul 2 17:54:57 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sat, 2 Jul 2011 19:54:57 +0200 Subject: [PATCH 0/2] libosmocore: logging and signal support for libraries Message-ID: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Hi Harald! These are the two patches that I'm using to support signalling and logging in the libraries. The patch that adds the logging support reworks your previous contribution so we only keep the logging subsystem in libosmocore, instead of the full definition of the logging subsystem. See patches descriptions for further details. Let me know if you're OK with these changes. Pablo Neira Ayuso (2): signal: reserve signal subsystems >= 64 for libraries logging: rework definition of logging subsystems for libraries include/osmocom/core/logging.h | 22 ++++++-- include/osmocom/core/signal.h | 23 +++++++++ include/osmocom/gsm/gsm.h | 6 ++ src/gsm/Makefile.am | 2 +- src/gsm/init.c | 22 ++++++++ src/logging.c | 107 ++++++++++++++++++++++----------------- 6 files changed, 129 insertions(+), 53 deletions(-) create mode 100644 include/osmocom/gsm/gsm.h create mode 100644 src/gsm/init.c -- 1.7.2.5 From pablo at gnumonks.org Sat Jul 2 17:54:58 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sat, 2 Jul 2011 19:54:58 +0200 Subject: [PATCH 1/2] signal: reserve signal subsystems >= 64 for libraries In-Reply-To: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> References: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> Message-ID: <1309629299-14272-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso The first range (from 0 to 63) of signal subsystems can be used by client applications while the second range (from 64 to 255) is reserved for libraries. This is useful to support signals defined in libraries that may be used by different client applications. --- include/osmocom/core/signal.h | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/include/osmocom/core/signal.h b/include/osmocom/core/signal.h index 535fd18..77490da 100644 --- a/include/osmocom/core/signal.h +++ b/include/osmocom/core/signal.h @@ -1,6 +1,29 @@ #ifndef OSMO_SIGNAL_H #define OSMO_SIGNAL_H +#include + +/* subsystem signaling numbers: we split the numberspace for applications and + * libraries: from 0 to 64 for applications, from 64 to 255 for libraries. */ +#define OSMO_SIGNAL_SS_APPS 0 +#define OSMO_SIGNAL_SS_RESERVED 64 +#define OSMO_SIGNAL_SS_MAX 255 + +/* signal subsystems. */ +enum { + SS_GLOBAL = OSMO_SIGNAL_SS_RESERVED, + SS_INPUT, +}; + +/* application-defined signal types. */ +#define OSMO_SIGNAL_T_APPS 0 +#define OSMO_SIGNAL_T_RESERVED 64 + +/* signal types. */ +enum { + S_GLOBAL_SHUTDOWN = OSMO_SIGNAL_T_RESERVED, +}; + typedef int osmo_signal_cbfn(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data); -- 1.7.2.5 From pablo at gnumonks.org Sat Jul 2 18:01:30 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sat, 02 Jul 2011 20:01:30 +0200 Subject: [PATCH 1/2] signal: reserve signal subsystems >= 64 for libraries In-Reply-To: <1309629299-14272-2-git-send-email-pablo@gnumonks.org> References: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> <1309629299-14272-2-git-send-email-pablo@gnumonks.org> Message-ID: <4E0F5CFA.3040208@gnumonks.org> On 02/07/11 19:54, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > The first range (from 0 to 63) of signal subsystems can be > used by client applications while the second range (from 64 > to 255) is reserved for libraries. Actually, this 255 limit is completely artificial, we can remove it. Sorry, it seems it got propagated from the logging patch. But, anyway, I'd like to know if you're OK with range-reserve idea. From pablo at gnumonks.org Sat Jul 2 17:54:59 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sat, 2 Jul 2011 19:54:59 +0200 Subject: [PATCH 2/2] logging: rework definition of logging subsystems for libraries In-Reply-To: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> References: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> Message-ID: <1309629299-14272-3-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patchs allow to invoke log_init(...) as many times as you want. Thus, applications and libraries can register their own logging subsystems in runtime. The idea consists of splitting the numberspace for applications and libraries. From 0 to 64 for applications, from 64 to 255 for libraries. #define OSMO_LOG_SS_APPS 0 #define OSMO_LOG_SS_RESERVED 64 #define OSMO_LOG_SS_MAX 255 The logging subsystem number definitions of the subsystem live in osmocom/core/logging.h /* reserved logging subsystems for libraries. */ enum { DLLAPDM = OSMO_LOG_SS_RESERVED, /* libosmogsm */ DINP, /* libosmo-abis */ DMUX, /* libosmo-abis */ DMI, /* libosmo-abis */ DMIB, /* libosmo-abis */ DRSL, /* libosmo-abis */ DNM, /* libosmo-abis */ }; The full definition (a.k.a. logging categories) is done in the scope of the applications and libraries. This patch limits the number of logging subsystems to 256. This limit is artificial until we provide a different way to define logging categories. Currently, we do: struct log_info_cat libosmo_abis_default_categories[] = { [DINP] = { .name = "DINP", .description = "A-bis Intput Subsystem", .enabled = 1, .loglevel = LOGL_NOTICE, }, ... }; Since, with this patch, DINP is 64, we waste 63 positions in the array defined in libosmo-abis. To avoid this, we can do it like: struct log_info_cat libosmo_abis_default_categories[] = { { .id = DINP, .name = "DINP", .description = "A-bis Intput Subsystem", .enabled = 1, .loglevel = LOGL_NOTICE, }, ... }; We can introduce this change in the near future and propagate the changes to existing applications and libraries. --- include/osmocom/core/logging.h | 22 ++++++-- include/osmocom/gsm/gsm.h | 6 ++ src/gsm/Makefile.am | 2 +- src/gsm/init.c | 22 ++++++++ src/logging.c | 107 ++++++++++++++++++++++----------------- 5 files changed, 106 insertions(+), 53 deletions(-) create mode 100644 include/osmocom/gsm/gsm.h create mode 100644 src/gsm/init.c diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h index 4276b3a..fa1e91b 100644 --- a/include/osmocom/core/logging.h +++ b/include/osmocom/core/logging.h @@ -5,6 +5,23 @@ #include #include +/* subsystem logging numbers: we split the numberspace for applications and + * libraries: from 0 to 64 for applications, from 64 to 255 for libraries. */ +#define OSMO_LOG_SS_APPS 0 +#define OSMO_LOG_SS_RESERVED 64 +#define OSMO_LOG_SS_MAX 255 + +/* reserved logging subsystems for libraries. */ +enum { + DLLAPDM = OSMO_LOG_SS_RESERVED, /* libosmogsm */ + DINP, /* libosmo-abis */ + DMUX, /* libosmo-abis */ + DMI, /* libosmo-abis */ + DMIB, /* libosmo-abis */ + DRSL, /* libosmo-abis */ + DNM, /* libosmo-abis */ +}; + #define LOG_MAX_CTX 8 #define LOG_MAX_FILTERS 8 @@ -36,11 +53,6 @@ void logp(int subsys, char *file, int line, int cont, const char *format, ...) _ #define LOG_FILTER_ALL 0x0001 -/* logging levels defined by the library itself */ -#define DLGLOBAL -1 -#define DLLAPDM -2 -#define OSMO_NUM_DLIB 2 - struct log_category { uint8_t loglevel; uint8_t enabled; diff --git a/include/osmocom/gsm/gsm.h b/include/osmocom/gsm/gsm.h new file mode 100644 index 0000000..9d3f418 --- /dev/null +++ b/include/osmocom/gsm/gsm.h @@ -0,0 +1,6 @@ +#ifndef _GSM_H_ +#define _GSM_H_ + +void libosmo_gsm_init(void *ctx); + +#endif diff --git a/src/gsm/Makefile.am b/src/gsm/Makefile.am index 88b2d9a..5e1d36c 100644 --- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -10,6 +10,6 @@ lib_LTLIBRARIES = libosmogsm.la libosmogsm_la_SOURCES = a5.c rxlev_stat.c tlv_parser.c comp128.c gsm_utils.c \ rsl.c gsm48.c gsm48_ie.c gsm0808.c sysinfo.c \ gprs_cipher_core.c gsm0480.c abis_nm.c gsm0502.c \ - lapdm.c + lapdm.c init.c libosmogsm_la_LDFLAGS = -version-info $(LIBVERSION) libosmogsm_la_LIBADD = $(top_builddir)/src/libosmocore.la diff --git a/src/gsm/init.c b/src/gsm/init.c new file mode 100644 index 0000000..00e6b30 --- /dev/null +++ b/src/gsm/init.c @@ -0,0 +1,22 @@ +#include +#include + +struct log_info_cat libosmo_gsm_default_categories[] = { + [DLLAPDM] = { + .name = "DLLAPDM", + .description = "LAPDm in libosmogsm", + .loglevel = LOGL_NOTICE, + .enabled = 1, + }, +}; + +const struct log_info libosmo_gsm_log = { + .filter_fn = NULL, /* the application should set this. */ + .cat = libosmo_gsm_default_categories, + .num_cat = ARRAY_SIZE(libosmo_gsm_default_categories), +}; + +void libosmo_gsm_init(void *ctx) +{ + log_init(&libosmo_gsm_log, ctx); +} diff --git a/src/logging.c b/src/logging.c index 24b310b..ffd81c6 100644 --- a/src/logging.c +++ b/src/logging.c @@ -58,22 +58,6 @@ static const struct value_string loglevel_strs[LOGLEVEL_DEFS+1] = { { 0, NULL }, }; -#define INT2IDX(x) (-1*(x)-1) -static const struct log_info_cat internal_cat[OSMO_NUM_DLIB] = { - [INT2IDX(DLGLOBAL)] = { /* -1 becomes 0 */ - .name = "DLGLOBAL", - .description = "Library-internal global log family", - .loglevel = LOGL_NOTICE, - .enabled = 1, - }, - [INT2IDX(DLLAPDM)] = { /* -2 becomes 1 */ - .name = "DLLAPDM", - .description = "LAPDm in libosmogsm", - .loglevel = LOGL_NOTICE, - .enabled = 1, - }, -}; - /* You have to keep this in sync with the structure loglevel_strs. */ const char *loglevel_descriptions[LOGLEVEL_DEFS+1] = { "Log simply everything", @@ -85,12 +69,6 @@ const char *loglevel_descriptions[LOGLEVEL_DEFS+1] = { NULL, }; -/* special magic for negative (library-internal) log subsystem numbers */ -static int subsys_lib2index(int subsys) -{ - return (subsys * -1) + (osmo_log_info->num_cat_user-1); -} - int log_parse_level(const char *lvl) { return get_string_value(loglevel_strs, lvl); @@ -142,7 +120,8 @@ void log_parse_category_mask(struct log_target* target, const char *_mask) if (colon) length = colon - category_token; - if (strncasecmp(osmo_log_info->cat[i].name, + if (osmo_log_info->cat[i].name != NULL && + strncasecmp(osmo_log_info->cat[i].name, category_token, length) == 0) { int level = 0; @@ -221,12 +200,6 @@ static void _logp(int subsys, int level, char *file, int line, { struct log_target *tar; - if (subsys < 0) - subsys = subsys_lib2index(subsys); - - if (subsys > osmo_log_info->num_cat) - subsys = DLGLOBAL; - llist_for_each_entry(tar, &osmo_log_target_list, entry) { struct log_category *category; int output = 0; @@ -607,8 +580,19 @@ err: return str; } -int log_init(const struct log_info *inf, void *ctx) +static void log_info_set(struct log_info_cat *lic1, struct log_info_cat *lic2) { + lic1->name = talloc_strdup(tall_log_ctx, lic2->name); + lic1->color = talloc_strdup(tall_log_ctx, lic2->color); + lic1->description = talloc_strdup(tall_log_ctx, lic2->description); + lic1->loglevel = lic2->loglevel; + lic1->enabled = lic2->enabled; +} + +static int log_info_init(const struct log_info *inf, void *ctx) +{ + /* keep this easy, allocate maximum number of categories. */ + size_t size = sizeof(struct log_info_cat) * OSMO_LOG_SS_MAX; int i; tall_log_ctx = talloc_named_const(ctx, 1, "logging"); @@ -619,31 +603,60 @@ int log_init(const struct log_info *inf, void *ctx) if (!osmo_log_info) return -ENOMEM; - osmo_log_info->num_cat_user = inf->num_cat; - /* total number = number of user cat + library cat */ - osmo_log_info->num_cat = inf->num_cat + ARRAY_SIZE(internal_cat); + osmo_log_info->filter_fn = inf->filter_fn; + osmo_log_info->num_cat = inf->num_cat; - osmo_log_info->cat = talloc_zero_array(osmo_log_info, - struct log_info_cat, - osmo_log_info->num_cat); - if (!osmo_log_info->cat) { + osmo_log_info->cat = talloc_zero_size(tall_log_ctx, size); + if (osmo_log_info->cat == NULL) { talloc_free(osmo_log_info); osmo_log_info = NULL; return -ENOMEM; } - - /* copy over the user part */ - for (i = 0; i < inf->num_cat; i++) { - memcpy(&osmo_log_info->cat[i], &inf->cat[i], - sizeof(struct log_info_cat)); + for (i=0; inum_cat; i++) { + if (inf->cat[i].name == NULL) + continue; + log_info_set(&osmo_log_info->cat[i], &inf->cat[i]); } + return 0; +} - /* copy over the library part */ - for (i = 0; i < ARRAY_SIZE(internal_cat); i++) { - unsigned int cn = osmo_log_info->num_cat_user + i; - memcpy(&osmo_log_info->cat[cn], - &internal_cat[i], sizeof(struct log_info_cat)); +static int log_info_add(const struct log_info *log_info) +{ + int i, limit = osmo_log_info->num_cat; + + if (osmo_log_info->filter_fn == NULL) { + osmo_log_info->filter_fn = log_info->filter_fn; + } else { + fprintf(stderr, "sorry, you cannot override filter " + "function in logging infrastructure\n"); } + if (log_info->num_cat > osmo_log_info->num_cat) + limit = osmo_log_info->num_cat; + osmo_log_info->num_cat = limit; + for (i=0; inum_cat; i++) { + if (log_info->cat[i].name == NULL) + continue; + if (osmo_log_info->cat[i].name == NULL) + log_info_set(&osmo_log_info->cat[i], &log_info->cat[i]); + } return 0; } + +int log_init(const struct log_info *inf, void *ctx) +{ + int ret; + + /* Artificially limit the maximum number of logging subsystems to + * avoid too big arrays with logging definitions. We can fix this by + * adding some ID field in the logging definition structure, later. */ + if (inf->num_cat > OSMO_LOG_SS_MAX) + return -EINVAL; + + if (tall_log_ctx == NULL) + ret = log_info_init(inf, ctx); + else + ret = log_info_add(inf); + + return ret; +} -- 1.7.2.5 From pablo at gnumonks.org Mon Jul 4 09:02:00 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 04 Jul 2011 11:02:00 +0200 Subject: [PATCH 2/2] logging: rework definition of logging subsystems for libraries In-Reply-To: <1309629299-14272-3-git-send-email-pablo@gnumonks.org> References: <1309629299-14272-1-git-send-email-pablo@gnumonks.org> <1309629299-14272-3-git-send-email-pablo@gnumonks.org> Message-ID: <4E118188.2010708@gnumonks.org> On 02/07/11 19:54, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > This patchs allow to invoke log_init(...) as many times > as you want. Thus, applications and libraries can register > their own logging subsystems in runtime. > > The idea consists of splitting the numberspace for applications > and libraries. From 0 to 64 for applications, from 64 to 255 for > libraries. I come up with an idea which would use your approach based on negative numbers. I expect to resend a new patch soon. From g_naveen_k at yahoo.com Sun Jul 10 14:20:27 2011 From: g_naveen_k at yahoo.com (Naveen Kumar) Date: Sun, 10 Jul 2011 07:20:27 -0700 (PDT) Subject: Hardware required to setup an SGSN Message-ID: <1310307627.91540.YahooMailNeo@web38106.mail.mud.yahoo.com> I am trying to validate some functionality of a BSC that we have. The BSC?will be?connected via Gb interface(over E1) to an SGSN. What kind of hardware(processor/E1 card) would I need to support the SGSN ? I am mainly interested in testing ns/bssgp functionality. Thanks in advance. ? Naveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Jul 10 21:51:56 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 10 Jul 2011 23:51:56 +0200 Subject: Hardware required to setup an SGSN In-Reply-To: <1310307627.91540.YahooMailNeo@web38106.mail.mud.yahoo.com> References: <1310307627.91540.YahooMailNeo@web38106.mail.mud.yahoo.com> Message-ID: <4E1A1EFC.5050206@freyther.de> On 07/10/2011 04:20 PM, Naveen Kumar wrote: > I am trying to validate some functionality of a BSC that we have. The BSC will > be connected via Gb interface(over E1) to an SGSN. What kind of > hardware(processor/E1 card) would I need to support the SGSN ? I am mainly > interested in testing ns/bssgp functionality. Thanks in advance. Can you provide some details about the BSC? From laforge at gnumonks.org Mon Jul 11 21:20:23 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 11 Jul 2011 23:20:23 +0200 Subject: Hardware required to setup an SGSN In-Reply-To: <1310307627.91540.YahooMailNeo@web38106.mail.mud.yahoo.com> References: <1310307627.91540.YahooMailNeo@web38106.mail.mud.yahoo.com> Message-ID: <20110711212023.GA4490@prithivi.gnumonks.org> Hi Naveen, On Sun, Jul 10, 2011 at 07:20:27AM -0700, Naveen Kumar wrote: > I am trying to validate some functionality of a BSC that we have. Pleaes note that this is the OpenBSC mailing list, after all ;) > The BSC?will be?connected via Gb interface(over E1) to an SGSN. What > kind of hardware(processor/E1 card) would I need to support the SGSN ? OsmoSGSN has only two protocol stackings available: BSSGP/NS/UDP/IP and BSSGP/NS/FR/GRE/IP. As such, you cannot directly interface any legacy BSC (rather: PCU) without developing the respective NS-over-E1 related code first. If you choose to go down that path, I'd be more than happy to review + merge it into our project. If you're running frame relay on your E1, you might use something like a cisco router that can adapt the FR over GRE/IP and then attach it to OsmoSGSN. 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 g_naveen_k at yahoo.com Tue Jul 12 01:01:43 2011 From: g_naveen_k at yahoo.com (Naveen Kumar) Date: Mon, 11 Jul 2011 18:01:43 -0700 (PDT) Subject: Hardware required to setup an SGSN Message-ID: <1310432503.95575.androidMobile@web38108.mail.mud.yahoo.com> Hi Harald ??? Thanks for the options. I will need to look into it in a bit more detail. Which part of the code base do I need to concentrate on to get the Fr over E1 functionality? Naveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 12 05:50:23 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 12 Jul 2011 07:50:23 +0200 Subject: Hardware required to setup an SGSN In-Reply-To: <1310432503.95575.androidMobile@web38108.mail.mud.yahoo.com> References: <1310432503.95575.androidMobile@web38108.mail.mud.yahoo.com> Message-ID: <20110712055023.GE4490@prithivi.gnumonks.org> Hi Naveen, On Mon, Jul 11, 2011 at 06:01:43PM -0700, Naveen Kumar wrote: > Thanks for the options. I will need to look into it in a bit more > detail. Which part of the code base do I need to concentrate on to get > the Fr over E1 functionality? I would suggest using the following route * Get a card directly compatible with the Linux kernel HDLC http://www.kernel.org/pub/linux/utils/net/hdlc/ - or (as they are all quite outdated) - * Get an E1 card supported by DAHDI (e.g. Digium or compatible) + Install DAHDI with CONFIG_DAHDI_NET enabled and run the device in "nethdlc" mode * Configure the hdlc linux kernel network device as appropriate, crating the PVC(s) you need * Extend the NS code that's in openbsc.git/openbsc/src/gprs/gprs_ns.c to work on top of the frame relay network "pvcN" device instead * Post the code here for review and inclusion. This is important, the project lives by its contributions... So you could probably re-use that code (I think DAHDI has more potential as more hardware is available for it), implement frame relay and then attach that to the existing NS/BSSGP installation. Warning: Our NS code does currently not support multiple NS-VCs in a single NS-Entity and thus there's no load sharing or fail-over if you have multiple PVCs (on one or multiple E1 links) leading to the same SGSN. If you need to support that, more work is required. Please note that there are also multiple people involved in the project offering paid R&D services, consulting and/or support surrounding OpenBSC / OsmoSGSN. 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 g_naveen_k at yahoo.com Fri Jul 15 14:58:14 2011 From: g_naveen_k at yahoo.com (Naveen Kumar) Date: Fri, 15 Jul 2011 07:58:14 -0700 (PDT) Subject: ggsn build problem In-Reply-To: <20110712055023.GE4490@prithivi.gnumonks.org> References: <1310432503.95575.androidMobile@web38108.mail.mud.yahoo.com> <20110712055023.GE4490@prithivi.gnumonks.org> Message-ID: <1310741894.82015.YahooMailNeo@web38101.mail.mud.yahoo.com> Harald I am trying to build the ggsn package so that openbsc can pick it up. I get the following errors when running autoreconf -i ? sing `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL' libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite ggsn/Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in `configure.in' ggsn/Makefile.am:9: required file `ggsn/getopt1.c' not found ggsn/Makefile.am:9: required file `ggsn/getopt.c' not found sgsnemu/Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in `configure.in' sgsnemu/Makefile.am:9: required file `sgsnemu/getopt1.c' not found sgsnemu/Makefile.am:9: required file `sgsnemu/getopt.c' not found autoreconf: automake failed with exit status: 1 ? I am able to build libosmocore and openbsc fine though. ? Naveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From g_naveen_k at yahoo.com Mon Jul 11 13:25:19 2011 From: g_naveen_k at yahoo.com (Naveen Kumar) Date: Mon, 11 Jul 2011 06:25:19 -0700 (PDT) Subject: OpenBSC Digest, Vol 31, Issue 6 In-Reply-To: References: Message-ID: <1310390719.77229.YahooMailNeo@web38105.mail.mud.yahoo.com> >> Can you provide some details about the BSC? Hans if you mean what brand this is a custom BSC that our company(Hughes) developed for a customer. This BSC is connected to a customer provided SGSN via 2 E1 links. ? ? Naveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Jul 11 13:51:17 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 11 Jul 2011 15:51:17 +0200 Subject: OpenBSC Digest, Vol 31, Issue 6 In-Reply-To: <1310390719.77229.YahooMailNeo@web38105.mail.mud.yahoo.com> References: <1310390719.77229.YahooMailNeo@web38105.mail.mud.yahoo.com> Message-ID: <4E1AFFD5.7000706@freyther.de> On 07/11/2011 03:25 PM, Naveen Kumar wrote: > >>> Can you provide some details about the BSC? > Hans if you mean what brand this is a custom BSC that our company(Hughes) > developed for a customer. This BSC is connected to a customer provided SGSN > via 2 E1 links. > Hi again, will you release the BSC as Free Software? holger From admin at manateeshome.com Tue Jul 12 16:09:35 2011 From: admin at manateeshome.com (Seungju Kim) Date: Wed, 13 Jul 2011 01:09:35 +0900 Subject: NanoBTS reset Message-ID: <008001cc40ae$19253de0$4b6fb9a0$@manateeshome.com> Is there any other way to reset a NanoBTS without building a reset dongle? My NanoBTS is acting strangely after a segfault of OpenBSC. I can connect and beacon my network with the BTS but it won't enable data for some reason. It was working fine before. Now it says something like this <000d> input/ipaccess.c:696 accept()ed new OML link from 192.168.1.139 SET ATTR NACK CAUSE=Message cannot be performed <000d> input/ipaccess.c:758 accept()ed new RSL link from 192.168.1.139 The NanoBTS doesn't even make a connection to the SGSN when this happens. Thank you I want to kno if there is a way to reset the nanobts without making the reset dongle? ./ipaccess-config works at the moment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cr3 at cr3.us Tue Jul 12 16:13:32 2011 From: cr3 at cr3.us (Chris Rankine) Date: Tue, 12 Jul 2011 12:13:32 -0400 Subject: NanoBTS reset In-Reply-To: <008001cc40ae$19253de0$4b6fb9a0$@manateeshome.com> References: <008001cc40ae$19253de0$4b6fb9a0$@manateeshome.com> Message-ID: Though it has the same effect as using the dongle, I have been successful using a small flathead screw driver and an extra set of hands to short out the pins until the light blinks. Chris Rankine On Tue, Jul 12, 2011 at 12:09 PM, Seungju Kim wrote: > Is there any other way to reset a NanoBTS without building a reset dongle? > My NanoBTS is acting strangely after a segfault of OpenBSC. > > I can connect and beacon my network with the BTS but it won?t enable data > for some reason. It was working fine before. > > Now it says something like this > > <000d> input/ipaccess.c:696 accept()ed new OML link from 192.168.1.139 > > SET ATTR NACK? CAUSE=Message cannot be performed > > <000d> input/ipaccess.c:758 accept()ed new RSL link from 192.168.1.139 > > > > The NanoBTS doesn?t even make a connection to the SGSN when this happens. > > > > Thank you > > > > I want to kno if there is a way to reset the nanobts without making the > reset dongle? ./ipaccess-config works at the moment. From laforge at gnumonks.org Tue Jul 12 18:27:56 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 12 Jul 2011 20:27:56 +0200 Subject: NanoBTS reset In-Reply-To: <008001cc40ae$19253de0$4b6fb9a0$@manateeshome.com> References: <008001cc40ae$19253de0$4b6fb9a0$@manateeshome.com> Message-ID: <20110712182756.GH11234@prithivi.gnumonks.org> Hi, On Wed, Jul 13, 2011 at 01:09:35AM +0900, Seungju Kim wrote: > Is there any other way to reset a NanoBTS without building a reset dongle? > My NanoBTS is acting strangely after a segfault of OpenBSC. > > I can connect and beacon my network with the BTS but it won't enable data > for some reason. It was working fine before. > I strongly suggest to debug the problem rather than trying an NVRAM reset. Where are your protocol traces? Have you analyzed them using the wireshark abis OML dissector for ip.access that we provide? Have you experimented with removing the attributes one by one in order to understand which attribute is not correct? Are you certain it is not some kind of misconfiguration in openbsc.cfg that causes invalid attribute contents? Have you checked OML error report messages that might be provided by the BTS? Have you checked the nanobts telnet interface using ipaccess-telnet? There are soooooo many things you can do to debug this problem, it "just" needs time and dedication. 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 Jul 13 13:03:19 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 13 Jul 2011 15:03:19 +0200 Subject: merge of 'daniel/controlif' branch Message-ID: <20110713130319.GO17260@prithivi.gnumonks.org> Hi! After many delays on my side (it kept falling off my TODO list), I have finally merged the daniel/controlif branch earlier today. For those who haven't heard about it so far: It is code that allows us to remotely get and/or set attributes of the BSC. Furthermore, it supports traps (similar to SNMP traps). The idea of it is to allow us to have centralized management of networks with many OpenBSC installations, offering SNMP-like feel but without adding the complexity of SNMP (asn.1, etc.) to OpenBSC itself. We might at some point have an independent gateway process that exports the attributes through real SNMP, but that mostly depensd on whether any production networks have such a requirement or not. The control interface is implemented either stand-alone (for osmo-nitb) or via the regular A and A-bis/IP as an additional ip.access stream identifier. Thanks to Daniel for writing the code, to On-Waves for funding the development and once again my apologies for the delays. btw: I have done a couple of cosmetic clean up commits in addition to Daniels branch, hopefully I didn't break anything while doign that... 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 daniel at totalueberwachung.de Thu Jul 14 11:39:08 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 14 Jul 2011 13:39:08 +0200 Subject: merge of 'daniel/controlif' branch In-Reply-To: <20110713130319.GO17260@prithivi.gnumonks.org> References: <20110713130319.GO17260@prithivi.gnumonks.org> Message-ID: <20110714133908.1f05acfb@adrastea.totalueberwachung.de> Hi, On Wed, 13 Jul 2011 15:03:19 +0200 Harald Welte wrote: > After many delays on my side (it kept falling off my TODO list), I > have finally merged the daniel/controlif branch earlier today. great, thanks. > btw: I have done a couple of cosmetic clean up commits in addition to > Daniels branch, hopefully I didn't break anything while doign that... I just had a look and it all seemed to be working. Thanks again, Daniel From holger at freyther.de Thu Jul 14 07:58:33 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 14 Jul 2011 09:58:33 +0200 Subject: OML issue? Message-ID: <4E1EA1A9.7060207@freyther.de> Hi all, I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I restart the osmo-nitb it is working again, so I suspect somehow our state of the BTS is corrupted. any ideas holger -------------- next part -------------- A non-text attachment was scrubbed... Name: change_admin_null_nack.pcap Type: application/x-extension-pcap Size: 1048 bytes Desc: not available URL: From admin at manateeshome.com Thu Jul 14 08:50:40 2011 From: admin at manateeshome.com (Seungju Kim) Date: Thu, 14 Jul 2011 17:50:40 +0900 Subject: OML issue? In-Reply-To: <4E1EA1A9.7060207@freyther.de> References: <4E1EA1A9.7060207@freyther.de> Message-ID: Do you get this error when starting osmo-nitb? SET ATTR NACK CAUSE=Message cannot be performed Sent from my iPhone On Jul 14, 2011, at 4:58 PM, Holger Hans Peter Freyther wrote: > Hi all, > > I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I > restart the osmo-nitb it is working again, so I suspect somehow our state of > the BTS is corrupted. > > > any ideas > holger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sat Jul 16 13:37:28 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 16 Jul 2011 15:37:28 +0200 Subject: OML issue? In-Reply-To: <4E1EA1A9.7060207@freyther.de> References: <4E1EA1A9.7060207@freyther.de> Message-ID: <4E219418.6030704@freyther.de> On 07/14/2011 09:58 AM, Holger Hans Peter Freyther wrote: > Hi all, > > I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I > restart the osmo-nitb it is working again, so I suspect somehow our state of > the BTS is corrupted. Hi, okay, this was introduced in this b7849987e516eb3bf102b29298ecc103b8b24d53 commit. Now in general this appears to be a step forward. So what about. a) 1.) We call the reset after the initial init 2.) try to understand our init code again b) 1. Revert but I don't think it is necessary. comments? holger From laforge at gnumonks.org Sat Jul 16 15:19:37 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Jul 2011 17:19:37 +0200 Subject: OML issue? In-Reply-To: <4E219418.6030704@freyther.de> References: <4E1EA1A9.7060207@freyther.de> <4E219418.6030704@freyther.de> Message-ID: <20110716151937.GV10557@prithivi.gnumonks.org> Hi Holger, On Sat, Jul 16, 2011 at 03:37:28PM +0200, Holger Hans Peter Freyther wrote: > okay, this was introduced in this b7849987e516eb3bf102b29298ecc103b8b24d53 > commit. Now in general this appears to be a step forward. So what about. sorry for introducing the problem ... > a) > 1.) We call the reset after the initial init > 2.) try to understand our init code again > > b) > 1. Revert but I don't think it is necessary. I'm definitely in favor of 'a', as 'b' would also break OsmoBTS ;) But more seriously speaking, I think we can not make any assumptions on the MO state after loosing the BTS link. And what would be 'a1', i.e. reset after initial init? Maybe I don't understand you correctly, but this doesn't seem to make sense to me. If we first do some initialization of the BTS (i.e. change its state) and then reset our view of that state, I don't think it can be right... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sat Jul 16 19:08:24 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 16 Jul 2011 21:08:24 +0200 Subject: OML issue? In-Reply-To: <20110716151937.GV10557@prithivi.gnumonks.org> References: <4E1EA1A9.7060207@freyther.de> <4E219418.6030704@freyther.de> <20110716151937.GV10557@prithivi.gnumonks.org> Message-ID: <4E21E1A8.4080907@freyther.de> On 07/16/2011 05:19 PM, Harald Welte wrote: > > And what would be 'a1', i.e. reset after initial init? Maybe I don't > understand you correctly, but this doesn't seem to make sense to me. My point would be to get the OML state in the state it would be after a loss of connection before we have the first connection. This way we would know the re-connection case is working. Maybe my understanding of what the state should be like after a disconnect is wrong. > > If we first do some initialization of the BTS (i.e. change its state) > and then reset our view of that state, I don't think it can be right... > From holger at freyther.de Mon Jul 18 09:00:38 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 18 Jul 2011 11:00:38 +0200 Subject: OML issue? In-Reply-To: <4E21E1A8.4080907@freyther.de> References: <4E1EA1A9.7060207@freyther.de> <4E219418.6030704@freyther.de> <20110716151937.GV10557@prithivi.gnumonks.org> <4E21E1A8.4080907@freyther.de> Message-ID: <4E23F636.4020308@freyther.de> On 07/16/2011 09:08 PM, Holger Hans Peter Freyther wrote: > On 07/16/2011 05:19 PM, Harald Welte wrote: > I am debugging this now, what also jumped into my eye is that the administrative is set. This will e.g. change the setting of the TRX lock. From holger at freyther.de Mon Jul 18 10:12:26 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 18 Jul 2011 12:12:26 +0200 Subject: OML issue? In-Reply-To: <4E23F636.4020308@freyther.de> References: <4E1EA1A9.7060207@freyther.de> <4E219418.6030704@freyther.de> <20110716151937.GV10557@prithivi.gnumonks.org> <4E21E1A8.4080907@freyther.de> <4E23F636.4020308@freyther.de> Message-ID: <4E24070A.4030102@freyther.de> On 07/18/2011 11:00 AM, Holger Hans Peter Freyther wrote: > On 07/16/2011 09:08 PM, Holger Hans Peter Freyther wrote: >> On 07/16/2011 05:19 PM, Harald Welte wrote: >> > > > I am debugging this now, what also jumped into my eye is that the > administrative is set. This will e.g. change the setting of the TRX lock. Hi Harald, and actually the above was the problem. In bts_ipaccess_nanobts:sw_activ_rep we will use the administrative state of the TRX (rc_state variable) and issue a change_adm_state, with NM_OPSTATE_NULL as rc_state we will get a NACK. Now my understanding might be wrong but I think the administrative state is something we want to 'maintain' from the BSC. So I think the administrative state should survive a BTS disconnect. In theory there is one way this could still fail, in the administrative ACK code path we will set the administrative state to the one returned by the BTS, we probably want to compare the result and then send a signal if setting the admin state didn't result in what we asked for. My proposed patch will call gsm_bts_mo_reset from within bts_bootstrap and removes setting the administrative state. what do you think? holger From zecke at selfish.org Mon Jul 18 09:26:07 2011 From: zecke at selfish.org (Holger Hans Peter Freyther) Date: Mon, 18 Jul 2011 11:26:07 +0200 Subject: [PATCH] bts-init: Initialize the BTS like it will look after a reset Message-ID: Reset the BTS MO State on BTS bootstrap. This way we will always test the BTS disconnect/reconnect case of the BTS. Do not reset the administrative state of objects. The BSC might have set these and wants to maintain them across disconnect/ reconnect. Right now this is true for the TRX state. --- openbsc/src/libbsc/bsc_init.c | 3 +++ openbsc/src/libcommon/gsm_data_shared.c | 1 - 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 1be8cb7..02a3adf 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -406,6 +406,9 @@ static int bootstrap_bts(struct gsm_bts *bts) bts->si_common.ncc_permitted = 0xff; + /* Initialize the BTS state */ + gsm_bts_mo_reset(bts); + return 0; } diff --git a/openbsc/src/libcommon/gsm_data_shared.c b/openbsc/src/libcommon/gsm_data_shared.c index 58e3bed..b52d58a 100644 --- a/openbsc/src/libcommon/gsm_data_shared.c +++ b/openbsc/src/libcommon/gsm_data_shared.c @@ -36,7 +36,6 @@ void gsm_abis_mo_reset(struct gsm_abis_mo *mo) { - mo->nm_state.administrative = NM_STATE_NULL; mo->nm_state.operational = NM_OPSTATE_NULL; mo->nm_state.availability = NM_AVSTATE_POWER_OFF; } -- 1.7.4.1 --------------050709080504010702000704-- From laforge at gnumonks.org Mon Jul 18 13:05:59 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 18 Jul 2011 15:05:59 +0200 Subject: OML issue? In-Reply-To: <4E24070A.4030102@freyther.de> References: <4E1EA1A9.7060207@freyther.de> <4E219418.6030704@freyther.de> <20110716151937.GV10557@prithivi.gnumonks.org> <4E21E1A8.4080907@freyther.de> <4E23F636.4020308@freyther.de> <4E24070A.4030102@freyther.de> Message-ID: <20110718130559.GC29859@prithivi.gnumonks.org> Hi Holger, On Mon, Jul 18, 2011 at 12:12:26PM +0200, Holger Hans Peter Freyther wrote: > Now my understanding might be wrong but I think the administrative state is > something we want to 'maintain' from the BSC. So I think the administrative > state should survive a BTS disconnect. Ok, seems fine to me. Feel free to apply. I'll do some tests with osmo-bts later today, and fix it up if it causes any problems. Right now I'm doing a port of osmo-bts to libosmo-abis, just to get some experience with it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Jul 18 13:10:32 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 18 Jul 2011 15:10:32 +0200 Subject: OML issue? In-Reply-To: <20110718130559.GC29859@prithivi.gnumonks.org> References: <4E1EA1A9.7060207@freyther.de> <4E219418.6030704@freyther.de> <20110716151937.GV10557@prithivi.gnumonks.org> <4E21E1A8.4080907@freyther.de> <4E23F636.4020308@freyther.de> <4E24070A.4030102@freyther.de> <20110718130559.GC29859@prithivi.gnumonks.org> Message-ID: <4E2430C8.7060603@freyther.de> On 07/18/2011 03:05 PM, Harald Welte wrote: > Hi Holger, > > Ok, seems fine to me. Feel free to apply. I'll do some tests with > osmo-bts later today, and fix it up if it causes any problems. thanks, I did a very basic test with osmo-bts before sending the patch, it seemed to work (RSL was estbalished) holger From benny at benny.de Thu Jul 14 08:39:24 2011 From: benny at benny.de (Benjamin Hagemann) Date: Thu, 14 Jul 2011 10:39:24 +0200 Subject: THC hacked Vodafone UMTS Femto cell Message-ID: <20110714083924.GO13606@quelle.benny.de> hello, a friend pointed me to this news: "Hackers crack Vodafone's network, can listen to all calls" http://www.tecca.com/news/2011/07/13/hackers-crack-vodafones-network-can-listen-to-all-calls/ so I jumped to the THC blog: http://thcorg.blogspot.com/2011/07/vodafone-hacked-root-password-published.html and THC wiki with more information about the FemtoMod, protocolls and so on: http://wiki.thc.org/vodafone have fun :) -- regards, benny gpg 0xFC505AB0 jabber benny at benny.de sip benny at benny.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From admin at manateeshome.com Thu Jul 14 09:19:23 2011 From: admin at manateeshome.com (Seungju Kim) Date: Thu, 14 Jul 2011 18:19:23 +0900 Subject: THC hacked Vodafone UMTS Femto cell In-Reply-To: <20110714083924.GO13606@quelle.benny.de> References: <20110714083924.GO13606@quelle.benny.de> Message-ID: <26E16179-A629-407A-A85C-180D3D7A75A0@manateeshome.com> Yup, A funny story. But this has been discussed earlier on the IRC channel :P Sent from my iPhone On Jul 14, 2011, at 5:39 PM, Benjamin Hagemann wrote: > hello, > > a friend pointed me to this news: > > "Hackers crack Vodafone's network, can listen to all calls" > http://www.tecca.com/news/2011/07/13/hackers-crack-vodafones-network-can-listen-to-all-calls/ > > so I jumped to the THC blog: > http://thcorg.blogspot.com/2011/07/vodafone-hacked-root-password-published.html > > and THC wiki with more information about the FemtoMod, protocolls and so on: > http://wiki.thc.org/vodafone > > have fun :) > > -- > regards, > > benny > > gpg 0xFC505AB0 > jabber benny at benny.de > sip benny at benny.de From laforge at gnumonks.org Sat Jul 16 11:49:21 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Jul 2011 13:49:21 +0200 Subject: Smatch results on openbsc / static code analysis Message-ID: <20110716114921.GO10557@prithivi.gnumonks.org> Hi! I've started to play a bit with Smatch (http://smatch.sourceforge.net/) and fixed a number of bugs in libosmocore. When applying it to openbsc, I get: CC ipaccess.o /home/laforge/projects/git/openbsc/openbsc/src/libabis/input/ipaccess.c +455 ipaccess_drop(28) info: loop could be replaced with if statement. /home/laforge/projects/git/openbsc/openbsc/src/libabis/input/ipaccess.c +451 ipaccess_drop(24) info: ignoring unreachable code. The point herer is: we loop over a list, but we return from the first iteration of the loop. Zecke? CC abis_nm.o /home/laforge/projects/git/openbsc/openbsc/src/libbsc/abis_nm.c +810 sw_load_segment(38) warn: unsigned 'len' is never less than zero. 'len' has to be signed, I fixed that one. CC paging.o /home/laforge/projects/git/openbsc/openbsc/src/libbsc/paging.c +134 can_send_pag_req(25) info: ignoring unreachable code. We have a goto statement in each possible caes (including defualt) above it. So the return 0 will never be hit. That's ok and not a bug. But I think the code is too convoluted this way. I think we should have one function that just returns (sdcch/tch) based on the rsl_type and net->pag_any_tch, and then a second function that has a simple if/else. I'm not against goto - but I think this time it really can be avoided easily. CC bsc_vty.o /home/laforge/projects/git/openbsc/openbsc/src/libbsc/bsc_vty.c +1062 show_e1ts(25) warn: variable dereferenced before check 'line' /home/laforge/projects/git/openbsc/openbsc/src/libbsc/bsc_vty.c +1075 show_e1ts(38) warn: buffer overflow 'line->ts' 32 <= 32 /home/laforge/projects/git/openbsc/openbsc/src/libbsc/bsc_vty.c +1080 show_e1ts(43) error: potential null derefence 'line'. fixed two of them, the third is bogus CC db.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +254 db_fini(6) info: redundant null check on db_dirname calling free() /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +256 db_fini(8) info: redundant null check on db_basename calling free() /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +280 db_create_subscriber(20) warn: variable dereferenced before check 'subscr' /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +1062 sms_from_result(36) warn: 256 is more than 255 (max 'sms->user_data_len' can be) so this is always false. fixed the first 3, the last remains as a safeguard CC gsm_04_08.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_08.c +550 mm_rx_loc_upd_req(46) error: we previously assumed 'conn->loc_operation' could be null. /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_08.c +1891 gsm48_cc_rx_setup(68) error: we previously assumed 'trans->subscr' could be null. /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_08.c +2193 gsm48_cc_rx_connect(40) error: we previously assumed 'trans->subscr' could be null. The first is bogus, the others need to be investigated CC gsm_04_11.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_11.c +599 gsm340_rx_tpdu(46) error: sms_alphabet is never equal to 4294967295 (wrong type 0 - 255). I fixed that one! CC ussd.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/ussd.c +54 handle_rcv_ussd(9) error: req.text[0] is never equal to 255 (wrong type -128 - 127). CC bsc_ussd.o /home/laforge/projects/git/openbsc/openbsc/src/osmo-bsc_nat/bsc_ussd.c +385 bsc_check_ussd(62) error: req.text[0] is never equal to 255 (wrong type -128 - 127). This is due to 'struct ussd_request.text' being 'char', I changed it to uint8_t. CC bs11_config.o /home/laforge/projects/git/openbsc/openbsc/src/utils/bs11_config.c +223 linkstate_name(5) error: buffer overflow 'bs11_link_state' 3 <= 3 /home/laforge/projects/git/openbsc/openbsc/src/utils/bs11_config.c +240 mbccu_load_name(5) error: buffer overflow 'mbccu_load' 6 <= 6 /home/laforge/projects/git/openbsc/openbsc/src/utils/bs11_config.c +905 main(34) info: ignoring unreachable code. fixed. CC ipaccess-firmware.o /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 2 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 3 zecke? CC ipaccess-proxy.o /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +173 store_idtags(14) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +173 store_idtags(14) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +175 store_idtags(16) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +178 store_idtags(19) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +500 ipaccess_rcvmsg(66) error: buffer overflow 'ipbc->rsl_conn' 4 <= 4 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +504 ipaccess_rcvmsg(70) error: buffer overflow 'ipbc->bsc_rsl_conn' 4 <= 4 fixed CC gprs_bssgp_util.o /home/laforge/projects/git/openbsc/openbsc/src/libgb/gprs_bssgp_util.c +114 bssgp_tx_status(17) warn: variable dereferenced before check 'orig_msg' fixed. CC gb_proxy_main.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/gb_proxy_main.c +284 main(81) info: ignoring unreachable code. bogus, sa it's jus an exit(0) CC gprs_gmm.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/gprs_gmm.c +757 gsm48_rx_gmm_att_req(133) warn: variable dereferenced before check 'ctx' fixed CC gprs_sndcp.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/gprs_sndcp.c +478 sndcp_unitdata_req(37) info: ignoring unreachable code. comment in the code says it is not reached CC sgsn_main.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/sgsn_main.c +284 main(83) info: ignoring unreachable code. comment in the code says it is not reached CC sgsn_libgtp.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/sgsn_libgtp.c +504 sgsn_rx_sndcp_ud_ind(32) info: ignoring unreachable code. fixed CC bsc_nat.o /home/laforge/projects/git/openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c +1553 get_next_free_bsc_id(20) info: ignoring unreachable code. zecke? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sat Jul 16 12:21:21 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 16 Jul 2011 14:21:21 +0200 Subject: Smatch results on openbsc / static code analysis In-Reply-To: <20110716114921.GO10557@prithivi.gnumonks.org> References: <20110716114921.GO10557@prithivi.gnumonks.org> Message-ID: <4E218241.8080908@freyther.de> On 07/16/2011 01:49 PM, Harald Welte wrote: > Hi! > > I've started to play a bit with Smatch (http://smatch.sourceforge.net/) > and fixed a number of bugs in libosmocore. > > When applying it to openbsc, I get: > > CC ipaccess.o > /home/laforge/projects/git/openbsc/openbsc/src/libabis/input/ipaccess.c +455 ipaccess_drop(28) info: loop could be replaced with if statement. > /home/laforge/projects/git/openbsc/openbsc/src/libabis/input/ipaccess.c +451 ipaccess_drop(24) info: ignoring unreachable code. > > The point herer is: we loop over a list, but we return from the first > iteration of the loop. Zecke? yes, it can be done with if (!llist_empty()), only ugly part is to access the first element and cast it. Will fix it today. > CC paging.o > /home/laforge/projects/git/openbsc/openbsc/src/libbsc/paging.c +134 can_send_pag_req(25) info: ignoring unreachable code. > > We have a goto statement in each possible caes (including defualt) above > it. So the return 0 will never be hit. That's ok and not a bug. But I > think the code is too convoluted this way. I think we should have one > function that just returns (sdcch/tch) based on the rsl_type and > net->pag_any_tch, and then a second function that has a simple if/else. > > I'm not against goto - but I think this time it really can be avoided > easily. Okay, will clean this up a bit. > > CC ipaccess-firmware.o > /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 2 > /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 3 > > zecke? Will take a look. > CC bsc_nat.o > /home/laforge/projects/git/openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c +1553 get_next_free_bsc_id(20) info: ignoring unreachable code. > > zecke? looks like a bogus break in there, will test. From alexander.huemer at xx.vu Sat Jul 16 12:25:29 2011 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sat, 16 Jul 2011 14:25:29 +0200 Subject: [PATCH] gsm 04.80: fix typo 265->256 Message-ID: <1310819129-30000-1-git-send-email-alexander.huemer@xx.vu> Commit 79599ba0eb7a9aeaeb9dfbbf4881f0633724a471 contained a double typo. --- include/osmocom/gsm/tlv.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/osmocom/gsm/tlv.h b/include/osmocom/gsm/tlv.h index 1e59cca..f659411 100644 --- a/include/osmocom/gsm/tlv.h +++ b/include/osmocom/gsm/tlv.h @@ -236,11 +236,11 @@ struct tlv_def { }; struct tlv_definition { - struct tlv_def def[265]; + struct tlv_def def[256]; }; struct tlv_parsed { - struct tlv_p_entry lv[265]; + struct tlv_p_entry lv[256]; }; extern struct tlv_definition tvlv_att_def; -- 1.7.6 From laforge at gnumonks.org Sat Jul 16 13:43:44 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Jul 2011 15:43:44 +0200 Subject: [PATCH] gsm 04.80: fix typo 265->256 In-Reply-To: <1310819129-30000-1-git-send-email-alexander.huemer@xx.vu> References: <1310819129-30000-1-git-send-email-alexander.huemer@xx.vu> Message-ID: <20110716134344.GS10557@prithivi.gnumonks.org> On Sat, Jul 16, 2011 at 02:25:29PM +0200, Alexander Huemer wrote: > Commit 79599ba0eb7a9aeaeb9dfbbf4881f0633724a471 contained a double typo. thanks a lot, I've fixed it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Sun Jul 17 11:52:37 2011 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 17 Jul 2011 20:52:37 +0900 Subject: Different protocols Message-ID: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> I see that pretty much every vendor in GSM industry uses their own dialect in their core network products, I wonder why. What do they achieve from it while killing compatibility with other products from other companies? From laforge at gnumonks.org Sun Jul 17 18:43:16 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 17 Jul 2011 20:43:16 +0200 Subject: Different protocols In-Reply-To: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> References: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> Message-ID: <20110717184316.GD8759@prithivi.gnumonks.org> Hi, On Sun, Jul 17, 2011 at 08:52:37PM +0900, Seungju Kim wrote: > I see that pretty much every vendor in GSM industry uses their own > dialect in their core network products, I wonder why. What do they > achieve from it while killing compatibility with other products from > other companies? It's pretty simple: They ensure the operator is in a "vendor lock-in" and thus has to buy all equipment from the same vendor. Thus, there is no real competition and the original "mix and match" idea as defined in the GSM specs is rendered void. As an equipment supplier, you can then extort a lot of money from the operator, since switching from one supplier to another and replacing equipment is an expensive proposition. What I'm personally surprised though is why nobody hires people (like us) to develop translators / gateways between those dialects. That's probably a hell lot cheaper than replacing your core network from one vendor with another vendor... Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Sun Jul 17 19:00:29 2011 From: admin at manateeshome.com (Seungju Kim) Date: Mon, 18 Jul 2011 04:00:29 +0900 Subject: Different protocols In-Reply-To: <20110717184316.GD8759@prithivi.gnumonks.org> References: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> <20110717184316.GD8759@prithivi.gnumonks.org> Message-ID: <8B4A6398-4555-494A-9707-41733E3E3BAB@manateeshome.com> On Jul 18, 2011, at 3:43 AM, Harald Welte wrote: > Hi, > > On Sun, Jul 17, 2011 at 08:52:37PM +0900, Seungju Kim wrote: >> I see that pretty much every vendor in GSM industry uses their own >> dialect in their core network products, I wonder why. What do they >> achieve from it while killing compatibility with other products from >> other companies? > > It's pretty simple: They ensure the operator is in a "vendor lock-in" > and thus has to buy all equipment from the same vendor. > > Thus, there is no real competition and the original "mix and match" idea > as defined in the GSM specs is rendered void. > > As an equipment supplier, you can then extort a lot of money from the > operator, since switching from one supplier to another and replacing > equipment is an expensive proposition. > > What I'm personally surprised though is why nobody hires people (like us) > to develop translators / gateways between those dialects. That's > probably a hell lot cheaper than replacing your core network from one > vendor with another vendor... I think it is because of the user agreement, I do not think that mobile operators are allowed to trace the dialects. Have you heard of a game Starcraft? Its end user agreement says that users must not sniff packets nor make gateways that mimics their protocols. Of course source modifications are not allowed either. I think there are such agreement between mobile operators and equipment suppliers about which we do not know much. That also could be another reason why used network equipments are so hard to get. > 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 Sun Jul 17 20:34:24 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 17 Jul 2011 22:34:24 +0200 Subject: [OT] Re: Different protocols In-Reply-To: <8B4A6398-4555-494A-9707-41733E3E3BAB@manateeshome.com> References: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> <20110717184316.GD8759@prithivi.gnumonks.org> <8B4A6398-4555-494A-9707-41733E3E3BAB@manateeshome.com> Message-ID: <20110717203424.GF8759@prithivi.gnumonks.org> On Mon, Jul 18, 2011 at 04:00:29AM +0900, Seungju Kim wrote: > > What I'm personally surprised though is why nobody hires people (like us) > > to develop translators / gateways between those dialects. That's > > probably a hell lot cheaper than replacing your core network from one > > vendor with another vendor... > > I think it is because of the user agreement, I do not think that > mobile operators are allowed to trace the dialects. I don't think you could do this, at least not under German law. Running a program and observing its input and output are always permitted, as long as you legally obtained the program. How do you think that Samba would have ever become such a success, and unharmed by Microsoft? Because they couldn't do anything against people observing communications protocols. > Have you heard of a game Starcraft? Its end user agreement says that > users must not sniff packets nor make gateways that mimics their > protocols. Not everything that people put in their EULAs is legally valid and enforcable. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From thseiler at gmail.com Mon Jul 18 21:00:51 2011 From: thseiler at gmail.com (Thomas Seiler) Date: Mon, 18 Jul 2011 23:00:51 +0200 Subject: [OT] Re: Different protocols In-Reply-To: <20110717203424.GF8759@prithivi.gnumonks.org> References: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> <20110717184316.GD8759@prithivi.gnumonks.org> <8B4A6398-4555-494A-9707-41733E3E3BAB@manateeshome.com> <20110717203424.GF8759@prithivi.gnumonks.org> Message-ID: Gentlemen, > What I'm personally surprised though is why nobody hires people (like us) > to develop translators / gateways between those dialects. ?That's > probably a hell lot cheaper than replacing your core network from one > vendor with another vendor... Hm, Consider this: For a network operator, the game is to get as close to 99.999....% uptime as economically possible. Why? If something breaks, and you can't fix it within the hour, you'll lose your credibility, and your customers will eventually move to another network. So its really all about business continuity, reliability and risk management. From laforge at gnumonks.org Mon Jul 18 22:18:29 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 19 Jul 2011 00:18:29 +0200 Subject: [OT] Re: Different protocols In-Reply-To: References: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> <20110717184316.GD8759@prithivi.gnumonks.org> <8B4A6398-4555-494A-9707-41733E3E3BAB@manateeshome.com> <20110717203424.GF8759@prithivi.gnumonks.org> Message-ID: <20110718221829.GB2015@prithivi.gnumonks.org> Hi Thomas, good to hear from you! On Mon, Jul 18, 2011 at 11:00:51PM +0200, Thomas Seiler wrote: > > What I'm personally surprised though is why nobody hires people (like us) > > to develop translators / gateways between those dialects. ?That's > > probably a hell lot cheaper than replacing your core network from one > > vendor with another vendor... > > Hm, Consider this: For a network operator, the game is to get as close > to 99.999....% uptime as economically possible. well, that (as well as the remaining argument) is true at least here in Europe. It's much different if you go to other places of the world... > This is the oh-so-familiar argument on why many companies use > exclusively Microsoft, or everything Apple, etc... ACK, it's the same story all over again. And still in each of the PC, Desktop, Server, Application Software, OS, etc. markets you see much more mix + match than in the GSM world... Even if you look at IP networks, not _everything_ is cisco, you commonly find heterogenous installations. 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 alfonso.degregorio at gmail.com Sun Jul 17 19:44:16 2011 From: alfonso.degregorio at gmail.com (Alfonso De Gregorio) Date: Sun, 17 Jul 2011 21:44:16 +0200 Subject: Different protocols In-Reply-To: <20110717184316.GD8759@prithivi.gnumonks.org> References: <4B74EE3E-2386-4859-A5BB-6D4123BE420C@manateeshome.com> <20110717184316.GD8759@prithivi.gnumonks.org> Message-ID: On Sun, Jul 17, 2011 at 8:43 PM, Harald Welte wrote: > What I'm personally surprised though is why nobody hires people (like us) > to develop translators / gateways between those dialects. ?That's > probably a hell lot cheaper than replacing your core network from one > vendor with another vendor... Though greater interoperability contributes directly in reducing switching costs, manufacturers enforce their lock-in strategy using also license agreements. For every degree of freedom adopters ask for (e.g., one more knob or switch, or vendor independence), they are willingly or not accepting one more quantum of liability. At the end of the day -- in a world where there's already very little accountability on the part of producers and products sold today -- adopters find themselves holding the liability bag. This can have a major impact on the operational risks. There is an opportunity for us, if we deliver not only a gateway between network dialects but also confidence about the (updated) processes to which operators would like to entrust their businesses in order to overcome the vendor lock-in. > Regards, > > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) Ciao, alfonso -- alfonso tweets @secYOUre blog http://Plaintext.crypto.lo.gy/ From daniel at totalueberwachung.de Sun Jul 17 15:48:16 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Sun, 17 Jul 2011 17:48:16 +0200 Subject: [PATCH 0/4] logrotate related patches Message-ID: Hi, this series of patches makes sure that the logs generated by osmo_pcap_server are cleaned up. I wasn't able to use logrotate since we wanted to keep the timestamped filenames and logrotate would treat every log as independent. The script now sorts the pcap logs per-client and deletes all but the newest N files. The oldest M remaining files will be compressed with gzip. Some small fixes for problems I encountered are included. I hope the requirement for libosmocore 0.3.2 is okay. Regards, Daniel Willmann (4): server: Fix memory leak and error handling in restart_pcap server: Register signal handler to reopen logfiles on SIGHUP Catch up with API change in osmo_sock_init contrib: Add a script to clean up in regular intervals Makefile.am | 2 +- configure.ac | 3 +- contrib/Makefile.am | 1 + contrib/clean_old | 46 ++++++++++++++++++++++++++++++++++ include/osmo-pcap/osmo_pcap_server.h | 2 + src/osmo_client_network.c | 2 +- src/osmo_server_main.c | 4 +++ src/osmo_server_network.c | 31 +++++++++++++++++++++- 8 files changed, 86 insertions(+), 5 deletions(-) create mode 100644 contrib/Makefile.am create mode 100755 contrib/clean_old -- 1.7.5.3 From daniel at totalueberwachung.de Sun Jul 17 15:48:17 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Sun, 17 Jul 2011 17:48:17 +0200 Subject: [PATCH 1/4] server: Fix memory leak and error handling in restart_pcap In-Reply-To: References: Message-ID: <082b68a755444446d93fc0027beef8d6722340e2.1310916741.git.daniel@totalueberwachung.de> --- src/osmo_server_network.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/src/osmo_server_network.c b/src/osmo_server_network.c index 121aa2c..be61d03 100644 --- a/src/osmo_server_network.c +++ b/src/osmo_server_network.c @@ -62,14 +62,20 @@ static void restart_pcap(struct osmo_pcap_conn *conn) conn->local_fd = -1; } - filename = talloc_asprintf(conn, "%s/trace-%s-%d%.2d%.2d_%.2d%.2d%.2d.pcap", conn->server->base_path, conn->name, tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec); + + if (!filename) { + LOGP(DSERVER, LOGL_ERROR, "Failed to assemble filename for %s.\n", conn->name); + return; + } + conn->local_fd = creat(filename, 0440); if (conn->local_fd < 0) { LOGP(DSERVER, LOGL_ERROR, "Failed to file: '%s'\n", filename); + talloc_free(filename); return; } @@ -78,6 +84,7 @@ static void restart_pcap(struct osmo_pcap_conn *conn) LOGP(DSERVER, LOGL_ERROR, "Failed to write the header: %d\n", errno); close(conn->local_fd); conn->local_fd = -1; + talloc_free(filename); return; } -- 1.7.5.3 From daniel at totalueberwachung.de Sun Jul 17 15:48:18 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Sun, 17 Jul 2011 17:48:18 +0200 Subject: [PATCH 2/4] server: Register signal handler to reopen logfiles on SIGHUP In-Reply-To: References: Message-ID: --- include/osmo-pcap/osmo_pcap_server.h | 2 ++ src/osmo_server_main.c | 4 ++++ src/osmo_server_network.c | 20 ++++++++++++++++++++ 3 files changed, 26 insertions(+), 0 deletions(-) diff --git a/include/osmo-pcap/osmo_pcap_server.h b/include/osmo-pcap/osmo_pcap_server.h index b408c47..1f2f6fc 100644 --- a/include/osmo-pcap/osmo_pcap_server.h +++ b/include/osmo-pcap/osmo_pcap_server.h @@ -63,6 +63,7 @@ struct osmo_pcap_conn { /* read buffering */ int state; int pend; + int reopen; char buf[4096]; struct osmo_pcap_data *data; }; @@ -80,6 +81,7 @@ struct osmo_pcap_server { extern struct osmo_pcap_server *pcap_server; +void osmo_pcap_server_reopen(struct osmo_pcap_server *server); int osmo_pcap_server_listen(struct osmo_pcap_server *server); struct osmo_pcap_conn *osmo_pcap_server_find(struct osmo_pcap_server *ser, const char *name); diff --git a/src/osmo_server_main.c b/src/osmo_server_main.c index 5c1ad58..4e67163 100644 --- a/src/osmo_server_main.c +++ b/src/osmo_server_main.c @@ -140,6 +140,9 @@ static void signal_handler(int signal) talloc_report(tall_vty_ctx, stderr); talloc_report_full(tall_bsc_ctx, stderr); break; + case SIGHUP: + osmo_pcap_server_reopen(pcap_server); + break; default: break; } @@ -175,6 +178,7 @@ int main(int argc, char **argv) signal(SIGABRT, &signal_handler); signal(SIGUSR1, &signal_handler); osmo_init_ignore_signals(); + signal(SIGHUP, &signal_handler); telnet_init(tall_bsc_ctx, NULL, 4241); diff --git a/src/osmo_server_network.c b/src/osmo_server_network.c index be61d03..513ca1f 100644 --- a/src/osmo_server_network.c +++ b/src/osmo_server_network.c @@ -253,6 +253,11 @@ static int read_cb(struct osmo_fd *fd, unsigned int what) conn = fd->data; if (conn->state == STATE_INITIAL) { + if (conn->reopen) { + LOGP(DSERVER, LOGL_INFO, "Reopening log for %s now.\n", conn->name); + restart_pcap(conn); + conn->reopen = 0; + } return read_cb_initial(fd, conn); } else if (conn->state == STATE_DATA) { return read_cb_data(fd, conn); @@ -336,3 +341,18 @@ int osmo_pcap_server_listen(struct osmo_pcap_server *server) return 0; } + +void osmo_pcap_server_reopen(struct osmo_pcap_server *server) +{ + struct osmo_pcap_conn *conn; + LOGP(DSERVER, LOGL_INFO, "Reopening all logfiles.\n"); + llist_for_each_entry(conn, &server->conn, entry) { + /* Write the complete packet out first */ + if (conn->state == STATE_INITIAL) { + restart_pcap(conn); + } else { + LOGP(DSERVER, LOGL_INFO, "Delaying %s until current packet is complete.\n", conn->name); + conn->reopen = 1; + } + } +} -- 1.7.5.3 From daniel at totalueberwachung.de Sun Jul 17 15:48:19 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Sun, 17 Jul 2011 17:48:19 +0200 Subject: [PATCH 3/4] Catch up with API change in osmo_sock_init In-Reply-To: References: Message-ID: <00e89d1b89d211940d8afcfdb08a54162c8bbde2.1310916741.git.daniel@totalueberwachung.de> The connect0_bind1 parameter has been replaced by a generic flag parameter. With this patch osmo-pcap works (only) with versions of libosmocore 0.3.2 or newer - configure.ac changed to reflects that. --- configure.ac | 2 +- src/osmo_client_network.c | 2 +- src/osmo_server_network.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 51669ec..9977ef6 100644 --- a/configure.ac +++ b/configure.ac @@ -15,7 +15,7 @@ AC_PROG_INSTALL AC_PROG_RANLIB dnl checks for libraries -PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore >= 0.3.0) +PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore >= 0.3.2) PKG_CHECK_MODULES(LIBOSMOVTY, libosmovty >= 0.3.0) dnl checks for header files diff --git a/src/osmo_client_network.c b/src/osmo_client_network.c index 281e8eb..bd1b9db 100644 --- a/src/osmo_client_network.c +++ b/src/osmo_client_network.c @@ -163,7 +163,7 @@ void osmo_client_connect(struct osmo_pcap_client *client) osmo_wqueue_clear(&client->wqueue); fd = osmo_sock_init(AF_INET, SOCK_STREAM, IPPROTO_TCP, - client->srv_ip, client->srv_port, 0); + client->srv_ip, client->srv_port, OSMO_SOCK_F_CONNECT); if (fd < 0) { LOGP(DCLIENT, LOGL_ERROR, "Failed to connect to %s:%d\n", diff --git a/src/osmo_server_network.c b/src/osmo_server_network.c index 513ca1f..a67f07a 100644 --- a/src/osmo_server_network.c +++ b/src/osmo_server_network.c @@ -322,7 +322,7 @@ int osmo_pcap_server_listen(struct osmo_pcap_server *server) int fd; fd = osmo_sock_init(AF_INET, SOCK_STREAM, IPPROTO_TCP, - server->addr, server->port, 1); + server->addr, server->port, OSMO_SOCK_F_BIND); if (fd < 0) { LOGP(DSERVER, LOGL_ERROR, "Failed to create the server socket.\n"); return -1; -- 1.7.5.3 From daniel at totalueberwachung.de Sun Jul 17 15:48:20 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Sun, 17 Jul 2011 17:48:20 +0200 Subject: [PATCH 4/4] contrib: Add a script to clean up in regular intervals In-Reply-To: References: Message-ID: <8b789537d6890b8bee67b35556d1a186ccdd7ef9.1310916741.git.daniel@totalueberwachung.de> This script should be run from cron. It compresses and deletes older files. --- Makefile.am | 2 +- configure.ac | 1 + contrib/Makefile.am | 1 + contrib/clean_old | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 49 insertions(+), 1 deletions(-) create mode 100644 contrib/Makefile.am create mode 100755 contrib/clean_old diff --git a/Makefile.am b/Makefile.am index b9a4331..7c9c65b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,6 +1,6 @@ AUTOMAKE_OPTIONS = foreign dist-bzip2 1.6 -SUBDIRS = include src +SUBDIRS = include src contrib BUILT_SOURCES = $(top_srcdir)/.version EXTRA_DIST = git-version-gen diff --git a/configure.ac b/configure.ac index 9977ef6..2f4de9d 100644 --- a/configure.ac +++ b/configure.ac @@ -57,4 +57,5 @@ AC_OUTPUT( include/Makefile include/osmo-pcap/Makefile src/Makefile + contrib/Makefile Makefile) diff --git a/contrib/Makefile.am b/contrib/Makefile.am new file mode 100644 index 0000000..b392196 --- /dev/null +++ b/contrib/Makefile.am @@ -0,0 +1 @@ +dist_pkgdata_DATA = clean_old diff --git a/contrib/clean_old b/contrib/clean_old new file mode 100755 index 0000000..3294c45 --- /dev/null +++ b/contrib/clean_old @@ -0,0 +1,46 @@ +#! /bin/sh + +# Script designed to clean up (zip/delete) old files +# Adjust the variables below and then copy/symlink this script +# to /etc/cron/cron.{hourly,daily} + +# We want to keep the filenames dated and that confuses logrotate, +# hence this script. + +# Number of pcap files per client +NUMFILES=8 +ZIPAFTER=3 +VERBOSE=0 + +# Path where the logfiles reside in +BASEPATH=/var/lib/osmo-pcap/ + +# Find the client names present in basepath +# Check how many files there are for each client +# Delete files in excess of NUMFILES + +CLIENTS=$(find $BASEPATH -name "trace-*" |sed -e "s/.*trace-\([^-]\+\).*/\1/" |sort |uniq) + +do_cleanup() +{ + i=1 + for log in $(find $BASEPATH -name "trace-$1*" |sort); do + if [ $i -gt $NUMFILES ]; then + [ $VERBOSE -eq 1 ] && echo "Deleting file $log" + rm -f $log + elif [ $i -gt $ZIPAFTER ]; then + if [ "${log##*.}" != "gz" ]; then + [ $VERBOSE -eq 1 ] && echo "Compressing file $log" + gzip $log + fi + else + [ $VERBOSE -eq 1 ] && echo "Noop for file $log" + fi + i=$(($i+1)) + done +} + +for client in $CLIENTS; do + [ $VERBOSE -eq 1 ] && echo "Cleaning logs for $client" + do_cleanup $client +done -- 1.7.5.3 From holger at freyther.de Tue Jul 19 16:00:27 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 19 Jul 2011 18:00:27 +0200 Subject: [PATCH 0/4] logrotate related patches In-Reply-To: References: Message-ID: <4E25AA1B.5010202@freyther.de> On 07/17/2011 05:48 PM, Daniel Willmann wrote: > Hi, thanks, applied and pushed. From axel at walsleben.info Mon Jul 18 16:55:13 2011 From: axel at walsleben.info (Axel Walsleben) Date: Mon, 18 Jul 2011 18:55:13 +0200 Subject: Compile Error with latest Version Message-ID: <4E246571.6040907@walsleben.info> Hi List, i just tried to build openbsc latest checkout. libosmocore compiles fine (checkout is also from today) i got this error: make[3]: Betrete Verzeichnis '/home/demo/openbsc/openbsc/src/libcommon' CC common_vty.o In file included from common_vty.c:26: ../../include/openbsc/vty.h:32: error: redeclaration of enumerator ?E1INP_NODE? /usr/local/include/osmocom/vty/command.h:77: note: previous definition of ?E1INP_NODE? was here In file included from common_vty.c:28: ../../include/openbsc/debug.h:16: error: expected identifier before ?-? token In file included from ../../include/openbsc/bsc_nat.h:24, from common_vty.c:30: ../../include/openbsc/mgcp.h: In function ?mgcp_timeslot_to_endpoint?: ../../include/openbsc/mgcp.h:180: error: ?DMGCP? undeclared (first use in this function) ../../include/openbsc/mgcp.h:180: error: (Each undeclared identifier is reported only once ../../include/openbsc/mgcp.h:180: error: for each function it appears in.) make[3]: *** [common_vty.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/demo/openbsc/openbsc/src/libcommon' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/demo/openbsc/openbsc/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/demo/openbsc/openbsc' so libcommon failes. is there a fix available or it is a unknown problem thanks. Regards axel From holger at freyther.de Mon Jul 18 17:01:18 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 18 Jul 2011 19:01:18 +0200 Subject: Making NITB Database code async Message-ID: <4E2466DE.50400@freyther.de> Hi all, I wonder what is the easiest way to make our database code async. Looking at our tables and code we do not seem to have a very complicated use. Problem: libdbi makes queries to SQLite that kills performance (e.g. every SELECT sends out pragma queries for every column to be queried). We have a hacked up libdbi from the last congress. We have some issues inserting new data into the database (e.g. the db being locked). In one way or another we have some issues there (either nitb will block, or the external process will...) When moving to postgres and a database on a different system we will have to deal with latencies and round trip time, but our code is sync. Goal: Most of our setting is 'set and forget'. We don't have complicate transactions (e.g. we don't have two nitb's setting the LAC of a subscriber, or wouldn't really care). When updating the in-memory representation, we don't mind how long it will take until it hits the disk on the remote system. Proposal: Also setting/storing will can remain like they are, the return value does only mean that a request has been sent. Only loading the subscriber, SMS, need to be asynchronous. M1: Change the gsm_subscriber code to load a subscriber asynchronously, this will mostly touch the gsm48 code and the VTY area. On load one can specify a callback. M2: Change the SMS code to load a SMS asynchronously, this will mostly change the SMS queue, some parts of the SMS submit (e.g. to check if there are still SMS to be sent) and the submit in the VTY M3: Probably create our own DB abstraction and provide a SQLite3 and Postgres backend using the native API of both of them (and getting rid of the libdbi and gdb issue) biggest problem: What do we do with the DB queries done from VTY that are asynchronous, e.g to confirm a SMS has been stored? Do we care about it? Do we turn this to a 'notification'? comments holger From laforge at gnumonks.org Mon Jul 18 22:24:48 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 19 Jul 2011 00:24:48 +0200 Subject: Making NITB Database code async In-Reply-To: <4E2466DE.50400@freyther.de> References: <4E2466DE.50400@freyther.de> Message-ID: <20110718222448.GC2015@prithivi.gnumonks.org> Hi Holger, On Mon, Jul 18, 2011 at 07:01:18PM +0200, Holger Hans Peter Freyther wrote: > I wonder what is the easiest way to make our database code async. Looking at > our tables and code we do not seem to have a very complicated use. I agree with your analysis in all points. I would probably look at the SMS issue independently, as we always wanted to get the SMS code out of the main program and into a separate process. If we do this, that process can do whatever it does. The main program simply behaves like a GW-MSC talking to an SMSC. > biggest problem: > What do we do with the DB queries done from VTY that are > asynchronous, e.g to confirm a SMS has been stored? Do we care about > it? Do we turn this to a 'notification'? One option would be to simply 'not do it', i.e. remove those features form the vty and have a different/external program that can query the database independently. If we still want to show everything under one command like, we might add some kind of 'pass through' where we pass certain commands out (via a socket) to an external program. That program then can have blocking semantics or whatever it wants. A more radical approach would be to have a per-telnet-vty thread. As there are only few concurrent (typically 1) vty sessions active, we wouldn't have to worry about the number of threads here. 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 daniel at totalueberwachung.de Tue Jul 19 09:58:14 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Tue, 19 Jul 2011 11:58:14 +0200 Subject: [PATCH 0/1] Updated script to handle whitespace Message-ID: Hello, here an updated version of the script that handles whitespace in filennames properly. Thanks Holger for pointing out that such things do exist. :-) Regards, Daniel Willmann (1): contrib: Add a script to clean up in regular intervals Makefile.am | 2 +- configure.ac | 1 + contrib/Makefile.am | 1 + contrib/osmo_pcap_clean_old | 47 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 50 insertions(+), 1 deletions(-) create mode 100644 contrib/Makefile.am create mode 100755 contrib/osmo_pcap_clean_old -- 1.7.5.3 From daniel at totalueberwachung.de Tue Jul 19 09:58:15 2011 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Tue, 19 Jul 2011 11:58:15 +0200 Subject: [PATCH 1/1] contrib: Add a script to clean up in regular intervals In-Reply-To: References: Message-ID: <7002fd050afb022e79df522b4857046fe4322fa5.1311069191.git.daniel@totalueberwachung.de> This script should be run from cron. It compresses and deletes older files. --- Makefile.am | 2 +- configure.ac | 1 + contrib/Makefile.am | 1 + contrib/osmo_pcap_clean_old | 47 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 50 insertions(+), 1 deletions(-) create mode 100644 contrib/Makefile.am create mode 100755 contrib/osmo_pcap_clean_old diff --git a/Makefile.am b/Makefile.am index b9a4331..7c9c65b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,6 +1,6 @@ AUTOMAKE_OPTIONS = foreign dist-bzip2 1.6 -SUBDIRS = include src +SUBDIRS = include src contrib BUILT_SOURCES = $(top_srcdir)/.version EXTRA_DIST = git-version-gen diff --git a/configure.ac b/configure.ac index 9977ef6..2f4de9d 100644 --- a/configure.ac +++ b/configure.ac @@ -57,4 +57,5 @@ AC_OUTPUT( include/Makefile include/osmo-pcap/Makefile src/Makefile + contrib/Makefile Makefile) diff --git a/contrib/Makefile.am b/contrib/Makefile.am new file mode 100644 index 0000000..32bb8c2 --- /dev/null +++ b/contrib/Makefile.am @@ -0,0 +1 @@ +dist_pkgdata_DATA = osmo_pcap_clean_old diff --git a/contrib/osmo_pcap_clean_old b/contrib/osmo_pcap_clean_old new file mode 100755 index 0000000..d24a94b --- /dev/null +++ b/contrib/osmo_pcap_clean_old @@ -0,0 +1,47 @@ +#! /bin/sh + +# Script designed to clean up (zip/delete) old files +# Adjust the variables below and then copy/symlink this script +# to /etc/cron/cron.{hourly,daily} + +# We want to keep the filenames dated and that confuses logrotate, +# hence this script. + +# Number of pcap files per client +NUMFILES=8 +ZIPAFTER=3 +VERBOSE=0 + +# Path where the logfiles reside in +BASEPATH="/var/lib/osmo-pcap/" + +# Find the client names present in basepath +# Check how many files there are for each client +# Delete files in excess of NUMFILES + +cd "$BASEPATH" + + +do_cleanup() +{ + i=1 + find . -name "trace-$1*" |sort | while read LOG; do + if [ $i -gt $NUMFILES ]; then + [ $VERBOSE -eq 1 ] && echo "Deleting file \"$LOG\"" + rm -f "$LOG" + elif [ $i -gt $ZIPAFTER ]; then + if [ "${LOG##*.}" != "gz" ]; then + [ $VERBOSE -eq 1 ] && echo "Compressing file \"$LOG\"" + gzip "$LOG" + fi + else + [ $VERBOSE -eq 1 ] && echo "Noop for file \"$LOG\"" + fi + i=$(($i+1)) + done +} + +find . -name "trace-*" |sed -e "s/.*trace-\([^-]\+\).*/\1/" |sort |uniq | while read CLIENT; do + [ $VERBOSE -eq 1 ] && echo "Cleaning logs for $CLIENT" + do_cleanup "$CLIENT" +done -- 1.7.5.3 From lists at infosecurity.ch Fri Jul 22 09:50:19 2011 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Fri, 22 Jul 2011 11:50:19 +0200 Subject: Telecommunication and Wireless Hacking at CCC CAMP 2011 Message-ID: <4E2947DB.5000904@infosecurity.ch> Hi all, i just wanted to send a summary of all most cool talk that will be at CCC CAMP 2011 related to Telecommunications and Wireless Technologies hacking: Open-source 4G radio - It's time to start WiMAX and LTE hacking http://events.ccc.de/camp/2011/Fahrplan/events/4446.en.html Applied Research on security of TETRA radio - Digital radio technology beyond GSM http://events.ccc.de/camp/2011/Fahrplan/events/4496.en.html GPRS Intercept - Wardriving phone networks http://events.ccc.de/camp/2011/Fahrplan/events/4504.en.html Introduction to Satellite Communications - Installation and Operation of Satellite Systems http://events.ccc.de/camp/2011/Fahrplan/events/4442.en.html Transition Telecom - Telecommunications and networking during energy descent http://events.ccc.de/camp/2011/Fahrplan/events/4459.en.html Anyone missing to the list? -naif From lists at infosecurity.ch Fri Jul 22 10:55:13 2011 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Fri, 22 Jul 2011 12:55:13 +0200 Subject: Telecommunication and Wireless Hacking at CCC CAMP 2011 In-Reply-To: <4E2947DB.5000904@infosecurity.ch> References: <4E2947DB.5000904@infosecurity.ch> Message-ID: <4E295711.6010000@infosecurity.ch> On 7/22/11 11:50 AM, Fabio Pietrosanti (naif) wrote: > Open-source 4G radio - It's time to start WiMAX and LTE hacking > http://events.ccc.de/camp/2011/Fahrplan/events/4446.en.html > > Applied Research on security of TETRA radio - Digital radio technology > beyond GSM > http://events.ccc.de/camp/2011/Fahrplan/events/4496.en.html > > GPRS Intercept - Wardriving phone networks > http://events.ccc.de/camp/2011/Fahrplan/events/4504.en.html > > Introduction to Satellite Communications - Installation and Operation > of Satellite Systems > http://events.ccc.de/camp/2011/Fahrplan/events/4442.en.html > > Transition Telecom - Telecommunications and networking during energy descent > http://events.ccc.de/camp/2011/Fahrplan/events/4459.en.html > > Anyone missing to the list? Stuff you don't see - every day - GNU Radio Internals - how to use the Framework http://events.ccc.de/camp/2011/Fahrplan/events/4453.en.html Hacking community is owning most radio frequencies and protocols! That's cooooool! :-) -naif From mailman at lists.osmocom.org Fri Jul 22 22:13:05 2011 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Sat, 23 Jul 2011 00:13:05 +0200 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: OpenBSC Member: christoph_schueler at web.de Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery System Subject: Mail delivery failed: returning message to sender Date: Sat, 23 Jul 2011 00:13:04 +0200 Size: 3934 URL: From mueller.lennart at googlemail.com Sat Jul 23 00:19:52 2011 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Sat, 23 Jul 2011 02:19:52 +0200 Subject: Current OpenBSC + LCR using MNCC socket Message-ID: Hello, since some days I'm using an old version of OpenBSC and LCR (as suggested by University of Freiburg) to interconnect our GSM and PSTN. We are using Debian squeeze and a nanoBTS. However, I would like to upgrade to a newer version of OpenBSC. Unfortunately, no current LCR version compiles without errors such as missing declarations etc., for example: g++ -DHAVE_CONFIG_H -I. -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -g -O2 -MT gsm.o -MD -MP -MF .deps/gsm.Tpo -c -o gsm.o gsm.cpp In file included from ./openbsc/include/openbsc/rest_octets.h:4, from ./openbsc/include/openbsc/gsm_data.h:9, from gsm_bs.h:2, from main.h:157, from gsm.cpp:12: ./openbsc/include/openbsc/gsm_04_08.h:33: error: use of enum ?gsm_chan_t? without previous declaration ./openbsc/include/openbsc/gsm_04_08.h:33: error: invalid type in declaration before ?;? token ./openbsc/include/openbsc/gsm_04_08.h:34: error: use of enum ?gsm_chreq_reason_t? without previous declaration ./openbsc/include/openbsc/gsm_04_08.h:34: error: invalid type in declaration before ?;? token In file included from ./openbsc/include/openbsc/gsm_data_shared.h:11, from ./openbsc/include/openbsc/gsm_data.h:154, from gsm_bs.h:2, from main.h:157, from gsm.cpp:12: ./libosmocore/include/osmocom/gsm/gsm_utils.h:62: error: expected identifier before ?)? token ./libosmocore/include/osmocom/gsm/gsm_utils.h:62: error: two or more data types in declaration of ?parameter? gsm.cpp: In function ?gsm_mncc* create_mncc(int, unsigned int)?: gsm.cpp:195: error: invalid application of ?sizeof? to incomplete type ?gsm_mncc? etc. etc. If I manually include some header files from libosmocore and OpenBSC to LCR and declare missing ENUMs (dirty hacks), LCR starts without a problem. Starting osmo-nitb with -P and -m parameters, LCR can connect to MNCC socket. But any try to start voice traffic either from or to a mobile station results into these continuous messages: <0006> gsm_04_08.c:2954 receive message GSM_TCH_FRAME <0006> gsm_04_08.c:2986 TCH frame to lchan without RTP connection <0006> gsm_04_08.c:2954 receive message GSM_TCH_FRAME <0006> gsm_04_08.c:2986 TCH frame to lchan without RTP connection <0006> gsm_04_08.c:2954 receive message GSM_TCH_FRAME <0006> gsm_04_08.c:2986 TCH frame to lchan without RTP connection ..... Furthermore, either OpenBSC ignores LCR messages or LCR does not send messages to OpenBSC, because calls from mobile stations are signalled through LCR to asterisk; calls from asterisk to a mobile station are indicated by LCR but not by OpenBSC. All configuration files of the running setup (openbsc.cfg, LCR files) are used. Commits... - LCR: 39a36cb99a6dba1441a7a4b51914e0dadf3a7ae8 - libosmocore: 95f7eb288c4b8b69d61fa8d68957fb21f09e11e5 - OpenBSC: fe2d9b2fab2ae36a12411435f910efc9697d7b18 (debian branch, but same problem with master) Is there really no possibility at the moment to run LCR with a current OpenBSC? Many thanks in advance, Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Jul 23 08:55:32 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 23 Jul 2011 10:55:32 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: References: Message-ID: <20110723085532.GT11553@prithivi.gnumonks.org> Hi Lennart, On Sat, Jul 23, 2011 at 02:19:52AM +0200, Lennart M?ller wrote: > since some days I'm using an old version of OpenBSC and LCR (as suggested by > University of Freiburg) to interconnect our GSM and PSTN. We are using > Debian squeeze and a nanoBTS. > However, I would like to upgrade to a newer version of OpenBSC. > Unfortunately, no current LCR version compiles without errors such as > missing declarations etc., for example: I've committed some changes a couple of minutes ago (to libosmocore + openbsc) that make lcr compile again. The only missing part is one minor change to lcr: diff --git a/gsm_bs.h b/gsm_bs.h index 8a55213..45bf083 100644 --- a/gsm_bs.h +++ b/gsm_bs.h @@ -1,5 +1,6 @@ extern "C" { #include +#include } /* GSM port class */ > Starting osmo-nitb with -P and -m parameters, LCR can connect to MNCC > socket. But any try to start voice traffic either from or to a mobile > station results into these continuous messages: I will try to look into it, but I'm not sure when I find time to do so, there are lots of other issues on my todo list pending at the moment. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mueller.lennart at googlemail.com Sat Jul 23 20:59:53 2011 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Sat, 23 Jul 2011 22:59:53 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <20110723085532.GT11553@prithivi.gnumonks.org> References: <20110723085532.GT11553@prithivi.gnumonks.org> Message-ID: Hi Harald, 2011/7/23 Harald Welte > I've committed some changes a couple of minutes ago (to libosmocore + > openbsc) that make lcr compile again. > > The only missing part is one minor change to lcr: > > diff --git a/gsm_bs.h b/gsm_bs.h > index 8a55213..45bf083 100644 > --- a/gsm_bs.h > +++ b/gsm_bs.h > @@ -1,5 +1,6 @@ > extern "C" { > #include > +#include > } > > /* GSM port class */ > Compiles now, thanks! > > Starting osmo-nitb with -P and -m parameters, LCR can connect to MNCC > > socket. But any try to start voice traffic either from or to a mobile > > station results into these continuous messages: > > I will try to look into it, but I'm not sure when I find time to do so, > there are lots of other issues on my todo list pending at the moment. > Okay, I see. It works now, I traced down the problem to LCR. The file gsm.cpp contains following function at line 200: int send_and_free_mncc(void *instance, unsigned int msg_type, void *data) There is an if-Query: if (instance) { #ifdef WITH_GSM_BS ret = mncc_send((struct gsm_network *)instance, msg_type, data); #endif #ifdef WITH_GSM_MS ret = mncc_send((struct osmocom_ms *)instance, msg_type, data); #endif } The problem is: The query is always false, so no messages are sent to OpenBSC. If I comment out the if-query, everything works as expected: Calls can be made mobile originated and mobile terminated. However, I don't think the if-query is there without a reason. Within gsm_bs.cpp, send_and_free_mncc is called with parameter p_m_g_instance, which is written at Line 64: p_m_g_instance = gsm->network; -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Mon Jul 25 09:49:20 2011 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 25 Jul 2011 11:49:20 +0200 Subject: AW: Current OpenBSC + LCR using MNCC socket Message-ID: > I've committed some changes a couple of minutes ago (to libosmocore + > openbsc) that make lcr compile again. > The problem is: The query is always false, so no messages are sent to OpenBSC. > If I comment out the if-query, everything works as expected: Calls can be made mobile originated and mobile terminated. > However, I don't think the if-query is there without a reason. Since there is only one (gsm-)network instance, the "gsm->network" pointer must be set to something != NULL. Then it should work Thanx, applied both fixes. (blindly) Please try if it works. From meierk at informatik.uni-freiburg.de Mon Jul 25 10:24:30 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Mon, 25 Jul 2011 12:24:30 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: References: Message-ID: <4E2D445E.5030709@informatik.uni-freiburg.de> On 25.07.2011 11:49, Andreas.Eversberg wrote: >> The problem is: The query is always false, so no messages are sent to OpenBSC. >> If I comment out the if-query, everything works as expected: Calls can be made mobile originated and mobile terminated. >> However, I don't think the if-query is there without a reason. > > Since there is only one (gsm-)network instance, the "gsm->network" pointer must be set to something != NULL. Then it should work > > Thanx, applied both fixes. (blindly) Please try if it works. Hi Andreas, I tried to compile the master branch of LCR with your last changes. It failed with the error below. Asterisk version is 1.6.2.5. Is Asterisk 1.6 still supported or is 1.8 recommended now? Best regards Konrad make[1]: Betrete Verzeichnis '/home/openbsc/bsc-software/lcr' gcc -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -Dtone_zone_sound=ast_tone_zone_sound -g -O2 -D_GNU_SOURCE -fPIC -c chan_lcr.c -o chan_lcr.po In file included from /usr/include/asterisk/astobj2.h:20, from /usr/include/asterisk/indications.h:29, from chan_lcr.c:160: /usr/include/asterisk/compat.h:93: error: expected identifier or ?(? before ?__extension__? /usr/include/asterisk/compat.h:101: error: expected identifier or ?(? before ?__extension__? /usr/include/asterisk/compat.h:101: error: expected identifier or ?(? before ?)? token chan_lcr.c: In function ?send_message?: chan_lcr.c:383: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c:679:2: warning: #warning DISABLED DUE TO DOUBLE LOCKING PROBLEM chan_lcr.c: In function ?lcr_in_proceeding?: chan_lcr.c:1115: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_alerting?: chan_lcr.c:1136: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_connect?: chan_lcr.c:1167: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_disconnect?: chan_lcr.c:1208: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_release?: chan_lcr.c:1242: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_information?: chan_lcr.c:1285: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_pattern?: chan_lcr.c:1361: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?lcr_in_dtmf?: chan_lcr.c:1391: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?release_all_calls?: chan_lcr.c:1655: warning: ignoring return value of ?write?, declared with attribute warn_unused_result chan_lcr.c: In function ?wake_event?: chan_lcr.c:1805: warning: ignoring return value of ?read?, declared with attribute warn_unused_result chan_lcr.c: In function ?load_module?: chan_lcr.c:3243: warning: passing argument 2 of ?ast_register_application2? from incompatible pointer type /usr/include/asterisk/module.h:427: note: expected ?int (*)(struct ast_channel *, void *)? but argument is of type ?int (*)(struct ast_channel *, void *)? make[1]: *** [chan_lcr.po] Fehler 1 make[1]: Verlasse Verzeichnis '/home/openbsc/bsc-software/lcr' make: *** [all] Fehler 2 From mueller.lennart at googlemail.com Mon Jul 25 19:48:36 2011 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Mon, 25 Jul 2011 21:48:36 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <4E2D445E.5030709@informatik.uni-freiburg.de> References: <4E2D445E.5030709@informatik.uni-freiburg.de> Message-ID: Hello Konrad, 2011/7/25 Konrad Meier > I tried to compile the master branch of LCR with your last changes. It > failed with the error below. Asterisk version is 1.6.2.5. Is Asterisk 1.6 > still supported or is 1.8 recommended now? > I have just compiled the current master branch without a problem, using the Asterisk 1.6 header files of asterisk-dev Debian package: # apt-cache show asterisk-dev Package: asterisk-dev Priority: extra Section: devel Installed-Size: 1688 Maintainer: Debian VoIP Team Architecture: all Source: asterisk Version: 1:1.6.2.9-2+squeeze2 Replaces: asterisk (<< 1:1.4.21.1~dfsg-1) Recommends: asterisk Filename: pool/main/a/asterisk/asterisk-dev_1.6.2.9-2+squeeze2_all.deb -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From meierk at informatik.uni-freiburg.de Tue Jul 26 12:31:36 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Tue, 26 Jul 2011 14:31:36 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: References: <4E2D445E.5030709@informatik.uni-freiburg.de> Message-ID: <4E2EB3A8.1020209@informatik.uni-freiburg.de> On 25.07.2011 21:48, Lennart M?ller wrote: > Hello Konrad, > > 2011/7/25 Konrad Meier > > > I tried to compile the master branch of LCR with your last changes. > It failed with the error below. Asterisk version is 1.6.2.5. Is > Asterisk 1.6 still supported or is 1.8 recommended now? > > > I have just compiled the current master branch without a problem, using > the Asterisk 1.6 header files of asterisk-dev Debian package: Hi Lennart, I tried it with a clean debian system and everything compiles well. It seems that I screwed up my test system. Thank you. The next problem is at runtime. If I use LCR to forward calls from openBSC, the call is rejected immediately by LCR with the following message: 000000 TRACE 26.07.11 14:01:12.979 CH: MNCC_REJ_REQ ---- cause coding=3 location=1 value=27 In openBSC it looks like this: ... <0001> gsm_04_08.c:1355 (bts 0 trx 0 ts 2 ti 8 sub 40732) Sending 'MNCC_SETUP_IND' to MNCC. <0001> gsm_04_08.c:3138 (bts 0 trx 0 ts 2 ti 08 sub 40732) Received 'MNCC_REL_REQ' from MNCC in state 1 (INITIATED) ... Have you seen the same problem? Best regards Konrad From meierk at informatik.uni-freiburg.de Tue Jul 26 13:38:17 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Tue, 26 Jul 2011 15:38:17 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <4E2EB3A8.1020209@informatik.uni-freiburg.de> References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> Message-ID: <4E2EC349.5090608@informatik.uni-freiburg.de> On 26.07.2011 14:31, Konrad Meier wrote: > On 25.07.2011 21:48, Lennart M?ller wrote: >> Hello Konrad, >> >> 2011/7/25 Konrad Meier> > >> >> I tried to compile the master branch of LCR with your last changes. >> It failed with the error below. Asterisk version is 1.6.2.5. Is >> Asterisk 1.6 still supported or is 1.8 recommended now? >> >> >> I have just compiled the current master branch without a problem, using >> the Asterisk 1.6 header files of asterisk-dev Debian package: > > Hi Lennart, > > I tried it with a clean debian system and everything compiles well. It > seems that I screwed up my test system. Thank you. > > The next problem is at runtime. If I use LCR to forward calls from > openBSC, the call is rejected immediately by LCR with the following message: > 000000 TRACE 26.07.11 14:01:12.979 CH: MNCC_REJ_REQ ---- cause coding=3 > location=1 value=27 > > In openBSC it looks like this: > ... > <0001> gsm_04_08.c:1355 (bts 0 trx 0 ts 2 ti 8 sub 40732) Sending > 'MNCC_SETUP_IND' to MNCC. > <0001> gsm_04_08.c:3138 (bts 0 trx 0 ts 2 ti 08 sub 40732) Received > 'MNCC_REL_REQ' from MNCC in state 1 (INITIATED) > ... I could solve the above problem by a system restart. The mISDN_l1loop module was loaded but for some reason could not be used by LCR. The LCR error message was: 000000 ERROR loop port 1 failed to bind socket. (errno 93) By playing with the mISDN_l1loop module I discovered a strange problem. If I load the module with "modprobe mISDN_l1loop pri=1 nchannel=30" all system memory is allocated by LCR after some seconds. If I load it with "nchannel=20" than everithing works fine. Can someone confirm this problem? Regards Konrad From mueller.lennart at googlemail.com Tue Jul 26 18:38:37 2011 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Tue, 26 Jul 2011 20:38:37 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <4E2EC349.5090608@informatik.uni-freiburg.de> References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> Message-ID: 2011/7/26 Konrad Meier > I could solve the above problem by a system restart. The mISDN_l1loop > module was loaded but for some reason could not be used by LCR. The LCR > error message was: > 000000 ERROR loop port 1 failed to bind socket. (errno 93) > > > By playing with the mISDN_l1loop module I discovered a strange problem. If > I load the module with "modprobe mISDN_l1loop pri=1 nchannel=30" all system > memory is allocated by LCR after some seconds. > > If I load it with "nchannel=20" than everithing works fine. > > Can someone confirm this problem? > > Regards > Konrad > From meierk at informatik.uni-freiburg.de Wed Jul 27 09:58:32 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Wed, 27 Jul 2011 11:58:32 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> Message-ID: <4E2FE148.5000700@informatik.uni-freiburg.de> On 26.07.2011 20:38, Lennart M?ller wrote: > From my experience, no. > My init.d script does the following in short: > > modprobe mISDN_dsp > modprobe mISDN_l1loop nchannel=30 interfaces=2 > sleep 1 > > echo 1 > /proc/sys/net/ipv4/ip_forward > iptables -t nat -A POSTROUTING -s 192.168.253.0/24 > -o eth0 -j MASQUERADE > > screen -S bsc -d -m su gsm -c "osmo-nitb -d > DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c > /etc/openbsc/openbsc.cfg -m -P" > screen -S lcr -d -m su gsm -c "/usr/sbin/lcr start" > > I'm using mISDN_l1loop.ko from current mISDN git because it was not > included in my kernel. Small patch to make it compile: > > --- a/drivers/isdn/mISDN/hwchannel.c > +++ b/drivers/isdn/mISDN/hwchannel.c > @@ -19,6 +19,8 @@ > #include > #include > > +bool flush_work_sync (struct work_struct *); > + > static void > dchannel_bh(struct work_struct *ws) > { Hi, I solved the memory allocation problem. It was the interface configuration from LCR. To work properly I had to remove the [Ext] and [Int] section in the file /usr/local/lcr/interface.conf This was indicated by a error message in LCR during start: 000000 ERROR Port 1 already in use by LCR. You can't use a NT port multiple times. All necessary steps for a working OpenBSC + LCR setup can be found in the step by step guide here: http://lab.ks.uni-freiburg.de/projects/gsm/wiki/Openbsc_lcr @Andreas: Can you apply the mISDN patch from Lennart to the mISDN-Git? Than everything compiles and works properly. Best regards Konrad From admin at manateeshome.com Sat Jul 30 17:17:51 2011 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 31 Jul 2011 02:17:51 +0900 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <4E2FE148.5000700@informatik.uni-freiburg.de> References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> <4E2FE148.5000700@informatik.uni-freiburg.de> Message-ID: <004201cc4edc$9e425260$dac6f720$@manateeshome.com> FATAL: Error inserting mISDN_core (/lib/modules/2.6.32-5-686/extra/mISDN_core.ko): Unknown symbol in module, or unknown parameter (see dmesg) I did the exactly same step with fresh Debian 6.0.2 installation and it yields this error. Does anyone know what causes this? I tried using EXPORT_SYMBOL but that case the kernel dropped the modules because of the loop. -----Original Message----- From: openbsc-bounces at lists.osmocom.org [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Konrad Meier Sent: Wednesday, July 27, 2011 6:59 PM To: openbsc at lists.osmocom.org Subject: Re: Current OpenBSC + LCR using MNCC socket On 26.07.2011 20:38, Lennart M?ller wrote: > From my experience, no. > My init.d script does the following in short: > > modprobe mISDN_dsp > modprobe mISDN_l1loop nchannel=30 interfaces=2 > sleep 1 > > echo 1 > /proc/sys/net/ipv4/ip_forward > iptables -t nat -A POSTROUTING -s 192.168.253.0/24 > -o eth0 -j MASQUERADE > > screen -S bsc -d -m su gsm -c "osmo-nitb -d > DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c > /etc/openbsc/openbsc.cfg -m -P" > screen -S lcr -d -m su gsm -c "/usr/sbin/lcr start" > > I'm using mISDN_l1loop.ko from current mISDN git because it was not > included in my kernel. Small patch to make it compile: > > --- a/drivers/isdn/mISDN/hwchannel.c > +++ b/drivers/isdn/mISDN/hwchannel.c > @@ -19,6 +19,8 @@ > #include > #include > > +bool flush_work_sync (struct work_struct *); > + > static void > dchannel_bh(struct work_struct *ws) > { Hi, I solved the memory allocation problem. It was the interface configuration from LCR. To work properly I had to remove the [Ext] and [Int] section in the file /usr/local/lcr/interface.conf This was indicated by a error message in LCR during start: 000000 ERROR Port 1 already in use by LCR. You can't use a NT port multiple times. All necessary steps for a working OpenBSC + LCR setup can be found in the step by step guide here: http://lab.ks.uni-freiburg.de/projects/gsm/wiki/Openbsc_lcr @Andreas: Can you apply the mISDN patch from Lennart to the mISDN-Git? Than everything compiles and works properly. Best regards Konrad From laforge at gnumonks.org Sat Jul 30 18:37:35 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 30 Jul 2011 20:37:35 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <004201cc4edc$9e425260$dac6f720$@manateeshome.com> References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> <4E2FE148.5000700@informatik.uni-freiburg.de> <004201cc4edc$9e425260$dac6f720$@manateeshome.com> Message-ID: <20110730183735.GO6210@prithivi.gnumonks.org> Hi, On Sun, Jul 31, 2011 at 02:17:51AM +0900, Seungju Kim wrote: > FATAL: Error inserting mISDN_core > (/lib/modules/2.6.32-5-686/extra/mISDN_core.ko): Unknown symbol in module, > or unknown parameter (see dmesg) did you actually check 'dmesg', as indicated in the error message? And what did it say? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Sat Jul 30 19:07:14 2011 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 31 Jul 2011 04:07:14 +0900 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <20110730183735.GO6210@prithivi.gnumonks.org> References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> <4E2FE148.5000700@informatik.uni-freiburg.de> <004201cc4edc$9e425260$dac6f720$@manateeshome.com> <20110730183735.GO6210@prithivi.gnumonks.org> Message-ID: <004f01cc4eeb$e6342580$b29c7080$@manateeshome.com> Yes, I checked dmesg but all it says is "Unknown symbol flush_work_sync" there was nothing else. I DID patch the code, and I tried adding EXPORT_SYMBOL(flush_work_sync); but it still does not work. -----Original Message----- From: openbsc-bounces at lists.osmocom.org [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Harald Welte Sent: Sunday, July 31, 2011 3:38 AM To: Seungju Kim Cc: openbsc at lists.osmocom.org; 'Konrad Meier' Subject: Re: Current OpenBSC + LCR using MNCC socket Hi, On Sun, Jul 31, 2011 at 02:17:51AM +0900, Seungju Kim wrote: > FATAL: Error inserting mISDN_core > (/lib/modules/2.6.32-5-686/extra/mISDN_core.ko): Unknown symbol in > module, or unknown parameter (see dmesg) did you actually check 'dmesg', as indicated in the error message? And what did it say? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mueller.lennart at googlemail.com Sat Jul 30 19:20:53 2011 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Sat, 30 Jul 2011 21:20:53 +0200 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: <004f01cc4eeb$e6342580$b29c7080$@manateeshome.com> References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> <4E2FE148.5000700@informatik.uni-freiburg.de> <004201cc4edc$9e425260$dac6f720$@manateeshome.com> <20110730183735.GO6210@prithivi.gnumonks.org> <004f01cc4eeb$e6342580$b29c7080$@manateeshome.com> Message-ID: 2011/7/30 Seungju Kim > Yes, I checked dmesg but all it says is "Unknown symbol flush_work_sync" > there was nothing else. > I DID patch the code, and I tried adding EXPORT_SYMBOL(flush_work_sync); > but > it still does not work. > Have you installed all modules using make install? I copied only the mISDN_l1loop.ko to the kernel module directory, because all other modules are already included in your kernel. You could try to restore your old kernel modules and copy only the one missing module by hand. Might somebody be able to test that issue and correct the patch? I'm not that familar with mISDN and kernel modules. Just tried to make it work quickly, and l1loop works fine so far. -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at manateeshome.com Sun Jul 31 17:24:15 2011 From: admin at manateeshome.com (Seungju Kim) Date: Mon, 1 Aug 2011 02:24:15 +0900 Subject: Current OpenBSC + LCR using MNCC socket In-Reply-To: References: <4E2D445E.5030709@informatik.uni-freiburg.de> <4E2EB3A8.1020209@informatik.uni-freiburg.de> <4E2EC349.5090608@informatik.uni-freiburg.de> <4E2FE148.5000700@informatik.uni-freiburg.de> <004201cc4edc$9e425260$dac6f720$@manateeshome.com> <20110730183735.GO6210@prithivi.gnumonks.org> <004f01cc4eeb$e6342580$b29c7080$@manateeshome.com> Message-ID: <000001cc4fa6$ad7f5370$087dfa50$@manateeshome.com> Hmm I just did the same as you did and it works! Do not overwrite mISDN_core.ko From: openbsc-bounces at lists.osmocom.org [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Lennart Muller Sent: Sunday, July 31, 2011 4:21 AM To: openbsc at lists.osmocom.org Subject: Re: Current OpenBSC + LCR using MNCC socket 2011/7/30 Seungju Kim Yes, I checked dmesg but all it says is "Unknown symbol flush_work_sync" there was nothing else. I DID patch the code, and I tried adding EXPORT_SYMBOL(flush_work_sync); but it still does not work. Have you installed all modules using make install? I copied only the mISDN_l1loop.ko to the kernel module directory, because all other modules are already included in your kernel. You could try to restore your old kernel modules and copy only the one missing module by hand. Might somebody be able to test that issue and correct the patch? I'm not that familar with mISDN and kernel modules. Just tried to make it work quickly, and l1loop works fine so far. -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjastles at gmail.com Sat Jul 23 17:15:49 2011 From: bjastles at gmail.com (Barnaby Astles) Date: Sat, 23 Jul 2011 13:15:49 -0400 Subject: Radios Message-ID: Has any one looked at airspan radios ? Specifically this one: http://www.airspan.com/products/airharmony/ Barnaby J Astles -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at manateeshome.com Sun Jul 24 00:58:29 2011 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 24 Jul 2011 09:58:29 +0900 Subject: Radios In-Reply-To: References: Message-ID: Yes, it is simply a nanoBTS + LTE transceiver On Jul 24, 2011, at 2:15 AM, Barnaby Astles wrote: > Has any one looked at airspan radios ? > > Specifically this one: > > http://www.airspan.com/products/airharmony/ > > Barnaby J Astles > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jul 24 06:52:36 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 24 Jul 2011 08:52:36 +0200 Subject: Radios In-Reply-To: References: Message-ID: <20110724065236.GA8595@prithivi.gnumonks.org> Hi Barnaby, On Sat, Jul 23, 2011 at 01:15:49PM -0400, Barnaby Astles wrote: > Has any one looked at airspan radios ? I am not aware of anyone in our community having had access to those devices. > http://www.airspan.com/products/airharmony/ it's hard to judge how easily they would integrate with OpenBSC based on the marketing speech says ;) I would guess that it should be fairly simple to integrate the GSM part, if it reuses the Abis related components from ip.access. However, they could just use some completely different parts of the ip.access software stack, and have something custom over the back-haul link. If you have an interest in OpenBSC interoperability with those units, I'm sure we could find a way to make it happen. My guess is that they would be pretty expensive, as the nanoBTS alone (without any LTE) is already horribly expensive. 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 admin at manateeshome.com Sun Jul 24 08:13:58 2011 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 24 Jul 2011 17:13:58 +0900 Subject: Radios In-Reply-To: <20110724065236.GA8595@prithivi.gnumonks.org> References: <20110724065236.GA8595@prithivi.gnumonks.org> Message-ID: <155D0D4D-F1F4-4BB9-AE65-FF6D98DCE467@manateeshome.com> Sent from my iPhone On Jul 24, 2011, at 3:52 PM, Harald Welte wrote: > Hi Barnaby, > > On Sat, Jul 23, 2011 at 01:15:49PM -0400, Barnaby Astles wrote: >> Has any one looked at airspan radios ? > > I am not aware of anyone in our community having had access to those > devices. > >> http://www.airspan.com/products/airharmony/ > > it's hard to judge how easily they would integrate with OpenBSC based on > the marketing speech says ;) > > I would guess that it should be fairly simple to integrate the GSM part, > if it reuses the Abis related components from ip.access. > I suppose it is just a nanoBTS + LTE transceiver station contained in one cabinet. Probably the nanoBTS is equipped with an external amplifier, from the brochure, they have greater max/min output power, but other specifications are the same. > However, they could just use some completely different parts of the > ip.access software stack, and have something custom over the back-haul > link. > > If you have an interest in OpenBSC interoperability with those units, > I'm sure we could find a way to make it happen. My guess is that > they would be pretty expensive, as the nanoBTS alone (without any LTE) > is already horribly expensive. > > 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 -------------- An HTML attachment was scrubbed... URL: From admin at manateeshome.com Sun Jul 24 08:13:58 2011 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 24 Jul 2011 17:13:58 +0900 Subject: Radios In-Reply-To: <20110724065236.GA8595@prithivi.gnumonks.org> References: <20110724065236.GA8595@prithivi.gnumonks.org> Message-ID: <155D0D4D-F1F4-4BB9-AE65-FF6D98DCE467@manateeshome.com> Sent from my iPhone On Jul 24, 2011, at 3:52 PM, Harald Welte wrote: > Hi Barnaby, > > On Sat, Jul 23, 2011 at 01:15:49PM -0400, Barnaby Astles wrote: >> Has any one looked at airspan radios ? > > I am not aware of anyone in our community having had access to those > devices. > >> http://www.airspan.com/products/airharmony/ > > it's hard to judge how easily they would integrate with OpenBSC based on > the marketing speech says ;) > > I would guess that it should be fairly simple to integrate the GSM part, > if it reuses the Abis related components from ip.access. > I suppose it is just a nanoBTS + LTE transceiver station contained in one cabinet. Probably the nanoBTS is equipped with an external amplifier, from the brochure, they have greater max/min output power, but other specifications are the same. > However, they could just use some completely different parts of the > ip.access software stack, and have something custom over the back-haul > link. > > If you have an interest in OpenBSC interoperability with those units, > I'm sure we could find a way to make it happen. My guess is that > they would be pretty expensive, as the nanoBTS alone (without any LTE) > is already horribly expensive. > > 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 -------------- An HTML attachment was scrubbed... URL: From bjastles at gmail.com Sun Jul 24 15:17:25 2011 From: bjastles at gmail.com (Barnaby Astles) Date: Sun, 24 Jul 2011 11:17:25 -0400 Subject: Fwd: Radios In-Reply-To: References: <20110724065236.GA8595@prithivi.gnumonks.org> Message-ID: Forgot the list >.< Barnaby J Astles ---------- Forwarded message ---------- From: Barnaby Astles Date: Sun, Jul 24, 2011 at 11:16 Subject: Re: Radios To: Harald Welte Yes Think you are right ... I am just horrified at the cost of the ip.access. I would like to get in to the project but the cost of entry is just so enormous. All I can do is research and hope to land on some sort of deal. Then I would try to get a low powered temp licence and the make the case for a low powered non-interference license to Industry Canada to deploy low cost building/campus zones. I am kind of sick to see all the spectrum get eaten up by the large corps and leave nothing for small companies. Barnaby J Astles On Sun, Jul 24, 2011 at 02:52, Harald Welte wrote: > Hi Barnaby, > > On Sat, Jul 23, 2011 at 01:15:49PM -0400, Barnaby Astles wrote: > > Has any one looked at airspan radios ? > > I am not aware of anyone in our community having had access to those > devices. > > > http://www.airspan.com/products/airharmony/ > > it's hard to judge how easily they would integrate with OpenBSC based on > the marketing speech says ;) > > I would guess that it should be fairly simple to integrate the GSM part, > if it reuses the Abis related components from ip.access. > > However, they could just use some completely different parts of the > ip.access software stack, and have something custom over the back-haul > link. > > If you have an interest in OpenBSC interoperability with those units, > I'm sure we could find a way to make it happen. My guess is that > they would be pretty expensive, as the nanoBTS alone (without any LTE) > is already horribly expensive. > > 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 -------------- An HTML attachment was scrubbed... URL: From mueller.lennart at googlemail.com Wed Jul 27 02:25:19 2011 From: mueller.lennart at googlemail.com (Lennart =?iso-8859-1?q?M=FCller?=) Date: Wed, 27 Jul 2011 04:25:19 +0200 Subject: nanoBTS + external Antennas + Repeater Message-ID: <201107270425.19493.mueller.lennart@googlemail.com> Good morning, I would like to use two directional antennas with a nanoBTS DCS1800. As far as I know, first I need a duplexer to use one antenna both for RX and TX - does anybody know a cheap model? I found only one for 500 Euros. Second, to connect two antennas to the duplexer, I need a power splitter. Can somebody suggest one for duplex usage? Third, to improve indoor signal level, there are plenty offers of duplex repeaters, but the legal situation is unclear because one might produce distortion on ARFCNs different from his own. Again, anyone with experience? Maybe a suggestion for a model with a fixed ARFCN setting? Thanks, Lennart From meierk at informatik.uni-freiburg.de Wed Jul 27 07:53:37 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Wed, 27 Jul 2011 09:53:37 +0200 Subject: nanoBTS + external Antennas + Repeater In-Reply-To: <201107270425.19493.mueller.lennart@googlemail.com> References: <201107270425.19493.mueller.lennart@googlemail.com> Message-ID: <4E2FC401.2030207@informatik.uni-freiburg.de> Hi Lennart, On 27.07.2011 04:25, Lennart M?ller wrote: > Good morning, > > I would like to use two directional antennas with a nanoBTS DCS1800. > As far as I know, first I need a duplexer to use one antenna both for RX and TX > - does anybody know a cheap model? I found only one for 500 Euros. The nanoBTS-Booster from Proximus has an integrated duplexer + HPA and LNA. I have two of them and they work great. http://proximus.com.ua/Nano_BTS_high_power_GSM_booster.html But in the past a loot of people tried to contact Proximus without success. The price for one Booster is about 1300 Euro. > Second, to connect two antennas to the duplexer, I need a power splitter. > Can somebody suggest one for duplex usage? > > Third, to improve indoor signal level, there are plenty offers of duplex > repeaters, but the legal situation is unclear because one might produce > distortion on ARFCNs different from his own. Again, anyone with experience? > Maybe a suggestion for a model with a fixed ARFCN setting? Some days ago I looked at the legal situation of broadband GSM repeaters in Germany. At least in Germany there is no way to operate such a device if you are not an operator. If you find an repeater that operates only on a specific ARFCN and you have a license for that frequency than it may be legal to operate such a device. Best Regards Konrad From holger at freyther.de Fri Jul 29 20:57:58 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 29 Jul 2011 22:57:58 +0200 Subject: Camp preparation and pySim Message-ID: <4E331ED6.1090002@freyther.de> Hi Sylvain, do we need such a hack on top of the 27c3 branch for the upcoming camp? I will try to create a proper patch before the start of the camp. holger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sim_card.hack URL: