- baseband-devel - lists.osmocom.org

None
by None 03 Jan '22

03 Jan '22

ISM868 bands that are located adjacent to the GSM 850/900 frequency allocations. My initial investigations and enquiries indicate that this should be possible by creative programming of the baseband processor in many models of phones. The trick, as I suspect you well know, is the difficulty in getting the information and tools required to reprogram these radios. I am now in a position to potentially fund further work on this. So, as the open-source group with the most experience reprogramming baseband radios, what is the feasibility of creating a proof-of-concept using the types of phones you already work with to send and receive arbitrary data packets without reliance on a cell tower (even for time synchronisation)? I know there are a lot of constraints and problems, but I am most interested in creative solutions that can get us to a working prototype, however crude, that can be used to demonstrate the feasibility of what I am proposing. If this discussion is off-topic here, I am happy to hold the conversation at the serval-project-developers google group, but I am equally comfortable with it continuing here. Thanks in advance, Paul Gardner-Stephen. Shuttleworth Telecommunications Fellow at Flinders University.

1 0

None
by None 03 Jan '22

03 Jan '22

* it tries to stay as close to POSIX and other Unix APIs as possible * you can actually have executable programs in the file system * it contains a small interactive shell * the changelog is verbose and releases are frequent * there's a test suite * there are already ports to other ARM7TDMI microcontrollers * there is a small UI framework and the notion of drivers for SPI- attached LCDs (with 1/2/4 bpp) * it has tasks and threads, pre-emptive and with priorities * it has posix message queues, which we could use for passing around primitives between elements in the stack * it can be used on Unix-like and Windows/Cygwin host OS * it has its own scripts to generate toolchains, which means we could possibly standardize on one of those toolchains Of course, not everything is perfect * there seems to be no writeable FS we can put in NOR flash * it has no scripting language integration (like lua) yet * i didn't find any memory allocator optimized for pools of objects of the same size (like 'struct msgb' or the like). Something with an API [not implementation!] of the SLAB/SLUB in Linux would probably be a good start. I've done some example compile runs for arm7, including the shell and the graphics support (nx example). I end up with an object code size of something like 70 kilobytes, which is pretty good! So unless anyone raises major objections, I think we should move ahead with Nuttx. Who is interested in working on the calypso port? Let's use this list for coordinating the effort. As for where to put the code: I already have a git-svn clone of Nuttx, and will push that to a soon-to-be-created nuttx.git repository on git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should all go in that tree. Meanwhile we will figure out how it would be possibel to keep the gsm related 'application' code out-of-tree from the nuttx code base. 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

None
by None 03 Jan '22

03 Jan '22

OsmocomBB> show ms MS '1' is up, service is limited (pending) =20 IMEI: 000000000000000 =20 IMEISV: 0000000000000000 =20 IMEI generation: fixed =20 automatic network selection state: A3 trying PLMN cell selection state: C4 normal cell re-selection radio ressource layer state: idle =20 mobility management layer state: MM idle, attempting to update OsmocomBB> show subscriber =20 Mobile Subscriber of MS '1': =20 IMSI: 234------------ =20 ICCID: 894----------- =20 Status: U2_NOT_UPDATED IMSI detached LAI: invalid =20 Registered PLMN: MCC 234 MNC 30 (Guernsey, T-Mobile) =20 Access barred cells: no =20 Access classes: C5 =20 List of preferred PLMNs: =20 MCC |MNC =20 -------+------- =20 214 |07 (Spain, movistar) =20 208 |01 (France, Orange) =20 310 |260 (United States of America, T-Mobile USA) 310 |170 (United States of America, Cingular Wireless) 262 |01 (Germany, T-Mobile) =20 272 |03 (Ireland, Meteor) =20 222 |01 (Italy, TIM) =20 204 |16 (Netherlands, T-Mobile) =20 268 |06 (Portugal, TMN) =20 206 |10 (Belgium, Mobistar) =20 505 |02 (Australia, Optus) =20 228 |03 (Switzerland, Orange) =20 232 |03 (Austria, T-Mobile) =20 520 |01 (Thailand, AIS) =20 230 |01 (Czech Republic, T-Mobile) =20 338 |180 (Jamaica, LIME (formerly known as Cable &=20 Wireless)) 655 |10 (South Africa,=20 MTN) =20 286 |02 (Turkey,=20 Vodafone) =20 602 |02 (Egypt,=20 Vodafone) =20 454 |00 (Hong Kong, 1O1O and=20 One2Free) =20 216 |30 (Hungary, Westel=20 900) =20 250 |01 (Russian Federation,=20 MTS) =20 334 |030 (Mexico,=20 030) =20 425 |02 (Israel,=20 Cellcom) =20 240 |01 (Sweden,=20 Telia) =20 202 |01 (Greece, Cosmote) 639 |02 (Kenya, Safaricom) 260 |02 (Poland, Era) 231 |02 (Slovakia, T-Mobile) 219 |01 (Croatia, T-Mobile) 413 |01 (Sri Lanka, Mobitel) 242 |02 (Norway, NetCom) 238 |30 (Denmark, Telia) 278 |01 (Malta, Vodafone) 604 |01 (Morocco, IAM) 617 |10 (Mauritius, Emtel) 419 |02 (Kuwait, zain KW) 244 |91 (Finland, Sonera) 284 |05 (Bulgaria, GLOBUL) 648 |03 (Zimbabwe, Telecel) 204 |20 (Netherlands, Orange Nederland) 228 |01 (Switzerland, Swisscom) 230 |03 (Czech Republic, Vodafone) 214 |01 (Spain, Vodafone) 202 |05 (Greece, Vodafone) 262 |02 (Germany, Vodafone) 222 |10 (Italy, Vodafone) 268 |01 (Portugal, Vodafone) 208 |10 (France, SFR) 342 |600 (Barbados, Cable & Wireless (Barbados) Ltd.) List of forbidden PLMNs: MCC |MNC |cause -------+-------+------- 234 |33 |#0 (Guernsey, Orange) 234 |15 |#0 (Guernsey, Vodafone) 234 |10 |#0 (Guernsey, O2) 234 |13 |#0 (Guernsey, 13) from the mobile application I get: =1B[0;35m<000e> sim.c:1206 init SIM client =1B[0;m=1B[1;33m<0005> gsm48_cc.c:61 init Call Control =1B[0;m=1B[1;34m<0001> gsm48_rr.c:4944 init Radio Ressource process =1B[0;m=1B[1;32m<0004> gsm48_mm.c:1220 init Mobility Management process =1B[0;m=1B[1;32m<0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because = no SIM. =1B[0;m=1B[32m<0002> gsm322.c:3472 init PLMN process =1B[0;m=1B[34m<0003> gsm322.c:3473 init Cell Selection process =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D10 = Guernsey,=20 O2) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D30 = Guernsey,=20 T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D13 = Guernsey,=20 13) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D15 = Guernsey,=20 Vodafone) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D33 = Guernsey,=20 Orange) =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x2fe2 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:697 go MF =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x3f00) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 1a) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D26) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D26 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x2fe2) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D10) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D10 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:229 received ICCID 8944301471319463636 = from=20 SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f07 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:706 requested path is longer, go child DFgsm =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x7f20) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 1a) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D26) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D26 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f07) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D9) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D9 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:259 received IMSI 234------------- from= SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f7e =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f7e) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D11) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D11 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:295 received LOCI from SIM (mcc=3D234 m= nc=3D30=20 lac=3D0x0886 U3) =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f40 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f40) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x94 sw2=3D0x= 04) =1B[0;m=1B[0;35m<000e> sim.c:952 command failed =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D1) =1B[0;m=1B[1;32m<0004> subscriber.c:608 SIM reading failed, ignoring! =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f20 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f20) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D9) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D9 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:342 received KEY from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f30 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f30) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D153) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D153 sw1=3D0x90 sw2=3D= 0x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D214 m= nc=3D07)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D208 m= nc=3D01)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D310 m= nc=3D260)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D310 m= nc=3D170)=20 from SIM ...... =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D208 m= nc=3D10)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D342 m= nc=3D600)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f31 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f31) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D1) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D1 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:401 received HPPLMN 5 (30 mins) from SI= M =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f46 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f46) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D17) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D17 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:635 SIM reading failed, file invalid =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f78 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f78) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D2) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D2 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:442 received ACC 0020 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f7b =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f7b) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D12) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D12 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:518 (ms 1) Done reading SIM card=20 (IMSI=3D234308339737861 Guernsey, T-Mobile) =1B[0;m=1B[1;32m<0004> subscriber.c:530 -> SIM card registered to 234 30=20 (Guernsey, T-Mobile) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:4147 (ms 1) Received 'MMR_REG_REQ' event =1B[0;m=1B[32m<0002> gsm322.c:3099 (ms 1) Event 'EVENT_SIM_INSERT' for auto= matic=20 PLMN selection in state 'A0 null' =1B[0;m=1B[1;37m<000d> gsm322.c:1072 Start search of last registered PLMN (= mcc=3D234=20 mnc=3D30 Guernsey, T-Mobile) =1B[0;m=1B[32m<0002> gsm322.c:1076 Use RPLMN (mcc=3D234 mnc=3D30 Guernsey,= T-Mobile) =1B[0;m=1B[32m<0002> gsm322.c:512 new state 'A0 null' -> 'A1 trying RPLMN' =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_NEW_PLMN' for Cell= =20 selection in state 'C0 null' =1B[0;m=1B[1;37m<000d> gsm322.c:2934 Selecting network (mcc=3D234 mnc=3D30 = Guernsey,=20 T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:2940 Start stored cell selection. =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C0 null' -> 'C2 stored cell=20 selection' =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 573 rxlev -98 (1= 2)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 573 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 573 rxlev -94 (1= 6)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 577 rxlev -101 (= 9)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 577 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 577 rxlev -97 (1= 3)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 579 rxlev -96 (1= 4)) ...... =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 713 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 713 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 715 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 715 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 715 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 717 rxlev -98 (1= 2)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 717 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 717 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2349 Found 31 frequencies. =1B[0;m=1B[34m<0003> gsm322.c:258 Sync to ARFCN=3D581 rxlev=3D-91 (No sysin= fo yet,=20 ccch mode NONE) =1B[0;m=1B[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=3D581, snr=3D11,= BSIC=3D37) =1B[0;m=1B[1;34m<0001> gsm322.c:2461 using DSC of 90 =1B[0;m=1B[34m<0003> gsm48_rr.c:4548 Channel provides data. =1B[0;m=1B[1;34m<0001> sysinfo.c:652 Ignoring SYSTEM INFORMATION 4 until SI= 1 is=20 received. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1798 New SYSTEM INFORMATION 4 (mcc 000 mn= c 000=20 lac 0x0000) =1B[0;m=1B[1;34m<0001> sysinfo.c:540 Now decoding previously received SYSTE= M=20 INFORMATION 4 =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1643 New SYSTEM INFORMATION 1 =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:1672 New SYSTEM INFORMATION 2 =1B[0;m=1B[34m<0003> gsm322.c:2054 New BA list (mcc=3D234 mnc=3D30 Guernse= y, T- Mobile). =1B[0;m=1B[1;34m<0001> sysinfo.c:633 New SYSTEM INFORMATION 3 (mcc 234 mnc = 30 lac=20 0x0376) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1764 Changing CCCH_MODE to 1 =1B[0;m=1B[34m<0003> gsm322.c:1598 Cell frequency 581: Cell found, (rxlev= =3D-91=20 mcc=3D234 mnc=3D30 lac=3D0376 Guernsey, T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:1608 Cell frequency 581 selected. =1B[0;m=1B[34m<0003> gsm322.c:1923 Tune to frequency 581. =1B[0;m=1B[34m<0003> gsm322.c:252 Sync to ARFCN=3D581 rxlev=3D-91 (Sysinfo,= ccch mode=20 NON-COMB) =1B[0;m=1B[34m<0003> gsm322.c:1964 Cell available. =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_CELL_FOUND' for Cell= =20 selection in state 'C2 stored cell selection' =1B[0;m=1B[1;37m<000d> gsm322.c:2744 Camping normally on cell (arfcn=3D581 = mcc=3D234=20 mnc=3D30 Guernsey, T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C2 stored cell selection' -> '= C3=20 camped normally' =1B[0;m=1B[1;32m<0004> gsm48_mm.c:4079 (ms 1) Received 'MM_EVENT_CELL_SELEC= TED'=20 event in state MM IDLE, PLMN search =1B[0;m=1B[1;32m<0004> gsm48_mm.c:882 new MM IDLE state PLMN search -> loca= tion=20 updating needed =1B[0;m=1B[1;32m<0004> gsm48_mm.c:882 new MM IDLE state location updating n= eeded - > attempting to update =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2138 Do normal Loc. upd. =1B[0;m=1B[1;37m<000d> gsm48_mm.c:2067 Perform location update (MCC 234, MN= C 30=20 LAC 0x0376) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2189 LOCATION UPDATING REQUEST =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2211 using LAI (mcc 234 mnc 30 lac 0x088= 6) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2225 using IMSI 234---------------- =1B[0;m=1B[1;32m<0004> gsm48_mm.c:887 new state MM IDLE, attempting to upda= te ->=20 wait for RR connection (location updating) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:4911 (ms 1) Message 'RR_EST_REQ' received= in=20 state idle =1B[0;m=1B[1;37m<000d> gsm48_rr.c:1181 Establish radio link due to mobility= =20 management request =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell= =20 selection in state 'C3 camped normally' =1B[0;m=1B[34m<0003> gsm322.c:2959 Going to camping frequency 581. =1B[0;m=1B[34m<0003> gsm322.c:252 Sync to ARFCN=3D581 rxlev=3D-91 (Sysinfo,= ccch mode=20 NON-COMB) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:363 new state idle -> connection pending =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1320 CHANNEL REQUEST: 00 (Location Update= with=20 NECI) =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[34m<0003> gsm322.c:2475 Channel sync error. =1B[0;m=1B[34m<0003> gsm322.c:2508 Loss of CCCH. =1B[0;m=1B[34m<0003> gsm322.c:2528 Loss of SACCH, Trigger RR abort. =1B[0;m=1B[1;37m<000d> gsm48_rr.c:2700 Radio link lost signal =1B[0;m=1B[1;34m<0001> gsm48_rr.c:2707 LOS during RACH request =1B[0;m=1B[1;34m<0001> gsm48_rr.c:363 new state connection pending -> idle =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_RET_IDLE' for Cell= =20 selection in state 'C3 camped normally' =1B[0;m=1B[34m<0003> gsm322.c:2890 Selecting frequency 581. after LOC.UPD. =1B[0;m=1B[34m<0003> gsm322.c:252 Sync to ARFCN=3D581 rxlev=3D-91 (Sysinfo,= ccch mode=20 NON-COMB) =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C3 cam= ped=20 normally' =1B[0;m=1B[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR= in=20 state wait for RR connection (location updating) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2589 RR link released after loc. upd. =1B[0;m=1B[1;37m<000d> gsm48_mm.c:2533 Location update failed =1B[0;m=1B[1;32m<0004> subscriber.c:1014 (ms 1) new state U3_ROAMING_NA ->= =20 U2_NOT_UPDATED =1B[0;m=1B[1;32m<0004> subscriber.c:795 Updating LOCI on SIM =1B[0;m=1B[1;37m<000d> gsm48_mm.c:2572 Try location update later =1B[0;m=1B[1;32m<0004> gsm48_mm.c:4083 (ms 1) Received 'MM_EVENT_CELL_SELEC= TED'=20 event in state wait for RR connection (location updating) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:1021 Starting T3211 after RR release. =1B[0;m=1B[1;32m<0004> gsm48_mm.c:391 starting T3211 (loc. upd. retry delay= ) with=20 15.0 seconds =1B[0;m=1B[1;32m<0004> gsm48_mm.c:1070 We are camping normally as returning= to MM=20 IDLE =1B[0;m=1B[1;32m<0004> gsm48_mm.c:892 new state wait for RR connection (loc= ation=20 updating) -> MM IDLE, location updating needed =1B[0;m=1B[1;32m<0004> gsm48_mm.c:882 new MM IDLE state location updating n= eeded - > attempting to update =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2083 Loc. upd. already pending. =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY=20 (handle=3D00000005) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f7e) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:294 UPDATE BINARY (offset=3D0 len=3D11) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[34m<0003> gsm322.c:2475 Channel sync error. =1B[0;m=1B[34m<0003> gsm322.c:2508 Loss of CCCH. =1B[0;m=1B[34m<0003> gsm322.c:2516 Loss of CCCH, Trigger re-selection. =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_CELL_RESEL' for Cell= =20 selection in state 'C3 camped normally' =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C4 nor= mal=20 cell re-selection' =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 0 rxlev -98 (12)= ) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 0 twice. Overwr= iting=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 0 rxlev -97 (13)= ) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1 rxlev -95 (15)= ) ...... =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1019 rxlev -95 (= 15)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1020 rxlev -95 (= 15)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1021 rxlev -95 (= 15)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1022 rxlev -96 (= 14)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1023 rxlev -96 (= 14)) =1B[0;m=1B[34m<0003> gsm322.c:2349 Found 568 frequencies. =1B[0;m=1B[34m<0003> gsm322.c:258 Sync to ARFCN=3D102 rxlev=3D-68 (No sysin= fo yet,=20 ccch mode NONE) =1B[0;m=1B[34m<0003> gsm322.c:2475 Channel sync error. =1B[0;m=1B[34m<0003> gsm322.c:2218 Cell selection failed, sync timeout. =1B[0;m=1B[34m<0003> gsm322.c:258 Sync to ARFCN=3D53 rxlev=3D-72 (No sysinf= o yet, ccch=20 mode NONE) =1B[0;m=1B[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=3D53, snr=3D15, = BSIC=3D52) =1B[0;m=1B[1;34m<0001> gsm322.c:2461 using DSC of 90 =1B[0;m=1B[34m<0003> gsm48_rr.c:4548 Channel provides data. =1B[0;m=1B[1;34m<0001> sysinfo.c:633 New SYSTEM INFORMATION 3 (mcc 234 mnc = 10 lac=20 0xc44b) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1764 Changing CCCH_MODE to 1 =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> sysinfo.c:652 Ignoring SYSTEM INFORMATION 4 until SI 1 is= =20 received. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1798 New SYSTEM INFORMATION 4 (mcc 234 mn= c 10=20 lac 0xc44b) =1B[0;mwriting msgb to gsmtap fd: Connection refused writing msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused

1 0

None
by None 03 Jan '22

03 Jan '22

Sure, it would be a nice addition, but it's not something that I consider extremely important. With regard to 'near future': I would say that in something like six months the osmo-bts (BTS-side A-bis) code will have matured, and is ready for an relaatively painless integration with OpenBTS. I personally think the USRP hardware cost is still way too high, and I would rather want to work on something that puts the financial entrance barrier to private BTS ownership much lower. Most of the people using OpenBSC today either use it commercially (and can afford the nanoBTS units), or they use it private and either with a very cheap second hand nanoBTS, or with a inexpensive BS-11. The recent work on supporting the RBS2308 that can be found for < 1000 USD goes into the same direction. I think whatever hardware will be affordable to hackers will see OpenBSC support - just as well as any hardware where we have a commercial customer will get OpenBSC support. > > This is where I don't get you. All that needs to be removed is the L3-to-SIP > > bridge. It doesn't make the vast majority of OpenBTS code disappear, > > and it does not render that latter part useless. A full-blown GSM network with > > all its components brings a lot of complexity. The stand-alone OpenBTS is > > much more simple. And why would you want all the complexity if you don't > > need to interoperate with legacy GSM? > > Well, because the the osmocom-integrated version will be, before or > later, more full-featured than OpenBTS standalone. > > Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable > only jointly with Osmocom integration but not by the opensource OpenBTS > standalone version. If you use the USRP hardware (or any other SDR hardware), you cannot use GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. As for hand-over, you may be right, but I don't know the OpenBTS plans here. Multi-ARFCN: This is an aspect of the radio-modem. So again, on the same hardware any OpenBTS/OpenBSC integration will not change this. > Obviously the community will then use the OpenBTS/OpenBSC integration > that would reach more features than just OpenBTS in the opensource edition. well, but you loose the important 'simplicity' feature. Right now I doubt there are that many people in our community who understand OpenBSC and the GSM/GPRS network architecture enough to deploy a network (like the burning man or CCC event networks) with it. We have close to zero documentation, and unless you know GSM protocol details, you are lost. VoIP is much better understood in the FOSS and Internet community! > So the integrated code will grow while the "OpenBTS commercial code" > will leave behind with less features and more buggy code (because less > used). you are making assumptions here. Do you have evidence or at least some other indication that bug fixes are not being propagated from the commercial to the free version? > Osmocom and it's possible future changes to the market of GSM > technologies could be defined as "the WikiLeaks of the GSM Industry" :-) I think this is a very bad comparison. We do not leak any proprietary/secret information. We just break the ignorance of the Free Software community to ever implement any of those openly-specified protocols. Not different from Free Software entering any other area of technology. And while we're doing that, we of course also like to challenge the ridiculous claims of hundred-man-year efforts that allegedly went into some proprietary GSM protocol stack implementations, which are often claimed by the existing carrier equipment industry. 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

None
by None 03 Jan '22

03 Jan '22

> Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation > for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a > simplistic BTS), and I have started to split that code out into a separate > repository at http://cgit.osmocom.org/cgit/osmo-bts/ > > This code should eventually be used with the OpenBTS, and potentially other > BTS types, too. That's cool!!!! > >> With that approach the 'GSM-um' interface would be a very simplified >> module of the overall system and osmocom would completely replace >> OpenBTS all-in-one project. > > This is where I don't get you. All that needs to be removed is the L3-to-SIP > bridge. It doesn't make the vast majority of OpenBTS code disappear, > and it does not render that latter part useless. A full-blown GSM network with > all its components brings a lot of complexity. The stand-alone OpenBTS is > much more simple. And why would you want all the complexity if you don't > need to interoperate with legacy GSM? Well, because the the osmocom-integrated version will be, before or later, more full-featured than OpenBTS standalone. Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable only jointly with Osmocom integration but not by the opensource OpenBTS standalone version. Obviously the community will then use the OpenBTS/OpenBSC integration that would reach more features than just OpenBTS in the opensource edition. That means that in few times only the "integrated code" will works better, because it will attract more user and will start getting used in "production environment". So the integrated code will grow while the "OpenBTS commercial code" will leave behind with less features and more buggy code (because less used). That's why i just think that the destinity of OpenBTS is to integrate (directly or just some piece) with OpenBSC, but doing that it will loose several important value of the "OpenBTS commercial edition" and people will start using what can be used for free instead of paying. That's what usually happen within the opensource environment, before or later. It could reasonably happen also with that opensource gsm environment. My comments was just consideration on this to stimulate the considerations on this by the various project players. I am just an opensource advocacy troll that like telephony stuff and perceive very valuable the achievement of the hacking community in opening a closed technology like GSM. Osmocom and it's possible future changes to the market of GSM technologies could be defined as "the WikiLeaks of the GSM Industry" :-) -naif p.s. i have no commercial interests of any kind in that stuff

1 0

None
by None 03 Jan '22

03 Jan '22

all the powerfull eye-candy apps. But that takes processing power. So SoC provider would separate processing on two cores, puting stack on the other core. Since this other core do not demand any application except PS, you would like to run some nice lightweight OS like eCos, or similar that have good RT performances to assure timing requirements for L1 and inter-CPU communication. If there would be satisfying performance on one core, there would certanly be interest to save money by rejecting the other. And to figure out how to separate closed source, how to keep legacy RTOS and RT apps, etc... And since more powerful cores are appearing, L4 comes into play on big doors (not to mention that it's the worlds first formally verified kernel). BR, Drasko

1 0

None
by None 03 Jan '22

03 Jan '22

what do you think?

1 0

None
by None 03 Jan '22

03 Jan '22

main_simtrace.bin, using dfu-util from http://dfu-util.gnumonks.org -- - 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

None
by None 03 Jan '22

03 Jan '22

velopment, so our drivers could be more portable and we'll see if they'll b= e also aplicable for MT6516. BR, Marcin=

1 0

None
by None 03 Jan '22

03 Jan '22

patience" is a really good guess. Let me explain how this works: In Shenzhen there is a huge electronics area. Thousands of shops and companies, hundreds of thousands of people working and trading there. I have a small collection of pictures so you get the idea... http://en.qi-hardware.com/wiki/Shenzhen_markets (this stretches over an area of at least 1x1 km, with dozens of 8+ level buildings, some higher like the 70-floor office tower :-)) Basically you can walk up to any PCB shop (there are at least 50 I would say). I went to one I used before with 2 Sciphone Dream G2 boards, and they accepted the job for 600 RMB (=ca. 90 USD). I got the pictures 4 days later. I got them as .bmp files, then I did some post-processing to make nice horizontally aligned, contrast-enriched PNGs out of them, and a big PDF too to easily flip through the layers (PDF readers tend to be quite powerful and efficient in scaling and flipping, so this seems to work well). I am not an electronics guy, so I need feedback to do this kind of work better in the future. For example, I don't know the exact names of the layers. Can someone who knows what they are add subtitles to the wiki? Copper layer, ground layer, via, whatever? (I just don't know...) Or reply here and I'll annotate the wiki. Anything else I should do to make this better next time? This is all background info I have, one day I will convince them to let me take some pictures of the actual work :-) Wolfgang

1 0

None
by None 03 Jan '22

03 Jan '22

\subsection{How to synchronize the GSM TDMA multiplex} As part of the BCCH, the BTS not only sends the FCCH but also the Synchronization CHannel (SCH). The Synchronization channel indicates the current GSM time / frame number (skipping the 3 least significant bits). By using this received GSM time and incrementing it every time the GSM bit-clock timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. Understanding the multiple layers of time multiplex such as the 26/51 multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all the logical channels of GSM. \section{Miscellaneous Topics} \subsection{GPRS} GPRS was the first packet switched extension to GSM. In fact, it is much more its entirely own mobile network, independent of GSM. The only parts shared are the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful coexistence between them. The L1 and L2 protocols are very different (and much more complex) than GSM. So while the phone baseband hardware did not need any modifications for a basic GPRS enabled phone, the software needed to be extended quite a lot. \subsection{EDGE} EDGE is a very small incremental step to GPRS. It reuses all of the time multiplex and protocol stack, but introduces a new modulation: Offset 8-PSK instead of GMSK to increase the bandwidth that can be transmitted. Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid zero-crossings in the modulator output. So while the software modifications from GPRS to EDGE are minimal, the 8PSK modulation scheme has a significant impact on the DSP, ABB and even RF PA design. \subsection{UMTS} UMTS (sometimes called WCDMA) is an entirely separate cellular network technology. Its physical layer, modulation schemes, encoding, frequency bands, channel spacing are entirely different, as is the Layer1. UMTS Layer2 has some resemblance to the GPRS Layer2. UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. Given the vast physical layer and L1 differences, a UMTS phone hardware design significantly differs from what has been described in this document. Notwithstanding, all known commercial UMTS phone chipsets as of today still include a full GSM modem in hardware and software to remain backwards-compatible. \subsection{Dual-SIM and Triple-SIM phones} In recent years, a large number of so-called {\em Dual-SIM} or even {\em Triple-SIM} phones have entered the market, particularly in China and other parts of East Asia. Those phones come in various flavours. Some of them simply have a multiplexer that allows electrical switching between multiple SIM card slots. This is similar to replacing the SIM card in a phone, just without the manual process of mechanically removing/inserting the card. As a result, you can only use one of the two SIMs at any time. The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf frontends, 2 analog basebands, 2 digital basebands, ... However, they use the same trick as smartphones: One of the two basebands does not have keypad or display and is simply a GSM modem connected via serial line to the other baseband processor. So if a smartphone (as defined in this document) is a GSM modem connected to a PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone in one case. Triple-SIM phones often combine the two approaches, i.e. they contain two complete GSM baseband chips, but three SIM slots that can be switched among the base bands. Only two SIMs can be active at the same time. \subsection{Powerful feature phones} Feature phones are becoming more and more powerful. However, their comparatively lower market price cannot afford a full-blown smartphone design with its two independent processors and the associated design complexity. Thus, more and more hardware peripherals are added to the only processor left in the phone: The baseband processor. Such peripherals include sophisticated camera interfaces, high-resolution color display controllers, TV output, touchscreen controllers, audio and video codecs and even interfaces for mobile TV reception. However, all of those features are still implemented on a fairly weak ARM7 or ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They also lack a real operating system and still run on top of a real-time microkernel intended for much less complex systems. They almost always lack any form of memory protection or multiple address spaces. This makes them more prone to security issues as there is no privilege separation between the GSM protocol stack and the applications, or between the applications themselves. \subsection{Security features} There are several (sometimes conflicting) security requirements that apply to mobile phones. Interestingly, the security features are typically used to protect some industry interest against the interest of the customer. There are very few security features in a phone that are meant to protect the user or his interests. \subsubsection{IMEI - The hardware serial number} The International Mobile Equipment Identifier (IMEI) uniquely identifies a GSM phone. It is a globally unique serial number which is programmed into the phone non-volatile memory (Flash or EEPROM) during the production process. There are no particular security features used to store the IMEI. Once you are able to write to flash and have found it, it can be changed. \subsubsection{The SIM Card} The SIM card is a cryptographic smart card that stores the secret key used for authenticating the user to the GSM network (Ki). The Ki is never released by the card, and as such copying (cloning) of the SIM is prevented. Furthermore, the SIM stores the International Mobile Subscriber Identity (ISMI). The IMSI is not encrypted or protected in some way. There is no security channel on the connection between the SIM card and the baseband MCU. Furthermore, there is no way how the MCU can securely identify/authenticate the SIM itself. Physical access to the SIM card slot allows sniffing and/or modification of the communication between MCU and SIM. \subsubsection{SIM or Operator Locking} GSM is an international standard. This ensures interoperability, i.e. any phone can be used on any network. However, in some cases, the vendors of a GSM phone want to restrict this interoperability and lock a phone to one specific network, or even lock it to a particular SIM. Those locks are implemented by software only, i.e. the MCU software will instruct the GSM protocol stack not to register with a network unless its network operator code is a certain factory-programmed network number. As such, techniques for circumventing those locks have become commonplace. It's somewhat of an ongoing race between the phone makers and the phone-unlockers. The industry invents ever more complex methods of obfuscating their locks in the software, while the phone-unlockers reverse engineer those bits for each and every phone model after some time. \subsubsection{DBB firmware signatures} In order to protect the operator and phone manufacturers peculiar business models based on SIM or operator locking, some vendors extended their baseband software with cryptographic signatures. Only if the correct signature is present in a software update, the bootloader program will accept the new software. However, there are more or less invasive hardware-related approaches in circumventing those signature checks, such as hardware debugging interfaces like JTAG, or replacing the external flash memory components. More recently, GSM chipset vendors introduced features such as hardware-assisted software signature checks. In this case a master key hash might be present in DBB-internal fuses, together with a signature-verifying boot loader in DBB-internal mask ROM. As the root of the chain of trust is moving deeper into the hardware, it becomes more difficult for anyone to make software modifications to the DBB. Especially with tighter integration, where RAM and FLASH are no longer present as discrete components but part of a multi-chip-package, the number of options are becoming more limited. On the other hand, an ever more complex baseband software stack is opening up many more options for exploiting software vulnerabilities. Given the lack of a proper/modern operating system with privilege separation and virtual memory, such exploits immediately give away full access to all aspects of the respective DBB. \section{Personal rant on the closedness of the GSM industry} The GSM industry is one of the most closed areas of computing that I've encountered so far. It is very hard to get any hard technical information out of them. All they like to spread is high-level marketing information, but they're very reluctant when it comes down to hard technical facts on their products. If you want to build a phone, you need to buy a GSM chipset for your product. There are only very few companies that offer such chipsets. The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI (now MediaTek) and Freescale. The GSM handset products they sell are not generally available and distributed like other electronic component they manufacture. If you need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth chip, RFID reader ASIC, you simply approach the respective distributors and order them. You get your samples directly from Digikey. This is impossible for GSM (or other cellphone) chipsets. For some reason those chips are sold only to hand-picked manufacturers. If you want to qualify, you have to subscribe to at least six-digit annual purchasing quantities. And in order for them to believe you, you have to cough up a significant NRE (non-refundable engineering fee). This has been reported as high as a seven-digit US\$ amount and is to make sure that even if you end up buying less chips than you indicate, the chipset maker will still have your upfront NRE money and keep it. And if you buy your way into that select club of cellphone makers, what you get from the chipset maker is typically not all too impressive either. The documentation you get is incomplete, i.e. it alone would not enable you as a cellphone maker to make any use of the hardware, unless you license the software (drivers, GSM protocol stack, ...) from the chipset maker, too. On the software side, most of the technologically interesting bits (like the protocol stack) are provided as binary-only libraries, you only get source code to some parts of the systems, i.e. some hardware drivers that might need modification for your particular phone electrical design. That GSM protocol stack was not written by the chipset maker either. They simply license a stack from one of the estimated 4 or 5 organizations who have ever implemented a commercial GSM protocol stack. It is not like the GSM protocols were some kind of military secret. They are a published international standard, freely accessible for anyone. So why does everybody in that industry think that there is a need to be so secretive? Having spent a significant part of the last 6 years with reverse engineering of various aspects of mobile phones in order to understand them better and do write software tools for security analysis, I still don't understand this secrecy. All the various vendors do more or less the same. The fundamental architecture of a GSM baseband chip is the same, whether you buy it from TI, Infineon or from MediaTek. {\em They all cook with water}, like we Germans tend to say. The details like the particular DSP vendor or whether you use a traditional IF, zero-IF or low-IF analog baseband differ. But from whom do they want to hide it? If people like myself with a personal interest in the technical aspects of mobile phones can figure it out in a relatively short time, then I'm sure the competiton of those chipset makers can, too. In much less time, if they actually care. This closedness of the cellular industry is one of the reasons why there has been very little innovation in the baseband firmware throughout the last decades. Innovation can only happen by very few players. Source code bugs can only be found and fixed by very few developers at even fewer large corporations. No chance for a small start-up to innovate, like they can in the sphere of the internet. It is fundamentally also the reason why the traditional phone makers have been losing market share to newcomers to the mobile sphere like Apple with its iPhone or Google with its Android platform. Those innovations really only happened on the application processor on high-end smartphones. The closed GSM baseband processor had to be accompanied by an independent application processor running a real operating system, with real processes, memory management, shared libraries, memory protection, virtual memory spaces, user-installable applications, etc. They still don't happen on the baseband processor, which is as closed as it was 15 years ago. \end{document} --3V7upXqbjpZ4EhLz--

1 0

None
by None 03 Jan '22

03 Jan '22

\subsection{How to synchronize the GSM TDMA multiplex} As part of the BCCH, the BTS not only sends the FCCH but also the Synchronization CHannel (SCH). The Synchronization channel indicates the current GSM time / frame number (skipping the 3 least significant bits). By using this received GSM time and incrementing it every time the GSM bit-clock timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. Understanding the multiple layers of time multiplex such as the 26/51 multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all the logical channels of GSM. \section{Miscellaneous Topics} \subsection{GPRS} GPRS was the first packet switched extension to GSM. In fact, it is much more its entirely own mobile network, independent of GSM. The only parts shared are the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful coexistence between them. The L1 and L2 protocols are very different (and much more complex) than GSM. So while the phone baseband hardware did not need any modifications for a basic GPRS enabled phone, the software needed to be extended quite a lot. \subsection{EDGE} EDGE is a very small incremental step to GPRS. It reuses all of the time multiplex and protocol stack, but introduces a new modulation: 8PSK instead of GMSK to increase the bandwidth that can be transmitted. So while the software modifications from GPRS to EDGE are minimal, the 8PSK modulation scheme has a significant impact on the DSP, ABB and even RF Frontend (especially the RF Amplifier). \subsection{UMTS} UMTS (sometimes called WCDMA) is an entirely separate cellular network technology. Its physical layer, modulation schemes, encoding, frequency bands, channel spacing are entirely different, as is the Layer1. UMTS Layer2 has some resemblance to the GPRS Layer2. UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. Given the vast physical layer and L1 differences, a UMTS phone hardware design significantly differs from what has been described in this document. Notwithstanding, all known commercial UMTS phone chipsets as of today still include a full GSM modem in hardware and software to remain backwards-compatible. \subsection{Dual-SIM and Triple-SIM phones} In recent years, a large number of so-called {\em Dual-SIM} or even {\em Triple-SIM} phones have entered the market, particularly in China and other parts of East Asia. Those phones come in various flavours. Some of them simply have a multiplexer that allows electrical switching between multiple SIM card slots. This is similar to replacing the SIM card in a phone, just without the manual process of mechanically removing/inserting the card. As a result, you can only use one of the two SIMs at any time. The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, that's right! They contain two full GSM phoen chipsets, i.e. 2 antennas, 2 rf frontends, 2 analog basebands, 2 digital basebands, ... However, they use the same trick as smartphones: One of the two baesbands does not have keypad or display and is simply a GSM modem connected via serial line to the other baseband processor. So if a smartphone (as defined in this document) is a GSM modem connected to a PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone in one case. Triple-SIM phones often combine the two approaches, i.e. they contain two complete GSM baesband chips, but three SIM slots that can be switched among the base bands. Only two SIMs can be active at the same time. \subsection{Powerful feature phones} Feature phones are becoming more and more powerful. However, their comparatively lower market price cannot afford a full-blown smartphone design with its two independent processors and the associated design complexity. Thus, more and more hardware peripherals are added to the only processor left in the phone: The baseband processor. Such peripherals include sophisticated camera interfaces, high-resolution color display controllers, TV output, touchscreen controllers, audio and video codecs and even interfaces for mobile TV reception. However, all of those features are still implemented on a fairly weak ARM7 or ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They also lack a real operating system and still run on top of a real-time microkernel intended for much less complex systems. They almost always lack any form of memory protection or multiple address spaces. This makes them more prone to security issues as there is no privilege separation between the GSM protocol stack and the applications, or between the applications themselves. \section{Personal rant on the closedness of the GSM industry} The GSM industry is one of the most closed areas of computing that I've encountered so far. It is very hard to get any hard technical information out of them. All they like to spread is high-level marketing information, but they're very reluctant when it comes down to hard technical facts on their products. If you want to build a phone, you need to buy a GSM chipset for your product. There are only very few companies that offer such chipsets. The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI (now MediaTek) and Freescale. The GSM handset products they sell are not generally available and distributed like other electronic component they manufacture. If you need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth chip, RFID reader ASIC, you simply approach the respective distributors and order them. You get your samples directly from Digikey. This is impossible for GSM (or other cellphone) chipsets. For some reason those chips are sold only to hand-picked manufacturers. If you want to qualify, you have to subscribe to at least six-digit annual purchasing quantities. And in order for them to believe you, you have to cough up a significant NRE (non-refundable engineering fee). This has been reported as high as a seven-digit US\$ amount and is to make sure that even if you end up buying less chips than you indicate, the chipset maker will still have your upfront NRE money and keep it. And if you buy your way into that select club of cellphone makers, what you get from the chipset maker is typically not all too impressive either. The documentation you get is incomplete, i.e. it alone would not enable you as a cellphone maker to make any use of the hardware, unless you license the software (drivers, GSM protocol stack, ...) from the chipset maker, too. On the software side, most of the technologically interesting bits (like the protocol stack) are provided as binary-only libraries, you only get source code to some parts of the systems, i.e. some hardware drivers that might need modification for your particular phone electrical design. That GSM protocol stack was not written by the chipset maker either. They simply license a stack from one of the estimated 4 or 5 organizations who have ever implemented a commercial GSM protocol stack. It is not like the GSM protocols were some kidn of military secret. They are a published international standard, freely accessible for anyone. So why does everybody in that industry think that there is a need to be so secretive? Having spent a significant part of the last 6 years with reverse engineering of various aspects of mobile phones in order to understand them better and do write software tools for security analysis, I still don't understand this secrecy. All the various vendors do more or less the same. The fundamental architecture of a GSM baseband chip is the same, whether you buy it from TI, Infineon or from MediaTek. {\em They all cook with water}, like we Germans tend to say. The details like the particular DSP vendor or whether you use a traditional IF, zero-IF or low-IF analog baseband differ. But from whom do they want to hide it? If people like myself with a personal interest in the technical aspects of mobile phones can figure it out in a relatively short time, then I'm sure the competiton of those chipset makers can, too. In much less time, if they actually care. This closedness of the cellular industry is one of the reasons why there has been very little innovation in the baseband firmware throughout the last decades. Innovation can only happen by very few players. Source code bugs can only be found and fixed by very few developers at even fever large corporations. No chance for a small start-up to innovate, like they can in the sphere of the internet. It is fundamentally also the reason why the traditional phone makers have been loosing market share to newcomers to the mobile sphere like Apple with its iPhone or Google with its Android platform. Those innovations really only happened on the application processor on high-end smartphones. The closed GSM baseband processor had to be accompanied by an independent application processor running a real operating system, with real processes, memory management, shared libraries, memory protection, virtual memory spaces, user-installable applications, etc. They still don't happen on the baseband processor, which is as closed as it was 15 years ago. \end{document} --0ntfKIWw70PvrIHh--

1 0

None
by None 03 Jan '22

03 Jan '22

or 6225 CPUs (need to look for documentation): --- MT6225BA CECT V8 TianShiDa TS822 --- MT6225/6225A CECT 388 CECT 98 CECT 2618 CECT N95i ChangHong 868 ChuangWei T508 DaXian X889 DaXian X769 GaoXinQi D808 Hantai HT622 Hantai HT6868 JingLi H9 (some H9 also have MT6226) JinPeng A918 JinPeng 858 JinPeng A9 JinPeng S3506 JinPeng 2298 JinPeng L818 JinPeng A608 TianYu D170 TianYu B898 TianYu A930 TianYu B926 TianYu A908 ZTC 6988 ZTC 598 ZTC 1118 ZTE ZTLV900 ZTE ZT688 (note MT6205 versions also exist) --- MT6223PA TianYu B5010 CECT D1088 Next steps for me: Scan the schematics stuff and put it online. Find some 6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally with some nice test points or JTAG. Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228. One word of caution - the above lists, and documentation we start digging up, may give a false impression of predictability. In reality the brand names and model numbers are a total mess in China. Typos everywhere. All sorts of things are printed on cases & boxes, chips are changed without anybody noticing or caring. There are endless smaller Chinese brands making phones with 6223 or 6225 chips, but I think it will be very hard to use them as a stable source, to get phones with the same chips over time. So I think it's better to focus on the somewhat bigger Chinese brands as listed above. Wolfgang

1 0

None
by None 03 Jan '22

03 Jan '22

not always 100% perfect (it depends on the phone and the cable), so moving the phone during the download may cause the connection to be interrupted. I have not yet looked at the serial signal with an oscilloscope to see if there are problems with the signal itself. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

None
by None 03 Jan '22

03 Jan '22

stage. Any ideas? If I boot the phone and use 57600bps I get some prints and then AT returns OK, no other AT commands work. In case it is too broken I have ordered a C121 from germany as well. /Erik

1 0

None
by None 03 Jan '22

03 Jan '22

without having to go through the real layer1 or at least without having<br> to go through the air.<br> <br> But without a clear path to later porting this on a real physical<br> layer1, there would be little motivation of doing all that work.<br></block= quote><div><br>I'd like to get involved in that, however these are my p= roblems:<br>- I have no running system that I could debug and <br>=A0 there= by learn how GSM works.<br> -=A0 To=A0 get a running system I would need to implement a software<br>=A0= =A0 only system, however, I cannot implement that without knowledge <br>=A0= =A0 of GSM<br>=A0That is kindof a deadlock. <br><br>Therefore I wonder wea= ther the expert of GSM would share their <br> knowledge in the obove described way:<br>Having=A0 <br>=A0 - a flow diagram= <br>=A0 - the etsi standard pages (or simple rewrites of it)<br>=A0 - the h= tml parsed imlemention of a real TSM30 stack implement.<br>and linking that= all together to get a way for a newbie to <br> get started.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"border-= left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left= : 1ex;"> <br> I think what makes OsmocomBB special is the very fact that we do not<br> have to rely on simulation, but can do the "real thing".<br> <br> Nonetheleess, if somebody was interested in implementing what I've<br> described, I'd be more than happy to help any such project and<br> include the neccessary support in OpenBSC and/or OsmocomBB.<br> <div><div></div><div class=3D"h5"><br> --<br> - Harald Welte <<a href=3D"mailto:laforge@gnumonks.org">laforge@gnumonks= .org</a>> =A0 =A0 =A0 =A0 =A0 <a href=3D"http://laforge.gnumonks.org/" t= arget=3D"_blank">http://laforge.gnumonks.org/</a><br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<br> "Privacy in residential applications is a desirable marketing option.&= quot;<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0(ETSI EN 300 175-7 Ch. A6)<br> </div></div></blockquote></div><br> --0016e65ae6825c4265048170c62d--

1 0

None
by None 03 Jan '22

03 Jan '22

without having to go through the real layer1 or at least without having to go through the air. But without a clear path to later porting this on a real physical layer1, there would be little motivation of doing all that work. I think what makes OsmocomBB special is the very fact that we do not have to rely on simulation, but can do the "real thing". Nonetheleess, if somebody was interested in implementing what I've described, I'd be more than happy to help any such project and include the neccessary support in OpenBSC and/or OsmocomBB. -- - 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

None
by None 03 Jan '22

03 Jan '22

data to the network by using the RSL RLL DATA REQUEST primitive. Also, while we are tuned to any BCCH/CCCH, the L3 frames are sent from L2 to L3 in RSL RLL UNIT DATA INDICATION messages. What is not as simple is the non-RLL part, i.e. sending the first RACH request, ... For those, we will have to invent our own new RSLms message types, possibly reusing as many RSL information elements as possible - meaning we can share more code/structure with what we already have in libosmocore/openbsc > is there a better (simpler) way? The RSLms approach might not be the simplest one, but I think it would be a very nice/orthogonal approach. Plus: In this model, we can eventually move the L2 implementation into the MS firmware, while talking RSLms over HLDC to L3 on the PC. 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

OsmoDevCall on Dec 10, 2021: osmo-dev and running TTCN3 test sultes locally + PFCP
by Harald Welte 09 Dec '21

09 Dec '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at December 10, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "osmo-dev and running Osmocom TTCN3 tests suites locally" by osmith 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

"OsmoDevCall" on Nov 25, 2021: Control/User Plane Separation (CUPS) + PFCP
by Harald Welte 24 Nov '21

24 Nov '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at November 25, 2021 at 20:00 CET (yes, Thursday instead of Friday this time!) at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "Control/User Plane Separation (CUPS) + PFCP" by laforge 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

"OsmoDevCall" on Nov 12, 2021: icE1usb in practice
by Harald Welte 11 Nov '21

11 Nov '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at November 12, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "E1 / TDM / PDH / SDH basics" by laforge 20:30 presentation "icE1usb in practice" by tnt later USSE: unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Re: OsmoDevCon 2022 ?
by Harald Welte 06 Nov '21

06 Nov '21

Hi Kevin, On Fri, Nov 05, 2021 at 02:18:14PM +0100, Kévin Redon wrote: > I'm also happy to help with the recording and streaming of the public talks for those not able to join on site. thanks for that, as usual. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Re: OsmoDevCon 2022 ?
by Neels Hofmeyr 04 Nov '21

04 Nov '21

> requiring vaccination to attend by default. Maybe with the option for attendees > to request attendance despite no vaccination, and then see whether we can > unanimously agree on that? I'd like to add that I find it should also be sufficient to have recovered from COVID. This is a common rule in schools in Berlin that does relieve teachers from the need to test regularly (called 2G, incidentally). Another question is whether we play by RKI rules and not accept certain vaccines. I guess we should first see whether anyone would be refused attendance based on these rules and take it from there? Here is a dudle to anonymously figure out the current vaccination status. Feel free to enter your current status, especially if you're not fully vaccinated and would like to attend. This is just to get a basis for discussion: https://dudle.inf.tu-dresden.de/w93G6NPqfA/ I guess we need to repeat such poll in early '22.

1 0

GSMTAP messages not generated
by Mario Lucas 30 Oct '21

30 Oct '21

Dear All, I am running a GSM stack: osmo-stp smo-msc osmo-hlr osmo-bsc osmo-bts-trx osmo-trx-lms It seems that my transmitter is emitting radio-waves into air (osmo-bts-trx and osmo-trx-lms communicate with each other through ports 5702 / 5802 — pls see attached printscreen), however i could not make GSMTAP tracing. Osmo-bts-trx does not send GSMTAP messages to port 4729. In most recent version of osmo-bts, GSMTAP tracing is arranged through config file: bts 0 gsmtap-remote-host 127.0.0.1 gsmtap-sapi ccch I could not run the GSMTAP tracing even in previous verions of osmo-bts where you have to specify in synopsis when you call a program: /usr/bin/osmo-bts-trx -s -c /etc/osmocom/osmo-bts-trx.cfg --gsmtap-ip 127.0.0.1 I thought may be i am having some issues in stack components behind osmo-bts for example in osmo-bsc or behind and i tried to run virtual bts. When i tried to run osmo-bts-virtual GSMTAP messages were visible in wireshark (please see attached file osmo-bts-virtual), therefore bts-bsc communication is good. However I still could not figure out why my osmo-bts-trx does not send GSMTAP messages. Or would you advise what log might be helpful to see what i am doing wrong …. Thank you for your always helpful assistance -- Mario Lucas

2 1

(bts=0,trx=0,ts=0,pchan_from_config=CCCH+SDCCH4,state=NOT_INITIALIZED) Abis RSL rx CCHAN: mismatching chan_nr=0x90
by Mario Lucas 22 Oct '21

22 Oct '21

When i try to run osmo-bts-trx i am getting following log in osmo-bsc abis_rsl.c:142 (bts=0,trx=0,ts=0,pchan_from_config=CCCH+SDCCH4,state=NOT_INITIALIZED) Abis RSL rx CCHAN: mismatching chan_nr=0x90 I tried to find out in bugs: https://osmocom.org/issues/4872 but could not understand … i am using osmo-bsc 1.7.1 and osmo-bts-trx 1.3.3 Could you pls advise me briefly whats happening and how to sort it out ? -- Mario Lucas

2 1

libmobile.a(mncc_sock.o) undefined reference
by Mario Lucas 16 Oct '21

16 Oct '21

Dear All, I am having following error during ‘make’ osmocombb: libmobile.a(mncc_sock.o): In function `mncc_sock_accept': /home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:229: undefined reference to `osmo_fd_read_disable' libmobile.a(mncc_sock.o): In function `mncc_sock_close': /home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:95: undefined reference to `osmo_fd_read_enable' libmobile.a(mncc_sock.o): In function `mncc_sock_write': /home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:159: undefined reference to `osmo_fd_write_disable' /home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:174: undefined reference to `osmo_fd_write_enable' libmobile.a(mncc_sock.o): In function `mncc_sock_from_cc': /home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:75: undefined reference to `osmo_fd_write_enable' libmobile.a(mncc_sock.o): In function `mncc_sock_write_pending': /home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:81: undefined reference to `osmo_fd_write_enable' collect2: error: ld returned 1 exit status Makefile:394: recipe for target 'mobile' failed make[3]: *** [mobile] Error 1 make[3]: Leaving directory '/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile' Makefile:325: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src' Makefile:351: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23' Makefile:97: recipe for target 'host/layer23/layer23' failed make: *** [host/layer23/layer23] Error 2 My arm-elf-gcc is gcc version 4.5.2 (GCC) libosmocore 1.4.1 I believe it is something with libraries but could not figure out …. -- Mario Lucas

2 1

Announcement of "OsmoDevCall" on September 24, 2021
by Harald Welte 23 Sep '21

23 Sep '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at September 24, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "ISO 7816 smart card interface FPGA softcore" by tnt 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Catching Frequency correction burst
by Mario Lucas 15 Sep '21

15 Sep '21

Dear Forum members i am not sure this question directly relates to Osmocom, but I don’t know where I can post it else …. If you know some active / alive technical forum which relates to GSM side (frequencies, modulations, GMSK etc etc) it would be very great if you could advise me ….. Meanwhile I ll continue with my question…. 51 TDMA multiframe starts with a FCCH which carries frequency correction burst on TS0. Due to nature of GMSK modulation and initial zeros of frequency correction burst the aired signal (signal that GSM modulator emits into air) as I understand is nothing but sine wave of an approximately 67Khz on top of the carrier frequency. Once mobile finds the frequency correction burst on some frequency it subtracts 67 Khz and precisely gets / sits on beacon frequency. So when it is said that upon switching the mobile phone on - it is looking for frequency correction bursts means in different words that it is looking for sine wave in GSM frequency interval it can work. Let’s say if my phone can work only in E-GSM900 interval (925 - 960 Mhz) it is looking for sine wave (frequency correction burst) and once finds it will subtract 67 Khz and it will be precisely the carrier frequency of beacon channel ? So if I use my rtl-sdr and software that analyzes RF spectrum (something like only oscilloscope) in 925 960 Mhz interval and I notice sine waves with periodic occurrence - as many times as FCCH appears in 51 multiframe - can I say that got frequency correction burst and subtracting 67 Khz I got beacon frequency ? -- Mario Lucas

1 0

osmo-bsc default config file time-slot TS0 configuration CCCH+SDCCH4 understanding
by Mario Lucas 11 Sep '21

11 Sep '21

Dear All, Could you please advise me based on what logic (how) can i decompose logical channel configuration CCCH+SDCCH4 which is mapped on TS0… ? So my understanding is as follows: There are 51 TDMA frames in multiframe, therefore i am having 51 consecutive TS0 slots. So CCCH+SDCCH4 should be redistributed in these 51 slots. SDCCH4 means that there are 4 SDCCH blocks, each block is having 4 bursts or 4 timeslots in another words (as i understand to transmit SDCCH «unit data» it is needed 4 burts), so 16 slots are occupied by SDCCH. Does it mean 51-16 = 35 slots to be occupied by CCCH ? If i use following notation CCCH=C, SDCCH1=S1, SDCCH2=S2, SDCCH3=S3 and SDCCH4=S4 does the decomposition looks like: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC S1S1S1S1 S2S2S2S2 S3S3S3S3 S4S4S4S4 If so should not there be an idle slots … ? Thank you so much. -- Mario Lucas

2 1

PCU socket has LOST connection
by Mario Lucas 05 Sep '21

05 Sep '21

Dear All, I try to run a virtual BTS: systemctl start osmo-stp systemctl start osmo-hlr systemctl start osmo-msc systemctl start osmo-bsc and finally i run osmo-bts-virtual…. but i am getting following outcome: DOML <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff): Sending PCU version report to BSC: PCU socket has LOST connection DPCU <0009> pcu_sock.c:1084 PCU socket connected to external PCU DPCU <0009> pcu_sock.c:967 Received 212 bytes on PCU Socket, but primitive size is 1006, discarding DPCU <0009> pcu_sock.c:895 PCU socket has LOST connection I tried to run osmo-pcu (I thought may be this will resole above issue) but it keeps saying: <000b> gprs_ns.c:322 NSVCI=65534 Creating NS-VC with Signal weight 1, Data weight 1 <000e> telnet_interface.c:104 Available via telnet 127.0.0.1 4240 <0001> osmobts_sock.cpp:224 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:248 osmo-bts PCU socket /tmp/pcu_bts has been connected <0001> pcu_l1_if.cpp:114 Sending 0.8.0 TXT as PCU_VERSION to BTS PCU interface version number of BTS (10) is different (9). Please re-compile! I have OsmoPCU version 0.8.0 OsmoBTS version 1.2.0.307-6e27 Would you kindly advise whats going on please…. As i understand osmo-pcu is to implement GPRS into my GSM network… ok but if i dont want GPRS implemented thus i dont need PCU …. can i run virtual bts without this PCU things ? pls help ….. -- Mario Lucas

2 1

Phone without a physical sim to connect to network
by Mario Lucas 30 Aug '21

30 Aug '21

Dear All, I have a running BTS (based on SDR) and i can connect my phone to my network… do / learn some operations… I have a couple of sim cards and each time i want to connect to network with different sim i have to switch of mobile remove previous sim put new one etc etc …. Is there an application that will be running on PC and connected to my phone which will a kind of simulate sim and connect my phone to my network ? Avoiding me each time physically remove previous sim put new one etc etc … Would you be so kind and advise me please… Also another question — is there a «search» option in the archives : http://lists.osmocom.org/pipermail/openbsc/ http://lists.osmocom.org/pipermail/baseband-devel/ just not to post questions which already could have been answered…. -- Mario Lucas

3 2

Announcement of "OsmoDevCall" on August 27, 2021
by Harald Welte 24 Aug '21

24 Aug '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at August 27, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "osmo-remsim in practice" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on August 13, 2021
by Harald Welte 12 Aug '21

12 Aug '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at August 13, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "GSM-R and its differences to GSM" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Leaks simcom ?
by Bastien 09 Aug '21

09 Aug '21

https://github.com/bbaranoff/simcom https://pl4y.store https://simcom.ee/documents

2 1

CalypsoBTS with recent OsmoBTS in 2021?
by . 06 Aug '21

06 Aug '21

Hello, I'm trying to run CalypsoBTS as described here: https://osmocom.org/projects/baseband/wiki/CalypsoBTS I'm using a single Motorola C123 phone and in my openbsc.conf, i have only one CCCH+SDCCH4 channel on timeslot 0: timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 I'm using the fixeria/trx branch with recent OsmoBTS. First, i load the trx firmware on the phone, and then i start the transceiver host app to sync with a known ARFCN. The syncing goes without any issues. Then, i start OpenBSC through OsmoNITB like that: osmo-nitb -c ~/.osmocom/openbsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM --yes-i-really-want-to-run-prehistoric-software And OsmoBTS: osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg OsmoBTS fails almost instantly with: <0012> input/ipaccess.c:898 received ID_GET for unit ID 1801/0/0 <000b> trx_if.c:701 phy0.0: Response message 'RSP ERR 1 ' does not match command message 'CMD RFMUTE 1' <000b> trx_if.c:645 phy0.0: transceiver rejected TRX command with response: 'ERR 1' <0001> oml.c:221 (bts=0,trx=0): O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. <000b> trx_if.c:134 phy0.0: Ignoring CLOCK IND 2061832, TRX not yet powered on The last message repeats until i terminate the application. On the OsmoNITB side, i get: <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 72 bytes total with 0 unreported attributes <0005> abis_nm.c:497 BTS0 Get Attributes Response: reported unexpectedly long (3 bytes) feature vector - most likely it was compiled against newer BSC headers. Consider upgrading your BSC to later version. <0005> abis_nm.c:507 BTS0 feature 'Frequency Hopping' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature 'Multi-TSC' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:577 BTS0: failed to parse SW-Config part of Get Attribute Response Info: Invalid argument <0005> abis_nm.c:550 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 34 bytes total with 1 unreported attributes <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:577 BTS0: failed to parse SW-Config part of Get Attribute Response Info: Invalid argument <0005> abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK <0005> abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Locked <0005> abis_nm.c:1938 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK And on the transceiver side, between the successful CLK Indication messages, i get: <0011> trx.c:509 [!] No handlers found for command 'RFMUTE'. Empty response <0011> trx.c:226 TRX Control send: |RSP ERR 1 | Is this issue due to the unimplemented in the transceiver command "RFMUTE" or what really fails is: <0005> abis_nm.c:577 BTS0: failed to parse SW-Config part of Get Attribute Response Info: Invalid argument ? I also tried using components from their circa-2017-2018 revisions but there are so many changes in core Osmocom libraries that they always fail to compile and fixing them is hardly worth it, given the amount of work it is. I know OsmoNITB is abandoned since 2017, but currently this is the only way for a beginner to experiment with BTS based on cheap Calypso phones, as it is not implemented in the new Oscomcom stack.

1 0

SoftSIM XOR-Algorithm
by Sebastian --- 28 Jul '21

28 Jul '21

Hi I would like to emulate a R&S Test-SIM. For that, I need a38 XOR Algorithm. Would this be possible with SoftSIM and Osmocom-BB? How do I put /calculate the Ki in the SIM.xml file? Theres just RAND,SRES,Kc field. Thanks.

1 0

Help on building the OpenBTS / OsmoBTS Transceiver branch
by . 22 Jul '21

22 Jul '21

Hello, I'm trying to build the transceiver branch for Calypso phones. I installed all OsmocomBB dependencies (including libosmocore) and i sucessfully built and installed libosmo-dsp from the Git repo. My ARM toolchain is from here: https://developer.arm.com/tools-and-software/open-source-software/developer… . When building, however, the compiler fails with: arm-none-eabi-ld: comm/libcomm.a(msgb.o):~/trx/src/target/firmware/comm/msgb.c:35: multiple definition of `tall_msgb_ctx'; ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o):(.bss+0x0): first defined here Makefile.inc:135: recipe for target 'board/compal_e88/hello_world.highram.elf' failed I tried both sylvain/testing and jolly/testing branches. What seems to be the problem? Thanks!

2 2

Announcement of "OsmoDevCall" on July 23, 2021
by Harald Welte 22 Jul '21

22 Jul '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at July 23, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "high-level overview on IMS, VoLTE, VoWiFi" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on July 9, 2021
by Harald Welte 09 Jul '21

09 Jul '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at July 9, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 hands-on tutorial by miaoski: Setting up open5gs 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on June 11, 2021
by Harald Welte 08 Jun '21

08 Jun '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at June 11, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by keith: "Screen Sharing peek at TIC A.C. infrastructure in Oaxaca" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call TIC A.C. is an operator of Osmocom based community cellular networks in indigenous communities of the Mexican state of Oaxaca. Keith works with Rhizomatica and TIC A.C. and will give us some live insight into how they operate Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on May 28, 2021
by Harald Welte 27 May '21

27 May '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at May 28, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by fixeria: "Hacking binary protocols with Pycrate" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on May 14, 2021
by Harald Welte 13 May '21

13 May '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at May 14, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by laforge: "SS7 and SIGTRAN in 2G/3G networks" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will cover some classic circuit-switched SS7 basics as well as SIGTRAN (SS7 over IP) and how this is used as underlying transport for a variety of interfaces in the 2G (GSM) and 3G (UMTS) cellular networks even today. Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on April 23, 2021
by Harald Welte 18 Apr '21

18 Apr '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at April 23, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by horiz0n: "YIG & YANG (Yet ANother yiG driver)" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will briefly introduce the working principles of YIG (Yttrium Iron Garnet) microwave circuits, their applications and finally conclude with a presentation of a recently developed driver circuit. Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Announcement of "OsmoDevCall" on April 9, 2021
by Harald Welte 07 Apr '21

07 Apr '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at April 9, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: pySim-shell - the next generation of pySim 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: For more than a decade, pySim-prog has been the tool to configure/program SIM cards in research/lab/private cellular networks. Originally designed for very simplistic GSM-only SIM Cards, it was extended again and again to cover more use cases and parameters. There is a limit as to how far one can go with stuffing everything into command line arguments. In 2021, pySim-shell was created as the next generation tool. It features interactive navigation around the file system, editing capabilities, backup and restore of all [known] files, ... Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Unable to build layer23/src/mobile
by Babar Ali 07 Apr '21

07 Apr '21

Hi I am trying to build osmocombb on Ubuntu 18.04 with GCC-4.9 & arm-elf-gcc-4.5.2, I am getting the following error, how do I fix this issued. Making all in mobilemake[3]: Entering directory '/root/trx/src/host/layer23/src/mobile' CCLD mobilelibmobile.a(gsm322.o): In function `memset':/usr/include/x86_64-linux-gnu/bits/string_fortified.h:67: undefined reference to `__warn_memset_zero_len'collect2: error: ld returned 1 exit statusMakefile:379: recipe for target 'mobile' failedmake[3]: *** [mobile] Error 1make[3]: Leaving directory '/root/trx/src/host/layer23/src/mobile'Makefile:325: recipe for target 'all-recursive' failedmake[2]: *** [all-recursive] Error 1make[2]: Leaving directory '/root/trx/src/host/layer23/src'Makefile:350: recipe for target 'all-recursive' failedmake[1]: *** [all-recursive] Error 1make[1]: Leaving directory '/root/trx/src/host/layer23'Makefile:51: recipe for target 'layer23' failedmake: *** [layer23] Error 2 Regards Babar Ali

1 0

osmocombb make error
by Babar Ali 04 Apr '21

04 Apr '21

Hi all, I am facing problem while compiling osmocombb on Ubuntu 18.04, i have tried libosmocore 0.9.0 / 1.1.0 but no luck, i have also tried to switch between gcc 4.9, 5, 7, all the time i have received same error, any idea to fix this issue, I have attached error log for reference, please. Regards Babar Ali

1 0

Idea for 2021: Regular "OsmoDevCall"
by Harald Welte 25 Mar '21

25 Mar '21

Dear Osmocom community, as the pandemic continues and physical meetings are out of the question for the forseeable future, it would be a good idea to have a periodic virtual online meeting of the interested Osmocom community. I was thinking of a format where we would serve two major purposes: 1) technical talks about osmocom relevant topics - ideally current/recent developments * can be pre-recorded to avoid any problems with technical setup, streaming, ... * should ideally have a Q+A session at their initial "airing" during one OsmoDevCall 2) unstructured solicited social event (USSE) * random chat in audio (optionally video) * not recorded, obviously The recording of the technical presentation should then be permanently made available (like the presentations of our prior OsmoCon / OsmoDevCon). Not every OsmoDevCall would neccessarily need the two parts, but I think it would be great if we can make that happen. We could also have e.g. a two-weekly schedule for the USSE and a monthly schedule for the technical presentation. We'd need somebody to volunteer to "manage" the "broadcast" side of this, preferably somebody with at least some prior exposure to online events (like the c3voc). I'm using https://osmocom.org/issues/4928 to collect a tentative list of topics. Feel free to add your ideas there, as well as any comment/ feedback you may have. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 4

Osmocom Mailing List re-organization
by Harald Welte 03 Mar '21

03 Mar '21

Dear Osmocom community, This topic has been past due for way too many years by now: A re-organization of our major mailing lists. I would like to propose the following changes. Pleas let me know if you have any comments or feedback. I'm aware that renaming will mean people have to update their mail filter rules, but I think we're long past the point where the names of some of our lists started to confuse users. == openbsc(a)lists.osmocom.org == * openbsc doesn't exist anymore since OsmoNITB, which is also obsolete * does already cover anything "Osmocom CNI" related * Proposed new name: osmocom-cni(a)lists.osmocom.org == osmocom-net-gprs(a)lists.osmocom.org == This date back to when GPRS was a highly experimental add-on to our GSM code base. This list should simply be merged with openbsc@ as osmocom-cni(a)lists.osmocom.org == simtrace(a)lists.osmocom.org == Historically was created to cover only the simtrace project. We should rename this to osmocom-simcard(a)lists.osmocom.org or something along those lines. I would like to suggest it covers * SIMtrace / SIMtrace2 hardware + firmware * pySim and related tools for working with SIM/USIM/UICC cards * any other information / discussion related to SIM/USIM/UICC cards, like OTA, ARA-M, ... == osmodevcon(a)lists.osmocom.org == This has been a private list for people attending OsmoDevCon I would like to open up list membership to the general public, and ensure it also covers the new OsmoDevCall. We could then have discussions regarding feedback, topics, scheduling, etc. on that list. Maybe rename it to osmocom-events(a)lists.osmocom.org instead? To differentiate: osmocom-event-orga(a)lists.osmocom.org should remain a private list related to organizational / administrative topics of those involved with organizing future events. == nextepc(a)lists.osmocom.org == Should have been renamed to open5gs(a)lists.osmocom.org quite some time ago, I simply forgot about it. My apologies. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Tonight: OsmocomBBs 11th anniversary party (online, of course)
by Harald Welte 19 Feb '21

19 Feb '21

Dear Osmocom community, today marks the 11th birthday of OsmocomBB, which had originally been announced on February 19, 2010 in the following mailing list post: https://lists.osmocom.org/pipermail/baseband-devel/2010-February/000142.html As we missed to properly celebrate the 10th anniversary, I'd like to use the off-by-one occasion to invite anyone interested to a spontaneous online birthday party tonight. As the original announcement was at 19:02:04 UTC, the online meeting today will also start at 19:02:04 UTC (that's roughly 8pm CET for those of us in the EU) at https://meet.sysmocom.de/OsmocomBB (password: Calypso) I know it's very shot notice, but I still thought it's a good idea, let's see whom of the past or current developers and users will be joining. There's no structure, presentation or anything. Just some USSE (Unstructured Supplementary Social Event). Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

LimeSDR output power during GSM set up
by Mario Lucas 15 Dec '20

15 Dec '20

Dear forum, I am setting / running GSM network with LimeSdr and Osmo-packgaes: osmo-bts-trx osmo-bsc osmo-hlr osmo-msc osmo-pcu osmo-stp osmo-trx-lms and as i understand the only option to vary / set up output power is through the → osmo-bsc → trx 0 nominal power 23 ! to use full TRX power, set max_power_red 0 max_power_red 20 So does this mean that 23-20=3 dbm? With this set up i instruct LimeSDRmini to transmit 3dbm signal into the air? If so — when i brought phone just into the very vicinity of LimeSDR antena (touching phone and SDR antena) on my smartphone screen i got signal -60 dbm …why did i get such a low figure ? Also if you know is there any supporting application / software that can tell at what dBm LimeSDRmini is sending RF into air? -- Mario Lucas

3 2

trx output power config in bts
by Mario Lucas 13 Dec '20

13 Dec '20

Dear team could you pls help me with this question In bts config we have following entries: trx 0 nominal power 23 ! to use full TRX power, set max_power_red 0 max_power_red 20 and osmotrx tx-attenuation (oml|<0-50>) So why do we need these «max_power_red 20» and «osmotrx tx-attenuation» which both as i understand weaken the signal? If we want to have a weak signal why we just don’t use only «nominal power» with whatever weak or strong signal value we want? -- Mario Lucas

2 1

Channel Synchronization Problem with USRP
by Alex Costouris 03 Dec '20

03 Dec '20

Hello, I have built a local GSM network with the Osmocom Stack and an Ettus B200. I can see and attach to the network with my smartphone. Now, i want to use another usrp to simulate a mobile device but i am having trouble with synchronization with the channel. I think the problem lays in the layer 1 control channel or maybe even with the mobile configuration file. It starts camping on the channel, gets sysinfo, ccch mode COMB but then following a FBSB RESP: result=255 i get a channel synch error. Any help in steering me to the right direction would be greatly appreciated. Thank you in advance. mobile configuration file: ! ! OsmocomBB example configuration for mobile application !! ! line vty no login ! gps device /dev/ttyACM0 gps baudrate default no gps enable ! no hide-default ! ms 1 layer2-socket /tmp/osmocom_l2 sap-socket /tmp/osmocom_sap sim sap network-selection-mode auto imei 123456789012345 0 imei-fixed no emergency-imsi no sms-service-center no call-waiting no auto-answer no force-rekey no clip no clir tx-power auto no simulated-delay stick 119 location-updating neighbour-measurement codec full-speed prefer codec half-speed no abbrev support sms a5/1 a5/2 p-gsm no e-gsm no r-gsm no gsm-850 no dcs no pcs class-900 4 class-850 4 class-dcs 1 class-pcs 1 channel-capability sdcch+tchf+tchh full-speech-v1 full-speech-v2 half-speech-v1 min-rxlev -106 dsc-max 90 no skip-max-per-band test-sim imsi 001010000000000 ki comp128 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 no barred-access rplmn 123 01 audio io-handler none no shutdown trxcon logs: 20201203162008375 DL1C NOTICE l1ctl_link.c:236 Init L1CTL link (/tmp/osmocom_l2) 20201203162008375 DTRX NOTICE trx_if.c:675 Init transceiver interface (127.0.0.1:6700) 20201203162008375 DSCH NOTICE sched_trx.c:136 Init scheduler 20201203162008375 DAPP NOTICE trxcon.c:341 Init complete 20201203162016623 DL1C NOTICE l1ctl_link.c:180 L1CTL has a new connection 20201203162016623 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162016623 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162017260 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162017260 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162017260 DL1C NOTICE l1ctl.c:399 Received power measurement request (GSM900: 119 -> 119) 20201203162017261 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162017261 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162017261 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162017261 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162017261 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162017261 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH 20201203162017261 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162017261 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162017261 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162017261 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162017513 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1481847 (42/51) for CCCH …. 20201203162017768 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1481902 (46/51) for CCCH 20201203162017777 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1481907 20201203162017892 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1481929 (22/51) for CCCH …. 20201203162018004 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1481953 (46/51) for CCCH 20201203162018012 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1481958 20201203162018037 DL1C NOTICE l1ctl.c:482 Received CCCH mode request (2) 20201203162018037 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162018037 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162018037 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018037 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162018037 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162018037 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018037 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162018037 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162018037 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162018498 DL1C NOTICE l1ctl.c:307 FBSB timer fired for ARFCN 119 20201203162018498 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162018498 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018498 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162018498 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162018498 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018498 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162018498 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162018498 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162018498 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162018498 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162018498 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162018520 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1481964 (6/102) for CCCH …. 20201203162018806 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482025 (67/102) for CCCH 20201203162018949 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1482060 20201203162018960 DL1C NOTICE l1ctl.c:307 FBSB timer fired for ARFCN 119 20201203162018960 DL1C NOTICE l1ctl.c:694 Received L1CTL_DM_REL_REQ, switching back to CCCH 20201203162018960 DSCH NOTICE sched_trx.c:177 Reset scheduler 20201203162018960 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162018960 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162018960 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018961 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162018961 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018961 DL1C NOTICE l1ctl.c:399 Received power measurement request (GSM900: 119 -> 119) 20201203162018963 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162018963 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018963 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162018963 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162018963 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162018963 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH 20201203162018963 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162018963 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162018963 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162018964 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162019070 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482184 (22/51) for CCCH …. 20201203162019890 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482361 (46/51) for CCCH 20201203162019898 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1482366 20201203162019920 DL1C NOTICE l1ctl.c:482 Received CCCH mode request (2) 20201203162019920 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162019920 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162019920 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162019920 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162019920 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162019920 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162019920 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162019920 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162019920 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162019920 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162019920 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162019920 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162019920 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162019920 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162019921 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162019921 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162020382 DL1C NOTICE l1ctl.c:307 FBSB timer fired for ARFCN 119 20201203162020382 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162020382 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162020382 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162020382 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162020382 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162020382 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162020382 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162020382 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162020382 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162020382 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162020382 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162020405 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482372 (6/102) for CCCH …. 20201203162020687 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482433 (67/102) for CCCH 20201203162020834 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1482468 20201203162020844 DL1C NOTICE l1ctl.c:307 FBSB timer fired for ARFCN 119 20201203162020844 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162020844 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162020844 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162020844 DL1C NOTICE l1ctl.c:399 Received power measurement request (GSM900: 119 -> 119) 20201203162020846 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162020846 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162020846 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162020846 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162020846 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162020846 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH 20201203162020846 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162020846 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162020846 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162020846 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162020953 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482592 (22/51) for CCCH …. 20201203162021298 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482667 (46/51) for CCCH 20201203162021307 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1482672 20201203162021424 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482694 (22/51) for CCCH …. 20201203162021533 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482718 (46/51) for CCCH 20201203162021543 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1482723 20201203162021660 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482745 (22/51) for CCCH …. 20201203162021770 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482769 (46/51) for CCCH 20201203162021779 DSCH NOTICE sched_clck.c:136 Clock indication: fn=1482774 20201203162021803 DL1C NOTICE l1ctl.c:482 Received CCCH mode request (2) 20201203162021803 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162021803 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162021803 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162021803 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162021803 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162021803 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162021803 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162021803 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162021803 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162022265 DL1C NOTICE l1ctl.c:307 FBSB timer fired for ARFCN 119 20201203162022265 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162022265 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162022265 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162022265 DL1C NOTICE l1ctl.c:342 Received FBSB request (GSM900 119) 20201203162022265 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162022265 DSCH NOTICE sched_trx.c:199 Add a new TDMA timeslot #0 20201203162022265 DSCH NOTICE sched_trx.c:274 (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 20201203162022265 DSCH NOTICE sched_trx.c:431 Activating lchan=SCH on ts=0 20201203162022265 DSCH NOTICE sched_trx.c:431 Activating lchan=BCCH on ts=0 20201203162022265 DSCH NOTICE sched_trx.c:431 Activating lchan=RACH on ts=0 20201203162022265 DSCH NOTICE sched_trx.c:431 Activating lchan=CCCH on ts=0 20201203162022309 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482786 (12/102) for CCCH …. 20201203162022518 DSCHD ERROR sched_lchan_xcch.c:102 Received bad data frame at fn=1482831 (57/102) for CCCH 20201203162022523 DL1C NOTICE l1ctl.c:426 Received reset request (1) 20201203162022523 DSCH NOTICE sched_trx.c:177 Reset scheduler and clock counter 20201203162022523 DSCH NOTICE sched_trx.c:223 Delete TDMA timeslot #0 20201203162022523 DL1D NOTICE l1ctl_link.c:81 L1CTL has lost connection …. mobile application logs: 000e> gsm322.c:1380 Start search of last registered PLMN (mcc=123 mnc=01 One, Two) <0002> gsm322.c:1384 Use RPLMN (mcc=123 mnc=01 One, Two) <0002> gsm322.c:810 new state 'A0 null' -> 'A1 trying RPLMN' <0003> gsm322.c:4060 (ms 1) Event 'EVENT_NEW_PLMN' for Cell selection in state 'C0 null' <000e> gsm322.c:3642 Selecting PLMN (mcc=123 mnc=01 One, Two) <0003> gsm322.c:3650 Start stored cell selection. <0003> gsm322.c:833 new state 'C0 null' -> 'C2 stored cell selection' <0003> gsm322.c:2793 Scanning power for sticked cell. <0003> gsm322.c:2868 Scanning frequencies. (119..119) <0003> gsm322.c:2916 Found signal (ARFCN 119 rxlev -55 (55)) <0003> gsm322.c:2933 Done with power scanning range. <0003> gsm322.c:2793 Scanning power for sticked cell. <0003> gsm322.c:2845 Found 1 frequencies. <0003> gsm322.c:2258 Scanning frequency 119 (rxlev -55). <0003> gsm322.c:477 Sync to ARFCN=119 rxlev=-55 (No sysinfo yet, ccch mode NONE) <0003> gsm322.c:2278 30 frequencies left in band 955..124 <000c> l1ctl.c:300 Dropping frame with 55 bit errors …. <000c> l1ctl.c:300 Dropping frame with 55 bit errors <0003> gsm322.c:2956 Channel synched. (ARFCN=119, snr=0, BSIC=63) <0003> gsm322.c:703 Starting CS timer with 4 seconds. <0001> gsm322.c:2979 using DSC of 90 <0003> gsm48_rr.c:4822 Channel provides data. <0003> gsm322.c:703 Starting CS timer with 4 seconds. <0001> gsm48_rr.c:1816 New SYSTEM INFORMATION 2 <000c> l1ctl.c:300 Dropping frame with 55 bit errors …. <000c> l1ctl.c:300 Dropping frame with 55 bit errors <0001> sysinfo.c:703 New SYSTEM INFORMATION 3 (mcc 123 mnc 01 lac 0x007c) <0001> gsm48_rr.c:1907 Changing CCCH_MODE to 2 <0001> gsm48_rr.c:1939 New SYSTEM INFORMATION 4 (mcc 123 mnc 01 lac 0x007c) <0001> sysinfo.c:615 Now updating previously received SYSTEM INFORMATION 4 <0001> gsm48_rr.c:1787 New SYSTEM INFORMATION 1 <0003> gsm322.c:2721 Received relevant sysinfo. <0003> gsm322.c:713 stopping pending CS timer. <0003> gsm322.c:2327 Scan frequency 119: Cell found. (rxlev -55 mcc 123 mnc 01 lac 007c) <0003> gsm322.c:1841 Select using access class <0003> gsm322.c:383 A (RLA_C (-55) - RXLEV_ACC_MIN (-110)) = 55 <0003> gsm322.c:385 B (MS_TXPWR_MAX_CCH (35) - p (33)) = 2 <0003> gsm322.c:387 C1 (A - MAX(B,0)) = 53 <0003> gsm322.c:1955 Cell ARFCN 119: Cell found, (rxlev=-55 mcc=123 mnc=01 lac=007c One, Two) <0003> gsm322.c:1970 Cell ARFCN 119 selected. <0003> gsm322.c:2428 Tune to frequency 119. <0003> gsm322.c:464 Sync to ARFCN=119 rxlev=-55 (Sysinfo, ccch mode COMB) <0003> gsm322.c:2455 Cell available. <0003> gsm322.c:4060 (ms 1) Event 'EVENT_CELL_FOUND' for Cell selection in state 'C2 stored cell selection' <000e> gsm322.c:3392 Camping normally on cell (ARFCN=119 mcc=123 mnc=01 One, Two) <0003> gsm322.c:833 new state 'C2 stored cell selection' -> 'C3 camped normally' <0005> gsm48_mm.c:4305 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event in state MM IDLE, PLMN search <0005> gsm48_mm.c:904 new MM IDLE state PLMN search -> location updating needed <0005> gsm48_mm.c:904 new MM IDLE state location updating needed -> attempting to update <0005> gsm48_mm.c:424 starting T3212 (periodic loc. upd. delay) with 1800 seconds <0005> gsm48_mm.c:2285 Do Loc. upd. for IMSI attach. <000e> gsm48_mm.c:2204 Perform location update (MCC 123, MNC 01 LAC 0x007c) <0005> gsm48_mm.c:2340 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2360 using LAI (mcc 123 mnc 01 lac 0x007c) <0005> gsm48_mm.c:2370 using TMSI 0x9d4f59da <0005> gsm48_mm.c:909 new state MM IDLE, attempting to update -> wait for RR connection (location updating) <0001> gsm48_rr.c:5449 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1299 Establish radio link due to mobility management request <0003> gsm322.c:4060 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:833 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3677 Going to camping (normal) ARFCN 119. <0003> gsm322.c:456 Sync to ARFCN=119, but there is a sync already pending <0001> gsm48_rr.c:359 new state idle -> connection pending <0001> gsm48_rr.c:1446 CHANNEL REQUEST: 00 (Location Update with NECI) <000c> l1ctl.c:169 FBSB RESP: result=255 <0003> gsm322.c:3001 Channel sync error, try again <0003> gsm322.c:464 Sync to ARFCN=119 rxlev=-55 (Sysinfo, ccch mode COMB) <000c> l1ctl.c:300 Dropping frame with 60 bit errors …. <000c> l1ctl.c:300 Dropping frame with 61 bit errors <0001> gsm48_rr.c:667 MON: f=119 lev=>=-47 snr= 0 ber= 61 LAI=123 01 007c ID=1e61 <000c> l1ctl.c:169 FBSB RESP: result=255 <0003> gsm322.c:3014 Channel sync error. <0003> gsm322.c:3018 free sysinfo ARFCN=119 <0003> gsm322.c:3027 Unselect cell due to sync error! <0003> gsm322.c:509 Unselecting serving cell. <0003> gsm322.c:3111 Loss of SACCH, Trigger RR abort. <000e> gsm48_rr.c:2879 Radio link lost signal <0001> gsm48_rr.c:2886 LOS during RACH request <0001> gsm48_rr.c:359 new state connection pending -> idle <0003> gsm322.c:4060 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'connected mode 1' <0003> gsm322.c:3581 Cell not selected anymore, choose cell! <0003> gsm322.c:833 new state 'connected mode 1' -> 'C5 choose cell' <0003> gsm322.c:3523 No BA range(s), try sysinfo. <0003> gsm322.c:2480 No BA, because no sysinfo <0003> gsm322.c:3527 No BA on sysinfo, try stored BA list. <0003> gsm322.c:3537 No BA list to use. <0003> gsm322.c:4060 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection in state 'C5 choose cell' <0003> gsm322.c:833 new state 'C5 choose cell' -> 'C1 normal cell selection' <0003> gsm322.c:2793 Scanning power for sticked cell. <0003> gsm322.c:2868 Scanning frequencies. (119..119) <0005> gsm48_mm.c:3902 (ms 1) Received 'RR_REL_IND' from RR in state wait for RR connection (location updating) (sapi 0) <0005> gsm48_mm.c:2739 RR link released after loc. upd. <000e> gsm48_mm.c:2683 Location update failed <000e> gsm48_mm.c:2693 Try location update later <0005> gsm48_mm.c:2694 Loc. upd. failed, retry #0 <0005> gsm48_mm.c:411 starting T3211 (loc. upd. retry delay) with 15.0 seconds <0005> gsm48_mm.c:1086 Not camping, wait for CS process to camp, it sends us CELL_SELECTED then. <0003> gsm322.c:2916 Found signal (ARFCN 119 rxlev -55 (55)) <0003> gsm322.c:2933 Done with power scanning range. <0003> gsm322.c:2793 Scanning power for sticked cell. <0003> gsm322.c:2845 Found 1 frequencies. <0003> gsm322.c:2258 Scanning frequency 119 (rxlev -55). <0003> gsm322.c:477 Sync to ARFCN=119 rxlev=-55 (No sysinfo yet, ccch mode NONE) <0003> gsm322.c:2278 30 frequencies left in band 955..124 <0003> gsm322.c:2956 Channel synched. (ARFCN=119, snr=0, BSIC=63) <0003> gsm322.c:703 Starting CS timer with 4 seconds. <0001> gsm322.c:2979 using DSC of 90 <000c> l1ctl.c:300 Dropping frame with 55 bit errors …. <000c> l1ctl.c:300 Dropping frame with 55 bit errors <0003> gsm48_rr.c:4822 Channel provides data. <0003> gsm322.c:703 Starting CS timer with 4 seconds. <0001> gsm48_rr.c:1816 New SYSTEM INFORMATION 2 <000c> l1ctl.c:300 Dropping frame with 55 bit errors …. <000c> l1ctl.c:300 Dropping frame with 55 bit errors <0001> sysinfo.c:703 New SYSTEM INFORMATION 3 (mcc 123 mnc 01 lac 0x007c) <0001> gsm48_rr.c:1907 Changing CCCH_MODE to 2 <0001> gsm48_rr.c:1939 New SYSTEM INFORMATION 4 (mcc 123 mnc 01 lac 0x007c) <0001> sysinfo.c:615 Now updating previously received SYSTEM INFORMATION 4 <0001> gsm48_rr.c:1787 New SYSTEM INFORMATION 1 <0003> gsm322.c:2721 Received relevant sysinfo. <0003> gsm322.c:713 stopping pending CS timer. <0003> gsm322.c:2327 Scan frequency 119: Cell found. (rxlev -55 mcc 123 mnc 01 lac 007c) <0003> gsm322.c:1841 Select using access class <0003> gsm322.c:383 A (RLA_C (-55) - RXLEV_ACC_MIN (-110)) = 55 <0003> gsm322.c:385 B (MS_TXPWR_MAX_CCH (35) - p (33)) = 2 <0003> gsm322.c:387 C1 (A - MAX(B,0)) = 53 <0003> gsm322.c:1955 Cell ARFCN 119: Cell found, (rxlev=-55 mcc=123 mnc=01 lac=007c One, Two) <0003> gsm322.c:1970 Cell ARFCN 119 selected. <0003> gsm322.c:2428 Tune to frequency 119. <0003> gsm322.c:464 Sync to ARFCN=119 rxlev=-55 (Sysinfo, ccch mode COMB) <0003> gsm322.c:2455 Cell available. <0003> gsm322.c:4060 (ms 1) Event 'EVENT_CELL_FOUND' for Cell selection in state 'C1 normal cell selection' <000e> gsm322.c:3392 Camping normally on cell (ARFCN=119 mcc=123 mnc=01 One, Two) <0003> gsm322.c:833 new state 'C1 normal cell selection' -> 'C3 camped normally' <0005> gsm48_mm.c:4310 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event in state wait for RR connection (location updating) <0005> gsm48_mm.c:1141 We are camping normally as returning to MM IDLE <0005> gsm48_mm.c:1166 Loc. upd. allowed. <0005> gsm48_mm.c:914 new state wait for RR connection (location updating) -> MM IDLE, location updating needed <0005> gsm48_mm.c:904 new MM IDLE state location updating needed -> attempting to update <0005> gsm48_mm.c:2222 Loc. upd. already pending. <000c> l1ctl.c:169 FBSB RESP: result=255 <0003> gsm322.c:3001 Channel sync error, try again <0003> gsm322.c:464 Sync to ARFCN=119 rxlev=-55 (Sysinfo, ccch mode COMB) <000c> l1ctl.c:300 Dropping frame with 60 bit errors …. <000c> l1ctl.c:300 Dropping frame with 60 bit errors <000c> l1ctl.c:169 FBSB RESP: result=255 <0003> gsm322.c:3014 Channel sync error. <0003> gsm322.c:3018 free sysinfo ARFCN=119 <0003> gsm322.c:3027 Unselect cell due to sync error!

1 0

"Bad signalling message, sign_link returned error: Operation not permitted" - during voice call
by Mario Lucas 03 Dec '20

03 Dec '20

Dear team, I did set up GSM network with SDR (LimeSDRmini). SMS are ok. However when try to make voice call got following message on osmo-bsc terminal: <0003> abis_rsl.c:1372 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x41, neci=0x01, chreq_reason=0x02) <0007> osmo_bsc_sigtran.c:305 Initializing resources for new SIGTRAN connection to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP... <0007> osmo_bsc_sigtran.c:351 Opening new SIGTRAN connection (id=31) to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0003> abis_rsl.c:1372 (bts=0) CHAN RQD: reason: answer to paging (ra=0x9b, neci=0x01, chreq_reason=0x01) <0007> osmo_bsc_sigtran.c:305 Initializing resources for new SIGTRAN connection to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP... <0007> osmo_bsc_sigtran.c:351 Opening new SIGTRAN connection (id=32) to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0004> abis_nm.c:344 BTS 0 reported connected PCU version 0.8.0 <0016> input/ipaccess.c:411 Bad signalling message, sign_link returned error: Operation not permitted. <0016> input/ipaccess.c:411 Bad signalling message, sign_link returned error: Operation not permitted. WHat is this bad signalling message operation not permitted? -- Mario Lucas

2 1

Osmocom C files syntax understanding
by Mario Lucas 25 Nov '20

25 Nov '20

Dear baseband-developers team, Would you be so kind to advise me on the following: I desire (dramatically want very much) to learn / understand Osmocom projects. I am a beginner in programming and i try to understand / learn C files that the project is build of. As an example i tried to learn / understand for example an Osmocom message buffer — msgb.h file. But immediately faced some syntax difficulties: This is the extract of msgb.h file: struct msgb { struct llist_head list; /*!< \brief linked list header */ /* Part of which TRX logical channel we were received / transmitted */ /* FIXME: move them into the control buffer */ union { void *dst; /*!< \brief reference of origin/destination */ struct gsm_bts_trx *trx; }; As it can be seen a structure «msgb» has as one of its components another structure — «gsm_bts_trx» But in whole Osmocom BB project files i could not find definition / description of struct «gsm_bts_trx». Would you kindly advise me please how to see which components / constituents / elements are in this gsm_bts_trx structure? From which components is struct gsm_bts_trx build of? Thank you so much for your kind advise. -- Mario Lucas

4 4

Dropped packets by HW.... Dumping Stale bursts
by Mario Lucas 25 Nov '20

25 Nov '20

Dear all, I am using LimeSDRmini to run osmo-bts… During operation from time-to time (and sometimes quite frequently) following messages pop-up in terminal: «Dropped packets by HW!» and «Dumping Stale bursts...» I guess my LimeSDRmini is dropping some packets. LimeSDRmini configuration is: Firmware 6, Hardware 3, Protocol1, Gateware 1.3. Would you advise — may be there is more or less stable firmware version that to some extent is stable while working with Osmo-bts ? Thanks -- Mario Lucas

1 0

PCU socket not connected, dropping message
by Mario Lucas 23 Nov '20

23 Nov '20

Dear baseband developers team, I built home gsm network with Osmo-stp-msc-hlr-bsc-bts, osmo-trx limeSDR. I managed and registered phones. I did send sms between each other. However when i decided to make a call — i noticed following message in terminal: «PCU socket not connected, dropping message». I searched on Osmocom web site and it is said that pcu socket is involved in GPRS things (i.e. in internet). Therefore why does such message appears when i try to make simple call between two mobiles — it has nothing to do with GPRS… And what would you advise me how to resolve this ? P.S. initially when i was about to start osmo-bts-trx i got message «PCU L1 socket failed» and i just renamed the pcu_bts file to some other name and osmo-bts-trx started. Thank you so much for your kind reply. Best regards -- Mario Lucas

2 1

fixeria trx.highram.bin stuck
by Mario Lucas 11 Nov '20

11 Nov '20

Dear all, Pls help me with the following issue: I want to run a transceiver having motorola c115… i follow the procedure described in CalypsoBTS page : http://osmocom.org/projects/baseband/wiki/CalypsoBTS without chainloader i get: /home/ubuntu# /home/ubuntu/trx/src/host/osmocon/./osmocon -m c123xor -p /dev/ttyUSB0 /home/ubuntu/trx/src/target/firmware/board/compal_e88/trx.highram.bin got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c ftmtool Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: c1 . got 1 bytes from modem, data looks like: 66 f and with chainloader i get: /home/ubuntu# /home/ubuntu/trx/src/host/osmocon/./osmocon -m c123xor -p /dev/ttyUSB0 -c /home/ubuntu/trx/src/target/firmware/board/compal_e88/trx.highram.bin got 2 bytes from modem, data looks like: 04 81 .. got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(chainloader): file_size=32, hdr_len=4, dnload_len=39 got 1 bytes from modem, data looks like: 00 . it seems with chainloader it is trying to do more but still stuck…. pls help…. Mario -- Mario Lucas

1 0

OsmoDevCon / COVID-19
by Harald Welte 04 Sep '20

04 Sep '20

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Osmocom scheduled outage on *2020-07-19 9am CEST*
by Harald Welte 19 Jul '20

19 Jul '20

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

OsmocomBB
by Антон Левченко 01 May '20

01 May '20

Hello! During build OsmocomBB I have problem. When I do "make", I get errors: *** No rule to make target `geo.c', needed by `geo.o'. Stop. vgsm@vgsm:~/osmocom/osmocombb/src$ make nofirmware make -C host/layer23 make[1]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23' Making all in include make[2]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include' Making all in osmocom make[3]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom' Making all in bb make[4]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb' Making all in common make[5]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/common' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/common' Making all in misc make[5]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/misc' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/misc' Making all in mobile make[5]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/mobile' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb/mobile' make[5]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb' make[4]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom/bb' make[4]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom' make[3]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include/osmocom' make[3]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include' make[2]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/include' Making all in src make[2]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/src' Making all in common make[3]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/src/common' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/src/common' Making all in misc make[3]: Entering directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/src/misc' make[3]: *** No rule to make target `geo.c', needed by `geo.o'. Stop. make[3]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/src/misc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/vgsm/osmocom/osmocombb/src/host/layer23' make: *** [layer23] Error 2 vgsm@vgsm:~/osmocom/osmocombb/src$

2 1

Osmocom GTM-900B carrier board
by Harald Welte 28 Apr '20

28 Apr '20

Hi all! It is quite some time since it was brought to our attention that there's an old Huawei module that also uses the Ti Calypso chipset and hence can be used with OsmocomBB: The GTM-900B. It's just a modem module with a FPC connector, so no easy to use interfaces for any of the related signals, no SIM holder, etc. At sysmocom we've finally found some time to do a carrier board design for this, which will expose all the relevant signals (audio, UARTs, power, reset, ...). Martin (Cc) is working on it right now. The discussion regarding this breakout board can be followed at https://osmocom.org/issues/4030 If you have any input, please provide it now, as we are trying to complete this design by the end of the week so we can order prottoypes. The actual design files (EAGLE) including a PDF export of the schematics can be found in the osmo-small-hardware.git repository. Thanks for your input. Once the prototype is validated, we plan to make the boards (bundled with GTM900B) available in the sysmocom webshop. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

newer NOkia 3310
by sagar gadgil 08 Jan '20

08 Jan '20

will it work with oscombb? or vintage model only?

1 0

add 2 mobiles in osmocomBB
by MG - SMS ARSIA 13 Dec '19

13 Dec '19

Hello all, I would like to add two (fake) mobiles by using the osmocomBB platform. Can you help by indicating how or web pages where I can find useful information. Actually I follow these instructions found here : https://osmocom.org/projects/baseband/wiki/FakeTRX Thanks, BR MaGo

2 4

OsmoDevCon 2020 registration
by Harald Welte 01 Dec '19

01 Dec '19

Dear fellow Osmocom developers, I would like to invite all developers and contributors to Osmocom [sub]projects to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin). For details known so far, please check http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2020. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Calypso BTS
by phreaker1983 16 Nov '19

16 Nov '19

I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc, libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg , then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l ~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005> bsc_init.c:498 Failed to parse the config file: '/root/.osmocom/open-bsc.cfg' file tried to create as administrator but without success , pleas help me -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html Sent from the baseband-devel mailing list archive at Nabble.com.

6 13

None
by Dimoon 29 Oct '19

29 Oct '19

Hi! I install the project according to the instructions https://habr.com/en/company/pentestit/blog/331406/ A few months ago, the installation was successful, but this month an error related to osmo_sock_init2_multiaddr () occurs when building libosmo-netif. The file "libosmo-netif / TODO-RELEASE" contains information: "libosmo-netif stream osmo_sock_init2_multiaddr () is used, requires libosmocore> 1.2.0 (to be released)." At the same time, the existing version of libosmocore is only 1.2.0 How to set up a project? I tried using diff to return libosmo-netif to version 0.5.0.2-6563-dirty as described in http://git.osmocom.org/libosmo-netif/commit/?id=592057bb33dc0c336a63003cd7a… but had no success. -- Dimoon

1 0

OsmocomBB SDR PHY
by Fitsum J 16 Oct '19

16 Oct '19

I am installing OsmocomBB SDR PHY on ubunt 18.04 and i have installedosmo-TRX, UHD Driver, Gr-gsm and Gnuradio from ubuntu package manager. but when i try to compile osmocomBB with TRX interface i got this problem: on make cd host/layer23 && autoreconf -i /bin/sh: 1: autoreconf: not found Makefile:91: recipe for target 'host/layer23/configure' failed make: *** [host/layer23/configure] Error 127 Thank you for your time!!!1

3 3

Osmocom Village at CCC Camp 2019
by Harald Welte 29 Jul '19

29 Jul '19

Dear all, I've been asked by a number of pepole about a possible Osmocom village at the CCC Camp 2019. I personally didn't really have any plans, but given related e-mails and "encouragement" I went ahead and registered an "Osmocom Village", see https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3 I also created a wiki page (as nobody else did, despite earlier discussion on IRC, SCNR) for coordinating related efforts at https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019 One of the bigger questions is about having a tent as well as some tables/benches to sit on and work. The Camp orga team nas been negotiating rates with a tent rental company, but to be honest I'm rather surprised by the extremely steep pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not sure we want to raise that amount of money? Even if we'd be 10 people sharing it, its still 82.50 EUR per person. And that excludes any tables/chairs. I'm attaching the relevant parts of a mail from the assemblies orga team FYI. Please note there also is some kind of fragmentation / overlap with the team planning to run the GSM/3G networks at the camp, see Lynxis' related post at https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003… It's questionable whether it makes sense to have tow distinct 'villages', but given that e.g. I don't know anyone of that singularity city, I'm not sure if we'd either be welcome there, nor whether we'd want to associate us with them? Also, while the GSM network operation for sure has good reasons to mingle with the POC and whatever facilities they have, I'm not sure if the wider Osmocom community attendees unrelated to the GSM network operation wouldn't just be a disturbance/nuisance. In the end, to be honest, I personally do not feel I have the time and mental capacity to take on any additional tasks in terms of organizing anything. I just created the entry in c3assemblies as I was asked to, and I similarly created the related mailing list and wiki page. So please, anyone interested in making an Osmocom village happen one way or another, step up [and continue this discussion on the camp2019-village(a)lists.osmocom.org mailing list, without crossposting everywhere else :) 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)

2 2

GTM-900B for OsmocomBB developers
by Harald Welte 06 Jun '19

06 Jun '19

Hi all! sysmocom has obtained a first batch of 10 GTM-900B with some FPC-to-2.54mm-breakout adapters from songbosi. They have just arrived yesterday in Berlin. I'm happy to make them available for free to [known/existing] Osmocom develoepers/contributors. Let me know if you're interestd and we'll send you an envenlope, likely mid next week due to the upcoming extended whitsunday weekend. 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

hand-over in L1CTL / trxcon
by Harald Welte 04 Jun '19

04 Jun '19

Hi Vadim, I'm currently facing the problem of testing hand-over related channel-activation in OsmoBTS. Three are various rules about how this has to be done, and a closer look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that right at all. I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL to control a (virtual or real) L1 for the MS side of testing the BTS. To break this down to low-level requirements in terms of MS capabilities: * switch to a different ARFCN * switch to a speciifed timeslot * change the synchroniztaion (in terms of where we currently are in the TDMA multiplex) to a given neighbor cell. The MS will have performed neighbor measurements before, and as part of that will hav received FCCH + SCH and hence know the timing both in terms of carrier freq as well as TDMA position [none of this is relevant for a fake_trx + trxcon setup] * ability to enable only the receiver for the main channel (SDCCH/FACCH), but suppress any reception (or passing up of received) SACCH. * ability to transmit RACH burst[s] in uplink on that new dedicated channel * ability to later on enable full Rx/Tx of all logical channels on that dedicated channel I've looked at the jolly/handover branch from 2013, and rebased that on top of current master, the result can be seen in laforge/jolly_handover_rebase Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags to DM_EST_REQ to * disable uplink transmission * use the sync information of a neighbor cell I would like to get at least that change to L1CTL merged to master, and while doing that, update all implementations of L1CTL at the same time. It may make sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while at it, which is required for neighbor channel measurements + reporting. We should also use that opportunity to introduce some kind of versioning support to L1CTL, to ensure future extensions of the protocol can be made in a way where incompatibility can at least be detected at runtime. Now the next question is how to this will impact trxcon/fake_trx. AFAICT, there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ would fail if there was already and established channel before. Is that correct? If so, what is the suggested/recommended way to get trxcon to support at least the minimum of what's required for handover in a virtual environment? 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)

2 5

Perfect module (D751749ZHH)
by songbosi 29 May '19

29 May '19

Hello every one: I am making a FAKE BTS defender(DOS of fake bts) since Jul 2017. This product is used to detect and attack the fake GSM station(running openbts). I use c118 at first and it work fine. But c118 is not a good idea for production. I have disassembled many old GPRS modules , at last I found this module is perfect(D751749ZHH). Now I have 500 pcs left This module have TCK/TMS/TDO/TDI ，I make a custom OsmocomBB firmware , only need modify some IO control for RF switch, there are some picture to share with you. OsmocomBB is running on an ARM board You can mail me 79543015(a)qq.com , if you are interested in this :P

2 3

OSMO-nitb problem
by Bilguun Tugs 28 May '19

28 May '19

Hi im doing this article. https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-… But this error comes at shell #4 root@kali:~# osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -m -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM There is no such command. Error occurred during reading the below line: timer t3103 0 <0005> bsc_init.c:551 Failed to parse the config file: '/root/.osmocom/open-bsc.cfg' Reading config failed. Exiting. What should i fix it ?

2 1

Osmo-bts-trx command error
by Bilguun Tugs 28 May '19

28 May '19

How to do this command. Im following this article. https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-… root@kali:~# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg -r 99 ((*)) | / \ OsmoBTS There is no such command. Error occurred during reading the below line: band GSM900 Failed to parse the config file: '/root/.osmocom/osmo-bts.cfg' *What should I do?*

2 2

Layer23- transceiver make command error
by Bilguun Tugs 22 May '19

22 May '19

Im following this article. These errors given. I wanna do this command. https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-… *Shell #3* # cd trx/src/host/layer23/src/transceiver/ # sudo ./transceiver -a [YOUR ARFCN FOUND WITH RSSI] -2 -r 99 This command doesnt work in trx folder. (kali 18.1) rot@kali:~/trx/src/host/layer23/src/transceiver# make CCLD transceiver /usr/bin/ld: gmsk.o: in function `osmo_gmsk_free': /root/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:85: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:87: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse': /root/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:123: undefined reference to `expf' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_rotation_tables': /root/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:146: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse': /root/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference to `sqrtf' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_modulate_burst': /root/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:227: undefined reference to `osmo_cxvec_convolve' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:230: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_generate': /root/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference to `osmo_cxvec_correlate' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:260: undefined reference to `osmo_cxvec_peak_energy_find' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:265: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:272: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_free': /root/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gsm_ab.o: in function `gsm_ab_detect': /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference to `osmo_cxvec_correlate' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: undefined reference to `osmo_cxvec_peak_energy_find' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gsm_ab.o: in function `gsm_ab_demodulate': /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference to `osmo_cxvec_scale' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: undefined reference to `osmo_cxvec_delay' /usr/bin/ld: demod.o: in function `gsm_ab_ind_process': /root/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:62: undefined reference to `osmo_cxvec_sig_normalize' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:70: undefined reference to `cabsf' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:76: undefined reference to `cabsf' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:101: undefined reference to `osmo_cxvec_free' collect2: error: ld returned 1 exit status make: *** [Makefile:360: transceiver] Error 1 How to build transceiver file ?

3 3

Trx Make error
by Bilguun Tugs 20 May '19

20 May '19

*root@bilguun-shady:~/Desktop/trx/src# make HOST_layer23_CONFARGS=--enable-transceiver* There is another problem on building trx. Im doing this article step by step. In this command there comes into that error. make[3]: Entering directory '/home/bilguun/Desktop/trx/src/host/layer23/src/mobile' CC gsm322.o gsm322.c: In function ‘gsm322_cs_select’: gsm322.c:1865:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] band = gsm_arfcn2band(index2arfcn(i)); ^ gsm322.c: In function ‘gsm322_search_end’: gsm322.c:2055:30: warning: variable ‘mnc’ set but not used [-Wunused-but-set-variable] int tune_back = 0, mcc = 0, mnc = 0; ^ gsm322.c: In function ‘gsm322_nb_check’: gsm322.c:4196:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] band = gsm_arfcn2band(nb->arfcn); ^ gsm322.c: In function ‘gsm322_nb_new_rxlev’: gsm322.c:4693:2: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] int band = gsm_arfcn2band(cs->arfcn); ^ gsm322.c: In function ‘gsm322_exit’: gsm322.c:5142:7: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] int rc; ^ In file included from /usr/include/string.h:635:0, from gsm322.c:25: In function ‘memset’, inlined from ‘bargraph.constprop’ at gsm322.c:325:2: /usr/include/i386-linux-gnu/bits/string3.h:86:7: warning: call to ‘__warn_memset_zero_len’ declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters __warn_memset_zero_len (); ^ CC gsm480_ss.o gsm480_ss.c: In function ‘gsm480_tx_ussd’: gsm480_ss.c:535:2: warning: ‘gsm_7bit_encode’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:242): Use gsm_7bit_encode_n() instead [-Wdeprecated-declarations] length = gsm_7bit_encode(msg->data, text); ^ gsm480_ss.c: In function ‘gsm480_rx_ussd’: gsm480_ss.c:779:2: warning: ‘gsm_7bit_decode’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n() instead [-Wdeprecated-declarations] gsm_7bit_decode(text, tag_data, num_chars); ^ gsm480_ss.c: In function ‘gsm480_mmss_ind’: gsm480_ss.c:1221:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] int rc = 0; ^ CC gsm411_sms.o gsm411_sms.c: In function ‘sms_from_text’: gsm411_sms.c:116:2: warning: ‘gsm_7bit_encode’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:242): Use gsm_7bit_encode_n() instead [-Wdeprecated-declarations] sms->user_data_len = gsm_7bit_encode(sms->user_data, sms->text); ^ gsm411_sms.c: In function ‘gsm340_rx_tpdu’: gsm411_sms.c:285:4: warning: ‘gsm_7bit_decode’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n() instead [-Wdeprecated-declarations] gsm_7bit_decode(gsms->text, smsp, gsms->user_data_len); ^ gsm411_sms.c:228:19: warning: variable ‘sms_mms’ set but not used [-Wunused-but-set-variable] uint8_t sms_mti, sms_mms; ^ gsm411_sms.c: In function ‘gsm411_rx_rp_ud’: gsm411_sms.c:375:2: warning: format ‘%li’ expects argument of type ‘long int’, but argument 7 has type ‘int’ [-Wformat=] LOGP(DLSMS, LOGL_INFO, "TPDU(%li,%s)\n", msg->tail-msg->l4h, ^ gsm411_sms.c:375:2: warning: format ‘%li’ expects argument of type ‘long int’, but argument 7 has type ‘int’ [-Wformat=] CC gsm48_cc.o CC gsm48_mm.o gsm48_mm.c: In function ‘decode_network_name’: gsm48_mm.c:269:2: warning: ‘gsm_7bit_decode’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n() instead [-Wdeprecated-declarations] gsm_7bit_decode(name, lv + 2, length); ^ gsm48_mm.c: In function ‘gsm48_mmr_dequeue’: gsm48_mm.c:780:20: warning: variable ‘mmr’ set but not used [-Wunused-but-set-variable] struct gsm48_mmr *mmr; ^ gsm48_mm.c: In function ‘gsm48_mm_conn_go_dedic’: gsm48_mm.c:3252:25: warning: variable ‘nmmh’ set but not used [-Wunused-but-set-variable] struct gsm48_mmxx_hdr *nmmh; ^ gsm48_mm.c: In function ‘gsm48_mm_sync_ind_active’: gsm48_mm.c:3333:25: warning: variable ‘nmmh’ set but not used [-Wunused-but-set-variable] struct gsm48_mmxx_hdr *nmmh; ^ gsm48_mm.c: In function ‘gsm48_rcv_rr_sapi3’: gsm48_mm.c:3603:28: warning: variable ‘nmmh’ set but not used [-Wunused-but-set-variable] struct gsm48_mmxx_hdr *nmmh; ^ CC gsm48_rr.o gsm48_rr.c: In function ‘gsm48_rr_tx_rand_acc’: gsm48_rr.c:1668:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] LOGP(DRR, LOGL_INFO, "Use alternative tx-power %d (%d dBm)\n", ^ gsm48_rr.c:1668:3: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] gsm48_rr.c:1676:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] LOGP(DRR, LOGL_INFO, "Use MS-TXPWR-MAX-CCH power value " ^ gsm48_rr.c:1676:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] gsm48_rr.c:1683:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] LOGP(DRR, LOGL_INFO, "Use MS-TXPWR-MAX-CCH power value " ^ gsm48_rr.c:1683:4: warning: ‘gsm_arfcn2band’ is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] gsm48_rr.c: In function ‘gsm48_rr_tx_meas_rep’: gsm48_rr.c:2736:53: warning: variable ‘multi_rep’ set but not used [-Wunused-but-set-variable] uint8_t rep_ba = 0, rep_valid = 0, meas_valid = 0, multi_rep = 0; ^ gsm48_rr.c: At top level: gsm48_rr.c:813:13: warning: ‘start_rr_t3124’ defined but not used [-Wunused-function] static void start_rr_t3124(struct gsm48_rrlayer *rr, int sec, int micro) ^ CC mnccms.o CC settings.o CC subscriber.o subscriber.c: In function ‘gsm_subscr_generate_kc’: subscriber.c:947:4: warning: ‘comp128’ is deprecated (declared at /usr/local/include/osmocom/gsm/comp128.h:22): Use generic API from osmocom/crypt/auth.h instead [-Wdeprecated-declarations] comp128(set->test_ki, rand, sres, subscr->key); ^ CC support.o CC transaction.o CC vty_interface.o vty_interface.c: In function ‘ms_vty_init’: vty_interface.c:2840:2: warning: ‘install_default’ is deprecated (declared at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly with install_node() [-Wdeprecated-declarations] install_default(MS_NODE); ^ vty_interface.c:2885:2: warning: ‘install_default’ is deprecated (declared at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly with install_node() [-Wdeprecated-declarations] install_default(SUPPORT_NODE); ^ vty_interface.c:2943:2: warning: ‘install_default’ is deprecated (declared at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly with install_node() [-Wdeprecated-declarations] install_default(TESTSIM_NODE); ^ CC voice.o CC mncc_sock.o AR libmobile.a ar: `u' modifier ignored since `D' is the default (see `U') CC main.o main.c: In function ‘main’: main.c:220:2: warning: ‘msgb_set_talloc_ctx’ is deprecated (declared at /usr/local/include/osmocom/core/msgb.h:734): Use msgb_talloc_ctx_init() instead [-Wdeprecated-declarations] msgb_set_talloc_ctx(l23_ctx); ^ CC app_mobile.o app_mobile.c:376:2: warning: initialization from incompatible pointer type .go_parent_cb = ms_vty_go_parent, ^ app_mobile.c:376:2: warning: (near initialization for ‘vty_info.go_parent_cb’) CCLD mobile libmobile.a(gsm322.o): In function `memset': /usr/include/i386-linux-gnu/bits/string3.h:86: undefined reference to `__warn_memset_zero_len' collect2: error: ld returned 1 exit status Makefile:379: recipe for target 'mobile' failed make[3]: *** [mobile] Error 1 make[3]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src/mobile' Makefile:325: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src' Makefile:350: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23' Makefile:51: recipe for target 'layer23' failed make: *** [layer23] Error 2 What should i do ?

1 0

Transceiver problem
by Bilguun Tugs 17 May '19

17 May '19

How to make this command ? Im doing this article. Also installed all those libraries. But cannot build transceiver file. Im installed libosmo-dsp. https://www.smartspate.com/how-to-create-2g-network-at-your-own-home/ root@bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make install CCLD transceiver gmsk.o: In function `osmo_gmsk_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:85: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:87: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:123: undefined reference to `expf' gmsk.o: In function `osmo_gmsk_generate_rotation_tables': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:146: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference to `sqrtf' gmsk.o: In function `osmo_gmsk_modulate_burst': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:227: undefined reference to `osmo_cxvec_convolve' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:230: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_generate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:260: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:265: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:272: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_detect': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_demodulate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference to `osmo_cxvec_scale' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: undefined reference to `osmo_cxvec_delay' demod.o: In function `gsm_ab_ind_process': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:62: undefined reference to `osmo_cxvec_sig_normalize' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:70: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:76: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:101: undefined reference to `osmo_cxvec_free' collect2: error: ld returned 1 exit status Makefile:355: recipe for target 'transceiver' failed make: *** [transceiver] Error 1 What should i do ?

1 0

Transceiver error
by Bilguun Tugs 15 May '19

15 May '19

*cd /root/osmocom/trx/src/host/layer23/src/transceiver/* *./transceiver -a ARFCN -2 -r 99* *I want to write this command. But it didnt have any transceiver file on this. I write make command but it seems so many error* root@bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make CCLD transceiver gmsk.o: In function `osmo_gmsk_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:85: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:87: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:123: undefined reference to `expf' gmsk.o: In function `osmo_gmsk_generate_rotation_tables': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:146: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference to `sqrtf' gmsk.o: In function `osmo_gmsk_modulate_burst': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:227: undefined reference to `osmo_cxvec_convolve' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:230: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_generate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:260: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:265: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:272: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_detect': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_demodulate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference to `osmo_cxvec_scale' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: undefined reference to `osmo_cxvec_delay' demod.o: In function `gsm_ab_ind_process': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:62: undefined reference to `osmo_cxvec_sig_normalize' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:70: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:76: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:101: undefined reference to `osmo_cxvec_free' collect2: error: ld returned 1 exit status Makefile:355: recipe for target 'transceiver' failed make: *** [transceiver] Error 1 What should i do ?

2 2

Trx connection problem
by Bilguun Tugs 13 May '19

13 May '19

In this command there is something wrong. Im using motorola c118. Command : ./osmocon -m c123xor -p /dev/ttyUSB1 -s /tmp/osmocom l2 -c target/firmware/board/compal_e88/trx.highram.bin Received PROMPT2 from phone, starting download handle_write(): 39 bytes (39/39) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 42 B Received DOWNLOAD ACK from phone, your code is running now! Enabled Compal ramloader -> Calypso romloader chainloading mode Received ident ack from phone, sending parameter sequence opening file: No such file or directory what was the problem ?

2 2

Trx build problem
by Bilguun Tugs 09 May '19

09 May '19

*There is an error to make command.* make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src/mobile' make[3]: Entering directory '/home/bilguun/Desktop/trx/src/host/layer23/src' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src' make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src' make[2]: Entering directory '/home/bilguun/Desktop/trx/src/host/layer23' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23' make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23' make -C host/osmocon make[1]: Entering directory '/home/bilguun/Desktop/trx/src/host/osmocon' make all-am make[2]: Entering directory '/home/bilguun/Desktop/trx/src/host/osmocon' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/osmocon' make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/osmocon' make -C host/gsmmap make[1]: Entering directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make all-am make[2]: Entering directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make -C target/firmware CROSS_COMPILE=arm-elf- make[1]: Entering directory '/home/bilguun/Desktop/trx/src/target/firmware' LD board/compal_e88/hello_world.highram.elf arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) ../../shared/libosmocore/build-target/src/.libs/libosmocore.a: could not read symbols: File in wrong format Makefile.inc:135: recipe for target 'board/compal_e88/hello_world.highram.elf' failed make[1]: *** [board/compal_e88/hello_world.highram.elf] Error 1 make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/target/firmware' Makefile:57: recipe for target 'firmware' failed make: *** [firmware] Error 2 I cant build layer23. What should i do ? (OS UBUNTU 32 bit).

2 1

libdbdi-drivers error
by Bilguun Tugs 09 May '19

09 May '19

*cannot make those files.* *Error looks like* make[3]: Entering directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers/sqlite3' /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I/usr/local/include -DDBDIR=\"/usr/local/var/lib/libdbi/sqlite3\" -std=gnu99 -MT dbd_sqlite3.lo -MD -MP -MF .deps/dbd_sqlite3.Tpo -c -o dbd_sqlite3.lo dbd_sqlite3.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I/usr/local/include -DDBDIR=\"/usr/local/var/lib/libdbi/sqlite3\" -std=gnu99 -MT dbd_sqlite3.lo -MD -MP -MF .deps/dbd_sqlite3.Tpo -c dbd_sqlite3.c -fPIC -DPIC -o .libs/dbd_sqlite3.o dbd_sqlite3.c:316:5: error: conflicting types for ‘dbd_goto_row’ int dbd_goto_row(dbi_result_t *result, unsigned long long rowidx, unsigned long ^ In file included from dbd_sqlite3.c:58:0: /usr/local/include/dbi/dbd.h:41:5: note: previous declaration of ‘dbd_goto_row’ was here int dbd_goto_row(dbi_result_t *result, unsigned long long rowidx); ^ dbd_sqlite3.c: In function ‘dbd_list_dbs’: dbd_sqlite3.c:409:16: warning: implicit declaration of function ‘_dirent_buf_size’ [-Wimplicit-function-declaration] entry_size = _dirent_buf_size(dp); ^ dbd_sqlite3.c: In function ‘dbd_list_tables’: dbd_sqlite3.c:504:3: error: unknown type name ‘dbi_inst’ dbi_inst instance; ^ dbd_sqlite3.c:513:14: warning: implicit declaration of function ‘dbi_driver_get_instance’ [-Wimplicit-function-declaration] instance = dbi_driver_get_instance(dbi_conn_get_driver(conn)); ^ dbd_sqlite3.c:514:14: warning: implicit declaration of function ‘dbi_conn_new_r’ [-Wimplicit-function-declaration] tempconn = dbi_conn_new_r("sqlite3", instance); ^ dbd_sqlite3.c:514:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion] tempconn = dbi_conn_new_r("sqlite3", instance); ^ Makefile:502: recipe for target 'dbd_sqlite3.lo' failed make[3]: *** [dbd_sqlite3.lo] Error 1 make[3]: Leaving directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers/sqlite3' Makefile:404: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers' Makefile:455: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0' Makefile:385: recipe for target 'all' failed make: *** [all] Error 2 What should i do ?

2 2

Fwd: Problems
by Bilguun Tugs 08 May '19

08 May '19

I have these problems on make command. What should i do ? I'm using Ubuntu 16.04 32 bit

2 1

Silabs Aero II transceiver datasheet?
by Mychaela Falconia 28 Apr '19

28 Apr '19

Hello OBB gang, The Potential Calypso Targets page in your wiki lists a whole bunch of phones with Silabs Aero II (Si4210) RF transceivers: http://projects.osmocom.org/projects/baseband/wiki/PotentialCalypsoTargets I wonder, has anyone ever succeeded in finding a datasheet for this transceiver? I found the datasheet for the older Aero+ transceiver (a 3-chip solution), but not for the single-chip Aero II aka Si4210. Here are the Silabs Aero materials I have found so far: ftp://ftp.freecalypso.org/pub/GSM/Silabs/ I got the marketing briefs for Aero+ and for Aero II, and the full technical datasheet for the former of the two. If anyone has a datasheet for Si4210 and would be willing to share it, I will gladly add it to the above collection. In the interest of full disclosure, if I get a hold of this datasheet, adding it to the above FTP archive may be all that I will ever do with it: even if I had the datasheet, I do not currently have any realistic plans of adding Silabs Aero RF support to FreeCalypso, let alone to OBB. I do have a couple of Motorola W220 phones on their way to me from ebay, and hopefully at least one of them will actually make it to me, unlike the first one that appears to have fallen into a black hole somewhere, but even with ideal documentation (full schematics and chip datasheets), adding support for a very different RF subsystem (in particular, Silabs' way of doing AGC is entirely different from TI's way) would require more systems engineering work than I can do at the moment. It also doesn't help that the only tpudrv12.c reference TPU driver we have is a reconstructed source made from the disassembly of tpudrv12.obj, not TI's original source - thus all quarter-bit timing numbers (there are lots of them, and they are very critical) are just "magic" numbers, and their original derivation has been lost - does not bode well for the task of figuring out what the corresponding timings should be for a different RF transceiver. All that being said, however, this Si4210 transceiver does look like an attractive alternative to TI's Rita: the Si4210 is 5x5 mm compared to TI's 7x7 mm (every square mm counts in a tightly squeezed modem module), and it has 4 separate LNA inputs for the 4 GSM bands, to be contrasted with Rita and Aero+ arrangement of 3 LNA inputs, one of which is shared between EGSM and GSM850. The Si4210 way with 4 separate LNA inputs allows a fully quadband MS to be implemented in a much more straightforward way. Thus tracking down a datasheet for this Silabs Aero II transceiver and adding it to the knowledge base should be a good step for the GSM enthusiast community as a whole. I already tried asking Silabs for the datasheet, and got the answer that the product line in question was sold to NXP back in 2007. Reading up on Wikipedia, it appears that this stuff did not stay long with NXP either, transferred first to ST-NXP Wireless and then to ST-Ericsson, and when the latter closed, it is totally unclear where the Silabs Aero stuff went, other than the great bit bucket in the sky. :-( M~

1 1

Free board offer to OBB developer with a CMU200
by Mychaela Falconia 09 Apr '19

09 Apr '19

Hello again OBB folks, In light of my discovery two days ago through CMU200 testing that current OBB on all Calypso devices (with or without my OS#3582 patch) produces grossly incorrect (spec-violating) radio transmissions, I am making the following offer to your gang in the case that any of you are interested in doing the work to fix your software and bring its radio transmissions into compliance. The offer is: if there is anyone in this so-called "community" who (a) has a CMU200 instrument or is willing to invest into buying one and getting it properly calibrated, and (b) is willing to do the major work of bringing OBB's radio transmissions into compliance as verified with that CMU200 instrument, then I am willing to send that person a fully tested, fully working and properly calibrated FCDEV3B GSM MS board free of cost. To recap, the areas in which OBB's radio transmissions were found to be non-compliant in my CMU200 tests last Saturday are as follows: 1) At least in the test scenario when the CMU200 instrument acting as a BTS makes a call to the connected MS, OBB's implementation of GSM MS transmits at each band's maximum power level instead of the lower power level commanded by the CMU acting as the BTS. 2) When the CMU200 commands the connected MS to change its Tx power level, OBB's implementation of GSM MS does not act on these commands. 3) Even when the MS Tx power level is set to each band's maximum on the CMU200 before initiating the call to the MS and not changed afterward, the power ramp put out by OBB is flagged by the CMU as being out of tolerance - despite the OS#3582 patch which makes OBB use the same Tx ramp template bits as the official FreeCalypso and Motorola firmwares (I tested on both hw platforms), or FreeCalypso fw on Motorola's hw, all of which produce perfectly compliant power ramps as deemed by the CMU200. 4) Without the OS#3582 patch, not only the power ramp but also the power level itself is out of tolerance. I do not see how anyone could address these defects without having their own CMU200 instrument so they can reproduce the problem first, and see the same thing I am seeing, which is why I am limiting my FCDEV3B offer only to those who have a CMU200 or are willing to invest in one. Furthermore, I also know from first-hand experience that many CMU200 units that sell on ebay for cheap may be defective in very subtle and non-obvious ways, or may have been subjected to repairs or repair attempts in less than fully diligent ways. Therefore, unless you bought your CMU200 from a high-end seller who sells it with a recent calibration certificate and with all case seals from the calibration lab intact, the only way to know for sure if the instrument's measurements are trustworthy is to send it to your nearest Rohde&Schwarz office for calibration, which costs about $1400 at least at the Columbia, Maryland (USA) office, which is where I had mine calibrated. For the above reasons, I further limit my free-of-cost FCDEV3B offer to those who not just own a CMU200 instrument in some unknown condition, but are also able to present a recent calibration certificate for it. (And don't even think about faking one, as I know what real ones look like - I got my own.) You will also need to have an N-to-SMA RF cable with precisely known insertion loss at GSM frequencies (at the center frequency of each uplink and downlink band, 8 frequencies in total), i.e., you need to demonstrate sufficient RF knowledge to compute a good estimate for these insertion loss numbers if you don't have access to a VNA to measure them directly. (In case it isn't already obvious, let me spell it out: producing your own GSM MS implementation that is safe to use on public airwaves does require spending a non-trivial amount of money on proper test equipment.) If you have the necessary test equipment as above and are interested in getting a free-of-cost FCDEV3B, you will need to further agree to do the following upon receiving the board: 1) Connect the FCDEV3B to your CMU200 while the board still runs its official FreeCalypso fw, and confirm with your own eyes and your own CMU200 that all RF transmissions put out by the FreeCalypso hw+fw combo satisfy all of the compliance tests. 2) Run OBB on the same FCDEV3B still connected to your CMU200, and confirm with your own eyes and your own CMU200 that OBB's transmissions exhibit the same problems which I see in my test setup. 3) Work toward bringing OBB's RF transmissions into compliance as seen by the CMU200, i.e., toward being like what the official FreeCalypso fw puts out. The tests performed by the CMU200 are the exact same ones which are performed by official certification labs on candidate GSM MS devices submitted for type approval testing; I don't know exactly what equipment those labs use, but I wouldn't be surprised if it is the very same CMU200 at least for the low-level tests, plus something else (a real BTS maybe) for higher-level GSM L3 protocol tests. Aside from the just-detailed offer of a free-of-cost board to whoever is willing to do the above work and has the necessary setup, I am now restricting sales of FCDEV3B hardware to OBB users. If anyone is interested in buying an FCDEV3B for the purpose of running OBB on it, I will only sell it to you if you can demonstrate that you have one of the following 3 acceptable setups: Option 1: a CMU200 or some other instrument acting as a base station simulator; Option 2: your own BTS plus all of the numerous pieces which are required in order to connect an MS directly to a BTS with a cabled setup without any radiated transmissions; Option 3: your own BTS plus a solid RF-blocking enclosure (reliably blocking any leakage) that is big enough to fit both your BTS and your MS. If I were to sell a board to an OBB user who does not have any of the above, then I would be helping facilitate willful interference and disruption of public radio communication networks, and could potentially be held liable for whatever damage you will cause by letting OBB transmit on GSM frequencies in open air, so nope, sorry, won't do. And finally let me pre-emptively address one very likely response: if someone says "why don't you, Mychaela, do the work of bringing OBB's radio transmissions into compliance and contribute code patches, given that you already have all of the needed high-end test equipment", my answer is that this work can only be done by someone who believes that investing effort into further development of OsmocomBB is the right thing to do, which is a position I disagree with - instead I believe that OBB (or at least OBB on Calypso, no opinion regarding OBB on SDR or the floating-around vaporware idea of OBB on MTK) should be deprecated from use and retired to the dustbin of history as a failed project that may have been interesting and may have had some merit at one time, but is now completely pointless. Sincerely, Mychaela Falconia, Mother of FreeCalypso www.freecalypso.org

6 11

Re: OBB does not work against CMU200 BTS simulator
by craig 10 Mar '19

10 Mar '19

Oops, I accidentally replied to Mychaela directly, here's our conversation so far, please others join in with thoughts. On Sun, Mar 10, 2019 at 09:09:31AM -0800, Mychaela Falconia wrote: > Hi Craig, > > > Thanks again for your details Mychaela. I will read this very carefully > > and keep it in mind as I try to port osmocom-bb to fernvale/mediatek. > > I already expect a good dose of refactoring in layer1 so maybe I will touch > > on fixing the issue. > > Have you got yourself a CMU200 instrument or not yet? A CMU200 is > absolutely required if you wish to have any chance of success at your > idea of OBB on MTK. I do have a Racal Instruments 6103E GSM Digital Radio Test Set which seems to work well so far. I have tested some SIM800 modules (mtk6261) with the internal BTS. Not sure if that will fall short or not but I'll take things one step at a time. When I need a CMU200 I'll probably get one. :) > Another question: is there any way to run any official MTK-based > firmware, however non-free and blob-laden it may be, on Fernvale hw? Probably. I know from reading that Bunnie and Xobs who designed fernvale did run standard firmware/OS on some similar 6260 based devices. Maybe we could track down a good firmware and test on fernvale. For what it's worth the fernvale isn't exactly my main target. I would much rather use a SIM800 module or eventually design of my own. > Has anyone actually done it and posted howto instructions? If not, > then how do you know if the RF hw on your Fernvale kit is actually any > good and not physically defective? Whoever physically manufactured > those Fernvale boards sold by Sysmocom, have they actually tested > their RF hw and how? And what about calibration - have they performed > individual per-unit calibration of various RF parameters on those > Fernvale kits like every standard GSM MS hardware manufacturer is > required to? I don't have any clue about these details. Will have to rely on Harald or maybe inquire of Bunnie and Xobs. > I calibrate my FCDEV3B boards at production time, use > the calibration procedure to also serve as a test of the RF tract, and > ship every unit with turnkey-working official firmware and a fully > valid and legitimate IMEI, fully fit for operation as an MS on public > GSM networks - do they do likewise or not? If not, then they are > substandard. > > M~ Thanks for your efforts, Craig

2 1

OBB does not work against CMU200 BTS simulator
by Mychaela Falconia 10 Mar '19

10 Mar '19

Hello OsmocomBB gang, Earlier today I was trying to run OBB against my CMU200 GSM MS RF tester, with the objective of trying to determine if the change currently stalled in OS#3582 (switching the Tx APC code in OBB from the original to my modified version that uses the same numbers as each target's respective original fw, i.e., Compal's numbers on Mot C1xx or FreeCalypso numbers on the FCDEV3B) makes things better or worse on OBB's primary compal_e88 platform (Mot C118). Running OBB with Tx enabled on a Motorola phone that has its internal antenna connection fully intact is not only illegal (transmitting in the tightly regulated GSM bands from an unlicensed device) but actually dangerous and harmful: as my CMU200 experiments have confirmed, OBB's transmissions are so wildly out of spec that the risk of causing *actual* interference and disruption to cellular networks is very real. While I don't give a damn about silly laws that declare perfectly safe and harmless things to be illegal, I do very much care about not disrupting cellular networks which people actually use for important communication, including safety-of-life communication, hence letting OBB transmit on real live airwaves is a big no-no. Instead the *only* safe way to run a Tx-enabled build of OBB layer1 on a Mot C1xx or SE J100 phone is to insert an RF cable terminated with an appropriate probe adapter into the RF test port on the back of the phone, and connect this cable to your own test BTS or to a specialized GSM MS RF tester like R&S CMU200. Pull out the rubber plug that keeps dust out, and insert the appropriate adapter. I use a Hirose MS-147-HRMJ-1 adapter for old-style MS-147 RF test ports on C118 and C155/156 phones, and a Murata MXHS83QH3000 adapter for the newer style of RF test ports found on Mot C139/140, SE J100, Openmoko, Pirelli and most newer phones. Both adapters are from Digi-Key, and both are still readily and cheaply available there. Both adapters convert the RF test port to SMA, and unlike the other SMA to MS-147 pigtail sold by Sysmocom, neither of my adapters requires any disassembly of the phone case - just pull out the rubber plug. The critical point here is that when you insert a probe into that RF test port under the rubber cover, the internal antenna is disconnected. Because I do not currently have my own sysmoBTS (at least not yet, may be able to afford one in another couple of months) and I have no interest in messing with SDR devices or trying to make a poor man's BTS out of one, the only thing to which I can connect GSM MS devices under test is my R&S CMU200 instrument. This instrument is generally considered to be the gold standard in the mainstream professional (non-FOSS) GSM industry, and I use it all the time to test not only my own FreeCalypso devices, but also various pre-existing ones, and they don't have to be TI-based or have hackable firmware. The CMU200 does have a so-called non-signalling mode that allows low-level Rx and Tx operations to be tested directly, and this mode of operation does require GSM MS firmware with special RF test modes that bypass all higher layers of the protocol stack - but the CMU200 instrument also has a "signalling" mode in which it acts as a standard BTS, allowing any MS to be tested as a black box. This signalling mode of the CMU200 works with every GSM MS in my experience (with FreeCalypso, with Motorola's original fw on all C1xx phones, and with various other phones with completely unknown chipsets and firmware architectures) with the exception of OBB. At first I had no success with getting OBB to play nice with the CMU200 at all: I would turn on the simulated BTS downlink signal on the CMU, run OBB's mobile app, and it would register to the test network - but as soon as I press the "Connect mobile" (call to MS) button on the CMU, everything would go haywire. However, after a lot of trial and error I figured out where at least some of the breakage is happening: 1) In order for the "call to MS" operation to succeed, the MS Tx power level setting on the CMU200 (i.e., the power level which the CMU acting as a BTS directs the MS to transmit at) must be set to each band's respective maximum (PCL 5 for low bands or PCL 0 for high bands), which is not the default setting. If one tries to make a call-to-MS from the CMU with the MS Tx power level set to something lower, it works just fine with every type-approved or would-pass-approval-if-someone- paid-for-it GSM MS including FreeCalypso and Mot original fw, but if one tries the same thing with OBB, a message pops up on the CMU200 screen saying "Overload at connector RF2", mobile's vty window says "% Call has been released", and everything breaks from there onward. At first I was totally bewildered as to how CMU200's input could possibly be overloaded when the RF2 port in question is rated for 33 dBm continuous power, the PA on my FCDEV3B or on Mot C1xx phones cannot put out anything more than 30 dBm in the DCS/PCS high bands, and my cable has about 2.2 dB of attenuation which I account for in my calibration and test procedures - an overload sounds physically impossible in this setup. But then I realized what is happening: because the CMU200 expects the MS to transmit at the power level instructed by the CMU acting as the BTS, the instrument software configures its sophisticated Rx chain for optimal reception at power levels around that target. What appears to be happening with OBB as the MS is that OBB does not implement Tx power control correctly, and transmits at the maximum power level even when the BTS told it to transmit at some much lower level. The CMU does not expect such gross misbehaviour from candidate MS devices submitted for type approval testing, and some stage in the configured Rx chain gets overloaded. Next experiment: I established a call between OBB and the CMU200 by setting the MS Tx power level knob to the maximum for the band I am testing in, and then tried changing it within the active call, i.e., had the CMU acting as the BTS command the MS to change its Tx power level while staying in dedicated mode. I am not sure if this signalling happens over FACCH or SACCH, but once again it works without a hitch with every type-approved or would-pass-approval phone I have available for testing, and I use this method all the time to verify the complete range of Tx power levels on the MS under test. Not so with OBB: I don't remember the exact error message displayed by the CMU200, but it was something along the lines of the MS failing to act on the Tx power level change command, and then it would drop the call. So apparently OBB fails to implement this aspect of the spec as well. So what about the OS#3582 change? Does it make things better or worse? Answer: I was unable to test it because the other show-stopping defects in OBB's GSM MS implementation prevent me from getting that far. The combination of the two bugs above (no ability to establish the call unless the MS Tx power level is set to max, and no ability to change the power level within the test call) makes it impossible to step through the power levels and see what the mobile puts out at each PCL, hence no ability to test the change. There also appears to be something wrong with OBB's timing of various steps involved in burst transmission, i.e., Calypso TPU programming. I say so because even if I stay at the band's maximum power level (don't try to change it), the CMU200 reports the power ramp as being out of tolerance, even with my OS#3582 patch which makes the actual ramp programming exactly the same as what each device's official fw uses to produce perfectly passing ramps - so it is probably something to do with timing. OK, so why did I produce this OS#3582 patch if it doesn't make things any better in practice because of other major bugs elsewhere? The answer is that it was my knee-jerk reaction to seeing hard-coded numbers for Tx power levels and ramps and for the VCXO slope that are completely and obviously wrong for Openmoko/FCDEV3B hardware. The hard-coded Tx power level and VCXO slope numbers in the current OBB master are approximately correct (at least within the ballpark of correctness) for Mot C11x/12x/155/156, but are NOT correct even for Mot C139/140 (different PA with different characteristics), and are wildly off-base for the completely different Openmoko/FCDEV3B RF hw - someone claimed Openmoko gta0x as "supported" all those years ago without anyone doing any real tests on that platform, and without noticing the utter bogosity. What was happening is that people were asking about running OBB on FCDEV3B hardware, I was trying to support those people in the hope that they would buy the hardware at the fair commercial price (which hasn't happened), it was obvious to me from a very cursory glance at the code that the stuff in current master has exactly zero chance of working anywhere close to correctly on my hw given those totally wrong hard-coded numbers, so I felt that at that very minimum, I had to fix those bogus numbers. Trying to fix just the numbers while keeping the architecture of the code that uses them was also a non-starter (more utter bogosity like trying to use GSM900 band APC numbers for all bands), so I did the only thing that seemed sensible: ripped that gunk out and replaced it with Tx parameter tables in the chip vendor's original format, filled with bits read from factory RF calibration records. But as today's experiments show, it was pretty much for nothing: while you do need to apply this patch if you wish to have any chance of ever putting out spec-compliant radio transmissions, it is nowhere close to being sufficient. The *only* way how OBB would ever reach a point of being safe to use as a GSM MS on live airwaves and being able to seriously compete with properly functioning, spec-compliant GSM MS products like FreeCalypso or Qualcomm/MTK/etc phones running their respective official fw would be if someone were to invest many, many person-years into it, and also invest their own money into appropriate test equipment - a CMU200 or equivalent is an absolute must, otherwise you have no way of knowing what your MS really puts out. And I will *not* *ever* be that person who invests her time and energy into whipping OBB into something that could kinda-sorta approach what MTK, Spreadtrum and FreeCalypso (have I missed any other GSM chipset vendors? I don't count Qualcomm as they hate GSM and give it the "unwanted bastard child" level of support) already provide today, with at least one of the listed vendors freely publishing their full source code. Meanwhile, the takeaway lesson is that running current OBB with Tx enabled on a Motorola phone without disconnecting its internal antenna is NOT safe, and the danger of interference to GSM or other cellular networks is way too high. People on this list swear up and down that no one uses OBB as a phone, instead people who call themselves "researchers" supposedly use it in their test setups somehow. But how exactly? I somehow doubt that most of you so-called "researchers" have expensive Faraday cages or go to the trouble of a fully cabled setup (lots of extra components required: duplexer, attenuators, multiple cables, adapters for connecting to RF test ports on phones) with no radiated transmissions. It seems far more likely to me that most of you so-called "researchers" probably operate your SDR-acting- as-a-BTS in open air, with the downlink signal power level set low enough so you don't get caught despite having no actual license, and your OBB phone transmits back to your home-grown BTS via open air. What I am here to tell you is that doing the above is NOT as safe as you think: if OBB is transmitting at the maximum power level the phone can put out, which is 2 W in the GSM900 band, if the power control is not working (OBB does not lower its Tx power when the BTS tells it to) and the power ramp is wrong for whatever reason (the CMU200 shows it as being out of tolerance), then only Cthulhu knows what kind of interference you may be putting out. My greatest hope is that some day more people will see the light and do the right thing: retire OBB to the dustbin of history as a project that may have been interesting once upon a time but is absolutely NOT worth doing any more work on in the present reality, and redirect their forces to more productive efforts. I am convinced that it would take far less work to reimplement the researcher-oriented functionality of OBB on top of the rock-solid FreeCalypso code base than to bring OBB to a point of being able to compete on technical merit. M~

1 0

Google Summer of Code 2019
by Vadim Yanitskiy 26 Feb '19

26 Feb '19

Dear Osmocom community, starting from 16th of January (until 7th of February) we can apply Google Summer of Code as an Open source mentor organization. Many well-known projects, such as Debian, FFmpeg, Apache, Git, GCC, GNURadio and others, have been participating last year. Personally, I think it's a great opportunity to move some of our projects forward. I would like to know your opinions about this idea, should we participate? I would be happy to be a mentor. With best regards, Vadim Yanitskiy.

3 3

Scaling up virtual bts tests for the BTS test - how I hold it wrong?
by Holger Freyther 22 Jan '19

22 Jan '19

After a lot of work[1] the gsm tester can finally: * Start a virtual bts * Mobile/virtphy processes * Complete LUs for 10 MS. The next step (besides having a proper test verdict) is scaling this beyond what a simple physical set-up can provide. Let's go to 100+ BTS and 10k subscribers but somehow I am still holding it wrongly and would like to have feedback to see how to evolve the gsm tester. What do I need to change to scale this up and how to externally parameterize it? * suite.conf: Add one line per virtual bts to reserve (I would prefer to specify type+num) * resources.prod.conf: Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs. * register_default_mass.py: I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable. What's missing: * High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is. * ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool. * IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers. * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change). Any idea or comment on how to achieve this? cheers holger [1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile but getting the GSM tester to spawn the network and we are unfortunately not done yet.

2 5

Re: I have a problem compiling osmocombb in Ubuntu 14.04
by Vadim Yanitskiy 21 Jan '19

21 Jan '19

> It is the same version of libosmocore that comes with osmocombb. https://osmocom.org/projects/baseband/wiki/Software_Getting_Started#Depende… > For osmocomBB, as for several other osmocom projects, you will also need libosmocore. > Note: Although libosmocore is included when getting osmocom-bb from the git repository, > you have to install it separately. The libosmocore subtree is only used to compile the > embedded ARM version of libosmocore. With best regards, Vadim Yanitskiy.

2 5

I have a problem compiling osmocombb in Ubuntu 14.04
by Andi Kita 21 Jan '19

21 Jan '19

sched_clck.o: In function `sched_clck_tick': /home/imsicatcher/osmocom-bb/src/host/trxcon/sched_clck.c:64: undefined reference to `osmo_clock_gettime' sched_clck.o: In function `sched_clck_handle': /home/imsicatcher/osmocom-bb/src/host/trxcon/sched_clck.c:123: undefined reference to `osmo_clock_gettime' Any help is appreciated. Thank you

2 1

Fwd: OSMOCOM-BB HandOver
by Muhammad Awais Aslam 12 Jan '19

12 Jan '19

Hi, We have been working on the handover feature in OsmocomBB and have managed to make some progress including SB/BSIC detection in dedicated mode which was not previously being successfully done in firmware. I wanted to share it and seek guidance on the last bit of handover implementation on which we are stuck. I hope someone would be able to help us or make use of our work. We took code related to handover from the osmocom-bb jolly branch by manually adding/deleting stuff in the master branch as updating to the latest copy was giving us issues. We added code from the “Safely change TPU offset on TS change or sync change” commit till the “Use only sel_si for information about the current cell” commit. Using the handover code in the jolly branch and after making the changes explained below we were able to obtain the handover command from the BTS. The synchronized handover case works sometimes though still not every time, however the non-synchronized case doesn't work at all as we are not able to get the physical information command from the new cell. I'll explain the changes/additions we made to achieve this. Firstly, we noted that in dedicated mode SB burst was not being detected. Changes were required at three main places in order to correctly perform FB/SB detection: - It was seen that the results for SB were being read from DSP API location dsp_api.db_r->a_sch which is for the idle mode. The results had to be read from the dsp_api.ndb->a_sch26 location for the dedicated case if TCH_SB_DSP_TASK is used. - After reading the FB we needed to update the quarter-bit offset of the TPU using the TOA of the FB to sync it with the start of frame of the neighbour cell in order to catch the SB (by changing the vaule of l1s.tpu_offset using the TOA of the FB). - Frequency compensation needed to be performed using the afc_correct function before reading the SB. * We actually kind of cheated a bit by adding 3 frames to the original idle frame in order to give us more time to perform FB/SB detection including the synchronizations mentioned above. This was because we weren't that proficient with the code and someone with more understanding could do this better. The call did not get dropped. We used the initial added “idle” frame to perform the quarter-bit and frequency compensation which was reversed in the idle frame with the response function to tune back to the serving cell. These things, when added to the code did the trick and BSIC of the neighbours was obtained. Once the BSICs were decoded the measurement report sent to the BTS became meaningful and the handover command was received. Upon receiving handover command, access bursts needed to be sent on the new channel which again was not currently being implemented properly as in order to tune to the new cell we needed to know its quarter-bit offset for start of frame, frequency compensation and absolute frame number which were not previously being obtained. Now that we were able to detect FB and SB these values were stored for the neighbours following detection of these bursts and were used to tune to a neighbour cell in case of a handover to it before the sending of access bursts. However, here is where we are stuck. We were expecting a physical information message following the access bursts but were not able to receive it due to which the handover failed. If only that could be achieved we believe handover should be successful. Either we are not syncing properly to the new cell or we might not be following GSM protocol properly. We also might not be reading the FACCH properly for physical information message after tuning to the new cell as we couldn't really understand that bit very well. We wanted someone expertise on this matter and were hoping our work could be of use. We were more interested in getting the work done first up. Best Regards, M. Awais Aslam

3 3

How osmocom-bb(mobile app) display non-english character SMS
by dechaoforever 07 Jan '19

07 Jan '19

Hi ALL. Last weekend I compiled osmocom-bb and now I can send English SMS from one peer to another by using its app 'mobile'. But how to make it possible if I want to send SMS including non-English character, like below. 你好こんにちは 안녕하세요. สวัสดี I will be appreciated if you can help me. ----------------- from dechao

2 1

OsmoDevCon 2019 registration
by Harald Welte 31 Dec '18

31 Dec '18

Dear fellow Osmocom developers, I'm a bit surprised to notice that not more people have signed up for OsmoDevCon 2019. I guess it was mostly an oversight when the date was originally announced, and not a lack of interest? ;) All details about the event are available at the related wiki page at: https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2019. 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

Motorola C118 online buy
by Babar Ali 30 Dec '18

30 Dec '18

Hi list I want to buy Motorola C118, from china, please share store link Regards Babar Ali

3 4

Loading HelloWorld firmware in Motorolla C118
by haiderali91 28 Dec '18

28 Dec '18

Hello, I am trying to load helloworld firmware into my phone (Motorolla C118) using sysmocom CP2102-25 cable by executing the following command sudo ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/hello_world.compalram.bin But I am not getting any response on pressing power button briefly. The command keeps on executing without any message. What can be the issue and how to deal with/debug this issue. I have also attached a cu terminal by using following command. $ sudo cu -l /dev/ttyUSB0 -s 115200 The cu terminal displays this message on pressing power button. ��A@ftmtoolerror

2 4

MT6260 Datasheet available
by Craig Comstock 19 Dec '18

19 Dec '18

Hi all, Somoene shared what looks like a quite useful datasheet for MT6260 at the kosagi/fernvale forum. I have downloaded it and looked a bit and it looks very helpful. I have linked to it in the wiki at: https://osmocom.org/projects/baseband/wiki/MT6260 Original post at kosagi forum: https://www.kosagi.com/forums/viewtopic.php?pid=3313#p3313 I hope to rejoin my effort on porting layer1 firmware to fernvale in about 1 month. Cheers, Craig

1 0

sms_request and clone sim function on mobile app on osmocombb
by Bastien Baranoff 14 Dec '18

14 Dec '18

hello video <https://www.youtube.com/watch?v=A5l8YCCYxrc&list=PLZGHrECD8YM9bcoY3gnb4r39k…> where you see sms_request function and Virtual machine <https://static.ptsecurity.com/phdays/2015/ctf_mobile.7z> with clone function from this link <http://blog.ptsecurity.com/2015/07/the-mitm-mobile-contest-gsm-network.html> could tell which branche does provide these function? Thank you

1 0

Re: Voice calls over Virtual Um
by Vadim Yanitskiy 27 Nov '18

27 Nov '18

Hello Andreas, sorry for late response. > I set up a network with Virtual Um and multiple OsmocomBB > phones. They register, they can send and receive SMS > and I wanted to try voice calls. First of all, it should be noted that voice support in OsmocomBB is experimental and undocumented. I have been working on GAPK back-end integration, and it seems you've already found some branch, but I would recommend to use 'fixeria/audio' instead of 'fixeria/mncc'. > calls can be established, but GAPK is never initialized and > again, I never see voice data appearing as an MNCC message. Please check out the configuration examples [1] for mobile app. There you should find the new 'audio' section, where: io-target hardware means that audio I/O (by default) should be handled by the hardware (i.e. by Calypso phone). GAPK is not enabled by default. In order to use GAPK based back-end, use 'gapk': io-target gapk It probably makes sense to rename 'gapk' to 'alsa', because at the moment 'gapk' enables both voice playback and capture using the audio system of the host that running mobile. > I never seem to receive a GSM_TCHF_FRAME-message on > the MNCC socket. This can also be configured: io-target socket In this case GAPK is not used, and all TCH frames are being forwarded to the MNCC handler 'as-is'. See [2] commit description for details. Please also note that audio I/O target != MNCC handler, that actually implements the Call Control logic. See [3] for details. [1] https://git.osmocom.org/osmocom-bb/tree/doc/examples/mobile/default.cfg?h=f… [2] https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=bdb2854503afd… [3] https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=22edbf3f846b1… With best regards, Vadim Yanitskiy.

1 0

Voice calls over Virtual Um
by Andreas Galauner 20 Nov '18

20 Nov '18

Hi, I set up a network with Virtual Um and multiple OsmocomBB phones. They register, they can send and receive SMS and I wanted to try voice calls. I looked around and found a repository [1] with an MNCC example application which sends voice samples. Calls are established and can be picked up, but on the other end, but I never seem to receive a GSM_TCHF_FRAME-message on the MNCC socket. I then checked out the fixeria/mncc branch [2] which includes GAPK integration which can use ALSA devices for audio, because that's what I need anyway at some point for my project I'm working on. Again, calls can be established, but GAPK is never initialized and again, I never see voice data appearing as an MNCC message. The GAPK audio backend is supposed to be initialized [3] when a CHANNEL MODE MODIFY message is received from the network. I never see the network request a channel mode modify though. I don't know enough about GSM to find out if that message is always supposed to be sent when a call is established or not. Did anybody ever transport audio with two OsmocomBB instances over the Virtual Um interface? Thanks, - Andy [1]: https://github.com/GerardPinto/call-control-mncc-sap [2]: https://git.osmocom.org/osmocom-bb/log/?h=fixeria/mncc [3]: https://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/gsm48_r…

1 0

no GSMTAP-Header-Remover in Gnuradio
by Thomas Baach 17 Oct '18

17 Oct '18

2 1

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 16 Oct '18

16 Oct '18

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - 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)

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel