OpenBSC

openbsc@lists.osmocom.org

14 participants
4198 discussions

Patch to USSD branch - eliminates static variables
by Mike Haben 22 Oct '09

22 Oct '09

Hi Harald, thanks for the review comments. Patch (attached) for the USSD branch addresses the first issue you highlighted - static variables have been eliminated. Best regards, Mike H.

2 1

[PATCH] USSD code - eliminate static variables, as per Harald's review Signed-off-by: Mike Haben <michael.haben@btinternet.com>
by Mike Haben 21 Oct '09

21 Oct '09

--- openbsc/include/openbsc/gsm_04_80.h | 15 +++++- openbsc/src/gsm_04_80.c | 90 ++++++++++++++++++----------------- openbsc/src/ussd.c | 19 ++++---- 3 files changed, 68 insertions(+), 56 deletions(-) diff --git a/openbsc/include/openbsc/gsm_04_80.h b/openbsc/include/openbsc/gsm_04_80.h index 11962d8..9bdf2c2 100644 --- a/openbsc/include/openbsc/gsm_04_80.h +++ b/openbsc/include/openbsc/gsm_04_80.h @@ -125,8 +125,17 @@ #include <openbsc/msgb.h> -char* gsm0480_rcv_ussd(struct msgb *msg); -int gsm0480_send_ussd_response(struct msgb *msg, const char* response_text); -int gsm0480_send_ussd_reject(struct msgb *msg); +struct ussd_request { + char text[32]; + u_int8_t transaction_id; + u_int8_t invoke_id; +}; + +int gsm0480_decode_ussd_request(struct msgb *msg, + struct ussd_request *request); +int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, + const struct ussd_request *req); +int gsm0480_send_ussd_reject(struct msgb *msg, + const struct ussd_request *request); #endif diff --git a/openbsc/src/gsm_04_80.c b/openbsc/src/gsm_04_80.c index 052b0a7..5d85c82 100644 --- a/openbsc/src/gsm_04_80.c +++ b/openbsc/src/gsm_04_80.c @@ -37,16 +37,16 @@ #include <openbsc/gsm_04_08.h> #include <openbsc/gsm_04_80.h> -static char ussd_string_buff[32]; -static u_int8_t last_transaction_id; -static u_int8_t last_invoke_id; - /* Forward declarations */ -static int parse_ussd(u_int8_t *ussd); -static int parse_ussd_information_elements(u_int8_t *ussd_ie); -static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length); -static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length); -static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length); +static int parse_ussd(u_int8_t *ussd, struct ussd_request *req); +static int parse_ussd_info_elements(u_int8_t *ussd_ie, + struct ussd_request *req); +static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length, + struct ussd_request *req); +static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length, + struct ussd_request *req); +static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length, + struct ussd_request *req); static inline unsigned char *msgb_wrap_with_TL(struct msgb *msgb, u_int8_t tag) { @@ -69,26 +69,24 @@ static inline unsigned char *msgb_push_TLV1(struct msgb *msgb, u_int8_t tag, } -/* Receive a mobile-originated USSD message and return the decoded text */ -char *gsm0480_rcv_ussd(struct msgb *msg) +/* Decode a mobile-originated USSD-request message */ +int gsm0480_decode_ussd_request(struct msgb *msg, struct ussd_request *req) { int rc = 0; u_int8_t *parse_ptr = msgb_l3(msg); - memset(ussd_string_buff, 0, sizeof(ussd_string_buff)); - if ((*parse_ptr & 0x0F) == GSM48_PDISC_NC_SS) { - last_transaction_id = *parse_ptr & 0x70; - rc = parse_ussd(parse_ptr + 1); + req->transaction_id = *parse_ptr & 0x70; + rc = parse_ussd(parse_ptr+1, req); } if (!rc) DEBUGP(DMM, "Error occurred while parsing received USSD!\n"); - return ussd_string_buff; + return rc; } -static int parse_ussd(u_int8_t *ussd) +static int parse_ussd(u_int8_t *ussd, struct ussd_request *req) { int rc = 1; u_int8_t msg_type = ussd[0] & 0xBF; /* message-type - section 3.4 */ @@ -97,11 +95,11 @@ static int parse_ussd(u_int8_t *ussd) case GSM0480_MTYPE_RELEASE_COMPLETE: DEBUGP(DMM, "USS Release Complete\n"); /* could also parse out the optional Cause/Facility data */ - ussd_string_buff[0] = 0xFF; + req->text[0] = 0xFF; break; case GSM0480_MTYPE_REGISTER: case GSM0480_MTYPE_FACILITY: - rc &= parse_ussd_information_elements(ussd+1); + rc &= parse_ussd_info_elements(ussd+1, req); break; default: fprintf(stderr, "Unknown GSM 04.80 message-type field 0x%02x\n", @@ -113,7 +111,7 @@ static int parse_ussd(u_int8_t *ussd) return rc; } -static int parse_ussd_information_elements(u_int8_t *ussd_ie) +static int parse_ussd_info_elements(u_int8_t *ussd_ie, struct ussd_request *req) { int rc; /* Information Element Identifier - table 3.2 & GSM 04.08 section 10.5 */ @@ -124,7 +122,7 @@ static int parse_ussd_information_elements(u_int8_t *ussd_ie) case GSM48_IE_CAUSE: break; case GSM0480_IE_FACILITY: - rc = parse_facility_ie(ussd_ie+2, iei_length); + rc = parse_facility_ie(ussd_ie+2, iei_length, req); break; case GSM0480_IE_SS_VERSION: break; @@ -138,7 +136,8 @@ static int parse_ussd_information_elements(u_int8_t *ussd_ie) return rc; } -static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) +static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length, + struct ussd_request *req) { int rc = 1; u_int8_t offset = 0; @@ -150,7 +149,9 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) switch (component_type) { case GSM0480_CTYPE_INVOKE: - rc &= parse_ss_invoke(facility_ie+2, component_length); + rc &= parse_ss_invoke(facility_ie+2, + component_length, + req); break; case GSM0480_CTYPE_RETURN_RESULT: break; @@ -171,7 +172,8 @@ static int parse_facility_ie(u_int8_t *facility_ie, u_int8_t length) } /* Parse an Invoke component - see table 3.3 */ -static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) +static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length, + struct ussd_request *req) { int rc = 1; u_int8_t offset; @@ -183,7 +185,7 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) } offset = invoke_data[1] + 2; - last_invoke_id = invoke_data[2]; + req->invoke_id = invoke_data[2]; /* optional part */ if (invoke_data[offset] == GSM0480_COMPIDTAG_LINKED_ID) @@ -195,7 +197,8 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) switch (operation_code) { case GSM0480_OP_CODE_PROCESS_USS_REQ: rc = parse_process_uss_req(invoke_data + offset + 3, - length - offset - 3); + length - offset - 3, + req); break; default: fprintf(stderr, "GSM 04.80 operation code 0x%02x " @@ -214,36 +217,33 @@ static int parse_ss_invoke(u_int8_t *invoke_data, u_int8_t length) } /* Parse the parameters of a Process UnstructuredSS Request */ -static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length) +static int parse_process_uss_req(u_int8_t *uss_req_data, u_int8_t length, + struct ussd_request *req) { - int rc = 1; + int rc = 0; int num_chars; u_int8_t dcs; - /* FIXME: most phones send USSD text as a 7-bit encoded octet string; - * the following code also handles the case of plain ASCII text - * (IA5String), but other encodings might be used */ - if (uss_req_data[0] == GSM_0480_SEQUENCE_TAG) { if (uss_req_data[2] == ASN1_OCTET_STRING_TAG) { dcs = uss_req_data[4]; if ((dcs == 0x0F) && (uss_req_data[5] == ASN1_OCTET_STRING_TAG)) { num_chars = (uss_req_data[6] * 8) / 7; - gsm_7bit_decode(ussd_string_buff, + gsm_7bit_decode(req->text, &(uss_req_data[7]), num_chars); + /* append null-terminator */ + req->text[num_chars+1] = 0; + rc = 1; } } - } else if (uss_req_data[0] == ASN1_IA5_STRING_TAG) { - num_chars = uss_req_data[1]; - memcpy(ussd_string_buff, &(uss_req_data[2]), num_chars); - } - + } return rc; } /* Send response to a mobile-originated ProcessUnstructuredSS-Request */ -int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) +int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text, + const struct ussd_request *req) { struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; @@ -278,7 +278,7 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); /* Pre-pend the invoke ID */ - msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, last_invoke_id); + msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, req->invoke_id); /* Wrap this up as a Return Result component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); @@ -288,13 +288,15 @@ int gsm0480_send_ussd_response(struct msgb *in_msg, const char* response_text) /* And finally pre-pend the L3 header */ gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh)); - gh->proto_discr = GSM48_PDISC_NC_SS | last_transaction_id | (1<<7); /* TI direction = 1 */ + gh->proto_discr = GSM48_PDISC_NC_SS | req->transaction_id + | (1<<7); /* TI direction = 1 */ gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; return gsm48_sendmsg(msg, NULL); } -int gsm0480_send_ussd_reject(struct msgb *in_msg) +int gsm0480_send_ussd_reject(struct msgb *in_msg, + const struct ussd_request *req) { struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; @@ -307,7 +309,7 @@ int gsm0480_send_ussd_reject(struct msgb *in_msg) GSM_0480_GEN_PROB_CODE_UNRECOGNISED); /* Before it insert the invoke ID */ - msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, last_invoke_id); + msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, req->invoke_id); /* Wrap this up as a Reject component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_REJECT); @@ -318,7 +320,7 @@ int gsm0480_send_ussd_reject(struct msgb *in_msg) /* And finally pre-pend the L3 header */ gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh)); gh->proto_discr = GSM48_PDISC_NC_SS; - gh->proto_discr |= last_transaction_id | (1<<7); /* TI direction = 1 */ + gh->proto_discr |= req->transaction_id | (1<<7); /* TI direction = 1 */ gh->msg_type = GSM0480_MTYPE_RELEASE_COMPLETE; return gsm48_sendmsg(msg, NULL); diff --git a/openbsc/src/ussd.c b/openbsc/src/ussd.c index 9dc2205..e414b1c 100644 --- a/openbsc/src/ussd.c +++ b/openbsc/src/ussd.c @@ -38,33 +38,34 @@ const char USSD_TEXT_OWN_NUMBER[] = "*#100#"; /* Forward declarations of network-specific handler functions */ -static int send_own_number(struct msgb *msg); +static int send_own_number(const struct msgb *msg, const struct ussd_request *req); /* Entrypoint - handler function common to all mobile-originated USSDs */ int handle_rcv_ussd(struct msgb *msg) { - char *ussd_text_rcvd = gsm0480_rcv_ussd(msg); + struct ussd_request req; - if (ussd_text_rcvd[0] == 0xFF) /* Release-Complete */ + gsm0480_decode_ussd_request(msg, &req); + if (req.text[0] == 0xFF) /* Release-Complete */ return 0; - if (strstr(USSD_TEXT_OWN_NUMBER, ussd_text_rcvd) != NULL) { + if (strstr(USSD_TEXT_OWN_NUMBER, req.text) != NULL) { DEBUGP(DMM, "USSD: Own number requested\n"); - return send_own_number(msg); + return send_own_number(msg, &req); } else { - DEBUGP(DMM, "Unhandled USSD %s\n", ussd_text_rcvd); - return gsm0480_send_ussd_reject(msg); + DEBUGP(DMM, "Unhandled USSD %s\n", req.text); + return gsm0480_send_ussd_reject(msg, &req); } } /* A network-specific handler function */ -static int send_own_number(struct msgb *msg) +static int send_own_number(const struct msgb *msg, const struct ussd_request *req) { char *own_number = msg->lchan->subscr->extension; /* Need trailing CR as EOT character */ char response_string[] = "Your extension is xxxxx\r"; memcpy(response_string + 18, own_number, 5); - return gsm0480_send_ussd_response(msg, response_string); + return gsm0480_send_ussd_response(msg, response_string, req); } -- 1.6.0.4 --------------080700070202040005090208--

1 0

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

21 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 19 Oct '09

19 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 15 Oct '09

15 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 14 Oct '09

14 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 13 Oct '09

13 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 13 Oct '09

13 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC