OpenBSC

openbsc@lists.osmocom.org

8 participants
4276 discussions

Progress on the GPRS side
by Harald Welte 22 Oct '09

22 Oct '09

Hi all! With the current code in the 'gprs' branch, I am able to get the NS (08.16) and BSSGP (08.18) layers up and running with the nanoBTS. The NS RESET and TEST procedures are running fine, as well as the BSSGP RESET and BLOCK procedures. I now need to work on patching the system information to indicate GPRS support and add a SI13 message. Hopefully at that point, it is possible to receive LLC frames that are being sent by the MS. Ignoring Mobility Management for now and considering only single-BTS operation of GPRS, the biggest remaining items are: * understand LLC better and implement it * implement SNDCP * how to interface the actual network (using pty's with pppd on top) * make things more dynamic rather than static at compile time Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

progress: nanoBTS multi-TRX configuration
by Harald Welte 20 Oct '09

20 Oct '09

Hi all, JFYI: There's some progress on the nanoBTS multi-TRX configuration. It seems it was my mistake. Setting the TRX0 unit ID to 1801/0/0 and the TRX1 unit ID to 1801/0/1 works using ipaccess-config. If you then connect the TIB cable (TRX0 TIB out -> TRX1 TIB in) and reboot both nanoBTS, you will get a single A-bis OML connection from 1801/0/0 where you get software activate requests for both transceivers. Somehow we're not handling them correctly yet from our abis_nm code, but that should be easy to solve. I'm working at it. So Dieter and others: No need to worry about this at the moment, we're very close now and I think it is no problem for the 26C3. Regards, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

Re: Mobile-originated USSD - double D'oh!
by Harald Welte 16 Oct '09

16 Oct '09

Hi Mike! Some comments: * it would have been good to Cc the mailinglist when you re-posted the patch, this way more eyes are on the code * I've looked at it but unfortunately there's a number of issues. That's why I've committed it to a new 'ussd' branch in git. * I've pushed an incremental patch as commit that cleans up the coding style issues that I had seen with the code There are also issues with the actual code that I'd like to see addressed, preferrably by incremental patches to my ussd branch: * the use of static global variables like ussd_string_buf in gsm_04_80.c Code like this will prove very difficult to ever use concurrently at some later point. global variables in the main program (or similar) are fine, but in actual 'library' style code, we should not keep code in static global variables across multiple calls. In such a case, the state needs to be associated with some of the data structures we have in memory anyway. ussd_string_buff looks like something the caller should allocate and pass into gsm0480_rcv_ussd(). Also, since rcv_ussd() only decodes, it should probably be called gsm0480_decode_ussd(). Things like the static last_transaction_id also will cause race conditions once multiple people send USSD requests at the same time. This data needs to be per subscriber, or per lchan, I presume. * the assumption that extension numbers are not longer than 5 characters in ussd.c is really not good. Please check the specs what is the maximum length of the phone number in this context, add a #define and then make sure the string buffer is large enough for it. Also, I prefer snprintf() to having XXXX that then get overwritten by memcopy :) If you could send patches for those two issues (one patch for each logical change), I would appreciate that and in the end merge the ussd branch into master. Thanks. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

FOSDEM: Who's coming ?
by Sylvain Munaut 16 Oct '09

16 Oct '09

Hi everyone, As I mentionned in the earlier post, I think it'd be great if we could use FOSDEM to get known more. These projects covers a wide area, from quite low level RF stuff, signal processing to higher level GSM protocols ...so the work is certainly not missing :) So what I'd like to know is who's planning on coming (yes/no/maybe) to FOSDEM and if you'd be ready to help out or have equipment you could bring. Exactly _what_ we could do will most likely depend on the number of answer to this mail :) I've included OpenBTS, OpenBSC and airprobe here because they're the three projects I know that deal with the 'network' part of GSM (as opposed to the MS side for things like OpenMoko, Android, ...). And even if they currently don't share that much code, the GSM knowledge you gain by contributing to one of these can be directly applicable to help out in the others. Cheers ! Sylvain

1 0

Mobile-originated USSD - corrected, now works 100%
by Mike Haben 15 Oct '09

15 Oct '09

(Hopefully) last patch attached - now sends the correct op-code in response, works with all 6 phones I have tried. Interesting that 5 out of 6 were happy with a completely different op-code and payload... Mike H.

2 2

Re: [Openbts-discuss] [Fwd: [FOSDEM] News : Call For Participation]
by Sylvain Munaut 14 Oct '09

14 Oct '09

For info: Ok, I called the IBPT and I got the procedure to follow to request frequencies. The 900 MHz is entirely allocated to commercial operators but in the 1800 spectrum there are possibilities to get experimental licenses for a small fee so I'm filling up the paper work ASAP. For OpenBTS to work in the 1800 band we may need more stable clock source (which I don't have yet). For OpenBSC, I have a 1800 nanoBTS. Sylvain On Mon, Oct 12, 2009 at 8:38 PM, Sylvain Munaut <246tnt(a)gmail.com> wrote: > On Mon, Oct 12, 2009 at 7:20 PM, Michel Daggelinckx <03taxi(a)gmail.com> wrote: >> >> >> FOSDEM [1], the most developer-oriented Free and Opensource conference in >> Europe, is taking place in Brussels, Belgium [2] on *Saturday 6 and Sunday 7 >> February 2010*. Apart from having many invited speakers, the conference >> offers developer rooms, stands and lightning talks to projects from the Free >> and Opensource community. This results in a staggering number of 250+ >> lectures! >> >> We hereby welcome proposals from speakers and projects to talk in a main >> track, man a stand, or hold a lightning talk. /Information on developer >> rooms >> will become available later, as we are slightly reworking the concept/. > > In relation to that, I'm trying to get an experimental license from the IBPT to > operate on the GSM spectrum during the conference. I didn't find much in the > legislation about this kind of licence in Belgium, but I must call > back the guy tomorrow ... > > I didn't take any contact with the fosdem yet to have a spot or > anything, I wanted to > hear back from the ibpt first. > > If other people are motivated, there is definitely something to do there. > I have equipment to run both OpenBTS and OpenBSC and I'm located in Belgium, > so I'll definitely be there. > > > Sylvain >

3 2

[PATCH] Corrected response to mobile-originated USSD ProcessUnstructuredSS Request - return same op code Signed-off-by: Mike Haben <michael.haben@btinternet.com>
by Mike Haben 14 Oct '09

14 Oct '09

--- openbsc/src/gsm_04_80.c | 31 +++++++++++++++++++------------ openbsc/src/ussd.c | 4 ++-- 2 files changed, 21 insertions(+), 14 deletions(-) diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c index d922ae5..d0dcbc2 100755 --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -90,11 +90,11 @@ char* gsm0480_rcv_ussd(struct msgb *msg) static int parse_ussd(u_int8_t *ussd) { int rc = 1; - u_int8_t msg_type = ussd[0] & 0xBF; // message-type - section 3.4 + u_int8_t msg_type = ussd[0] & 0xBF; /* message-type - section 3.4 */ switch(msg_type) { case GSM0480_MTYPE_RELEASE_COMPLETE: - DEBUGP(DMM, "USS Release Complete\n"); // could also parse out the optional Cause/Facility data + DEBUGP(DMM, "USS Release Complete\n"); /* could also parse out the optional Cause/Facility data */ ussd_string_buff[0] = 0xFF; break; case GSM0480_MTYPE_REGISTER: @@ -115,7 +115,7 @@ static int parse_ussd_information_elements(u_int8_t *ussd_ie) { int rc; - u_int8_t iei = ussd_ie[0]; // Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 + u_int8_t iei = ussd_ie[0]; /* Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 */ u_int8_t iei_length = ussd_ie[1]; switch(iei) { case GSM48_IE_CAUSE: @@ -141,7 +141,7 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) u_int8_t offset = 0; do { - u_int8_t component_type = facility_ie[offset]; // Component Type tag - table 3.7 + u_int8_t component_type = facility_ie[offset]; /* Component Type tag - table 3.7 */ u_int8_t component_length = facility_ie[offset+1]; switch(component_type) { case GSM0480_CTYPE_INVOKE: @@ -178,7 +178,7 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) last_invoke_id = invoke_data[2]; if (invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) /* optional part */ - offset += invoke_data[offset+1] + 2; // skip over it + offset += invoke_data[offset+1] + 2; /* skip over it */ if (invoke_data[offset] == GSM0480_OPERATION_CODE) { /* mandatory part */ u_int8_t operation_code = invoke_data[offset+2]; @@ -208,13 +208,11 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) int num_chars; u_int8_t dcs; -// DEBUGP(DMM, "USSD request params %s\n", hexdump(uss_req_data, length)); /* FIXME: most phones send USSD text as a 7-bit encoded octet string; the following code also handles the case of plain ASCII text (IA5String), but other encodings might be used */ if (uss_req_data[0] == GSM_0480_SEQUENCE_TAG) { if (uss_req_data[2] == ASN1_OCTET_STRING_TAG) { dcs = uss_req_data[4]; -// DEBUGP(DMM, "Data coding scheme = 0x%2.2X\n", dcs); if ((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) { num_chars = (uss_req_data[6] * 8) / 7; gsm_7bit_decode(ussd_string_buff, &(uss_req_data[7]), num_chars); @@ -228,6 +226,7 @@ static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) return rc; } +/* Send response to a mobile-originated ProcessUnstructuredSS-Request */ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) { struct msgb *msg = gsm48_msgb_alloc(); @@ -235,20 +234,28 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) u_int8_t *ptr8; int response_len; - response_len = strlen(response_text); + response_len = (strlen(response_text) * 7) / 8; + if (((strlen(response_text) * 7) % 8) != 0) + response_len += 1; msg->bts_link = in_msg->bts_link; msg->lchan = in_msg->lchan; /* First put the payload text into the message */ ptr8 = msgb_put(msg, response_len); - memcpy(ptr8, response_text, response_len); + gsm_7bit_encode(ptr8, response_text); - /* Then wrap it as an IA5 String */ - msgb_wrap_with_TL(msg, ASN1_IA5_STRING_TAG); + /* Then wrap it as an Octet String */ + msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG); + + /* Pre-pend the DCS octet string */ + msgb_push_TLV1(msg, ASN1_OCTET_STRING_TAG, 0x0F); + + /* Then wrap these as a Sequence */ + msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); /* Pre-pend the operation code */ - msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_DATA); + msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ); /* Wrap the operation code and IA5 string as a sequence */ msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c index ba2f045..5f9a457 100755 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -45,7 +45,7 @@ int handle_rcv_ussd(struct msgb *msg) { char* ussd_text_rcvd = gsm0480_rcv_ussd(msg); - if(ussd_text_rcvd[0] == 0xFF) // Release-Complete + if(ussd_text_rcvd[0] == 0xFF) /* Release-Complete */ return 0; if(strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) { @@ -60,7 +60,7 @@ int handle_rcv_ussd(struct msgb *msg) /* A network-specific handler function */ static int send_own_number(struct msgb *msg) { - char response_string[] = "Your extension is xxxxx"; + char response_string[] = "Your extension is xxxxx\r"; /* Need trailing CR as EOT character */ char* own_number = msg->lchan->subscr->extension; memcpy(response_string + 18, own_number, 5); -- 1.6.0.4 --------------050801040303060009020404--

1 0

[ANNOUNCE] Report on OpenBSC powered GSM network at HAR2009
by Harald Welte 13 Oct '09

13 Oct '09

Hi! I finally finished the report from the GSM test network that we operated at HAR2009 using OpenBSC and two BS-11. The report is available for download from http://openbsc.gnumonks.org/trac/attachment/wiki/HAR2009/har2009-gsm-report… Regards, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

AW: Running an licensed experimental GSM network at 26c3
by Andreas.Eversberg 13 Oct '09

13 Oct '09

>I believe in the positive impact of OpenBTS and OpenBSC interoperability for >the both communities and as encouraging factor for possible future OpenBTS >test sites. > >We're ready to work with you beforehand to minimize on-site efforts. > >PS Where can we find agenda? Official 26C3 site is nearly empty. hi all, on the congress i use linux-call-router to route isdn traffic from versatel to berlin and vice versa for free as part of versatel sponsoring. i would like to join the POC (phone operation center) in the upper hall again this year. there we sit close to the "eventphone" guys, so we can easier communicate and do cabeling of our hardware. it would be nice to have also the openbsc and openbts projects close to us. we could easier interact and build one test networks. since eventphone uses an own linux-call-router hardware, i can use my test machine without disturbing the external isdn connection to versatel. it is equipped with two E1 cards, one for interconnection with eventphone, the second one can be used for BS11. eventphone has a big DECT pbx running and provides mobile access. what do you think? andreas

4 5

Patches - add support for mobile-originated USSD
by Mike Haben 10 Oct '09

10 Oct '09

Hello again, More patches - these two (combined) add support for mobile-originated USSD. The demonstration application, implemented in ussd.c, is that sending *#100# to the network will display your 5-digit extension. It's not 100% finished - I've tested it on 6 handsets, 5 of them work perfectly, but the 6th (Samsung i520) doesn't seem to receive the response, so more experimenting to be done... Best regards to all, Mike H.

3 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC