- baseband-devel - lists.osmocom.org

Re: osmocom-commitlog Digest, Vol 557, Issue 1
by Andreas Eversberg 27 Nov '12

27 Nov '12

osmocom-commitlog-request(a)lists.osmocom.org wrote: > The branch, zecke/work-with-nitb has been created > at 2076448d458ce1271dcd4d584fe276a8b8857e35 (commit) > > - Log ----------------------------------------------------------------- > http://cgit.osmocom.org/cgit/osmocom-bb/commit/?id=2076448d458ce1271dcd4d58… > > commit 2076448d458ce1271dcd4d584fe276a8b8857e35 > Author: Holger Hans Peter Freyther<zecke(a)selfish.org> > Date: Mon Nov 26 17:15:07 2012 +0100 > > mobile: Do the LU with a IMSI... to deal with changing NITBs.. > > NITB will not ask for the IMSI if the TMSI is not known... work around > and do the LU with the IMSI.. hi holger, i saw your patch, but i did not like it. i just breaks the way location updating is done by standard. it is a workaround and not committed to master, but i think this should be an option for a baseband stack that is designed to test an play with. therefore i made a patch to configure this option via vty. it is not tested, but it obviously should work. regards, andreas

2 2

[PATCH] Add option to force location updating with IMSI, event if TMSI is valid
by Andreas Eversberg 27 Nov '12

27 Nov '12

To set this option, enter VTY: enable conf t ms 1 location-updating imsi-only write --- .../layer23/include/osmocom/bb/mobile/settings.h | 1 + src/host/layer23/src/mobile/gsm48_mm.c | 2 +- src/host/layer23/src/mobile/vty_interface.c | 33 ++++++++++++++++++- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/mobile/settings.h b/src/host/layer23/include/osmocom/bb/mobile/settings.h index fae1220..6ff8b12 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/settings.h +++ b/src/host/layer23/include/osmocom/bb/mobile/settings.h @@ -51,6 +51,7 @@ struct gsm_settings { uint16_t stick_arfcn; uint8_t skip_max_per_band; uint8_t no_lupd; + uint8_t lupd_imsi; uint8_t no_neighbour; /* supported by configuration */ diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index 0598768..06f6629 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -2358,7 +2358,7 @@ static int gsm48_mm_tx_loc_upd_req(struct osmocom_ms *ms) gsm48_encode_classmark1(&nlu->classmark1, sup->rev_lev, sup->es_ind, set->a5_1, pwr_lev); /* MI */ - if (0 && subscr->tmsi != 0xffffffff) { /* have TMSI ? */ + if (!set->lupd_imsi && subscr->tmsi != 0xffffffff) { /* have TMSI ? */ gsm48_encode_mi(buf, NULL, ms, GSM_MI_TYPE_TMSI); LOGP(DMM, LOGL_INFO, " using TMSI 0x%08x\n", subscr->tmsi); } else { diff --git a/src/host/layer23/src/mobile/vty_interface.c b/src/host/layer23/src/mobile/vty_interface.c index 4d7f6a2..e6add60 100644 --- a/src/host/layer23/src/mobile/vty_interface.c +++ b/src/host/layer23/src/mobile/vty_interface.c @@ -1334,6 +1334,9 @@ static void config_write_ms(struct vty *vty, struct osmocom_ms *ms) if (!hide_default || set->no_lupd) vty_out(vty, " %slocation-updating%s", (set->no_lupd) ? "no " : "", VTY_NEWLINE); + if (!hide_default || set->lupd_imsi) + vty_out(vty, " %slocation-updating imsi-only%s", + (set->lupd_imsi) ? "" : "no ", VTY_NEWLINE); if (!hide_default || set->no_neighbour) vty_out(vty, " %sneighbour-measurement%s", (set->no_neighbour) ? "no " : "", VTY_NEWLINE); @@ -1893,7 +1896,7 @@ DEFUN(cfg_ms_no_stick, cfg_ms_no_stick_cmd, "no stick", } DEFUN(cfg_ms_lupd, cfg_ms_lupd_cmd, "location-updating", - "Allow location updating") + "Do location updating") { struct osmocom_ms *ms = vty->index; struct gsm_settings *set = &ms->settings; @@ -1904,7 +1907,7 @@ DEFUN(cfg_ms_lupd, cfg_ms_lupd_cmd, "location-updating", } DEFUN(cfg_ms_no_lupd, cfg_ms_no_lupd_cmd, "no location-updating", - NO_STR "Do not allow location updating") + NO_STR "Do not perform location updating") { struct osmocom_ms *ms = vty->index; struct gsm_settings *set = &ms->settings; @@ -1914,6 +1917,30 @@ DEFUN(cfg_ms_no_lupd, cfg_ms_no_lupd_cmd, "no location-updating", return CMD_SUCCESS; } +DEFUN(cfg_ms_lupd_imsi, cfg_ms_lupd_imsi_cmd, "location-updating imsi-only", + "Do location updating\nAlways use IMSI to perform location updating") +{ + struct osmocom_ms *ms = vty->index; + struct gsm_settings *set = &ms->settings; + + set->lupd_imsi = 1; + + return CMD_SUCCESS; +} + +DEFUN(cfg_ms_no__imsilupd, cfg_ms_no_lupd_imsi_cmd, + "no location-updating imsi-only", + NO_STR "Do not perform location updating\n" + "Do not force location updating with IMSI, if TMSI is valid") +{ + struct osmocom_ms *ms = vty->index; + struct gsm_settings *set = &ms->settings; + + set->lupd_imsi = 0; + + return CMD_SUCCESS; +} + DEFUN(cfg_codec_full, cfg_ms_codec_full_cmd, "codec full-speed", "Enable codec\nFull speed speech codec") { @@ -2821,6 +2848,8 @@ int ms_vty_init(void) install_element(MS_NODE, &cfg_ms_no_stick_cmd); install_element(MS_NODE, &cfg_ms_lupd_cmd); install_element(MS_NODE, &cfg_ms_no_lupd_cmd); + install_element(MS_NODE, &cfg_ms_lupd_imsi_cmd); + install_element(MS_NODE, &cfg_ms_no_lupd_imsi_cmd); install_element(MS_NODE, &cfg_ms_codec_full_cmd); install_element(MS_NODE, &cfg_ms_codec_full_pref_cmd); install_element(MS_NODE, &cfg_ms_codec_half_cmd); -- 1.7.3.4 --------------030505010406090507000203--

1 0

Re: baseband-devel Digest, Vol 34, Issue 17
by Christian Inci 27 Nov '12

27 Nov '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd the same problem. Now, my C118 is bricked. :-( I'm now waiting for my Bus Pirate in order to unbrick it. Does anybody knows a fast way to do it? Should I use the test points (maybe those who are accessible from the battery compartment) or even directly to the nor flash? Many thanks in advance! - -Chris On 11/27/2012 12:00 PM, baseband-devel-request(a)lists.osmocom.org wrote: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel or, via > email, send a message with subject or body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of baseband-devel digest..." > > > Today's Topics: > > 1. Unable to flash firmware (Akib Sayyed) 2. Re: Unable to flash > firmware (Alexander Huemer) 3. Re: Unable to flash firmware (Akib > Sayyed) 4. Re: Unable to flash firmware (Akib Sayyed) > > > ---------------------------------------------------------------------- > > Message: 1 Date: Tue, 27 Nov 2012 12:30:30 +0300 From: Akib Sayyed > <akibsayyed(a)gmail.com> To: baseband-devel(a)lists.osmocom.org > Subject: Unable to flash firmware Message-ID: > <CAMG-S93etEd9b_zo-YiwXWdRwBZiXzx=fa8SWjJzZVqxz486Dw(a)mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > Dear all i am unable to flash firmware of C118 with RSSI.bin > > i am using 64bit Ubuntu.and 64bit gnu toolchain > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQtK0BAAoJEDfL/pqB6n6N3dAQAJLpkD+4MVJbzfBHDt6mepN6 OcXyX/EbgZkN7zZY4ulRadlqyMvq7MH7pN9zv1sRk+2oMWRTEOwHeT1xG8Lfoukp J4GMTY21bv6Ov0QLQOisxydRH4TQ7riJGfSbATPA6VBUMQWuxrws140BFDslXaPk 8Vk9o5a2G9kQTbLdJp/tqxjKnlLZ3m22qSgph0O1uV7w4e82tc45rOX8FiAps7f2 cCjGfbphjpb+GVx/OT5mSTaKseYAPyLsm2n1CvTbFYm0OVlJ9d8Pp/iVluQdrPdQ pBLpF/MFPdqw7swUTXTSjL5PFjhBnwz1b0hImdoFBG/uHRGrU8l8sG4ll553DWtw OnPEo1lEDkPdoRY0vpqYWVhrf6t1b54k5cc+ISKVvLweRoscMjkU7DBdzwuSyIQv FVLk9cLatp33ogCqpzinebEBNl6eQpa869c+MC2ii/Y+A82QRiyhSs6JMmYOCYRg jMiw/0lZIZcUEzHfGm75X7LnyfEyPDaG39MWl8m/xU/1aQhZHN4p23sKrqEAaZQp z439nICJoCybsPsPDZiz1XEqcD4lNVVWvba6Ofd+cNKNzSJb3Y8IjUFFPwPyCCw6 dlkgqo52xBnQvb3PzAv+JTUkFesdGqyvcSOMsnFxB8zZGl3pkRn0XPnX+0TsLZdC B701/yHCM9CXYeckOYft =Rsu7 -----END PGP SIGNATURE-----

2 3

Unable to flash firmware
by Akib Sayyed 27 Nov '12

27 Nov '12

Dear all i am unable to flash firmware of C118 with RSSI.bin i am using 64bit Ubuntu.and 64bit gnu toolchain -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 3

Re: Programming SIM card RAND?
by Dieter Spaar 26 Nov '12

26 Nov '12

Hello Andrew, On Mon, 12 Nov 2012 10:25:19 +0000, "Andrew Back" <andrew(a)carrierdetect.com> wrote: > > I'm trying to get some MS test equipment working and have programmed a > SIM with pysim-prog.py, but the tester has a configuration field for > RAND and I cannot see how to set this on the SIM. In fact this has > confused me as I thought the network always supplied this... Most certainly the RAND value of your MS tester is the value which is sent during authentication. All MS testers I have seen so far allow to configure this value, either use random data or set it to a fixed value. > I have the IMSI, Ki, MCC and MNC set the same on the tester and SIM, > but tests don't get very far and fail with "incorrect SRES". I would expect that you need a SIM card which supports XOR for A3/A8. This algorithm is the only one I have seen on nearly all MS tests sets I have access to. Those test sets usually don't support COMP128 and its variants (I guess your SIM card only supports this algorithm), so you need a SIM card which uses the same algorithm as the MS test set. However if you can set a fixed RAND value on the MS test set you can check what your SIM card will return with this RAND and set Kc and SRES on the test set to those values. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 3

Re: Using 900/1800 C118 on 1900
by Akib Sayyed 24 Nov '12

24 Nov '12

i ordered stuff to modify phones. just waiting for them to be delivered On Sat, Nov 24, 2012 at 3:48 PM, Marten Christophe <technosabby(a)gmail.com>wrote: > Hello Akib, > > > Have you able to sniff TCH channel or intercept other phone calls by > OsmocomBB > > Regards, > dev > > On Tue, Nov 20, 2012 at 7:37 AM, Akib Sayyed <akibsayyed(a)gmail.com> wrote: > > phone with filter rework will work right and i also will be able to sniff > > traffic on 1900mhz witnh burst_ind.but my issue is how to tell code of > > app_ccch to sniff 1900 mhz instead of 1800 as they share same arfcn no?? > > > > > > > > On Tue, Nov 20, 2012 at 10:33 AM, Harald Welte <laforge(a)gnumonks.org> > wrote: > >> > >> On Mon, Nov 19, 2012 at 07:24:45AM +0300, Akib Sayyed wrote: > >> > Guys is wanted to know if there is any tweak that can allow me to use > >> > 900/1800 C118 phone on 1900 band. > >> > >> you have to remove the shielding cover and replace the 1800 band filters > >> with footprint-compatible 1900 MHz filters. It's possible, but requires > >> good SMD soldering skills and access to the right parts. > >> > >> You can also remove the filters completely. This will hovever > >> significantly degrade receiver performance in the presence of > >> out-of-band interferers. > >> > >> -- > >> - 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) > > > > > > > > > > -- > > Akib Sayyed > > Matrix-Shell > > akibsayyed(a)gmail.com > > akibsayyed(a)matrixshell.com > > Mob:- +91-966-514-2243 > > > > > -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

1 0

is my decode for efr decode right?
by bob 23 Nov '12

23 Nov '12

Hi, list I write a decode for efr decode for TCH,but there some bug, and I have not a debug device, Can someone help me find the problem, Thanks! static void process_tch_efr(struct osmocom_ms *ms,struct l1ctl_burst_ind *bi) { int16_t rx_dbm; uint16_t arfcn; uint32_t fn,B; uint8_t cbits, tn, lch_idx; int ul, bid, i, k, length; sbit_t *bursts, mC[456]; ubit_t steal_bit[2], bt[114],convu[189],convd[189],tch_raw[260],TCHW[260],EFRBits[244],EFRAMR[8 + 244]; pbit_t voice[33]; /* Get params (Only for SDCCH and SACCH/{4,8,F,H}) */ arfcn = ntohs(bi->band_arfcn); rx_dbm = rxlev2dbm(bi->rx_level); fn = ntohl(bi->frame_nr); ul = !!(arfcn & ARFCN_UPLINK); cbits = bi->chan_nr >> 3; tn = bi->chan_nr & 7; B = -1; if((fn%13)%4 == 0) flag= 1; if(!flag) return; //B = count_tch % 8; B = (fn % 13) % 8; printf("fn % 26 = %d, fn % 13 = %d,B = %d\n",fn%26 ,fn%13 ,B); if (B == -1) return; /* Unpack (ignore hu/hl) */ osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0); //osmo_pbit2ubit_ext(steal_bit, 0 , bi->bits, 114 , 2 , 0); //printf("steal_bit %x , %x\n",steal_bit[0],steal_bit[1]); /* save stealing flags */ hl[B] = !!(bi->bits[14] & 0x10); // hl 57 hu[B] = !!(bi->bits[14] & 0x20); // hu 58 printf("steal_bit %x , %x\n", hl[B],hu[B]); /* Convert to softbits */ for (i=0; i<114; i++) app_state.mI[B][i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); count_tch++; // Deinterleave according to the diagonal "phase" of B. // See GSM 05.03 3.1.3. // Deinterleaves i[] to c[] if((B % 4 ==3)&&(count_tch >= 7)){ if(B == 3) { if(!hl[0] && !hl[1] && !hl[2] && !hl[3] && !hu[4] && !hu[5] && !hu[6] && !hu[7]) { tch_deinterleave(mC, 4); } else if(hl[0] && hl[1] && hl[2] && hl[3] && hu[4] && hu[5] && hu[6] && hu[7]) { printf(" may be FACCH.\n"); return; }else{ printf("not a speech frame.\n"); return; } }else{ if(!hl[4] && !hl[5] && !hl[6] && !hl[7] && !hu[0] && !hu[1] && !hu[2] && !hu[3]) { tch_deinterleave(mC,0); } else if(hl[4] && hl[5] && hl[6] && hl[7] && hu[0] && hu[1] && hu[2] && hu[3]) { printf(" may be FACCH.\n"); return; }else{ printf("not a speech frame.\n"); return; } } //mC is soft bit, and must convert to ubit type for (k = 0; k < 78; k++) { if(mC[378 + k] < 0){ tch_raw[182 + k] = 1; }else{ tch_raw[182 + k] = 0; } } osmo_conv_decode(&conv_tch_afs_12_2, mC, convu); // 3.1.2.1 // copy class 1 bits u[] to d[] for (k = 0; k <= 90; k++) { convd[2*k] = convu[k]; convd[2*k+1] = convu[184-k]; } memcpy(tch_raw,convd,182); // the last 78 bit has been stored! //now only process EFR or AMR 12_2, fix me! tch_unmap(gsm660_bitorder, 260, TCHW, tch_raw); // Remove repeating bits and CRC to get raw EFR frame (244 bits) for (k=0; k<71; k++) EFRBits[k] = TCHW[k]; for (k=73; k<123; k++) EFRBits[k-2] = TCHW[k]; for (k=125; k<178; k++) EFRBits[k-4] = TCHW[k]; for (k=180; k<230; k++) EFRBits[k-6] = TCHW[k]; for (k=232; k<252; k++) EFRBits[k-8] = TCHW[k]; // Map bits as AMR 12.2k tch_map(gsm690_12_2_bitorder, 244, EFRAMR + 8,EFRBits); fillField(EFRAMR, 0, 0x3c, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, 0); fwrite(voice, 1, length, d_speech_file); } } -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-my-decode-for-efr-decode-righ… Sent from the baseband-devel mailing list archive at Nabble.com.

2 1

Re: osmocom-commitlog Digest, Vol 551, Issue 1
by Andreas Eversberg 22 Nov '12

22 Nov '12

osmocom-commitlog-request(a)lists.osmocom.org wrote: > commit 73a809e57b8a531b9b8a33b6841ed3df2ea22620 > Author: Harald Welte<laforge(a)gnumonks.org> > Date: Tue Nov 20 10:13:44 2012 +0100 > > Tell L1CTL_FBSB_REQ the expected received signal level > hi harald, please note that cell_log.c and mobile (gsm322.c) use signed uint8_t for real rx-level (dbm). i think you should use dbm2rxlev() before handing it to l1ctl_tx_fbsb_req(). regards, andreas

3 2

gsm322.c:arfcn2index patch
by Joshua Lackey 20 Nov '12

20 Nov '12

(This is a patch against the latest, as of last night, git master.) If you enable PCS, you'll never make it out of power-measurement without this patch: (This should be applied by everyone.) ---8<--- diff --git a/src/host/layer23/src/mobile/gsm322.c b/src/host/layer23/src/mobile/gsm322.c index ce5e1e1..ffecfc3 100644 --- a/src/host/layer23/src/mobile/gsm322.c +++ b/src/host/layer23/src/mobile/gsm322.c @@ -300,11 +300,14 @@ uint16_t index2arfcn(int index) int arfcn2index(uint16_t arfcn) { - if ((arfcn & ARFCN_PCS) && arfcn >= 512 && arfcn <= 810) + int is_pcs = arfcn & ARFCN_PCS; + arfcn &= ~ARFCN_FLAG_MASK; + if ((is_pcs) && (arfcn >= 512) && (arfcn <= 810)) return (arfcn & 1023)-512+1024; return arfcn & 1023; } + static char *bargraph(int value, int min, int max) { static char bar[128]; ---8<--- If you enable PCS, you'll never receive packets without this patch: (which I only include for e88 and e86 but it should work for others) (This should be applied if you don't use DCS in your area.) ---8<--- diff --git a/src/target/firmware/board/compal/rffe_dualband.c b/src/target/firmware/board/compal/rffe_dualband.c index f4b7361..5df1dfc 100644 --- a/src/target/firmware/board/compal/rffe_dualband.c +++ b/src/target/firmware/board/compal/rffe_dualband.c @@ -47,7 +47,8 @@ void rffe_mode(enum gsm_band band, int tx) /* Returns RF wiring */ uint32_t rffe_get_rx_ports(void) { - return (1 << PORT_LO) | (1 << PORT_DCS1800); + // return (1 << PORT_LO) | (1 << PORT_DCS1800); + return (1 << PORT_LO) | (1 << PORT_PCS1900); } uint32_t rffe_get_tx_ports(void) diff --git a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c index 25bb099..10459d9 100644 --- a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c +++ b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c @@ -51,7 +51,8 @@ void rffe_mode(enum gsm_band band, int tx) /* Returns RF wiring */ uint32_t rffe_get_rx_ports(void) { - return (1 << PORT_LO) | (1 << PORT_DCS1800); + // return (1 << PORT_LO) | (1 << PORT_DCS1800); + return (1 << PORT_LO) | (1 << PORT_PCS1900); } uint32_t rffe_get_tx_ports(void) ---8<---

5 7

Using 900/1800 C118 on 1900
by Akib Sayyed 20 Nov '12

20 Nov '12

Guys is wanted to know if there is any tweak that can allow me to use 900/1800 C118 phone on 1900 band. please let me know. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

3 3